 Hello, hope you had some good lunch and ready for the next two presentations, actually. So the next thing we'll do is a bit of a special thing. It's kind of an experiment, it's kind of an idea that we had in the track chairs. So I'm the track chair of site building and case studies for DrupalCon Amsterdam. So together with my colleagues of the other tracks, we decided which sessions that we'll actually present. And I can tell you it's super hard because we get ten times more sessions of missions that we actually have slots. So what we already knew from the beginning is that there will be a lot of modules about Drupal 8 country modules because all the maintainers, they're heavily working already on porting their modules. So we said, okay, let's put it down and beside of like actually using a lot of spaces. We do one session, which is a double session, which is a country status update. So what will happen exactly? Because we cannot have everybody present at the same time. So we have eight presenters and they're actually the module maintainers. So we didn't spare any time to contact all of them, to find the time. They all have time during DrupalCon. I can tell you that's super hard. So they're all sitting here now, which is super cool. And they will present us some of the most used modules. Drupal 8 modules, 11 modules, the most used current Drupal 7 modules. So they most probably will also be really heavy used Drupal 8 modules. And they will tell about the status. Each of them will take 12 minutes, so it's really short. And it's about what is the plan for Drupal 8? Are there any changes or the adaptions? What is the current status? And of course, we're an open source community. So is there anything that you can help? There are a lot of different modules. They have different ideas, what they need. So they will tell you how they need help. There's a short Q&A. We have two microphones left and right. So if you have a question, please get up and walk there. So we have it on audio and we don't lose too much time. And we have like three to four minutes of Q&A per module. If they're a bit faster, we have even more. So if you have a question, ask it. If it's way too long, the people will be here all week. So you can ask them later and you can discuss that. There will be a 15-minute break. So because I said it's a double session, so we'll do some break. And you will get the full update on Drupal 8 Contrib. So if you walk out here, you will know which module is ready and when you can start to build your Drupal sites. So we start with the first one, that's Drupal 8 Rules. And the presentation will be done by Josef and we need to change that. Cool. So hello, everybody. This presentation is about rules in Drupal 8. And I'm not really the maintainer of the rules module, nor I'm the creator. But we are a whole team, so Fago. He's the rules creator. There's Clausi on the team who is the commentator. We have Nico Greenauer who provides design and I'm responsible for all the other stuff. What is the rules module? So we have a new logo and we like it because we can create custom workflows based on events, conditions, and actions. So it's very useful, for example, to send customized emails that the site builders can actually go into the site and configure small workflows or even set up bigger workflows like redirections, system messages, breadcrumbs. It's very useful and it has a lot of integration. So it's based on the entity API. It integrates with the whole Drupal commerce ecosystem. We use bulk operations, for example. And this is because of a great architecture. So the entities, they expose the metadata that the rules module then can interact with, which is either provided by Drupal Core or any other module. And the success that we have seen makes it happen that it's used on every fifth Drupal site, so more than 250,000 installations. We have hundreds of integration modules available and this is just a few examples of them. So yeah, this is rules from Drupal 5, basically, to Drupal 7, and it has been a great success story. And then there was always the big question mark, what are we going to do for Drupal 8? Because the maintainers, they are pretty busy working on Drupal Core, running their own companies, and lots of other stuff. So our predictions were like, it's going to be hard, but we have lots of great ideas. So what you can expect for rules in Drupal 8 under the hood is all the best practices that you can see in Drupal 8, like Evolv developer experience, object orientation, all the new patterns, service-oriented architecture, and so on. It's obviously based on the plugin system, on the Drupal 8 plugin system now, and it's based on entities and the new type data thing that you will all deal with in Drupal 8 as a developer. And another great thing for the developers or even for administrators will be, we will be able to deploy configuration or the rules configuration via the configuration management initiative via CMI. So that made us all, like, looking forward to it. And we also want to, like, be aware about getting off the island. It's also integrating better with other systems. So we want to provide more reusable components and work with the others in the community. For example, the context API should be shared with Drupal Core and Page Manager so that we do not have contextual systems duplicated, but we combine the efforts. Also, tokens. We have to provide tokens, of course, similar to entity tokens in Drupal 7, so they are automatically exposed via the type data. Then, if you're not working with fields, but you want to have widgets for any data and formators for any data, you can use the type data widgets and formators. And then finally, the whole rules UI components, they should be, we should be able to integrate them separately. So we can have actions and conditions or the rules data selector. So when we talk about actions and conditions, I could, for example, extend the block configuration user interface and add the possibility to add conditions in the block's UI. So the site builder could just go into the block's UI and do, like, Page Manager selection rules based on the rules UI components so that we felt like that would be cool. And the data selector, as you know it in Drupal 7, wouldn't it be nice to use it like, for example, for tokens or just any other system in Drupal? It doesn't really have to be tight or a dependency of the rules module. So cool. Finally, not all of us are into coding, so the site builders, what can they expect? So the administrative user interface should all leverage the best practices and the UI patterns that we have in Drupal 8. There is views bulk operations in a simplified versioning course. We can also leverage that to execute rules actions or rules components. And finally, I'm very fascinated about this idea. We don't know how it will look like in the UI, but we'll basically get rid of the rules conditional, rule set, all of the complicated stuff and just allow to nest rules inside the other. So inline rules will allow us to build stuff in a more efficient way. Yeah. So can we have it now? We thought it would be nice to have it now or as early as possible, and this is why we came up with the idea, how can we do fundraising? So we did a Kickstarter-like campaign on Drupal funders. And we also did corporate funding. And now basically, as you can see on the slide, we have basically financed the first milestone. So the whole project is budgeted for 1,000 of hours of work. And we have sponsors and the community funders do that. And we were pretty successful at that. So we raised in total about 18,000 euros. But to go to the very end, we need 48,000 in total. So it's still a long way to go. And how did we do that? Well, we were happy to find all these companies, supporters, and we are still looking for more. And we did so via the Drupal funders campaign. We produced some cool rulers that you still can get. And we also run sprints on various events in order to already get coding. So we're not just trying to get funds, but we're also spending the money already. And we're developing all on GitHub using the pull request workflows. So it's all shiny and a very cool experience. For new contributors, you can join us on the sprints. So the current development focus is on porting actions. So this is great for newcomers because it's like very individual tasks that allow you to get into the system, but you do not have to be an expert at all. On the other hand, we are working on Drupal 8 core integration for the context system and basically finishing the whole milestone one. As an overview, milestone one is almost done and it has also been funded. And we are still looking for funds to complete milestones two and three, but we mainly focus on development right now because we do not want always to ask for money without doing something. So milestone two should be finished by the end of the year if we get the funds, if not, it's probably delayed. And then by the beginning of the next year, we should be able to ship the whole rules modular at least until Drupal 8 is going to be shipped. Yeah, that's like the status update from my side. You can meet us at 1 p.m. on Thursday for an extended buff where you can answer even more questions, but I'm very happy to take some right now. There's also be a whole sprint day on Friday where we focus on porting the actions and fixing all the stuff that is left for milestone one and would be happy to get all of you developers or just any feedback, yeah. Cool. Do we have any questions about rules? No? I got one. Will it be translatable out of the box like messages and stuff? So because we use CMI, we can also translate it. Yay for reasonable content. Okay, cool. So if somebody wants to support you with money, who should they contact? So, basically, you go to the DEAT rules website and we have a contact formula where you just fill in all your data and we will get back to you as soon as possible to get the money. Yeah. Or just hit me up on the conference. We have produced, for the Kickstarter campaign, we have produced those rules and they were really popular. So if you have donated to the project and haven't received your ruler yet, please come to me and I will make sure that you're served. And one ruler, basically, is one hour of development. So the agencies, Epico, and Stronomics agreed on 45 euros per hour, which is basically them covering the self-cost in Vienna. So they are not making any money anymore, but they allow the developers Fago and Clausi, who are like top developers, to work on the DEAT rules port in the company time. So if you want to fund an hour of DEAT rules work, you can get the ruler for 50 euro, which basically includes the ruler plus the one hour of work. Cool. Yes. And I think rules is a bit a special case because a lot of automodules depending on it. So that's why... So if you, for example, cannot decide about money in your company, but go to the DEAT rules, there's a really cool video where people, a lot of other automodules maintainer explain why they need rules to run their own modules. And that's why also rules is really important to be early finished. So to be before we actually, I don't know, do you plan on a release candidate as well, like when DEAT has a release candidate or so? Yeah. We have not really talked about release candidates, but we'll do something. It's just really good to have it already out before other modules start using it because they depend on it. Yeah, in order... Because if rules would not be ported early, then we would not have... The other models would have to wait with their integrations, and we really want to fix that. For example, we also have ideas around symphony events, so that could really be important for the whole ecosystem when they are possible to integrate with events and all that stuff in an easy way as early as possible. Okay, good. If there are no more questions, thank you, Josef, and we go to the next one. All right, the rulers, and there are some stickers. So the next module is panels. Check it out. Hello. Okay, so it's sort of intimidating coming after rules because we are way less prepared. So, panels... Combining forces for good. So panels, as some of you may know, is a fairly monolithic module, and it comes with... Well, it doesn't come with, but it depends on seat tools, another somewhat monolithic module. And the process basically is to get rid of that and make panels do what it does well and have it not do anything else. And so one of those, or a few of those issues here, we're working on Page Manager by Tim Plunkett. Basically, Page Manager is being moved out of panels, and then it's all going to go into this own module. So as soon as that module is out, we'll be building on top of that. There was discussion about what's going to happen with the layout module. So Display Suite and other display modules using layouts are going to be needing to combine forces, and that's sort of what we want to do because right now we have our own layouts in panels D7, and we want to change that. So it's right now in Contrib, and I think it'll stay that way for a while. So we need to get that done. And then we're looking at using Frega's layout plugin, which we'll use to power panels. And then we're working on the remaining C-Tools features. With any luck, C-Tools will no longer exist in D8, but we'll see. We've ripped out a lot, but there is a lot in there, so we'll see. So a few things that we... The main process right now is we need to get a layout variant, and actually this was... David Snowpeck has been doing a lot of work in this arena, and he's been doing a lot, basically most of the porting on the panel's side. So he's made a panel's layout variant, and it worked. And then D8 sort of upgraded itself a little bit, and now it doesn't work, but we're working on fixing it up. So we did have a proof of concept, and that part is at the 85% side. Once that's done, we're going to go ahead and plug in. So these are the two major components of panels. And then, lastly, work on a migration pass, so you can go from the D7 panel's page manager into D8. As far as everything else in panels, we're trying to keep it as similar to D7 as far as what the end user sees. So you're not going to see a whole lot of new features, probably from panels quite yet. We're trying to try to offload everything, like use the core context system, and everything else that core is now providing. We want to get out of panels. And see tools. So, like I said, does panels layout, someone had to have kittens. Do they work? Yeah, it did, but it doesn't at the moment. However, you can join us and try to help us. And if you ping David, myself, Tim Plunkett, you'll probably get a response. Oh, Eclipse GC. So Chris Vandewater has also been doing a bunch of work on this. And there's a few others that I don't have off top of my head. But we also have a weekly update meeting we do in IRC. Right now, we're looking for a better meeting time. So if you sign up on there, on the doodle, because unlike some other modules, we're still pretty preliminary in where we're going here with panels. And then, of course, the issue queue we'll be working on basically all the style plugin and the layout plugin will be in there as meta issues, and then we'll go through the various parts there. So that's about it for panels. Any questions? All right, thanks. I have one, I have one, I have one. Yes. There are a lot of modules around panels that add additional features, like panelizer, panels everywhere. Are there any plans in that area? So I don't know how they're doing on those panels, but all I know is that we're not right now planning to bring it in to panels. At least right now, the idea is to be really a straightforward, because we want to get panels out as soon as possible, and we feel like the more things we add to it, the longer it'll take. And for the people which I tried Pageminature already out, and it looks kind of already like panels, so will then panels depend on Pageminature? Correct. And from the UI, what else will it bring? Because there's already quite a lot of stuff. So it'll bring the display variants, the rule selections, not rules, but basically trying to figure out what's going on, so that's the part that will go on top of Pageminature. Cool. I think I see one more. I have a question. You almost gave the answer, but still I'd like to answer the question usability. I know it has to be built, it has to be changed, but what do you need to make it happen, to make better usability experience for the panels module? So that's a great question. As in the panels, the D7 panels this morning and admittedly is a pretty horrible UI, but it's very powerful. There has been talk, but we don't have any funding yet to work on panels, so it's pretty much take the D7 version and D8, make it D8. So I'm hoping that there'll be work in that realm and we could totally use volunteers or other help in that spot. Hopefully, I know it's not the answer you want here, but I'd love to give you the better one. Yeah. Is there still something like Spark to play? Yeah, so the Spark initiative it's going and panels is not really a part, I mean it's sort of a part of it, but we haven't really been working on it too much. My guess is that as D8 matures, there will be more initiative from those resources to help work on the UX components and potentially panels will be part of that. So we don't only need coders, if you are interested in usability, also talk to these guys because panels use a lot and I can say from my own experience that like for people who should never use it before, it's really hard, but it's super powerful. If you're interested in helping, definitely talk to the guys and find them around. There's a few of us around, but most of the D8 people are not here, but if you find Chris, myself, I don't think Damien McKenna is here, but yeah, and Tim isn't here. So find either one of us and we can sort of help steer in the right direction. Cool, thank you. Next one up is media. So we have Dave and Yannis. Thank you for being here. All right. Hi, everyone. My name is Dave Reed and I'm Yannis. And we're going to give a quick update on what's happening in the state of Drupal 8 media. And I want to say panels, you're not alone in this situation. So, yeah, the media module, it's great, but there's been a lot of minor issues or major issues, WYSIWYG integration, maybe it doesn't work properly sometimes or all the time. So we wanted to make sure that we really look forward going into Drupal 8, fixing these issues from the ground up, not really porting, but rewriting from scratch, especially since we had other modules like Skald come in the picture that provided an alternate viewpoint to do things. We wanted to make sure that we collaborated with those teams too. So that's kind of where our vision is going. We're kind of joining forces with these teams and working on some common components. And what can I go through these components with you right now? Yeah, so first component that we're working on is called Entity Browser. It's, if you are familiar with media it's how the widget for selecting and uploading media works in 7. It's similar, but it's made in a more general way so it can be used with any entity type. And it's more pluggable so it's more extensible. And it can be used in different contexts. It's not suitable only for media, but you can use it just to power an entity reference field for notes and bringing related articles and stuff like that. Entity Browser is still in very early stage of development so we can only show a mock. But if you go to the project page there are a few issues open and there is also a discussion about architecture where we go more into detail and you're invited to join us. Second component is one of two storage components that we're planning to build. It's called MediaEntity and if you're familiar with FileEntity in the 7 it works in a bit different way. It works similar to how Scout works. It doesn't use files for everything. Instead of that it creates a new entity type that is then used to actually store your media. And as a result of that it's not necessarily it's not necessary to store everything in FileManageTable. It works heavily with fields. Basically the idea behind this that you store everything is like standard field API fields and then you have plugins that provide you some business logic or validation or metadata that works with your media type. Let's say you have a YouTube video you just use a text field where you can paste your URL in and then you have a plugin that validates this and it provides you text description that can be fetched from YouTube API and things like that. It's basically already working this so you can try to contest it and there is an example plugin for YouTube videos that you could look into and play with it. Another major component the entity browser that was mentioned before is one of our big parts that we're collaborating on. The embedding portion is the other big part that we're collaborating on. This is where you actually put something in your WYSIWYG. We want to make sure we get this nailed down right. I'm really happy to say that we started this new project called Entity Embed. We had a really great summer of code student as evidenced by me wearing my summer of code shirt and so we're solving all these kind of embedding problems and it's going so well. This is pretty much almost complete. You can have multiple buttons, one for embedding content, one for embedding files, one for embedding users if you want to do that. You can have multiple buttons. It works for all those entity types out of the box with no additional code. The really cool thing is that it reuses the concept of field formatters that were introduced in Drupal 7. For instance, if you're embedding a file or an image, you can reuse file and image formatters to display your output. Like here in our screenshot, this is an image, a field formatter. It's not necessarily attached to a field, it's a file entity. You can pick how you want to display it and provide options and actually provide alternate options. You can see that it's in the screen. It all just works all together. Once you submit this form, it's all serialized into one HTML attribute that uses data attributes, HTML5 attributes. It's all encapsulated in one nice HTML tag, doesn't use special markup, doesn't use special tokens. It just uses HTML and works. The other cool thing is that it also doesn't use any code. If you have an entity, it makes sure to embed the UUID of that entity in the HTML tag so that when you deploy your site to production or something, it won't and if your entity IDs change, but your unique ID should not change, it will still keep working out of the box. This is a great one to check out. I know some people are actually just using this module in production now, they're crazy, but I love them. This is totally usable right now. It only just maybe breaks when Drupal 8 updates, that's all. We're doing our best to keep it up to date. Shanden is our Google Summer Code student. Shanden is cs underscore shadow. If you see him on IRC, say hi. He's done a really great job. After we developed this entity embed module, I realized that a lot of the stuff that we're doing can be reused for things that are not entities. If I want to embed a YouTube video and configure how I want it displayed with height and width, it's kind of the same principle. Or if I want to embed a field from the same entity, it's kind of the same principle. I want to pick which field and how to display it. We're probably going to be expanding this concept a little bit more with this. An entity embed will be one version that kind of supports that. There may be a URL embed for your kind of remote media and YouTube vimeo, that kind of stuff. Field embedding, short code for like just kind of you put in something and it gets output of something else. It's a WordPress thing. We want to make sure we support it. So there's going to be more coming there. And so media entity was mentioned before. File entity is the other kind of storage solution for how we refer to media or files. It's a big module in Drupal 7 and we do still plan on porting it. It's been started a port right now. But we haven't worked on it too much. And we want to abstract it a little bit more. File entity does so much right now. It exposes the UIs for listing, adding, editing, deleting your files. It makes them fieldable. You can have different file types. You can have audio files, video files. It does a lot of work on one. So we maybe want to split it up a little bit. Maybe it's just we expose the UI first. That's just what people like out of the box. And if you want fields on your files, you can enable that extra too. But you don't have to have that out of the box. So let's split that up a little bit more. Another interesting module that we've worked on is called fallback formatter. So for any kind of field that has more than one formatter available, you get this fallback formatter. And it says, well, okay, try the default formatter for this field. And if it doesn't return anything, then go try the trimmed formatter and see if that returns something. And if that does return, show that. So it's just a way to provide multiple options. If you are familiar with file entity in Drupal 7, it kind of has this concept, but for managing file display. And we wanted to abstract it out. So this is kind of a nice way. Like if you had a formatter for audio tag or video tag, and you had a file field that accepted both audio and video, this is the way to make it display for both things. You could say, hey, first try the video formatter. And if it didn't work, display as an audio field. And it'll support both things then in the same field. And we also introduced some other small things. File image formatters was a small thing I wrote that lets you use image field formatters for your file fields. If you upload images in a file field, you can't output them as an image style. So we wanted to fix that. So that's a nice little reusable thing. And we also want to write a formatter module for an entity reference field that lets you output only a specific field on that referenced entity in a certain formatter. So just making sure there's lots of options available. And so kind of the big question then is what happens with the media module itself or the Skald module? These were these large modules that we used to do things. Hopefully now that we split all these things up, we're going to have a lot more dependencies, but we're in control of those. And it should be a lot more easier to just be like exporting some default configuration to this module and maybe a little bit of glue code to make sure we bring all together and it all works really nicely together. So like media will ship with its own entity browser configuration and an entity embed button configuration so that's the plan for those. We haven't really gotten started with that since we're focused on the components. And if you would like to come help, we have a weekly IRC meeting in the Pound Drupal-Media channel. We'd love to have you join us there. We do most of our primary development on GitHub in the Drupal-Media organization now, but we automatically put that back to Drupal.org when we're done with code too. We have a Drupal group that we're going to be at the sprint on Friday. So any questions? It was just too good, okay. So I kind of see the thing happening with, again, that they've read their own 20% of your modules because you've split up media and there are a lot of modules again. Yeah, it's just a secret ploy for me to be able to write more modules. That's the goal, yeah. Okay, cool. Yeah, one question, like the whole embed is that depending on CK Editor or CK Editor, it's not going to be easy. So the entity embed stuff, since it's Drupal-8 and Drupal-8 ships with CK Editor by default, that's what we integrate with by default. I'm not sure how it's going to shape out with Drupal-8 and alternative WYSIWYG editors, but it's theoretical it should support those as well. It hasn't really happened yet. So, okay. Yeah, in the background, it works with text filters. You can see that we've manually entered the correct HTML tag and it should be translated. So, you don't need WYSIWYG to actually embed stuff. Okay. And another question, maybe that's a political one, but there was once a discussion about Drupal Media in core as an initiative. So, it looks like that's all now not, or can you tell us anything about that? As far as we know, there's no official Drees We've kind of taken it on as our team to do our best with pushing us forward and organizing ourselves. We would welcome an official initiative. I've kind of told Dreeze that. So we'll see if it happens. And it's totally possible, like this stuff could be added in Drupal 8.1 or 8.2 down the road too. So that's not out of the option as well. Okay. Yeah, and there were some improvements in the eight. We can now finally upload multiple files in one step. We have a file listing that is there by default. So when you upload things into image or file fields, you get a listing, which is a view, and you can change it of course. And you can embed images into WizzWik by default just with core. So we only need to handle embedding for other types of media. Okay, cool. There is a question. Yeah, I was just wondering. The rules module had an estimate of getting it ready end of 2014, maybe beginning 2015. Do you have an estimate when you think media will be ported? I will just say when it's done, because we don't have any funding and it's all volunteer basis right now. So people fund them. Yeah, we will accept funding, yes. And we can probably, I mean, we've already finished one major component with entity embed. So we're making a good progress. I would hope that we have a usable set of stuff by the time Drupal 8's released. So. I think that's the same with rules. It's like the web evolves. We have more and more media. We have more and more embeds from other sites. But I think that's definitely something we can focus on. Yeah, I mean, we're kind of trying to solve some really hard problems with embedding and the entity selections. It's like, these are modules that have at least 10 different solutions right now in Drupal 7. So like, as soon as we can get these out and workable now, we can get more people using them and have them be like the officially sanctioned one, which I think will be a lot of progress in moving that forward into core. So yeah. Cool, okay, good. Thank you. Thanks. So will you do it? I don't care. You can do. Okay, next one, search API. Hello, I'm Thomas Seidel aka DrunkMonkey and I'm the maintainer of the search API module. So I'm gonna talk about it's a Drupal 8 version now. Regarding the changes compared to Drupal 7, love is still in discussion. So if you're interested, please look at that meta issue and find child issues, create your own and just discuss with us in what direction we should take this Drupal 8 port. One decision we have already made is that the basic architecture will remain unchanged. So if you've used search API in the past, you still have search servers, search indexes, much of the same configuration in both and creating searches on the indexes. But we focused on a lot of the problems we spotted in the Drupal 7 version. A lot of them relating to flexibility, just problems that we really didn't think of when creating the search API in the first place and then which turned out to be pretty hard to solve in Drupal 7 with the fixed architecture. So we're doing a lot there to improve the Drupal 8 version to be able to solve all these problems more cleanly, which we identified in Drupal 7. And on the other hand, user experience because usability was also pretty poor, or at least especially for new users. And a lot of them had problems just figuring out how to come up with the basic search and what each setting means. And there were a lot of issues regarding wrong configurations, so we also tried to solve that in Drupal 8 by providing better guidance to users. So going a bit into detail about flexibility improvements, one large improvement there is that search indexes will now not be restricted to a single item type. So previously in Drupal 7, you could only have index with nodes or with user profiles or with whatever else. But now in Drupal 8, you can just create one index which has all the item types you need in searches. And with that, you have vastly better support of creating a unified site search, which is something that a lot of people need but was very hard to do in Drupal 7. So I think that's one of the really great improvements in Drupal 8. Then under the hood, we've just made a lot of more components pluggable. So things that were previously hard coded can now be swapped out for specific use cases and also things that weren't previously configurable are configurable now. For example, here we have the item types on the index can be configured more. So when you say you want an index to contain nodes, then you can right away say which content type should be indexed from the nodes. And this is also something a lot of people requested in Drupal 7 and was hard to solve there. So this is also now possible much more cleanly and should also provide great improvement for a lot of sites. Regarding user experience, there was just a lot of work done on the user interface is just making all the pages more cleaner and easier to use, easier to understand. Of course, also leveraging all the core improvements here. We're talking about revising some of the terminology and already did it so that we better convey the meaning behind some of the special terms used in the search API also to hopefully help new users to understand what we mean with the different terms and components. Something that we've planned is doing a simplified user interface. And I'd really love to see that. So that's if you're a new user, you can just, you have just no access right away to the advanced user interface as we have it now and just maybe a simple wizard for setting up a search with which it was default value, sensible default values for the more complex settings and just allows you to basically do, configure a few searches and only then allows you to switch on the advanced user interface if you have really a use case for that need to configure it more but otherwise hide the complexity for new users. And of course, we also plan to support the tour module which is now in core, which should hopefully also help new users get started. So that sounds all good. How are we doing with that? Well, a lot of the existing functionality from the framework itself is ported or really all of it. But other than a few back ends, so database backend and solar are also ported and we've had a Google some of code student work on elastic search. And a bit of diffusion, the creation is already finished but not much more regarding country modules. So there's still a lot of work to do and a lot of the improvements we've already planned to do in the Troop 8 version need to be implemented as well. So we're still pretty far from, while it is already usable and I've heard just yesterday that someone is using it on production with 20,000 nodes, lunatic. But yeah, so it's very much usable already but there's still a lot of way to go until we even get an alpha or then even a release. We are working the whole week here at TroopCon on it and we are also having a fair session tomorrow at 10.45. So if you want to hear just some more detail, provide your own opinion and discuss things then please also come there. And yeah, otherwise, if you're interested in search API and interested in seeing its Troop 8 version soon, then there are many ways to help with that. First off, of course, if you're a developer then we're sure to have some tasks for your level. Even if you're new to the search API, it's a great way to get started because we'll explain things to you and then get you started with some easy tasks and yeah, it's great for getting your feeling of the search API code. In Amsterdam, you can find us in the Coal Launch. Otherwise contact us, we have an IRC channel where we are discussing things and also weekly hangout meeting. Otherwise, if you're not a programmer, you're still welcome to join the discussions and the issues. Just provide your own opinions, your own use cases, your own problems with the search API in Troop 7, what we could improve and make easier to do in Troop 8. And finally, especially for companies, if you're using the search API and are planning to use its Troop 8 version, I assume it would be really great to get some funding because currently we are almost completely unfunded and especially for me, it's getting hard to get enough working time to bring this forward and keep the momentum and also getting funding for sprints is always a great way to push the project forward. So if you want to do that then please contact me and we're sure to find some way how you can contribute in a way that makes sense to you. Thank you. Questions already? Yeah, just go to the microphone. You have time. Hi. I read some discussions about Apache Solar in the Troop 8. You were talking about the search API based model but about the Apache Solar model and the search API Solar integration, they are merging. What exactly will happen? Exactly. So what will happen is basically that there will only be a search API based Solar module in Troop 8. We'll merge the two modules and support all the use cases that either of them supported in Troop 7 with the new search API Solar module. So this is also, of course, a great improvement for users who were previously confused with the two modules on which of those should be used and we'll just try to make one kickass Solar module in Troop 8 that is the best for everyone. So... What about... Go ahead. No, go. So about backends. We have talked about Solar. Is there other backends available? Yeah, database backend is also already ported and working quite well and elastic search was partially ported. I don't know about the other modules but I don't think any of those have started porting yet. But of course, I expect that most of those that are available in Troop 7 will also be available in Troop 8 at some point. And finally, what about the facets? Um, Brampe Goffins is coming up soon and he is already... No, we don't know yet. But we're probably discussing that tomorrow too. So if you have about two months free time and no facet API then please we'll be eternally grateful and otherwise, yeah, we'll just figure out what to do with that. What about multilingual search? Sorry? What about multilingual search? Oh, um, yeah, so since, uh... Uh... translations are pretty... pretty well supported in Troop 8 Core now. We figured that this needs to be supported in search API 2. So, um, what you had previously with the search API entity translations module is now completely baked into the search API framework already. So, by default, you'll have all of the translations of entities indexed right away. You can search through them based on the language and we'll also plan to support that way better in Solar 2 in some way so that if you have a multilingual site, the Solar settings will make sense, uh, there too. Great. Good. I got one question. Um, so there will still be search in Troop 8 Core. Um, when I enable search API, will it automatically replace it or will the URLs change? How is the idea there? Um, the, uh... I think the approach here will be the same as in Troop 7. It will more or less ignore core search, so you should probably disable it if you're using search API, but there is no plans on doing some automatic replacement or some integration there. Good. Thank you. Thanks. Thanks, Thomas. So, I think... And I actually think he mentioned a really interesting point. So, if you are currently using Troop 7 modules and you have a really big pain point with search API or whatever other modules, go to the maintainers and talk to them. Um, because most of the stuff anyway has to be rewritten, so, uh, why not write it in a better way? So, I think if you have any idea of any modules, talk to these people right now is the time because probably in a year, for the next three years, there will be no upgrade anymore and you will be stuck with that functionality. So, now is the time to talk to the people and convince them whether to be here or not, however you want to do that, and to change the functionality. Good. The next one, before we make a short break, is commerce. Oh, yeah. Thank you. Thank you. Okay. So, I'm Bon Jovanovich, and I'm the development lead for commerce to the techs. I work for commerce guys and I'm paced to work on Drupal commerce full-time. Three years ago, we released commerce 1.0 back at DrupalCon London and in that time, we have reached almost 50,000 live installs. And the reason why commerce became so popular is because we built it from scratch on the new technologies that Troop 7 gave us. And by doing that, we became immediately familiar to anyone who was already familiar with Troop 7 itself. We were then able to take these concepts and push it further in ways that later became standard, for example, by using views for admin listings. So, in order to replicate that success, we must once again start from scratch completely and build something new for Troop 8 and the completely new technologies that it itself brings. So, we are starting from scratch. We are taking into account every single angry comment you ever posted to the commerce issue queue. Any feedback we might have received or experiences we had dealing with our own projects. And, of course, one of the big themes of Troop 8 is getting off the island. So, we found a boat of our own and we are doing the same. And we are doing that by taking the core Troopal commerce functionality and releasing it as completely separate standalone PHP components. Because when you think about it, currencies and prices and taxes and addressing and payments and so much more, none of this is specifically tied to Troopal. And even if we use entities for data storage and other Troopal APIs, that doesn't mean that there is no separate core. So, that's why we've started developing the libraries and that has been our primary focus which is how long we've been developing all this. So, the first library that we've created is called internationalization and it significantly improves on currency handling and currency formatting. Back with commerce 1.x we shipped with a completely static currency list which was not good because it had holes and it got deprecated or outdated pretty quickly because currencies change or inflation eats the subunits. We also tied formatting to the currency itself which meant that one currency could only have one set of formatting rules. Rules such as where does the symbol go and which grouping and decimal separators do we use and so on. And when you look at my numbers, when you look at three different euro amounts, you will realize that they are all different. The first one is how it will look in France, the second one is how it looks in Germany and the third one is how it looks in the UK. So, we realized that this time around we needed to do currency formatting per locale. So, ideally we wanted to have a way to automatically generate the currency list and to automatically gather the formatting information and we managed to find that in the CLDR project. So, the CLDR project is a repository of data that's assembled by Apple and Google and Microsoft and other big players. It's used pretty much everywhere. And we use it for currencies. So, it gives us a set of all currencies in the world and it gives us translations for 250 locales which is pretty much every single language and country you can think of. So, that means that for every country for every locale we have the translated currency name and even the translated currency symbol and the formatting data for all of those countries which is really something and on the Drupal side we import the currencies into config entities and automatically create translations for all of the languages that you have defined on your site and when you add a new language we will automatically import the translations for that as well. So, we use that to create a really great number formatter that replicates what the PHP internationalization extension does. We couldn't depend on it because it's not present but we managed to replicate it using the data found here and so we even support cases such as Arabic or Hindu numerals. So, if you're doing an Arabic site they really expect the prices to be shown using their own numbers that wasn't possible before it's possible now. So, all things considered we are significantly better equipped to handle multilingual and multi-market websites. So, we have the internationalization which limited itself only to English but since we published this they expressed a desire to change that so by symphony 2.7 all of this functionality will be in symphony itself which is a really nice example of cross-project collaboration and it's been our first success. The second library we made is called addressing. We previously had address field which was pretty okay but the problem was that it didn't have predefined formats for many countries so things such as which fields are used how are they required how is the zip code formatted, what are the subdivisions for example US states that are used all of that data needed to be collected manually and because of that we didn't have support for that many countries out of the box. However, Google has created a great new data set in the meantime that they use for Android and since it's freely available we are actually parsing that and including it in our library so that means that for commerce to attacks we have predefined address formats for 200 countries and we have predefined subdivisions for 40 countries including their translations and we use that data to generate the address forms to generate the shipping slips and everything else that needs to be done and once again address field pulls in this library, defines the config entities which hold the data and then uses that to generate the triple forms and this library has also been very successful for us in the sense that we've been trending on github as the most popular repository for a few days the new week came around so that's now gone we enjoyed our five minutes so those were the first two libraries and now at triplecon we are focusing on releasing the second two the first one introduces the concept of zones so you can define for example a zone that's called the European Union has a set of countries or a zone that's called Germany and France or a zone that's called German VAT so for example German VAT is used in Germany and five Austrian zip codes so you can define that and the point of this is to define the zones that are used for taxes or shipping and use it to significantly decrease the number of conditions that you need to have in a rule or a hook to do your own thing so it really simplifies those use cases that's the first one the second one that we are building is called tax and this is our most ambitious one to significantly improve the commerce support for taxes especially bringing in the improvements that we've had in modules such as commerce VAT and commerce EUVAT so this module will have predefined tax rates for all of Europe, for Canada, for Australia whatever we can gather there's no external source for this so we're going to have to do it ourselves and then we're going to optimize for all of the common use cases for example selling digital products shipable ones Canada taxes which can be added together and have some different rules for determining the place of supply and so on in general our taxes requirements are twice more complex than they were in WandaTex and we are really looking forward to making this easier on you by handling the tricky parts ourselves so we made all of these cool libraries but you came here to hear about the module the module is being developed on GitHub primarily because we are using Travis the build bot to run our own tests and Drupal.org bots don't support Composer so that's why we needed to go to GitHub and we really enjoy pull requests so that we will keep using GitHub up until we reach a beta early next year and by that time we should be ready to get back to Drupal.org and we are mirroring all of the commits so you can go there and send the pull request we are still using the Drupal.org issue queue so if you want to start working on a task this week you can go to our normal Drupal.org issue queue and start looking at that the future is bright and we have many many plans so for example we are killing the concept of product displays you now only have products and the products can exist in a hierarchy if you want so you can see an example of one where you have a hierarchy that's based on colors and sizes we are also looking into completely recreating the payment API to be more powerful and to make payment modules much much easier to implement we are looking into the OmniPay library as a base for this effort but I'm not yet sure how that will turn out, we'll see I'm definitely interested though I really want to credit all of the awesome contributors that we've had in the previous two months and while they can still fit on one slide of course so Yale Becker has had 26 commits added to commerce Pedro Cumbra 10 and these guys have commits that have more than 3000 lines of code usually so even the number itself is not the most impressive thing Josh Taylor has had 10 claimants 6 Andy Giles 1 David Kitchen 1 so we've had all six very persistent non-commerce guys contributors working day by day on making commerce to a tax a reality and I'm really thrilled to see that and I'm hoping that the number of them will increase more and more so you can install commerce today you can create a product list it you can create a product list of all the amazing things and the reason why we are making so much progress is because of them if you have any questions we have above tomorrow at 1045 Emerald Lounge I'm really looking forward to hearing all of your stories use cases frustration so we can make sure we do it right this time so whatever you have to discuss then is a great moment so 3 p.m. GMT plus 2 which is most of Europe come to IRC and start discussing or grab an issue we will be happy to guide you and we have issues of all sizes from two hours to two months choose your poison and that's it for me any questions about commerce yeah we've heard with rules that rules is not yet ready but should be for a lot of content modules based on rules such as commerce so where is commerce regarding not those architectural founding things but really usable being a usable module I would say early 2015 at best I'm aiming to have a release around middle 2015 and we'll see how that goes and whether a beta happens in February or April it's really too early to tell but we are doing monthly blog post updates that should provide a better estimate as we go along I was curious since you're moving toward components to know if you consider Cilius as a possible project to kind of use or collaborate with we've had a lot of contact with Cilius they're great guys hoping that they will actually use our addressing code and we've also been in contact with the Sonata guys who are also interested in our taxes so there will be collaboration I'm not yet sure who will take what Cilius doesn't really have reusable components at the moment they're very basic but we are actively talking with them and to them about changing that is there going to be better support in the roadmap in Drupal 8 for two-way marketplace in commerce? Yes, we now have a commerce store entity by default that should allow us that and it should provide a very good basis for a marketplace module we still don't know how much function will be in commerce itself but definitely more than there was before I really like that you try to get off the island and I'm curious obviously as the rules guys, we are interested in what is your take on the functionality that you currently implement using rules are you planning to do that with rules or like maybe something else? Yeah, so from a developer standpoint I would say rules is more of a nice to have but from a site builder standpoint it's definitely a must have we are working on being able to use commerce without rules at the moment but I'm really following rules development closely and we will then see my current plan is to just emit events by default and have rules be one of the listeners allowing people to use or not use rules as they choose but assuming that most people will still want to use rules. Okay, that's cool. Thanks, Boyan. So we are actually a bit ahead of time so I think what we can do we do the next three parts and then we are actually probably finished before the next session starts so we won't even use the two sessions so in case you want to see the next one which only starts in half an hour you can still do that and we do now display suites, then we have simple news and actually four more modules all in one token redirect and all these things but now display suites. Hi. So display suites so we have a small team working on display suites on Drupal 7 and before we start off, Svendol, he started the module a few years ago Drupal 6 and he's still doing some work on it on Drupal 8 now. My name is Bram, I'm a Spelicious I started working on the Drupal 7 module as part of my internship with Crimson now Wunderkraut and at the moment I'm mainly focused on the Drupal 8 support and I built most part of it with Chris, he's the guy that suffers the Drupal 7 Drupal 6 suffers from the Drupal 6 port so he maintains it but he's not going to add new features he's just fixing critical bugs if they occur and then you have others that just made small patches that we committed I love those people by the way so when we started with port for Drupal 8, we didn't want to change a lot in the user interface because after the rebuild, the 7.2 rebuild we got some nice comments from people that they liked the new interface and we planned to keep it for Drupal 8 so the main focus for us was rebuilding the display suite on the new architecture of Drupal 8 but keep the UI as simple as possible but as this is a side builder track I'm going to focus on the things that has changed for example but most people know the PHP code field you could inject PHP from the UI by just entering some lines say I wanted on the nodes on that bundle and then you had some nice injected PHP in your display as we all know this is good why because it's fast it's fast snippets and you don't need a module but the evil part is way more important it's not secure it's not secure and it's misused a lot I have many bug reports in the issue queue about people that doing crazy stuff with that code field and Drupal 8 decided to remove the PHP filter from core so did we so we removed the PHP filter field some may hate me, some may love me now but I don't care but we replaced it with a token field so it's the same functionality as the Drupal 7 code field but without the PHP part to make up with the people that hate me now I rebuilt the DS fields functions I made them plugins for developers to implement a plugin and it's also easier for new people to learn how they have to build the DS fields themselves there's Drush integration if it works at the moment because everything is broken at the moment but it worked last week and then you can just say Drush create DS fields and then it creates a class for you to implement the render methods so that's almost as easy as going to the field and do some dirty hacks in there the torus will follow when the part is done and when I have more time so a new feature I added it was mainly as a joke at first time but it can be really handy is a copy of a display suite field so I made a display suite field that can copy a display suite field so you can have two times the same fields on your display without having two functions that point to the same code it's kind of awesome but at the moment it's only limited to display suite fields it would be better if we also could copy normal fields of other stuff so you can have like one code function and we use, put some settings in it and it does other stuff but yeah, I need some help with other field types because it's really complicated and you get into loops and stuff like that some may know the dynamic field it was based on Ctools magic in Drupal 7 as there is no Ctools yet in Drupal 8 and maybe there will not be Ctools in Drupal 8 so there is no replacements in Drupal 8 yet so if you use this feature a lot please tell me so I know there is interested in so I know there is interested in the feature so I can see if I can do something about it but I'm not sure if there will be a dynamic field in Drupal 8 so we have like three field types now we have the block fields and the create a copy of the display suite field those are pluggable this means that anyone can create their own type of pluggable UI fields you can extend my base class so you don't have to implement the entire form it's pretty easy and there will be tutorials how you can do that for developers so sidebuilders if you can't do it yourself just push your developer and say I need this, I need this thank you and then we have a comparison between the Drupal 7 and Drupal 8 layout UI interface it's kind of similar except the view mode step that was visible in Drupal 7 is disappeared from the Drupal 8 version why? there are no more view modes, no it's not true they are still alive but they are moved to core so we don't have to maintain that code anymore then we have the field templates there was a feature that's almost the most popular feature of display suites and there was the famous expert field template I think I have more than 20 issue reports or feature requests that want to extend the expert field template because it's not expert enough I'm sick of it so I decided to feature freeze the template in Drupal 7 this is now in dev and I'm not going to add any more features to it but for Drupal 8 I made the templates pluggable so everyone can add new field templates by implementing 3 days ago but it's broken now so I'll fix it like a lot of stuff I'm going to fix this week but you can try it so like I said there are no big UI changes this is pretty much the same as before the thing that has changed in the back end is that the templates are converted to WIC another team expert so I can use some teamer to review the templates and optimize where needed so what is the current status of display suites it was functional last week core changes fast 80% of the work is already done so please, please, please give it a try in the near future but do not use it in production yet I got several mails this week from people that are trying to use it in production we will rewrite the storage of display suites that's the 20% that has to be done so all your settings will be lost when you use it in production so this is a new version of display suites just a note I'm going to put like a big warning on the project page so are there other layout modules ready apparently panels is busy but it will not be finished before mid-2050 I don't know display suites will be done before the end of the year I promise that but if core changes in 2015 and after we do my work that's not my problem just to be sure so you can contribute first of all you can code you can help us find bugs you can help us fix bugs if you have a new feature you can build it if I think it's usable for everyone with some nice extra I can make a link on the display suites page to link to your module so others can find it I don't have a lot of time to work on display suites so if there are people that need a stable display suites like before November then you have to pay me sorry if you wanted before 2015 I'll do it for free so if you want specific features just talk to me and we'll see what I can do so that's it for me any questions? when the panels guys were on stage they said they were still wondering how to tackle the layouts because in Drupal 7 they were based on C2 you could use panels layouts in display suite and vice versa I've noticed you have already finished the layouts so how did you go about it? that's a very good question this is just a straight board from the display suites layouts in Drupal 7 I started to to try make reusable layouts but it's very very very hard I had several discussions with several people how to do it at the moment there isn't a solution yet so I just made my solution when we figure something out we will combine them it will not break your settings or stuff like that but just to be sure I just ported the Drupal 7 layouts I hope we can figure something out with panels if not we can use separate layouts for panels and display suites and maybe I can include some panel layouts with some tweaks and vice versa but I hope we can manage to combine them thank you the next one sounds a bit spooky it's Berdier so we figured out there are a lot of smaller modules that we all use in Drupal 8 and Drupal 7 so that's redirect, global redirect and Tosh will say ok, I'm going to do a presentation about all of them and give you a short update of them ok yes, so I guess you know those modules and use them on your sites so I'm not going to talk much about what they do redirect allows you to create redirect from one site to from one URL to another for example it's mostly used when you pause auto and change your note title to make sure that the old links still work global redirect allows to set up some settings and then for example make sure that you are always on URL alias so when you go to note slash 7 it redirects you to the right alias the token module adds two things and one it adds a lot more tokens than Drupal Core has like tokens for fields and menus and a lot more and it has a token UI that allows you to set up rules on how to automatically create aliases for your news for example or other types of content so about me my name is Sascha Rosenbacher my Drupal username is Berrier I work at Amdi Systems in Switzerland I'm a core contributor and entity field I play maintainer and I'm not a maintainer of any of those modules but I'm involved in Drupal 8 country ports and including those so about the changes there are a lot of API changes and core changed a lot so redirect and pass out had to change a lot and the way they have to integrate in the core changed a lot and they're being updated improved and rewritten in Drupal 8 ways for example using services instead of functions so that certain parts can be replaced if you don't like how it works however the look and feel the user interface is mostly the same most of those user interfaces have just been ported directly from Drupal 7 how they work in Drupal 7 so the status in general all of those modules are kind of working they have functional ports not all features are there yet but I'm keeping them up and running whenever I can so starting with global redirect as I said the basic functionality is working you can enable it and set it up enable the options you want and it's going to do those redirects it's already on Drupal org so if you want to try it out go to the project page and give it a try there are some issues with language prefixes so if you have a multilingual site be careful there have been issues in Drupal 7 and there are new issues in Drupal 8 that we haven't figured out yet how to fix and there's a topic that always has been the idea to merge them merge the module into redirect that did not happen yet but it's still an option for Drupal 8 I think so this doesn't look quite up to date need to get back to this the redirect module so again it's basically working it's integrated into PassAuto and the manual UI for creating redirects is there you can set up your redirects as you were used to it in Drupal 7 it's currently on our GitHub repository so you can get it from there there are a few things missing for example we're not using views for the UIs so the UIs are currently very old they have no paging, no filtering and all that stuff that you use from Drupal 7 that's not yet there we will add that when we switch to using views for the UIs and there are some additional features and some of those various alter hooks and extension points are not there yet so that's how the module looks at the moment in Drupal 8 there's the user interface for adding redirect you can enter that you want to get redirected to where you want to redirect to that's basically most of the user interface you can see in this module and then you have the token module as I said it has two functions one is providing a ton of additional tokens that Drupal code doesn't have like for fields for menus and complicated tokens or extend flexible tokens like combining stuff into combining arrays and splitting them into strings and so on so a lot of those are working and can be used already they often break because they're deeply integrated into core APIs so every time those parts slightly change then it falls apart but I'm trying to keep it up to date and fixing those things the field tokens are very limited at the moment so if you want to show up a user interface you can use them but they don't have any references yet and you can't control the properties and view them in a different way you just get the default output for those field values basically this is also on a GitHub repository at the moment you can get it from there and try it out the second part of the module is the token UI that I tried to get in Drupal Core that didn't happen yet so it has to stay in the module for now it has been slightly updated to use the new jQuery UI that's now in Drupal Core and the new displays and then you overlay stuff there but other than that there weren't many changes there's quite a lot to do in that module improving the tokens adding more test coverage so we know when things break and adding more tokens and so on and then you have the last one of those modules oh I forgot some of those screenshots moved around that's how the user interface looks at the moment there's that well known you can embed it directly into the page or you can have that pop-up and that's how that pop-up looks at the moment so you get your tokens go into that table and click down and select the token you want it has the same problems and limitations as it has in Drupal 7 like it explodes when you have a lot of fields that has making it more Drupal 8 like so removing the hooks for integration and instead using plugins to make it easier to extend to make it more flexible so that certain entity types can have certain logic in there and don't need to hard-code things like logic for turns in the core module that's how the UI looks at the moment it's basically the same as in Drupal 7 you get those patterns that you can fill out for each node type language for each node type and so on and you can also see the token UI embedded here this is a slide that's more oriented at developers so in Drupal 7 you had to write a lot of code to integrate it as a new entity type you had to write implement different hooks, you had to call pass auto functions and define stuff and in Drupal 8 it's building on top of fields and widgets so in Drupal core the pass user interface is now a field that has a widget so we basically just replace that with a user's where it doesn't have any integration core that's more or less all the code you need to integrate it and then you get the widget on the manage form display page and you get that user interface where you can enter a manual alias or use the one that's generated for you I don't have many plans at the moment, myself as I mentioned there's the idea to merge redirect and globedect together hopefully that will happen would be one less module you need to download and care about on every side and as I mentioned Kim Pepper is working on making on converting pass auto to plugins and making it more flexible if you want to help there are some known issues in core, for example the language prefix stuff that I mentioned last time I talked about this topic I had another core issue in here about pass aliases and how they change and how Contrib is able to react to changes there has been some improvements there yet so I was able to remove that topic from this slide which is nice token API could use a lot of help in Drupal core, I'm not sure if it's still possible to improve that now that we will have the beta this week if you want to help submit pull requests for the Github projects or patches for what is on Drupal.org you can also just use the time you have here to try it out, install it experiment and report box and if you want to sprint on it on Friday or so then get in contact with me and I haven't worked on all those modules alone many of the people are involved in this in Drupal 7 and the number of other people that are porting the token module and other modules and are helping out any questions about the modules how close are we to other generating tokens from type data because they really don't want to write any more token integrations anymore I'm not sure I basically just have an existing approach in token module work for now so it's not using type data yet it's just using the existing field API I know that the rules guys are looking into making token generation from type data work there has been some approach in Drupal core to make that work but that didn't happen yet unfortunately so I'm kind of relying on it so next is a shared presentation simple news so hello yes simple news not possibly not so popular as all the other modules hmm oh that was not yes it's like number 90 or something and actually I got into charge of it from Eric two and a half years ago and I'm happy to say that today basically my team is taking care of it especially even finally joined us and helped us parting it because let's say last year for instance there was not too much activity around it and for instance there was also a module called newsletter that has been started which seems now to be abundant and finally migrates to simple news back again when our version of Drupal 8 is ready now as said I'm founder of and assistance luckily we are working a lot of with Drupal 8 stuff since starting this week and pushed a lot of these modules you've seen and as said this is even Fuchs actually a developer of one of our clients who joined the team and helped us parting as a new contributor okay as Mira said did most of the parting we started some months ago which changed a little bit the order because the first thing is the changes so what changed from Drupal 7 to Drupal 8 we tried to use all the Drupal 8 pattern like the configuration, the entities the fieldable entities and all that stuff so what was known until now the categories which is the newsletter itself is now a configuration a config entity and we used also the the principles of the entity reference so it's like enlarged entity reference we use this for the subscriptions and the issues and also the blocks we changed and we're using now there the Drupal 8 and Drupal 9 as you can see here it's a little diagram where you know what is a subscription what is an issue so that's just for the overview here you see the block configuration pop up for the moment because until now on D7 for a simple news block you just enabled it on the newsletter itself so you had only this newsletter or there was some summarizing block for all the newsletter now with the the plugin system you can have as much blocks as you want and you can always select for which newsletter you would like to have this block so you can activate one or n or however you want to use it I would say most or about all the functionality that you had on D7 in the first step it was just a raw porting of what we had you have all the configuration of the newsletter, the settings the UI we did not yet do the views integration so you have just simple listings at the moment the blocks were ported as I said with the plugins, the mail pool works the subscriber is now fieldable we also did in the last few days colleague is working on personalization so he already did some synchronization of the subscriber and the user so like first name, last name this stuff and their sending and stopping of a newsletter is already working so you can send around some default newsletters for those of you who know simple news are perhaps happy to read here stopping newsletter yes we have now a stop button where you can stop sending your newsletter at the moment it's just rudimentary stop stopping deleting the mail out of the spool and setting back the status but we will work on that too here is a little overview as I said it's just at the moment listing no views integration of the newsletter itself where you can edit it and you see on top also the settings tab these are two examples so indeed it's the same example of a subscription block once you're locked in the other one is not as you can see you have their checkbox of different newsletters then you have the subscriber overview indeed it's an overview of the active subscriptions that's a problem we are also working on because you don't really have an overview of all subscribers because when you unsubscribe somewhere and so you don't have an active subscription to something you're not listed anywhere so we will try to separate these two things that we have a subscriber overview and a subscription overview that it's handled easier or it's you view it a lot better this is the subscriber edit form as you can see there are those fields first name, last name which are synchronized to the user which it depends on so this is I think yesterday it started working so we're making progress in that that's the fieldable subscriber as I said we used also these principles and the subscriber is completely the fieldable you can put on whatever you want it makes it quite flexible and also for the user synchronization which all the fields that are put on a user can also be on a subscriber so the synchronization works this is the newsletter issue overview so the newsletter issue is the thing that is sent regularly for the moment we don't have any VBOs or filtering on that as I said also because of the use integration that is missing but as you can see the subscribers in D7 we had the problem that indeed every issue of a newsletter that was sent showed the same number of subscriber number in this overview because it just was looking up how many are subscribed now so we fixed also that you can see how many subscribers or how many sent newsletters were at this issue so you can also see the evolution of subscriptions to a newsletter yes here you can see the stop sending button that you have on an issue and that's the same possibilities as in D7 where you can send your newsletters, send test mails all that stuff and now we come to the plans and there I give the word back to Milo actually I would have expected some applause for the stop sending button because you can't imagine how many mails possible we spam the whole world with simple news and we really wanted to stop this issue same also with other discussions around architecture so we identified the concept of a subscriber as you see basically subscriber is kind of similar to a user but it's not the real user that can log in but still he can kind of maintain his subscriptions so basically there's currently a little bit of discussion whether the subscriber as such should be separated and not basically really be a part of simple news internally so we found that really but most importantly we want to improve the UI a bit that personalization stuff was a huge demand in past already so people basically ended up in customizing writing custom code to add first name or the last name field to subscriptions this pain is really over so basically we have a solution that is much more near to real life requirements and for instance I have really things that I'm concerned about since Drupal currently is really bad at doing it's mail reputation so basically most of the platforms are sending emails to recipients that possibly bounds and no one is taking care of that this is not a simple news problem in my point of view and we want to work on that so let's start doing this and we will release some other modules components part of simple news on its own and sure there is always a topic like give me statistics provide click information on who actually clicked on links opened it previous sub modules might be ported might be part of simple news in the future and finally sure we want to provide examples through for instance simply test me one thing also I basically let's say started to dream years ago it's like best would be that every theme basically that ships with Drupal you can use should also provide an HTML mail theme we are far from that it's still something I want to basically get better with simple news because it was always a pain to ship a theme that finally works for your newsletters and this is something we need to improve and we sure can we need to help even will continue we will make this production ready by start of next year basically simple news can already be used we will have some ideas where we continue to work as I told you but still basically no one is currently taking care of the migrate path all that personalization stuff with there's a ton of requirements that's basically start once you have these fields in order to successfully deliver personalized emails and sure all these ideas can need you to make it happen yes that's was it thanks a lot thank you both any questions simple news sending emails good okay okay I guess we had all of them so the only thing I can really say is yes so on Friday we have sprints so if you're interested in helping in any of these modules or another module you want to port come to the sprints on Friday even if you never worked before on any core or country modules there will be help from the mentors they will tell you how it works how it works how you set up your local environment and all these things and then you can help us there is also the initiative to do again Drupal country info website unfortunately the old one that we had is now taken by an Asian domain taker but there will probably be another domain which is not yet ready where sooner or later we will see like an overview of all the updates of each module that you can really easily see if they're already stable version or not so not like click around like crazy on Drupal.org yes I hope that was interesting as I said it was an experiment to see if this works but we really hope that you got some information about Drupal 8 of Contrib to know which modules and which status and I wish you a really nice day and enjoy Drupal Con thank you