 Okay, welcome, welcome amigos to DrupalCon, of course. And we're day two, so I hope everyone's having fun. We've been having fun, so. We're here to talk about migration into Drupal8. Some people say that there's no migration path in Drupal, but that's not true, so we're going to talk about how you can actually get stuff into Drupal8 today, and we will talk about what's coming in the future. So, my name is Ryan Wheel. I work based out of Montreal in Canada, and this is my colleague, Novella. Maybe do you want to say hello on a Spaniard? Hello, my name is Novella, and this presentation, of course, will be about migration. As Ryan said, we work in Montreal, and we are two thirds of the cafe team. We do a lot of migration, and we are very interested in migrations, especially for Drupal8, mostly because it's a lot of fun. Okay, so what is migration? How many people have used migrate in Drupal7? Is this familiar to people? Okay, roughly half, probably, okay. How many people are missing some chunks of hair from this migration experience? And how many people have upgraded Drupal sites in the past, using the upgrade.php page? So, a little bit more, but about half as well. Okay, so migration and upgrade are different things when we're talking about this stuff. Migration is a set of templates that you can use to port your data, and it ports your data by connecting to your old data source. And in this case, we're going to be talking about Drupal6, because that is what is currently in Drupal8 core. There is a plan to get Drupal7 to migrate as well, in addition to other things, so let's talk a bit more about that. In Drupal7, there was a package called migrate Drupal2Drupal, and this was a set of templates for bringing data from Drupal5, Drupal6, and Drupal7 into Drupal7. It was originally done as a proof of concept for maybe doing a new migration path, and it's now been declared the new standard, so that old upgrade.php page is gone, and that one, it used to work that you would take your Drupal6 site, and you would just drop your D7 site on top of it and run upgrade.php. So it's a little bit different now that we're actually connecting to an old site and not changing it at all, but just changing our new site and using that. So a little bit more about the Drupal2Drupal templates is that if you were using them in Drupal7, they are object-oriented, which is great news for many people. Obviously, the Drupal8 system is more object-oriented and they continue to be so in Drupal8. So it's also worth noting this happened later in the development process in Drupal8. It was actually after feature freeze, I believe, that it was decided to put migrate into core, so as a result, some things are still in progress. Now, you may have noticed, I talked about Drupal6 as opposed to Drupal7 as the initial path, we're now able to skip over versions. So this is really great when you're looking at older sites that are now nearing end of life. As many of you know, when Drupal8 gets released, in theory, Drupal6 will be no longer supported for security updates, so there's an urgent need to move Drupal6 sites to something else, and rather than drag people through two versions, which can be very difficult to upgrade, we can skip right over that and just say, okay, we can connect to D6, pull all of the data out, and make a wonderful new Drupal8 site. So there is still a plan to kind of replicate that old upgrade.php page with all of this working magically under the hood, and that is currently flagged for not 8.0.0, but the 8.1.x release. So it may or may not be there in 8.0.0, but before you go and say there's no migrate in core, there is actually two migrate modules in core. The migrate module that runs the migration is there, it's working, it can be used today, and then the migrate underscore Drupal module, which is the equivalent to migrate D2D in the old version, and what that one does is that has all of the mappings in D6 to say a D6UID is going to become a D8UID, and it has mappings for each of the fields so that you don't have to do that. So here's what we're looking at for version support. Currently D6 to D8 is in core right now, and it has been for months. D7 to D8 is in the process of development, and that's happening in a sandbox off of the main migrate path, so what's going to happen there is people are going to build the templates to a point where the quality is really good, and then those will get brought into the migrate underscore Drupal module in D8 core. The templates between D6 and D7 are not very different, so it's probably going to start moving very fast in the near future. If you're interested in helping with that process, we'll give you some information at the end of this presentation on how you can connect to people that will allow you to get in there into the sandbox and work with that. And lastly, D8 to D8, because sometimes you need to rescue projects, and in D7 this became a really popular option when you take on a rescue project and you go, okay, well the data's in that D7 site, but the code in that site may not be what we want to use. So for people that were doing rescue projects, having a path within the same version is very important, and there is also talk about using migrate to do migrations between the different beta versions of D8. I still haven't seen any templates for that yet, but this little rumor has been around, so it's something that's out there. And then lastly, I put an asterisk here that of course D6 support should in theory stop when D8 is released, but there's also been some discussion about extending that temporarily for a period to allow people to do that transition, but there's really an imminent need to move away from D6, because as security updates get applied, there's not as much testing framework in D6 to make sure that that's all stable, so there's always a risk every time we make a change. So in the long term, we would like to see D6 kind of move on. Here's the exciting stuff. Do you want to talk a little bit about this? Yeah, I can talk. As it says, everything that's in D8 core now will be pulled in from D6, even if it was in contrib for D6, but it's in core now, but I don't know, definitely. Configurations is a very important part at least for site builders. One thing that has been very troublesome for D7 was to have to replicate every click manually. For D8, that's not something that you really have to worry about, and that comes over with all of the data that's been put when you migrate. Multilingual is a big aspect of this, as many of you have probably heard today. The new multilingual system in Drupal 8 is, as Gabor describes it, a wonderland. It's so much easier to use than other systems. D7 was well-supporting for multilingual as compared to other content management solutions. D8 goes way further with this, extends it throughout the system, so all aspects of the system can be translated, but in the old system, you needed like 10 modules, 12 modules, 15 modules to make everything translatable. Almost everything's translatable by default now. I can't think of a single thing that isn't. So that stuff was contrib, but because it's now in core, we're actually reaching back into the old system and we're grabbing that contrib data and pulling it in. So. So, pro tip, if you had a contrib module in D6 that is now in core, even if you disabled it and uninstalled it, you think that it went by-by you might not have completely done so. So, for instance, one really big thing that people have run into is the book module. You know, in D6, a lot of people had it on, then you turn it off, you know, will you use it? Now it's in core, so remember to enable it when you go into D8 when you're doing your migrations. Otherwise, you'll just get a whole bunch of pro. So this is kind of an open bug because what happens here is that in past versions, we always supported moving the data forward. So if you enable the module that's in core now at some point and you have data there, we want to bring it across, but it needs somewhere to go. So if you don't have the target module enabled, you're going to need to enable that. There will be better support for catching those errors in the future, but something to watch out for. A couple other points on this note. Views were initially talked about as being maybe an exception to this, but currently they're not in core as being supported for the migration, but there is work being done on making a migration for views. I guess it's also worth noting that your content types get set up. If you were looking at your D7 migrations and thinking I have to set up all these content types, you don't even need to do that because the idea is that when we do have that replacement for upgrade.php, which we'll talk about in a minute, the idea is that we have the same process. So you should be able to go to a page and click upgrade and bam, everything's there. So this stuff should come through. Another example of areas that are kind of tepid support is migrating your blocks, blocks come across, but if you're not using one of the default themes, we don't really know where to put things. So what's going to happen is your blocks are going to come across and you're going to have to place them in your new theme. So something to watch out for as well. There's even more wonderful stuff in Migrate that handles the multilingual stuff because multilingual structures have changed. And the biggest one of these is that in the past, if you had translations, you would have one node for English and one node for Spanish and they would have to know about each other. And sometimes you had to do the node in English before Spanish or in Spanish before English and it always had to be the same process. All of that is gone. It's now one node. So if you have a car in English and an automobile in French, you know that it's one object. So now in Drupalate, they are one object. So during the migration, all of these pieces get merged into one object. So one thing to watch out for them is when you're bringing things over, say you had however many nodes because you had X number of languages, now they will all be one node. So if you don't see them, don't worry. Yeah, you'll see them in the interface and we'll show you an example of that in a minute. Configuration of translations should come through as well. There's more details of that in the config management side of things. So just kind of be aware that that's out there but most importantly, test these things a lot because not everyone has multi-lingual sites. I suspect many people in this room do. So you will want to run some tests on these things while we have the chance now, maybe at the sprint tomorrow, you can come and try running some stuff, try it in your own time, try it on your agency sites and report issues if you find issues with particularly multi-lingual migrations because sometimes these cases don't get covered as I'm sure we all know if we work on multi-lingual sites. So now let's talk a little bit about how this is envisioned to work in the user interface. So first we need to know that we need to enable the migrate and migrate Drupal modules and we mentioned just a second ago that you do need to have all of your target modules enabled so if you were using aggregator, make sure that's enabled. If you're using book, make sure it's enabled. Translation support, make sure it's enabled. Then you're ready to go. One thing that's definitely tripped people up while they're getting things set up was just the PHP and Dresch versions. And I know people are always harping on this and I'll do it again. Make sure that your PHP and Dresch versions are proper for Drupal 8 because they are a bit different from Drupal 7. So yeah, first step, install Drupal 8. Second step, enable all the modules. And then third step is make sure you've enabled migrate and migrate Drupal. And now you're kind of ready to do the basics. We're gonna go one step further though because in this initial part of our presentation we wanna talk about the migrate upgrade module which is the replacement for the upgrade.php page. So migrate upgrade is contrib at the moment. This is the one that will be merged into probably 8.1.x and it replaces upgrade.php with just slash upgrade. Now, we couldn't put .php because then we would have to put a file there. And right now this is just a config page in Drupal so it's great, we can just use this. It's gonna ask us to input our credentials for the D6 site. So it's important that these live on the same host because that way it can run really fast and we don't have to worry about firewalls. You don't have to worry about the wifi stopping. We don't have to worry about any of that stuff. We do need to put in an address where we can access the files. And I believe right now at the moment this interface also uses this to do some text handling. So it may look for this address pattern in your body text and other things like that. But in any case, you do need to have your files somewhere and you can put in a path as well for your private files. So of course in Drupal 6, I think you had the option of public or private and then there was some hacks you could do to do both but they were kind of weird. But it's in core and it has been since D7 so private files can be put into this interface. It's the public files, if it throws an error with the public files address that you stick in there through the interface, you may need to put a snippet of code which you can copy and paste for me in your manifest file which we'll talk about in just a bit. So yeah, so right now we're looking at the UI and it is the most buggy part of the system. So let's just, let's get through the UI and then let's get to the good stuff. So this is what the migrate upgrade page looks like. We put in some database credentials and an address and then we go, we scroll down if you can imagine, we're not doing a live demo here. There's your public files directory and then it just says perform upgrade and then things are gonna run. The configuration is going to import first because we need our node types to be there so that we can put stuff into them. We get the site name, we get like all of those types of settings, we get your like whatever preferences you configured when you first installed Drupal are all gonna come through and be like what you set them to and then there's a hook that runs that you can take advantage of which we'll get into more later and you can use the hook to override what's being done in this if you don't want to, if you want to minimize the amount of code you want to do if ideally you don't have to do any if you're running it this way. And then boom, it's just gonna do a status bar and it's gonna run. In D7, it was discouraged to run stuff in the user interface due to a bug in batch APR that would time out on you and die. It doesn't do that anymore. So because this is what we've always done in Drupal as we've gone to the upgrade PHP page the intention is it will work in this way. So we are working out all the bugs and that is hopefully going to work perfectly. This is a snapshot of kind of an older version of the upgrade process but it's pretty much the same. It's gonna say yay everything worked. It might tell you if something failed here it might say like a couple things failed. Things go into the watchdog now. So if you're like okay where do I find out what happened? You can just go to the watchdog like everything else and that's on the reports page as we all know. So and then I put in this special slide because of what we said earlier I wanna point out we've got three nodes here but as you can see we've got five entries and what this was in the old site this first one was language neutral so that appeared on all languages. So that's node one. The second node had a translation so node two and three on the old site was like a French version and the English version. So we've got links to each of those but they're actually one node under the hood and then we've got a third node that was also translated and again that's showing as two entries in the interface but in reality it's actually one node. So if you hover over those edit links you're gonna see that the node IDs there's actually only three of them there but that's what you want and in D7 this was called entity translation. So if you've used entity translation you're probably gonna be very excited about this. Okay, do you wanna talk a little bit about Drush? Yeah, so maybe you can tell most of my comments are geared toward site builders and this is actually something that I've tried to convince other site builders of but do Drush use it and use it wisely of course but this is one place where you really do want to use it. As you saw in the UI it was very simple you put in your database credentials and you hit go and you just cross your fingers and I've done a lot of test migrations on the Drupal 8 path and I've done it both in the UI and with Drush and one thing I found was that when I did it in the UI if something screwed up everything would stop. With Drush, luckily I can run it but I can make sure that I'm only running one piece at a time and that's really nice and of course that is Drush for the combination of the manifest file which we'll get to in a second. You can do both Drush and the user interface just to see what's really going on behind the scenes but this is basically just a plug for using Drush as site builders. So this is what is if you want to just use Core and not use that contrib module this is the way that people are usually building the migrations and testing them in real life. This is what the developers are using. So as developers this is the most accessible thing to most people. Now there's a few components of what's happening in the background. The first thing is that in order to do this in Drush you're going to need a manifest file and that's just a YAML file, it's just a text file that lists out the names of migrations. There's a bit more detail of that but think of it just as a list of migrations you want to run. There's a hook which we mentioned earlier and you can use that hook to look at each item that you're pulling through as it comes in and if you don't want it you can say bye bye. I don't want this one. I don't want this node type. I don't want this particular node. I don't want this setting to come through because I'm gonna do that myself. This is the type of stuff that's very useful when you're building a site because maybe you want an entirely new site and you just want the blog posts. That's important so you could use the manifest file to specify what migrations to run and then you can do a bit of processing just using a hook. By doing that you can just put things into a .module file and just implement a hook which is something that's very familiar if you're using Drupal 6 or Drupal 7. So that's like the easy way to get into this without having to learn a whole bunch of crazy new things. The thing about the hook is that even if you are using Drush and a manifest file all your fields, for instance, may try to run at the same time. And I know recently I've had a problem with running the image field as opposed to text fields and integer fields and things like that. So I just used a hook to print everything out so I could really narrow it down and see what I needed to exclude in order to make the other fields come through. And that's a really great process for debugging which is certainly necessary now and will probably be necessary even when things are a lot more stable. Now the last thing which is really where Migrate gets really awesome compared to the old version is the plugins. And if you haven't used plugins you should use them because they are awesome. Plugins in Drupal 8 are just files that live in a special directory where they're known to be. So in this case they could go into your custom module under the source folder, under plugin, under Migrate and then further into one of three different folders depending on what type of plugin you're using. And you can go into the Migrate or you could go into the core modules Migrate folder or the Migrate underscore Drupal folder and find examples of these and just copy them into your own module if they don't do what you want. And you can make them do whatever you want. All you need to do is make sure you update the name which appears in the comment and install your module and then you have a new plugin. Plugins can then be referenced in your manifest file as an override. So there's lots of opportunity here to just take something that's close to what you want and either modify it with a hook or just go and create your own implementation. I know with Drupal 7 we had people write migrations for WordPress, for Joomla, for Microsoft SQL Server things, for XML, all sorts of different handlers. So you can go into your Migrate underscore Drupal folder, look at all those implementations and go, hmm, I bet I could write one for some other legacy platform and you can make a module for that just by copying those files, renaming them, changing exactly what the schema of the database needs to be to make it work and registering your own migrations that way. There's also things called process plugins and these are things that you can use to modify things as they go in so you can do things like change all the titles to lowercase and again you can just reference that in the manifest file. So there's lots of cool things that you can do with that. Basically it's all plugin based so you can just remix these things, you can chain them, you can say change all the titles to lowercase and then add three numbers to the end of it and remove all the spaces and you could just chain all these plugins together. So it's very extensible in that way. A manifest file looks like this, kind of ignore the bullet points along the side if you will, but so we put it in the root but it could go anywhere as long as you reference it when you run the drush command and in this case we've just provided a short example but D6 user role, D6 user, D6 filter format, these can go in any order so you don't need to worry about what order they're in, you just put them there, these are the names of the migrations. If you wanted to change the process plugin that was used you could indent underneath one of those and change that by just saying what the process plugin you want to run will be. You could also change the source or the destination if maybe you wanted to turn users into nodes, you could do that but that would be really weird but you could do that. Another good thing about doing it with drush and using a manifest file to declare all these things is that when you run it in drush if you're missing anything in your manifest file it'll just tell you right there and then you just go put it in. Yeah, so it's gonna calculate the dependencies and it's gonna say I can't run nodes until I have users because there's a user field on nodes so I need a user to be there so it's gonna tell you you must run d6 user so this is very helpful. As well you can find out about all of the migrations, I've got a command listed here. If you're using the most recent drush of course it's very important to note actually we didn't have a slide about this. You need to have the latest drush, it needs to be drush seven and you install that with composer so you also need to get composer. And you get that from getcomposer.org I believe. Anyway. It's also the option of using the dripple.org slash tool. I think that is the correct URL. Yeah and Acquia Dev Desktop does have this installed as well and so you could use Acquia Dev Desktop to do your migrations in this way but you will need a bit of customization around the database connect string so we don't have that in the slide but it's instead of local host it would be, we're dumping a head here, it would be 127.0.0 colon 33, it's not 3306, 3307. I have this in a blog post if people need it they can feel free to contact me but in any case you can run drush config dash list and then do grep to narrow it down to only migrate items and this will list out all of the migrations that the system knows about and these are all things that can be put directly into your manifest file and then you can run the command drush migrate dash manifest provide it a database connection string. This should be familiar if you've used other things on the command line that connect to databases. It's a, so I put here d6 user colon d6 password at local host slash database name which in this case is d6 and then the path to the manifest YAML file. That should be enough to get you there. One thing to note is that on the slide although it's two lines, it should be one long line when you do it. Yeah, so that drush manifest, it's legacy dash db dash url all as one so just be mindful that the slides couldn't quite fit that long string in there. So now sometimes you'll need to customize stuff especially if you have a custom module that you yourself have written perhaps you have a custom field type. A good example of something like this that took a while to get support in d7 was the address field. So maybe you're moving address field into something else or maybe you're the author of that module and you want to make a migration path for your users. You can put your plugins into your custom module and then you will need to deal with the fact that this is a custom entity type. So like nodes, those are in every site, those are in core, we're gonna deal with those but if core doesn't know about it then we need to deal with it. Cleanup tasks like Novello was suggesting with like maybe you don't want your image fields to come through or maybe they're broken and you don't care. Cleanup tasks could be done with some customization as well. And then you could actually go as far as making some of your theme, like moving your blocks into the locations in your new theme. You could do some customization for that as well. So these are just some examples of things you may wish to customize. This is just a really rough look at what the hook looks like. So we were just running this before the presentation. It's really awesome if you just want to cycle through those elements and say, if the field name is this, false. We don't want it, we don't want it go away. It's like, we don't need this in the new site. So another thing that's kind of important if you're new to programming in Drupal 8 is that you'll see that instead of, like we have the row variable here and it's prefixed with the row type. Row is a type of object. So it's not an array like it was in D7. You'll have to look at the row method to see what the commands are to dump out all of the data if you are new to working with object oriented stuff. It's a fairly simple thing to do, but just like a fair warning that this is no longer just strictly an array as with many things in the new system. And just another tip, whether you're new or not, that you can run a drush print r with the hooks and that's what really helped us out when we're doing it all afternoon. We're just looking at things as they were coming through. Yeah, drush print r, drush underscore print underscore r and then you put in your variable there will give you stuff dumped out on the command line. It's a tip that works in Drupal 7 as well. So it's worth looking at if you are like, why isn't this working? And then you're like, oh, okay, those three ran and then suddenly that's where it went kaboom. Okay, and then you realize that maybe you have some corrupted data in your old system that maybe you wanna fix. We talked a little bit about plugins already, so sorry for jumping ahead there. One important point with when you do make plugins, you don't need to register them anywhere. You don't need to put them into your info file, nothing. You just need to put it in the folder where it wants to go. So if you went into core modules, migrate underscore Drupal, source plugin, D6, source, no, sorry, almost there. Anyway, you're in the plugin, you're in migrate, you're in source and then you're in D6. For example, you would put it in a like place. You'd put it in the same naming convention in the same folder in your own module. So really the only place then that you'll need to declare the plugin is on a post-it note on your wall so you can actually list those folders out. And if you've never used plugins, there's a really awesome way you can try and that is to make a custom block. Blocks are plugins in D8, so under your source folder, under your plugin folder, you can have a block folder. Go copy an existing block from somewhere you know that's easy to use and you can just put it there and change the name in the comments because comments are now code, weird. So some things that need polish. D6 migrations do have small bugs and that's what trips up the user interface. That's what trips up the migrate underscore upgrade module. So if you're able to go in there and do lots of testing when you're doing migrations for D6, please submit your patches to the core issue queue. If you have to jump over stuff, we've given you some tips on how you may be able to override that or just skip those things if they're not necessary for you. Template development is needed for Drupal 7 to Drupal 8 as well as Drupal 8 to Drupal 8 because that will be a thing at some point whether it's during beta or whether it's post-beta. There will be rescue projects. I'm looking at some smiles in the audience and it's like yeah, there will be, I know there's live Drupal 8 sites right now and those are obviously not on the stable version because there is no stable version. So at some point there will need to be D8 to D8 migrations. A major feature that existed in Drupal 7, well major features I guess I should say, there were things like rollbacks. You can't rollback right now. You just reinstall and start over. So build things in modules that create your site at this point in time and that way you can kind of keep moving with things, build and destroy, build and destroy, use continuous integration. If we're gonna go buzz-worthy, buzz words here. Continuous integration is wonderful for this because it already embraces that build and destroy methodology. There were things called incremental migrations. So you can rerun the migration twice, three times, four times, 400 times, that's fine. It's going to be additive. So if you've added new nodes, more new nodes will come through. But you can't do things yet, limit how many things you wanna import. So in D7, you could say limit 10 and you'd only get 10 nodes. You can't do that yet, but it was put on the roadmap at the end of January, so it's going to be coming very soon. All right, and as a silver lining to the no rollbacks thing yet, you have DrushSI where you can really just site and install one more time and that'll drop your database and do everything for you. And you also have DrushCEX, which is config export. Yeah, config export will let you see all the details. So if you're like, what's happening in D6 user? How did they set that up? How was it configured? You can either go into the module that created it, so migrate Drupal, and under config install that will be there. But if something has changed in the system, maybe you overrided something or maybe you want to override something, you can use config management to dump the config, see what's happening there, and then make some plans to change it. Not an expert in config management. I know there are people in the room who are. So I defer to them for more details on that, but rest assured that you can look at the YAML files that are provided by the system that provide the default implementations of each of these migrations. You can see the details of like this D6UID equals D8UID, D6, whatever the field name was gets changed into this new field name. Those things are all available to you. And of course, we've just said this many times, but it's worth repeating. Expect to re-migrate, expect to reinstall because it's not final yet. I know if you've tried Drupal 8 and then you've gone away for a couple of weeks and come back, you'll probably have to reinstall, so just be aware that that's gonna happen until everything is stable and finally like in that final 0.0 branch. Okay, so how you can get involved? This is kind of important because if you run into trouble, maybe you'll like wanna tap into the community who can give you answers really quick because they're like, oh yeah, we know about that or oh, we should deal with that and other things. And this is how you would also get involved in developing the D7 templates or if you wanted to build templates for other programs, other platforms to bring them into Drupal. So there's this Drupal groups page, imp, so it's short for import. I think it was an acronym at some point, but I don't know what it is. There's an IRC group. There's almost always somebody in this IRC group. It's pound Drupal dash migrate and it's on free node like every other Drupal chat that's in IRC. I believe if you've never used IRC, there's a page on Drupal.org slash IRC. That will give you details on how to do that. And recently we've changed the time of this, but there is a weekly call that you can do on Google Hangouts. It's important to join the IRC group before this call happens because that's how you get the URL. So that happens at 9 p.m. Eastern Standard Time, which I believe is where we are right now, at 9 p.m. So it's difficult to coordinate times. We're dealing with people in every time zone almost. It's just people are scattered throughout the globe and we've got people from Europe to Australia and everywhere in between and other places far flung all over the globe. So 9 p.m. Hope you can make it. It's a great place to get support for creating your own custom plugins and it's a good place to report problems in tests that you've run. If you're running a migration on multilingual data and you run into something that you think is unexpected, it can be good to check in in this group. So report problems, please. If you report the problems, that means it's gonna be automatically resolved for the next person if we're able to put some code in there to fix that. And one really important way that you can get involved come to the sprint tomorrow. Yes. And if you can't get Drupal 8 installed and you're like, oh, this is terrible. I can't get it installed. We actually built some virtual machines that we can spin up for you if you're absolutely desperate. I hope not to do a ton of these things, but if you're absolutely, absolutely stuck and you can't get it installed, do come talk to us because we would rather, people are able to get in there and do some work. So we will try to help you out with that. If your machine blows up and you need to use a tablet, we could actually support that, which is sort of ridiculous, but kind of awesome. Okay, so I mentioned this earlier, but drupal.org slash project slash drupal, I was getting mixed up with these issue URLs. Anyway, the core issue queue is where you put your stuff for the D6 migrations. For D7 stuff, if you're interested in that, we're gonna connect you with the sandbox and the stuff lives there for now. I tend to stay away from the sandbox myself because I like to just work with core. So again, just come to the IRC group, say hello, ask people how to connect if you're very interested in D7. And again, test, test, test, you're about to think you will stuff. Okay, we've mentioned this, yes. Very important point. Do you want to mention this last one? No, okay. It's a really big cantaloupe. I've been through the upgrade process many times and for my own blog it was on D5 and I moved it to D7 and I sat down at a cafe where I could make my angry face and someone would bring me coffee. And it took me like about six hours of like, okay, I went from D5 to D6 and there's bugs in the upgrade process and then I resolved the bugs and then I spent an hour looking for the image fields and then I was like, I guess I'll redo it. So I redid it. Where are the image fields? Then I realized there was only five images on the site. So then I upgraded to D7. All of these things sort of introduce like problems because in D5 the way that we error checked and validated things may be different than D6. So sites that have moved between different versions over and over and over, those sites are the riskiest ones to migrate and those are the ones that we need to test the most because we may not know that sometimes user names could be formatted this weird way that we don't allow in D6. But they maybe got through the upgrade process. It would be weird, but it is possible. So if you're planning on some site that was perhaps in Drupal 4.7 and then got upgraded to D5 and then got upgraded to D6 and now you're like, okay, let's skip D7. That's a great opportunity to test that site and contribute feedback because that's the type of site that's gonna have the most unusual data in it. And then of course, when I mentioned those five images, this is another good point. Novella recently did a brochure site for her mom. And it was like new content. There was really nothing to migrate. Copy and paste would work if you're doing a five page site. So it's worth noting, don't kill yourself on doing all this stuff unless you really wanna learn. And if it's a really small site, like there's always these other options, but they're not the most ideal. And if you do wanna learn this stuff for your bigger projects, then investing that time can be very valuable. Well, and just to put a plug in there for copy and paste, it's a really great way to learn the interface for D8. And the interface for D8 is excellent and I was able to actually teach it to my mom in one evening. So let me just say, it's for individuals, it's for businesses, for everybody. And that is a completely legit way to migrate your stuff. Yeah, so if it's a very small site, you may just wanna do this for research purposes. I mean, it will get you there, but it is worth noting, I mean, D8 is great for small sites. As Larry mentioned earlier this morning, it's like you can do big or small and all sorts of different types of sites. I mentioned doing continuous integration and we've kind of been working with this on a new site that we're kind of doing a mixed thing. So we're working on our own agency site. We have new content for most of the front end stuff. So we're actually using a module that we built that like sets most of our new settings and creates some of our new content and then we're using a migration for the rest. So these mixed mode kind of things will work with your continuous integration practices. So that's another thing to be mindful of and again, another reason to use Drush if you don't just want to like, boom, like import everything because nobody likes to like migrate and then have to do a whole bunch of little tasks afterward because then you have to remember all those tasks. And then if the project gets put on hold, you have to remember all those tasks and you can't sleep at night because you're remembering all these tasks. So okay, we're like at the end. I've got four links that I've been plugging since I was at Bad Camp and these things are things that you can use to teach yourself Drupal 8. And by teaching yourself Drupal 8, all of the stuff that we covered today will be really, really easy. The first is the developer guide that's on www.drupal.org. That one is edited frequently by people and if it goes out of date, please click edit and update it. But you can, if you're logged into Drupal.org, go to this page, scroll to the bottom, click the printer friendly link because it will render all the sub pages in one long HTML file and then you can just read it like a book and it's fabulous doing that. That will get you through most of the API changes that you need to know about as a developer and that will get you a background on configuration management, which is how all of this stuff, like the manifest files, how those are constructed, all of that stuff is configuration management. So if you read the developer guide, even the first couple chapters, you're gonna have a really good understanding of how you can override all of this stuff really easily. Examples module has been used for years. It's up to date as well. So if you're looking for like, how do I make a block in code? How do I do stuff like that? Go into that module if you're curious about how to do an implementation of something because there is up to date stuff in there and I actually went into the examples module and used those to upgrade the developer guide. Examples module is very up to date so that's very useful. The API docs on api.drupal.org are also up to date but this is the documentation that's generated from the comments in code. So it's useful but that needs to go through code review before it gets in. So there's less opportunity to just like add in a little like, oh, you need to do this also. Like it's harder to change that stuff because it's not just something you can click edit. And lastly, the most important awesome one on this list, change records. If you're going in and starting to code something for your site if you're doing a continuous integration module or just like, where did this go? I know one time I was trying to use the watchdog command and I was like, watchdog does not exist. Okay, what do I do? What do I do? There's no watchdog. I could know I shouldn't do any crazy things. I should go to the change records page and I just put in the word watchdog or whatever the command I'm trying to run that no longer exists, paste it into the search form and it's gonna give you a change record that says watchdog became this and here's how you use it, the old way and the new way and you can copy and paste that into your code and go home. That's also just a good general resource when you have errors. Sometimes they are just because something may have changed. So list changes, you can't find any issue queue or to search both. List changes is definitely a really great phrase to that. This can also be very useful if you started working on a droop late site and then you got distracted for two weeks and then it's broken for some reason when you updated and you're like, what changed? That's what changed. There will be entries in there that will say, these three things changed since you were here two weeks ago and you can just look at them and go, it's probably that because I'm using that function. Okay, cool. So change records, wonderful. Thanks change record team. And we've got a few minutes for questions. I guess five minutes for four minutes for questions. So Jess, microphone. So I have a correction slash clarification, a recommendation and then an actual question. The clarification, I just wanted to say regarding Drupal 8 to Drupal 8 updates and migrations. We didn't kill update.php, update.php is still in core. What we did kill is that you can't ever, ever, ever, ever use it for upgrading from one version of Drupal, like a major version like Drupal 7 to Drupal 8. So by default, when Drupal 8 ships, you will still be using update.php to upgrade from 8.0.0 to 8.0.1, for example. And also between betas, you'll also be using update.php. The same old, if you're a developer, you've written the module, you'll be writing the same old hook update and for that. But eventually you'd also like to include Drupal 8 source plugins so that you can do those Drupal 8 to Drupal 8 migrations as well. The idea being that when you're running a minor update, you don't necessarily want to create and build out a second site for that. Sometimes you just need to fix one little thing and so an update hook is all you need. So that's just a minor clarification there. So but in soon, update.php is still there, you just can't use it to migrate anymore. Then the recommendation is regarding views migrations. I worked in the views and core team on my Max Jam and I would strongly recommend that you consider just rebuilding your views in the UI after you've migrated the rest of your data. It's great that someone's trying to build a plugin for that but the views API is so complex, the data model is so full of things and not only have we, it's very different under the hood than it was in Drupal 7 but also that last link on Ryan's last slide about change records, we kind of sort of don't really have them. There's like two of them about minor things maybe and but like the major ones that tell you the important things that change aren't there so it's gonna be difficult to write accurate migrations for views for that reason. So you might wanna consider do everything else and then just rebuild the view because honestly it's probably gonna be faster than trying to fix all the bugs with it. And then my question, I don't wanna take up too much time but my question was about the manifest files. So you said that first of all they're not required, right? It's just an optional thing that you can add on, right? They are required if you're running them in Drush. It's the only way, yeah. And then the second thing was you said that it would give you an error message if you for example tried to put a line for importing nodes before users. Not the order but just if you omitted something. Or if you omitted, okay, yeah. So it will actually order them for you if you're not. Yeah, it will. There was a bug during bad camp where one of them was out of line and it was fixed. So I believe it was fixed at least. So it will automatically resolve all the dependencies and order them correctly but if you forgot one it will be like, oh I do need that, please add that. So thanks for those tips, that's wonderful. I'm actually one quick question back to you. Did upgrade PHP get removed and brought back in? No, it didn't, okay, interesting. That's okay. Cool, and yeah, rebuilding views has been something that yeah, we've often redone between versions so that is really important to know. So thank you again for those tips. It's funny. Okay, we'll direct to Novella. Una pregunta en Trupal 6, los pagos se guardaban en M5. Al pasar a Trupal 7 se guardan un hash. ¿Cómo lo hacen en Trupal 8? ¿Sigue la misma política de Trupal 7? Do you want to just repeat that in English? Okay. Bueno, en la versión de Trupal 6, los passwords de los usuarios se guardaban en M5, sí? He's saying that in Trupal 6 user passwords were stored in M5 but in Trupal 7 it is a hash. So, well, I really don't know how is it in Trupal 8 but how are you dealing with that? It's dealt with in the same way it was between the upgrade to Trupal 6 to Trupal 7. I believe it's actually the same code just running in a different place and I believe if I'm not mistaken the format is, I think it's the same between 7 and 8. The hashing strategy is the same. So it's the same idea that it did from Trupal 6 to Trupal 7. It will convert them and it deals with it in a way that's secure. So I don't know the specific details because I haven't dealt with this in D8 but I have looked at the function in D7 and it does a transformation and that code has been brought over. So, yeah. Other questions? Yes. Here. Hi. Yeah, can I speak it in Spanish? Do you think so? Oh, my god. En relación con la migración de Trupal 6 a Trupal 8, ¿verdad? ¿Cómo sería más o menos en la migración de Trupal 7 a Trupal 8? Sé que todavía no está lista pero según su experiencia ¿Cómo creen que va a ser? You mean like what is our experience of trying to do things? No, I'm saying that now it's not ready to migrate a migration process to Trupal 7 to Trupal 8, ¿verdad? But you know how to do it with Trupal 6 to Trupal 8. Now, how do you think that going to be the migration process in the future, of course, about Trupal 7 to Trupal 8? The same strategy, exactly. So we will put a copy of the Drupal 7 templates. The same strategies will apply. If you go to Migrate, Upgrade, User Interface, you just put in the database credential, it will detect that it is Trupal 7, it will know that it understands Trupal 7 and it will run them. So this is why we have Migrate Module and Migrate Drupal Module, so that the Migrate Module is generic and it can run any platform and then Migrate Drupal is just this specific. So, and then on Drush, again, same thing. So you just list the name of migration. In that case, the name of migration will be D7 underscore user. So the naming will be different. I think we've been called for time, so thank you, everyone. Gracias.