 Let's just post a demo. And yeah, today is two-page contributor model. So, hands up, who has already started working on a global aid project? Sites with multi-country, multi-domain functionalities. We haven't started doing so. We try to limit our use cases to what we have tested so far. But I think in the next half a year, building with domain will definitely be something that we will try. In general, I think every agency, every developer has their own personal taste on how you want to approach using modules. And some say that you should not use any other release, for example, or you should not use any death release. And there is definitely a recent product. For example, if you rely on the security team. But in general, we think that just because it has a name, because it's about the release, because it's a better release, it also depends on how much trust you have for the developers to work on that model. A model can have a final release, and it's totally broken. So being part of the community, having spent time working on several projects, I think every one of us will get our own understanding on how stable something is, how much we can trust it. Workflows, yes. So for example, the e-mail registration model. It's like a simple workflow that's already there. The workbench moderation, it just had an alpha release recently. I couldn't try it, but I think it's kind of nice. Entity registration is not there, but there is an alternative to it, RNG. I found it quite interesting. I played around a bit. It has a lot of functionality already. And then besides that, the workflow module has its first alpha release. Organic groups is already being ported, and we are working actively on porting the rules module. So we expect the first MVP in the next month. And yeah, you can sprint with us on Sunday. Basically, the rules module already provides a lot of functionality. So it's kind of interesting. Other modules can already start porting their integration, but there is no release. So that could take at least a month. All right. Yeah, so we got those. For building, let's talk a bit about how we approach menus. Well, Tupper Core itself obviously provides the menu UI, the custom menu links. And then, for example, the sitemap module already works. Also, web terms, maybe. When we talk about forms, the web form module, it's kind of a not-ported module at the moment. And interestingly, the e-form or entity form has been started porting. What we currently rely on is the contact module. So that's part of Tupper Core. And you can create different forms based on the contact module. Just by itself, it doesn't store anything. So the contact storage module allows you to then store the data. And yeah, for example, with the CSV serializer, you can also export the data that got stored for other systems. I think the main difference here is how scalable is the solution. If you want your clients to be able to create their own formula, then that's definitely a use case that we would implement with web form. Because all the contact of the e-form, they rely on fields being created for every of the form fields. And that can be getting slower if you create thousands of fields. SEO. So, well, Tupper Core by itself obviously supports part. Then the meta-type module has made quite some steps in development. I found it interesting that you would use meta-type now as a field. So you attach a field to a node type. And there you can specify the defaults. But now with the latest release, there's also the classic meta-type approach where you can define global defaults and then overwrite them for node types or for the autonomous, for example. Then ParkAllow is already pretty solid. The redirect module as well. We also used the Google Analytics module and then XML-sidemap. That didn't work out because it's not... The standard XML-sidemap module doesn't support language at the moment. We started working on a patch but it didn't get very far. But we found an alternative. So the simple XML-sidemap module also works with multilingual. And it's built solid. Then also the file field paths and pathological modules are kind of in a shape that you can already play around with. Then display data. So tomorrow I will do a session together with Adam Drude about coding versus clicking to compare approaches of implementing layouts in code or with site building tools. And some of them are mentioned here. So the blocks and layouts initiative has made very good progress in terms of enabling blocks to be much more than they were in Google 7. So the block system in Google 7 was basically something that nobody liked at all. And now it's based on plugins. As I said, you can define different block types. You can put fields on them. So it's kind of interesting also in terms of how do I structure my content because basically you can create reusable pieces of content based on blocks. But then when you want a layout, so there's like something like you got split up into different parts when the panels module was not yet reported. The first are the two extract page manager. And together with the layout plugin, you could already create like landing pages that have different regions and place any kind of block into that. It's kind of great. Also the display street module has been reported really early. So they had a release like over a year ago already. And it's kind of a matter of taste that I think you can use any of these. And panels and panelizer have had releases in the last month as well. So they also got to a point where people can already try them. I personally, I said we use paragraphs most of the time and layout plugin and page manager. That's what we have used successfully already on projects. I think that panels now is also in a shape that I would try and I just haven't had a need for the display street so far. Then listings, well, that's kind of easy. No complicated modules required there. Views, the new UI, they are part of the core. There's some small extension modules for them available. More interesting research. So the core search is listed here. I think we should do a search with core search. The exciting thing about... The exciting thing is that the Apache Solar module and the search API module, they join forces. So for Drupal 8 there will be no more confusion between two competing modules. Search API, given with the Solar Search, they all have had releases, like multiple releases already. They are adding more and more functionality there. Also FastSense, so it's now renamed from FastSense API to FastSense. They are a really, really active initiative. It's the FastSense. We already started using it on the project that we haven't released yet. But so far, it's much more limited because you don't have all the different FastSense widgets, for example. But in general, I think it's definitely something that I would already... And if I'm not familiar with it, I would already install and try it out. As mentioned, the PrettyPals module is not ported. But I'm looking into finding somebody to take over the inhibition for it. So if you want to do that. Or, to be honest, maybe it doesn't even have to exist because if we get the FastSense module right, the overhead of the PrettyPals module could really use even more. And then we can just maybe add it as an extension there. All right, maps. I did my master thesis on creating interactive maps with Drupal, which was kind of fun. So the Geocaster module is about putting 100,000 or millions of points on it that make it scalable. But right now, I'm going to talk more about just the standard use case. You want to have a map on the contact page, for example. Or you want to visualize a list of data on it. So we kind of think it's also a good opportunity in general for all of the use cases where you don't find the module yet. Well, maybe that's just a JavaScript library, or you can, in general, with the hype about Drupal 8 getting off the island. Maybe for those use cases where you don't find yet the module, maybe there's like a symphony module for that. So for the maps, we recommend, well, we don't need all those bloated modules, we just go with JavaScript if possible and expose the data as a GeoChase, for example, on the server side. Yeah, they've used GeoChase, and the Geofield modules are being like alpha releases. So they are quite buggy at the moment as far as I see. And then there's a ton of helper modules. So for administrative purposes, well, Drupal Core has the contextual links which allow you to be able to edit things wherever you are on the side, which is cool. We always install the admin toolbar, like the admin menu, that you can quickly access in the ITAPT, even though the responsive admin menu that Drupal Core provides is also really great. From time to time, I went into a Drupal 7 site on my phone and I realized that we should install that. I think it's back ported actually, so we could install it. Try to focus as much as possible in Drupal 8. Masquerade, also nice, because you can switch between users. That already works. There's also an admin theme ported already in the admin menu that was kind of popular in Drupal 7 as well. Then services. So we also have Klausi in the room who is the maintainer of the REST module, thank you. So Drupal Core by itself, with all the talks about decoupling Drupal, Drupal Core itself provides the restful functionality, which is great. How is the serialization? And then I'm adding feeds here, so the feeds module is not ported at the moment. And somebody started saying that he's porting it, but it doesn't look at the moment that there's much progress. And I also want to add GraphQL, because that's the new hype. It's going to be awesome. We are able to just drill into the data explosive as a graph. So the GraphQL is quite active, and there's also a project behind that to make it happen. So I'm looking forward to the results there. Then performance. Drupal 8 by itself has quite some performance improvements in the system, the cache tag system. And there's already a release for the manage module. And then we're looking forward to big pipe being integrated into Drupal Core. And there's like a first release of the ultimate graph model if you rely on that. Probably makes sense if you have more complicated contracts. Then configuration management. All part of Drupal Core. I think that's a big relief for all of us. I think, from my understanding, people are still figuring out the perfect workflows, how this is going to work out. The bundle. So what you can do now in Drupal Core is that everything gets exported. But if you want a bundle functionality, if you want a transfer functionality through the other side, what you want then to use is the features module. That for me didn't work out yet. Has anyone used any features? Drupal 8? Drupal 8? There is a collection of helper modules that try to facilitate the configuration management. Like for example, automatically exporting whenever somebody is side building. I haven't seen like D1 module there. And then what we always use is the Linux CSS module just to ensure that the CSS is properly put into the HTML. And the advanced aggregation module also has as much to leaves. So if you want a full side building, put all the JavaScript into the filter, that's what you want to do there. Yes, and then what migrates in Core and the migrate UI will also be soon. The migrate to Drupal, the Drupal to Drupal, they are all pretty usable already. And then I'm adding some more like coder, token, develop, SQL, skip deploy, hacked, honeypot. Those are all modules, like helper modules that we can already use or need to use. That's it basically. I think there was like a big overview. As we can see on the next slide, there's some really good resources. I definitely would recommend the Content Tracker. So people have started creating issues for every of these modules. And you can see on the Kanban style board which of the modules have already been started porting, which of the modules are redundant now because they're covered by the local functionality. There's like 50 of them that we don't need anymore. So that's kind of the go-to overview because this presentation will probably tomorrow be updated again. Then there's also the end status from any systems. What they show there is also like if tests are coming, how the test data is going to be. Then I would like to show you a spreadsheet. So basically the information that I talked about right now is what I distill into this spreadsheet. That's also linked from the presentation. Again, it's my personal assessment of what is relevant and how well ported it is. But it's maybe a good list to just come through and to decide for yourself what you're going to try out next, what you can already sell your customers and all the time. Any questions? So what would be the reason for you to suggest the customer to use the Pro7 instead of the specific modules or functionality? What's the missing piece or the missing pieces that are likely to be running for us in Pro7? Well, first of all, I think it depends on multiple things like the customer's access to an agency that can provide proper services. And there's more and more agencies that can provide proper services but there's a lot of agencies that have no experience with Pro7 yet. So it's like this chicken-eye problem that you first have to learn it and you can use it. But the big pieces that are missing, like if you really need webform, then either you have to find a custom solution to build your own webform module or to actually port the webform module. More like a commodity question. Would you want to invest in something that is rock solid that people have used for various reasons already? Or do you want to invest into something that not thousands of people have used already but is going to be relevant for much, much longer? Because, I mean, now everybody's freaking out about Pro6 not being supported anymore and the same will happen for Pro7. We can make our customers sure that the Pro7 will be supported let's say three, four or five years. We don't know exactly, but that kind of number. And if they want to build something that is supported longer than that, I would always try to relate it also. Those are not the case. Does that answer your question? Yeah? When can I over-port that? So, any approximate deadline where Dubai is the last Pro7? Can you repeat that? I'm not sure if I understood. Any approximate deadline? I think actually 2.8 doesn't require as many workarounds as we have in Pro7, for example. 2.8 is already better than Pro7 in a certain sense and it's already more extensible. And the solutions that have proven themselves in Pro7 are there for Pro7 and much more flexible like you can attach fields to drops, for example, which provides more and more. I was going to say side. This is simple side. But since the domain module was not reported yet and there was some issues I have encountered using domain module, I had to just hold that. So, when we predict a used grasp in state of boundary in modules, when we... So, he is saying more about the problem and using of the existing undergraduate modules, which I want to use. And I say we can identify that these many modules are more installed in education and education. So, he's asking about... Is there a problem or a next step that has been set for certain problems that let's say after one month or a couple of months, we will not be able to do this many modules. So, basically they're like... If the project architecture is like an architecture in any site, like influence and that these many modules you can use for now. So, that is when can I... Can I answer? So, I mean it... And there can be multiple answers to that question because we are asking for the whole triple certain ecosystem. When is it ready for the parade? My answer would be it will never be... I will never because some things will just throw away and nobody will report them at all. But like let's say the 80% use case that everyone of us likes to be able to send to our clients. And I would say like in the next half a year we'll be able to build a lot of stuff for them. But if that covers your particular use case, your particular module, there is... Officially there's nobody able to tell you that everything will be ported at some point. It just doesn't work in our open source environment. But there's... Like I noted for example like we are also like trying to fund a lot of contributed modules. For example they provide lots of funds for us for the rules initiative. And that allowed us to now predict that the MDP will be ready in the next month. So that's something really helpful. And I think that something... I don't know. That's the perfect cause. Everyone of us dedicates a bit of time to Drupal Core or provides a bit of funding to the module that we want to see. It doesn't mean that we have to fund all the modules because if we multiply our resources then success is close. You can say excellent development, service-provided, excellent service-provided, it's a high-time business time. But for a sales person, you can say after six months or a year you can say enough. One of my customers have a site in Drupal 6 and it's running from last year. And I've just run for a maintenance company there. I propose me to migrate to Drupal 7. But he's myself... So with Drupal 8, we have ditched the upgrades like the update functionality and what we now prefer is migration. So we don't just hit a button that tries to upgrade everything but we program or configure a migration that will just fetch the data or fetch the configuration and translate it into a new site. Which in general is what everybody found as the best practice anyways because after a couple of years what you have built in Drupal version is not the way that you want to build it again. You still want to restructure things. You want to learn from the mistakes with that. You want to build something fresh. You maybe also want to just throw away a bunch of functionality that nobody needs anymore on the website. So I think going from 6 to 8 is a perfectly valid choice. Because it has a longer future. I have a question about importing content. Since this module is not available in Drupal 8, it's the migrate module only way to import the initial content on the website. To make an initial content import? Yes. I don't know import content module. It's called upgrade. Upgrade automatically. Upgrade module is written in a script that automatically migrate to it. It looks like it's a migrate project but it's just a creating a website and you want to import the initial content from csv5 or html5. It's just for the demo. So I have a distribution called multilingual demo that has like 10 lines of code to import a csv to entities. So it's probably easier to use than the lines of code instead of the migrate module because for the migrate module you would need to somehow figure out how to import a csv and map that to entities and stuff that's probably harder than just creating the csv and putting it to the right fields. So if you want to look it up it's the multilingual underscore demo project on Drupal.org. It has all the permitted install files for setting up a sample site in terms of setups. Okay, but then... Multilingual demo. Sure. There's also the Drupal console provides a command as well for generating content but if you want to import great content obviously like the feed module for example has an important leader but such a small hand for a developer can definitely go like this. The FDAP is pretty nice. So it's super easy to create content but there's no logic. In continuation? So how easy would it be to migrate a Drupal server site in Drupal 8? No, actually the migrate Drupal to Drupal understands the configuration that you have on the outside and will allow you to import that configuration. So that depends on how many contributed modules you have and if they also provide their own migration paths. If you can live with the core functionality and then build around again or create custom migrations for everything else you need it really depends on how the site was built and how complex it was. But the nice thing about migrations is that you can just rerun them. So you first start migrating then you've got to print them out and then you can rerun the migration later. We need to do the same question. What I wanted to know is if I have a Drupal 6 site like what this DAB was referring to and if we are referring that we should go directly to Drupal 8 and this entire session is about 200 modules which is still in a phase and still going on and a lot of things must need to be ported. What do you think in a semi-complex Drupal 6 site right now is the time to go to Drupal 8 or we have to wait until all these 200 modules get ported to Drupal 8? I hope that you don't need the 200 modules anymore for your Drupal 8 site because some of them will be redundant some of them you can find more elegant solutions in Drupal 8 so in general having 200 modules is like really the upper limit that feels not good for maintaining in here In any case I would like you to check if you can reduce something What you suggest to the client right now is that we should go for Drupal 8 and evaluate first what is the way contribution modules are available in D6? Right now let's start with what works already let's try to be HR in the sense that we first build the stuff that we really really need then the client can learn how properly it feels for him and then he can take together with you decisions on how he wants to have the rest of the let's say you can already port 60% of the functionality and then you can decide together with the client ok now you know how Drupal 8 looks and how well it plays with the 60% do we really need the 40% and how are we going to approach them so I don't know how long the project will take for you but if it's like a 6 month project then after 3 months Drupal 8 itself will already be much faster you can based on the experience that you have while building the site and the client has the experience of being able to make more informed decisions then there's a problem with waterfalls that to me the client asks you what you're going to be able to deliver in a year it's impossible the problem arises because the client is not technical at all the more annoying thing about Drupal 7 is Drupal 8 he doesn't care, what he cares is it is D6 given the latest version of Drupal so it's very difficult convincing that Drupal 7 is a different architecture and Drupal 8 is a different architecture if you really want to switch right now I can actually support you for Drupal 7 and later we can do Drupal 8 but Drupal 8 is an architecture and still not put a lot of money so that's the line to draw I understand the concept but I'm trying to choose projects where I can convince the clients that it's Drupal 8 and it's not like 6 plus plus but you will have to work that out with base America because it's high for me to answer that question what stage like one version is capable to go for this development of Drupal 8 there should be some information which we can represent to other companies so that will be one for the developer it's like a car a car it's like 10 years old do you really want to have a copy of the same car as just a painting on it do you want to have the latest technology and then maybe I don't know how to get another kind of fuel also the person that uses the car has to adapt to the new but in the long run it will really be able to benefit from all the improvements but it's disruptive technology it's not like every Drupal really is disabled you can just take a copy of this it will be in December we'll get closer to that in 8.123 but with the major releases from my perspective like Swift, like us to be able to migrate from 6 to 8 without any cost just a little bit migrated from order version to new version so is there any way to migrate to the new version I think so the question is if you can migrate that theme from an old to a new version well, in a sense because if you adapt all the output marker to reflect the same that you had before then you can import the CSS but it will also change because Drupal 8 has tweaked so the templates will have to change a bit or you will have to write a PHP-based template actually for Drupal 8 or you decouple it first and you have it in front of it and then you migrate the background there's various ways to approach it but the automated upgrade for a theme as far as I know doesn't exist maybe somebody will write some helpers that will replace the common functionality but in the end again it's a new it's totally new concept and usually doesn't make sense to migrate the theme from 6 to 8 directly so actually Drupal 8 is everything yes yes what can you export individual items single items things as well as one thing so are we talking about different about copies copies of the same sites or about different sites because when it's the same sites then the CMI system basically supports exporting and exporting configuration if you have two different sites you need some you need some metals to be able to export a different functionality with the CMI you can export so it's basically possible and what you can also do is you can put the configuration that you export into the config default directly so that it doesn't have to live in the big folder but it can also live in the model which is big like in general it works so there's a way to do that like maybe after watching ok that's it thank you everyone more discussion