 Okay, so the screen's adjustment might still be tweaked, but I think we could get started. Should be readable now. So, hola Barcelona, that was corny, but I had to say it. We are speaking on building sites in Drupal 7 with an ion Drupal 8. I am Ashraf Abid, Ashraf Abid. I work at Acquia, who was officially all in for D8 since the date listed above. I also founded Debug Academy, where we train individuals to become Drupal developers competent enough to join a development team with a proper workflow. I'm an Acquia-certified grandmaster as of this Drupal con. And in D8, I upgraded the admin user by role module and contributed various patches and whatnot to D7. Hello, I'm Frédéric Maran, also known as FGM on Drupal.org. I'm a performance engineer. We're doing mostly work on speeding up media sites, mostly in France. I've been a long time contributor to Drupal since four something. And we already did a number of projects on Drupal 8, for which we did above this morning. And we have, I have had experience with having customers with large sites already built on 6 and 7 and who wanted to use a Drupal 8-like code and could not still afford to use Drupal 8. And this allowed me to define some procedures. We'll be explaining to you during this presentation to show how you can work on 6 or 7 and still not be writing codes that we will have to throw away when you go to Drupal 8. So this talk should help you if you're going to be building a Drupal project in the near future and you're deciding whether to wait for D8 to come out. A lot of people are, a lot of clients say we don't wanna build our project in D6 or D7, well in D7 because D8 is coming out soon and we're just going to have to upgrade. The question isn't as black and white as we're going to display here. We're going to show that it's possible to build a website in D7 which is not such a huge lift to upgrade to D8. So, go ahead. So as I said, what we are explaining is not about whether or not you should go to D8 but how you can work with the current versions and be ready for D8 for a minimal cost. So in other words, should you choose to develop this new site that you are about to start on the classical Drupal 7 workflow you have been using for the last five years probably? And or should you use something still on Drupal 7 but ready for Drupal 8? Or maybe should you even consider doing Drupal 8 work already? The idea is in any case what you want is minimize the cost of the future of your site. That is, you have to spend an amount of time and amount of money on building this site right now on 7 probably, hopefully not on 6 unless it's maintenance. And you still want to minimize how much it will cost to move to Drupal 8 when the time comes because if any of you have been using Drupal 6 in production until today, you know that it has become quite difficult these days to get the competent Drupal 6 developers to maintain existing projects. And there's no need to take a wild guess. It will be difficult in two years probably to find Drupal 7 developers because everyone will be using Drupal 8 and maybe starting to work on the future Drupal 8 something or maybe a Drupal 9. And if you are doing any work for a long, long lifetime something like an extra net, it will often live for five years. And in five years, there will not be anyone able to maintain this correctly on the market. So you will want to update Red to 8 and as you probably know, Drupal 8 is a major release. There are more changes from 7 to 8 than from Drupal 1 to Drupal 7 actually. So how can you minimize this cost? This is the topic. One question which can be asked is, wait, can we just wait for Drupal 8? Well, waiting has a cost. So there's a reason that you're building a new site, of course. You may have business benefits for the project. For example, it may save you money or make you money for every month that you have your new website. And you are going to be, if you decide to wait to D8, you lose those benefits for every month you're waiting. On top of that, D8 is ready when it's ready. You don't even know how long you're losing those benefits. And it's possible that your security department may refuse projects that are at a release candidate state. Let's see. Not sure if that's the dongle or not. Even when D8 finally comes out, the contrib, when D8 is officially released, it doesn't mean, of course, that contrib is ready. We've got modules like panels, which so many sites are based on or rely on in a heavy way, which still have a very long way to go. Additionally, a lot of contrib that's been important to D7 sites simply won't make it at all to D8 and there will be different ways of doing these things. So it's just, there's too much uncertainty for one to say, we'll just wait for D8. Another reason to defer going for D8 is that the resource scarcity. I mean, if you asked Drupal shops with which you work, or if you are a Drupal shop yourself doing fixed price work, you will probably notice that the market is still not ready to take up fixed price projects in project mode on Drupal 8 because they can't start doing proper estimates on what the time and cost of realizing a project will be here. So many suppliers whom you have come to trust will not be available if you are a customer. And if you are a supplier, you know that your own project managers who have honed their skills on estimating projects for Drupal 6 and 7 are not yet ready to take up these estimations for 8. You need to train internal teams whether you are an internal team at an end user or at a supplier. You need training and even training is not completely available yet for Drupal 8. Of course, since Drupal 8 is not completely ready. So what we're talking about, one of the things we'll be talking about is the ability to build D7 plus sites now. If you pick the right contrib modules, for example, you can align yourself with the modules in D8 that are already far along. And that's not always the same modules that are popular in D7. You can also write portable code. When you're writing custom code typically for D7, you simply just utilize hooks, utilize what you know. But there's a different way it could be written to make it so that it's easy to move your code from D7 to D8 with minimal to very little really refactoring. And additionally, your end users, you can use consistent modules from D7 to D8 with the intention of not only simplifying life for your developers, but also for your end users. Although it may make sense to pick a specific module in D7 and a different one in D8, there's a benefit to picking the same modules across the board so that the end users who are using your application ultimately have a smooth experience and smooth transition. This being said, of course, you can build on Drupal 8 already. As I said, we've already done four projects on Drupal 8. Many other companies have already done and delivered Drupal 8 projects. Even in DrupalCon Los Angeles six months ago, there were already shops showing Drupal 8 projects online. You can do this if, first thing, your project does not rely on too many contribs. If you have a dependency on a big country which has not been ported, it will be very hard. You can do this if you have expert contractors. For instance, say you are working with Acquia, which is ready maybe with other larger companies like maybe the Wundercruits and the M8 Zlabs and maybe OZNet and if you're in France, you can have expert contractors who can guide your teams and lead them on the right path for Drupal 8. If you are yourself an expert internal team working at one of these companies, you can have already an existing knowledge, especially with Symphony 2, which will help a lot when you are doing development because if you are coding your solution as custom code, you will find that it has a lot in common with mainstream Symphony applications. And finally, one other thing which may help is if your code is decoupled between the back and the front and you are using the headless technologies because then you are skipping the last pain points in Drupal 8, which happens to be all centered around theming with Twig and headless relieves you from just that. It's easy to already deliver code for headless than it is to deliver it for the normal Drupal backend side build. So, which should you start with? That depends. If your site has a short time to market, short time to live, so if your client needs the site to launch soon, then you go with D7. That one's generally a straightforward decision. And if you have a simple project, relatively simple project, and it has a good amount of time before it needs to go live, for these cases you can consider going straight to D8. In this case, it's not too much of a risk and you get cost savings in the long run by avoiding the upgrade altogether. For complicated projects, if there's an early start time, then you're going to be going with D7, especially if your website needs to launch in the next few months or a year even. If you're starting farther in the future and you have a restricted budget, again, you'll be going with D7, but building it in a manner that's upgradable to D8. But if you have a later start time and a very significant budget, it's possible to go straight to D8. In those cases, we're talking about very large projects who may be able to bear the burden of actually upgrading contrib modules for their own projects. And in that case, there may be a large number of contrib modules that they'll have to upgrade. But there are cases where that's still within budget. And referring to budget, of course, this is mentioning you will have to budget for the fact that you'll have to continue to maintain the website as D8 becomes release ready. If you have a, if there are complex existing non-Driple Sites to update, then again, if it's a short time to market, you should build it in D7 with portable code so that it's easier to upgrade to D8. If you have a long time to market, you may be able to go straight to D8. And if you have custom code and you're seeking continuity of service, then prepare for D8. So if you have a non-Driple website built on custom code, it may just make sense to start planning your D8 project rather than migrating a whole custom application to D7 and then migrating it again to D8. So how do we include portable, how do we include portable code to D8? He's the expert. Well, one thing we found out after building a number of sites on Drupal 8 is that the Drupal 8 site building process is actually very similar to the Drupal 6 to 7 process. This was, I should say, unexpected because as developers, as coders, we know that site coding is very different for Drupal 8. But site building is very familiar and most of site builders are very productive on Drupal 8 from day one. Basically, if they're familiar with the process using features, using strong arm and installation profiles, they will find it doesn't make many changes. Basically, instead of features, they will be using CMI. There will be new Drush commands. It will be Drush config export instead of Drush features update. But basically, the concepts are the same. It's just a matter of a few hours to learn the new commands and they perform basically the same roles. So in a sense, it's feature on their friends just better without the bugs which are so many in the features process in Drupal 7. Also, if your process existing, the existing process on Drupal 7 is code driven, that means everything is always pushed to code instead of staying in the database that's revolved over time. This is exactly the process that you should be using for Drupal 8. So again, this is something which is simple. What does it mean in terms of Drupal 8? You create something in the UI. You create a view. You create a content type. You add fields to a content type. And then you export it as config just as you would have exported it in a feature in Drupal 7. And then it's code. You commit it to Git and you go on. You keep the full process with possibility that you have with code, except it applies to the side building. Just as with 7, it's really easy and that was a very positive uptake from the first Drupal 8 project. It really replaced side building of D in Drupal 7 almost instantly. Of course, that means that you have to deploy updates to code. But since you are using this in Drupal 7 with the features, mostly you just change your scripts and the logic is still there. As I said, features and strong arm. One thing that changes a lot and for the better is if you have been using features, you probably always have seen features which were in conflict and you had to resolve them or maybe you didn't even resolve. Or features which always stayed overridden no matter how many times you tried to revert them. Yeah, I see people in the audience say, oh yes, I've seen that. The good news is that this no longer happens in Drupal 8 because CMI handles dependencies. Anytime you create a config, it is sure not to be in conflict with any other configuration and it always exists in one place and not two. So if you built your features previously as separated items, grouping features, not in the module sense, but as islands of functionality, you had no conflicts and this will be the same process you will be using in Drupal 8. Now, talking about contribution, you have various levels of risk which are involved when choosing your modules. Adler? So, when you're picking your modules for Drupal 7, specifically when building a site for Drupal 7 which you hope to make upgradeable to Drupal 8 with the least trouble, there's levels of risk with each module you pick. This is a short, of course, not comprehensive list of some of the modules that represent a lower risk in picking these for Drupal 7. So CK Editor, for example, is in core as is Quick Edit and a number of other of these features. What's it called? So entity form, web form, web form slipped my mind. So, of course, web form is used for huge forms, forms big and small, but it's going to take a long way to get web form ready for D8. So, if you have simpler forms, it might make sense to use entity form instead. Additionally, workbench moderation and related modules have seemed to have won in D7 in terms of the right module to pick for workflow management or content workflow management. But in D8, there's a lot of really good work going into the workflow module. It's rather far along as opposed to workbench, which is not quite so far along in D8. So it may actually make sense to use workflow in your D7 website instead. On the other hand, modules that represent medium risk include the whole Drupal commerce suite, rules module and media modules. That's because these modules, they've shown good progress in Drupal 8, but they're bigger beasts to conquer and it's harder to predict when they'll be finished. So, we're not necessarily saying don't use them in D7, but using them, you should acknowledge that they still may be some ways away from making it to D8. On the other hand, these modules are higher risk. They still have a very long way to go to make it to D8 and it's best to avoid them in your D7 build if you're planning to upgrade in the relatively near future. For example, for organic groups, you could possibly utilize entity references and some late programming to mimic the effects and the benefits that you would get from organic groups, at least for relatively simple sites. So in these cases, I would recommend avoiding them if there's a simple way around it. As for the front-end architecture, don't use panels for theming. If the primary purpose you're using panels is to arrange your layout as a site builder or as a developer, it's just not the right fit. Panels is very bulky. It'll take a long way to get to D8 and although you're likely to redo your theme in D8, once you start using panels, you could find yourself relying on it more and more by adding little add-on modules here and there and it'll become a bigger dependency than you may have originally intended. And as I said, you're likely to rebuild the front-end during any major site update. So it kind of renders the base theme that you use in your D7 site relatively insignificant in terms of the upgrade path to D8. But if you are so inclined to try Twig out early, there is a Twig for Drupal 7 module, TFD7, which might reduce the efforts required to port a theme as is. You might need to rewrite less theming code from Twig specifically, but it's unlikely that you'll end up being able to actually port theme code from your Drupal 7 site to eight. So especially because the CSS classes will also differ in D8, so you still will have to update your CSS and oftentimes CSS is where you spend most of your time as a themeer. And again, you can reduce the amount of contrib that you're using, you know, go back to basics. As I was mentioning with entity reference instead of using organic groups, if possible, you could also do the same thing with other modules. For example, node queue or entity queue, creatively use entity reference to avoid more complicated modules that will take a longer time to appear and contrib. Also, if there's a module that you rely on, sponsor it now. Let the module maintainers bring it to D8 for you while you are working on your D7 website or maintaining your D7 website. It'll be cheaper ultimately to sponsor the module to get updated now than it may be to do an overly complicated workaround. So how do we code for portability? This was quite interesting. Just coming back for a second on the previous slide, Ashraf mentioned sponsoring part of key contrib modules and for many of you probably rules is a major contrib module that needs porting. And I just had a specific request from Fago this morning asking me if you know of people who are ready to be using rules on Drupal 8, please tell them to sponsor the port for Drupal 8. Thanks for rules and for everyone in Drupal 8. So how do you write portable code to save the coasts when you are going to maintain that code and move it to Drupal 8? As we said, there's less contrib, you know that of course. But also, since you are using less contrib code that means you have more custom code and one of the key findings from these early Drupal 8 sites is that Drupal 8 code after the initial training and the shock of the new APIs and the size of the new APIs is actually simpler to write than Drupal 7 and the earlier versions code. Why is that? Basically in Drupal 7 and before, you would put a lot of code in your hooks, in your module files. It was an accumulation of a massive number of things which were laid out in a limited number of files. And so there was a sort of mass effect on your code. All the functions or most of them at least, unless we are talking about views plugins and a few other case of object oriented code. All of that was a bunch of functions, flat functions in a flat name space without any structure. And it was difficult to find any things also. Since Drupal has always been based on an aspect oriented programming model, that means that anytime you're on a large site where you are touching something in one place, you find it modifies something elsewhere. This does not happen so much in Drupal 8 and by quite a bit. The code is organized in small files which are classes and these classes have been designed with the single responsibility principle in mind which means that basically one class just does one thing. And if it does several related things, that means that each method on the class just does one thing again. So this is easy to reason about and to compose. Also the code is organized in name spaces which means that they are grouped by functional level of affinity and everything in one given name space does the same type of thing. So how do you use that on your Drupal 7 or 6 sites to make them ready for Drupal 8? Well, you must stop to think in terms of implementing hooks in your module and start to think in terms of a model. Model is not what goes directly into the database. It's the domain space representation of what is in your business logic. Basically, if your process is about modeling cart items or shopping or whatever property can be, you need to define them as classes, having methods by which they interact with other entities in the domain space. And then when you have this, this is what is called a domain model. That model you implement your custom logic on and this is all object oriented code which is new, I must admit for most Drupal 7 developers. But this code can take services like Drupal 8 defines them using inversion of control and that way you can get this code to be independent of Drupal. In the end, what remains is you have to plug this code with Drupal itself and here that's where you use the module code. The module code is just stubs plugging your code into Drupal. This is called componentization. You create components of your model and you plug these components in Drupal using the module. That way the module code becomes much smaller and everything that you wrote on your model layer can go to Drupal 8 basically unchanged. In an experiment we did for a media publisher in France already two years ago, they had a large Drupal 6 site in production and I was tasked with creating a new commenting system and didn't want to do it in Drupal 6. I was already ready to do a Drupal 8 work. So I created that code for the then current version of Drupal 8 using this type of logic and only coupling it with a stub for Sylex, one for symphonyful stack and one for Drupal 6 which was the actual intended target. When the code was delivered, we found that the Drupal 6 specific part was only about 20% of the whole set of code that had been developed, meaning that 80% of the code and hence the cost could be reused as such on Drupal 8. That means dividing the total cost of upgrading from six to eight by a factor of five. This is a major. Also, this code in many instances will be of higher quality than what you usually wrote right in Drupal 6 and 7 because since it's written as components receiving services by service injection using inversion of control, that means that you're never pulling information from the environment but it's being pushed into your code by whatever adapters you are bringing. And then this code can be unit tested and writing PHP unit tests is much, much simpler than writing tests with simple tests. If you've tried it, you know what kind of pen that is. There's a very good text and a MOOC available on this which is engineering long lasting software by Fox and Patterson. If you are interested in the subject, I suggest you look at it, it's an edX. Now, if you have this project on Drupal 7, how do you make sure it will be ready for Drupal 8? The first thing is that you have to build a data inventory. Until Drupal 7, we basically had two types of information identified which were content and configuration and it took us several years over the course of development of Drupal 8 before identifying that there were more types of data. So what are the equivalent? If you have content which is usually well known like the terms, like users, like nodes and terms, if you can, you should create custom entities. And then when you are building lists of this content or creating a mutator methods on these contents, you should never use any SQL because you may not know, but on Drupal 8, there exists a version working on MongoDB without any SQL at all. So if you can imagine running a SQL in your code, that means it wouldn't work with that version. On the other hand, if you use the entity field query system to provide access to your custom entities, the one which implement your model, then you will be able to reuse that with a new entity query system in Drupal 8 which is quite similar to the one for Drupal 7, but is compatible both with SQL and no SQL. Configuration in Drupal 7 and before was mixing several different things actually. The best known API for that is the variable functions like variable init, variable var gate, var set. And the problem is that these were used both for the configuration properly, like what is the site name or what are the fields I have had it to my content type. But also for the state, like what is the time of the last run run? These have been split in Drupal 8. A good way to be ready for this with your Drupal 7 code is to use variable module because variable provides you an API which is quite close actually to how CMI works when to access the information. The default which you always need to put in variable gate is no longer there because it's declared just like your defaults are declared for config in 8. Another type of data which you already know in 6 and 7 is cache. Everything in the cache API in 7 has a Drupal 8 equivalent. The Drupal 8 API for caching is much more evolved than the one in 6 and 7, but as long as you use the Drupal 7 cache API, you have equivalence for everything in Drupal 8, so feel free to use the cache API. You can just reuse that type of logic. State information, as I mentioned, is the type of things which is relevant only to a specific instance of a server, like I'm on the pre-production server, which is the time the chron was run last. This is completely irrelevant to the production server. In Drupal 8, that will still be a variable, of course, but what you can do is write a custom state service. It's about a few tens of lines at most that you will build on top of the variables. And then, since you have separated them, the day you move to Drupal 8, you can just unplug your custom state system and use the normal Drupal 8 state API. Settings, which are the things you find in your settings file in both versions, have not changed much, actually. The main difference is that in Drupal 8, they are no longer merged into a configuration, but other than that, there's not much to change. Finally, session storage is coded differently, but it still uses the same type of logic. In short, the idea is to think solid. I don't know if you're familiar with the algorithm, this acronym, but it means that code, which is using the single responsibility principle, which applies the open-close principle, which enables list of substitutions, that honors the demater principle, and provides single responsibility. Practically, this means that we talked about the model entities, which represent the entities in your problem domain, and then you have the processing, the logic. This logic should not be made of functions, but it should be considered as a couple of logic plus configuration, and this is what symphony and Drupal 8 call a service model, because that way, any service can define what other services and parameters it depends on, and then it can receive this by injection, which makes it possible to create these services by configuration, push them to your model objects, and then have them be mocked when you are doing tests, making tests easy. To do this, what you need is typically a core service, which will be a replacement of domain Drupal core functions which you use all the time, like L on T, and a few others. It's about 2,200 lines if you look at it. It's the barest code, the barest fraction of the Drupal class in Drupal 8. Just use what you need very often, and inject it instead of calling the functions. As you may have understood from what I just said, always use inversion of control. That means do not in your code ask Drupal for something, but make sure that when your model object is created by Drupal, it receives what it needs. Data, push data into your model, and then have it work with these methods instead of having the code be triggered by Drupal and fetch data from Drupal. That way, you are in charge of what gets passed to your model, and you can really test it in isolation and put it from one version to another by just changing the way you initialize the injected values. How do you combine that with functional code? If you think of a hook, say for instance, you are trying to implement a behavior when your user logs out. This is a hook user log out in Drupal 8, much like in 7, actually. But in Drupal 8, you have access to a user's proxy service in Drupal 7. There is no such service. So what you do is you implement a service manager which will instantiate your services based on configuration, and this is what you call in your hooks. When you are in the hook in functional code, you fetch the service manager. This is a single-ton pattern most of the time, and you ask it, give me the service, and this service, you pass it, the values you got from the hook, and you invoke the methods on it. Finally, how do you organize the code? Well, again, you don't want to have these big, these huge module files and the includes that you load manually here. You separate everything. If something is a hook menu, it becomes a controller. You put it in a controller class within a specific namespace. If it's a form, instead of having your form builder and your form validate function and your form submit function, you put that in a form class, and you do this for every controller, that is an entry in a hook menu, or in every class that you are going to build, every form that you're going to build. Again, I'm still seeing the same thing. There's an excellent talk that Boyan Zivanovich from Commerce Guys gave on this topic, which goes into much detail on how to write such componentized code. Or you can just look at the Commerce 2 source code which is built on these principles. As I said, in the module code, you then have just the hook implementations which receive data from Drupal and pass them to your model. This is the key because this is small and this is the 20% you will be throwing away when upgrading and not in your full logic which is in your model which will be carrying along with you to Drupal 8. One thing which can ease this for you is a module by Fabian X who essentially recreated dependency injection container much like the one in Drupal 8 but standalone for Drupal 7. It's called Service Container. It enables you to write symphony-like services and inject them to your code on Drupal 7 already. It enables the whole type of workflow I just described. Finally, this is maybe less important but with Drupal 8, we've started to get off our island as Krell has been saying and we apply most PHP standards. In module code, you had to do require once and require once, you loaded your files manually. Now, no longer use this, rely on an autoloader. We have a very good autoloader in Drupal 7 which is called ex-autoloader. It will just use the same practice as Drupal 8 so any logic you implement using PSR4 can be loaded the same way from 7 to 8. For logging, we had the custom API watchdog but now there's a standard which is called PSR3. There is a PSR3 logger module on Drupal 7 use it instead of using watchdog although down below it still uses the watchdog API. Your code will be using the standard PSR3 API and it will be portable for eight. Same thing, there's a recent standard which has emerged which is PSR7 for the processing of any HTTP workload be it client or server side. It can replace Drupal HTTP request and anything you need to perform as HTTP client. Finally, as I said, PHP unit is much simpler to use than simple test and works the same in Drupal 7 and 8. As I said, the Drupal 7 cache API is entirely included in the Drupal 8 API but the Drupal 8 API goes much further. It has tag support which is not so well known outside Drupal and it has the completely new and groundbreaking context notion which is a Drupal 8 specific. It can be good for you to at least understand what these contexts are about because it will enable you to write code that will be ready for it to handle cache invalidations which are one of the two big problems in computing usually. It will enable you specifically to do this, to prepare the cache metadata which are the big innovation in Drupal 8 which extends the render cache mechanism we had in Drupal 7 and which are what enables Drupal 8 in spite of its mass to be almost as fast as Drupal 7. As soon as you add this data in Drupal 8 it enables caching at very smart level of operation and if you do this in Drupal 7 it will just do nothing but if you think of what this means when you are working developing your code on 7 you will start to gain the benefits when you migrate to Drupal 8 and it won't help you when you're still on 7. One thing which is a change there when you are coding your pages or your forms is the habit of using Drupal at JS or Drupal at CSS quite a lot. This is going away in Drupal 8. You must start to think in terms of attaching these libraries instead of adding them in order to enable cacheability. And finally Markup, as Ashraf said you may want to use and tweak to simplify the Markup layer of your theme and of your project but this is probably the least important part of it all because by the time you need to upgrade the site to 8 you will probably want to get a new design anyway and this will have to be redone. If however you still have to do this for some internal reason it's good to think about SMAC's classification for your CSS and the BEM naming standard because that's what Drupal has been using for Drupal 8 for at least three years now. It won't be of much help for your Markup and the actual layout but it can help if you are developing plug-ins in JavaScript. This was the hardcore part of coding and now assuming you have an existing Drupal site how can you make it more ready to upgrade even if it didn't already apply this practice? So first of all you do your best to clean up the custom code you have written and apply these practices but I won't even try to go ahead and summarize that. But additionally, on especially large websites you've definitely created content views, content types, fields, et cetera which maybe they were used before but they just aren't used anymore. This is a good time to go ahead and actually delete all of them because when it comes time to set up your migrations that's not the time you want to be trying to figure out which views do we really need. So go ahead and delete the views, fields, content types, groups, themes, et cetera that are actually providing no benefit now and furthermore even if they are publicly displayed see if there's ones that can be nonetheless removed that you aren't really getting a benefit from. And obviously this extends as far as you can extend it really if there are modules or rules that were created that aren't really necessary go ahead and remove all of those as well. Additionally you shouldn't have been doing this anyways but sometimes it happens. Make sure that you didn't edit any contrib modules or core itself directly especially without using documented patches and if you did go ahead and create patches out of the changes you made. Do a diff between the current, the same version of contrib and core export the work you did into proper patches, submit them to the proper places and that'll simply just make it a lot easier to replicate those edits in the next version. And also go ahead and build a content inventory. Essentially do a full audit of the content that you have and organize it, be aware of it all and be ready to have a plan for it for your migration to D8. Okay so we've been talking a lot about getting ready for Drupal 8.0 either with site building or with coding and maybe this was a bit hard on the code part, I'm sorry about that. But then we are all waiting for Drupal 8.0. Driz told us two days ago that RC1 was only a few days away now since it ends due for the 7th of October. But this is not the ultimate horizon. We've been waiting for it for almost five years now but this is not the end of course. Coming with Drupal 8.0, the community has been developing a new release policy. We will no longer be just applying trivial minimal updates with each release which come monthly but we are going to have twice yearly releases and each of these will be including new features. For instance I wouldn't be too surprised if version 8.1 would include GraphQL for instance which appears to be a killer features in upcoming Drupal releases. So this was about getting ready for Drupal 8.0. Now you must start also to think about getting ready for 8.1 and 8.2 because these updates that you previously had like Drupal 7.1, 7.2, these will now be minor updates like 8.0.1, 8.0.2 to emphasize the fact that they are just bug fixes and changes are coming and they will be coming much faster than we had in previous versions because we now have this time boxed development process in which we have these twice a year releases. Business wise that means that once a site is delivered it should no longer be the case that it's considered to be finished until it has to be redone. A site should no longer be going on for years with just maintenance but it should be considered something that evolves. It's a product which can take advantage of new technologies which will appear every six months and technologies which can be used to provide new values to the site applications to the users of the site actually because this is the type of the new agility that Drupal 8.0 is supposed to provide for all of us in the community and for our users. And to help with this we invite you to come and take part in the sprint tomorrow to help with the release of Drupal 8.0 and the contributions. Thank you for your attention. Thank you all. If there are any questions there's a microphone in the middle of the room over there. It's only a quick one if you've got the slides up somewhere on your page for us to review. We have not shared them yet but if I still have the ability to edit the session page on the Drupal.com page I'll go ahead and upload them. Okay thank you very much. Thanks for the session. The question is can you share some of the best practices of converting Drupal 7.0 page callbacks to symphony like page controllers and actions? Okay so the question, I'm not sure I heard it well is those about how to convert page callbacks to controllers. Basically you see it's mostly a question of wording because fundamentally what you have in hook menu when you declare page callback you are effectively declaring a controller. When you write it in Drupal 7.0 or in Drupal 6.0 this is a plain function which goes in basically usually in your module file or in include if you declare it with an additional parameter. And this function receives the parameters from the actual request for which it is being invoked. The change in Drupal 8.0 is that it will now be implemented as a method on a controller class. The good practice for this is for these controller classes to be created using a static method called create which receives the service container. This factory method on your controller class fetches all the services it wants from the service container thus using it as a service locator which is an anti-pattern for most cases except for factories. And then it adds these services as properties on the controller class. Then when your controller is invoked like the page callback used to be called it receives the arguments which were declared for the root which is declared on the routing.tml file. And it then can use all the services that were created by the factory method because they are available on the controller instance. That way they can use any feature they need because it has been designed into the controller class without having to call Drupal core. That means the services were injected to the controller object and then the controller method just accesses these objects. That means that your controller is now testable. And of course you usually want to return either a symphony for an HTTP foundation response in which case you bypass the theming layer. This is useful if you want to send XML or JSON for instance. Or you can return a render array in which case you trigger the whole metadata cacheability system. Or you can just send anything for which you implement an event listener which will enable you to do custom rendering as long as you recognize that the output of your controller is in a specific format. For instance we have been working on a project for a customer which is entirely XML based. And in this case the controllers return an XML object which is a subclass of DOM document actually and there's a view listener which recognizes that the response is not a render array, is not a symphony response, but a DOM document and then handles it and builds a symphony response from it. And this enables you to build your own completely custom rendering for just any type of controller. Does it answer your question? Yeah, it definitely does, thank you. When you mentioned XML just now was that for Drupal 7 or 8? No, for 8. For 8, okay. Another question, a quick one. Do you know if there's a backboard, any sort of backboard of Drupal 8, CMI and D7? Anything that supports say, you know, strong arm exports, variable exports in the ML files? I'm not aware of that, Ashraf. I believe there is, but I don't know that it's widely used. So I think there is, but I don't know that I would use it. Gotcha, do you happen to know the name or like is it a sandbox project or something? I think it's a module, but I'll try to find you after and look it up. Thank you. I don't know whether this was covered. I got sidetracked with something important with work, but did you cover patterns module in your presentation? So patterns is a module that you can export YAML in Drupal 7 sites. So for configs, it might be worth a look. Well, I've not used it and actually when you are working with Drupal 8, exportability for your content as well as your config is provided basically with core. All you have to do if you want to export data as YAML for instance, say is you declare a dependency on the serialization module and in your controller, what you do is you take your data, say it's an entity, you do an entity load and you say, you pass it to the serializer and you say serialize this and the serializer will automatically find the proper normalizer which will transform the data to an array and then invoke an encoder which will put the data from the array to your target format. This is really a two line affair. Okay, well, the point I was coming from is if maybe I wondered whether it's possible to, or if it was possible to, the exports from patterns on a Drupal 7 site could be used on a Drupal 8 site. That might be a consideration perhaps as part of this agenda of building a Drupal 7 site with Drupal 8 in mind, that was what I was thinking. I wonder, I wondered, I don't know, I don't know and I'm not saying you know the answer but it might be something for folks to go and look at with the patterns module to see whether the output of that patterns module in terms of YAML could be then imported into a Drupal 8 module. And just another thought I had was with panels, I wonder whether with panels you can export that as features in Drupal 7. And another thought that people might could take away is I wonder if it's possible to, if instead of you could, in Drupal 8, instead of exporting panels as YAML, you could export panels as Twig, you know, and then build, I know it sounds far fetched but you know, just with an idea. So there were a few things mentioned. I want to repeat some, I keep forgetting to repeat them because this microphone is recorded on the video. So the pattern module was mentioned for exporting YAML with the idea. Exporting YAML with the idea to perhaps use that YAML in a Drupal 8 site. Right, with the idea to perhaps use that YAML in a Drupal 8 site. And there was also a mention of ideally exporting panels potentially using features for a Drupal 8 site. Yeah, output Twig from panels. Potentially output Twig from panels. I would have to say that I would think that one's rather far fetched, especially because it's a big deal in itself just to get panels to D8. And I don't know about exporting features to be used, you know, from D7 to D8. Yeah, I'm not expecting any answers, but I just thought let's throw the idea up there. My people think, oh that's interesting or not. But yeah, I agree. The latter one is very far fetched. So yeah, thanks for repeating on that. Again, great talk, thanks very much by the way, cheers. Thank you. Yeah, my question is, I'm not sure how easy it's gonna be to do something like export a view from Drupal 7 to features and then kind of import that features item into D8. And similarly with a content type, because for me, if I can do those two things then half of my migration is sorted. I think actually the migrate module is what you should be using for migrating views as well as content types from D7 to D8. And I believe that the migration paths are relatively far along in that grade. It's migrate Drupal, the other module. Migrate Drupal is the module name. And the question was about exporting views and content types from D7 to D8. And the answer was don't use features, use the migrate module. Go ahead. Thanks for the great session. I have an answer and a question. The answer would be the back port of CMI to Drupal 7 is called configuration. The machine name is just called configuration of the module. The question is what would be the best practices when it comes to multilingual websites? For instance, in Drupal 7 it's been notorious in multilingual capabilities, whether we use internationalization modules, translation management, and entity translation. So I'm aware that Drupal 8 has been much better in translation, so should we rely more on entity translation or on internationalization? What will be better when we migrate to Drupal 8? The first thing, I'll repeat the easy part. The name for the CMI back port module to D7 is configuration. At least that's the machine name or the project name on Drupal.org. Do you have information on the? Neither of us seem to know the answer to your other question on how to best create a multilingual site in D7 to make it easy to migrate to D8. I know that the migrate module itself has, I believe, a good amount of work to go for it to be able to smoothly migrate multilingual websites. I just have a question from a business point of view. So if your long-term plan is really to migrate your site to D8, and chances are there are new things you need to learn about how to do things in D8, and then your project still requires you to do something that works in D7, and I think what you said is just like trying to do a D7 site in the D8 way, like writing containers and services and those attached indexes or things like that. So I mean, how do we balance this extra effort? Because obviously, you may have really material ways to do things in D7, and then when you do these new things and you still have to make sure that they work in D7, and then what level of testing or trial do you need to do to make sure that they do, they will definitely provide benefit when you try to migrate, and still it's not a massive headache when you try to make them work in D7 as well. So I'll repeat the question. When taking these additional steps for your D7 website and making it migratable from a business perspective, how can you ensure that there's value when you, and how can you ensure that you are going to benefit from writing code in the portable manner in D8? Like how far do you go with testing and et cetera to ensure you're building your D7 site correctly, but also that your code will be beneficial for D8 migration? And actually, I think the answer is twofold for this first. When you are at the step of building your products, it's usually easier to just increase a bit the cost by maybe a few percent to allow for future migrations because it will be easier to have a few extra on a big budget already, than it will be to get the funding for the next operation which will be proportionally smaller and then harder to finance for extra work. So that's just from a financial point of view. Technically, however, as I said, it's rather easier to write Drupal 8 code for the reasons I outlined. And that means that if you are working on a large Drupal 7 project, and by large, I mean something above, say, the 300,000 lines of code just to give a number, maybe half a million lines. Typically, you are writing this code in this new way, the future compatible way, should be shorter than writing it in 7, although there's an upfront cost, as you mentioned, because what you will find is that you have less regressions. Regressions are the most costly part of large Drupal 6 and 7 projects because of all this flat code and the dependency hell we have within it which has been mostly resolved with the services model. So in short, if it's a small project, as Ashraf said on the point is to choose the strategy, there's not much value in creating it Drupal 7 plus, as we said, because the upfront cost, which you mentioned, will be high in comparison with the total cost of the project. On the other hand, if it's a large project, that relative part of the upfront cost will be small in relation to the project. It will be easier and you might even gain some smaller development time than you would have with just the classical Drupal 7 way.