 Helló, minden minden. A szovájátok, hogy hagydunk a szerepet a fokhagymát, amikor gyöntem, vagyok megválaszott, és ez a migrálisdásra, az a versencsével és a drúpel, egy helyik biztosabb nyilvának. Én Péter Ponyán, a CTO és a különbözőre dei Renésem, megtudom a kagyom, Dominika Pieterova, a különbözőről a különbözőről. Hello everyone, I'm very happy to be here, and happy to see your smiling faces, I don't know why, but it's a good feedback, so let me tell you a few words about the project, we made by genomica.com, it's a tech news portal with quality content and without all school advertisement, and their target group is mainly enterprise leaders and business decision makers, so what we did was a remake of a WordPress site, which was made in 2013, and we remade it to a Drupal 8 project, let me emphasize it here that we don't want to make a general comparison between the Drupal and WordPress as the content management systems, We will just compare the genomica.com using WordPress and in Drupal. Yeah, so we took these topics and compared the two systems based on regarding content structure, editorial UI, navigation, image and media handling, modules and integration, performance, SEO, and of course we would like to deliver you some kind of summary and key takeaways. Maybe it's time for a small question, please raise your hands if you ever installed or use the WordPress site, it's not a shame to admit it. Ok, and please raise your hands if you did a migration from WordPress to Drupal, maybe? Or the opposite way? Maybe the opposite way? Oh, that guy at the back, ok. Ok, regarding the content structure, at the WordPress we had two sites, one for the dgenomica.com and there was a sub-site called government.vgenomica.com, so we had basically two databases with two user groups and media, and in the WordPress there was a huge category 3, we don't know exactly why was it built that way, maybe it was an architectural planning that way, but everything was a category, so during the migration we did refactoring also, so we merged the two sites into a single one, the databases into a single one, also the users and the media, and we reused a number of the categories in a way that we separated the categories and the tags and the partners, and we made content type of it, so the structure is easier to overview and handle. Regarding the editorial UI, the WordPress used the default theme, which had some advantages and disadvantages also, for example in the WordPress, I don't know many of you raise your hands, so probably you know that there are more editing options, you can edit the whole content or only just the single elements of it, which was a big advantage, but due to the big category 3 and also many third party plug-in integrations, the page depth was really big, so it was quite hard to overview the page when you were editing it. With the Drupal, our first decision was not to use the default Drupal theme, how to put it nicely, probably you know it, so yeah, it's just ugly, so we went with the Thunder admin theme and I guess it was a great choice. The result is this, so on the left hand side, you see the WordPress compared to the Drupal editorial UI, so we made the Drupal interface cleaner one, we got rid of the unnecessary fields and just combined the fields, so it follows editorial flow and got rid of the unnecessary fields. The navigation was a UX question basically, in the WordPress, they had a single level navigation, which was quite confusing because from the main menu structure, which is, can you see my mouse? Yes, okay. So, this is the main navigation in the WordPress, from where you could get to a landing page, but there were several subpages of those landing pages, but there was no way to get there. And there were these so called cornerstone pages, which was basically a collection of the categories, so here you can see that the main navigation is duplicated here and there is a list in the visibility, how can you get to the deeper level. So, we remade the navigation, the whole menu structure and just made a two level navigation basically, so now you can hover on the main menu and there is a drop down and you can get to the deeper pages with the landing page and other categorization. Yes, so regarding image and media handling, we have to admit that from the editorial perspective WordPress is still better. We went with the media, with the core media module and with some contributed modules to boost it to a better level, but still in WordPress the editors could use on the fly cropping and to use custom size for images when they inserted them into the visibility editor, while in Drupal with the media module and not the standard image handling. There are still some limitations, of course there are also some good points of this because the look and feel is more consistent that they have to choose the editors from image presets. There were also other differences, all the embedded media from other social sites were handled in a way in WordPress that they requested for the embed codes when the editor hit the save button and this resulted in a very slow save procedure. While in Drupal we used this iFramely service and this works much smoother, faster and it supports over 1900 external social and other sites so it will be always enough. Ok, regarding modules and integrations, this WordPress site was really bloated with plugins. Yes, we realized that many of those plugins were missing from Drupal, but some of those we were able to just simply get rid of. But some others which were important like the contextly recommendation and gene integration and also the Yoast, we had to work on that then because for example contextly wasn't available for Drupal 8, Yoast was buggy, so we had to work a lot. These are the most important ones, what we use, we completely had to port the contextly module to Drupal 8 and also add some features. We use also a custom, not a custom, it's contributed but built by us module for grabbing statistics data from the analytics, Google Analytics API. We had to extend some AMP features to provide full AMP support, so many of these. At the end, I think the end result is much more consistent and much more stable in Drupal. Then about performance and stability, there were complaints from the customer that from time to time there were performance issues with that bloated WordPress installation. And we solved this mainly with two things. First of all, we found a good hosting provider with the CDN, which has good integration with Drupal caching system and of course also with thanks to the AMP integration and implementation. All the pages which are served from Google's cache servers are of course lightning fast. So of course we did some improvements like general optimizations, so also the Lighthouse audits course are better now. But I'm really proud of this because this is now covering five months and comparing the five months, the same period of last year to this year. The average payload time, which is the most important thing because this is like really what the users perceive at the end on their devices. This was really boosted compared to the WordPress. Regarding the SEO, Peter briefly mentioned that we had to build a full AMP team, which helped us a lot in organic search traffic. So we managed to increase it by 24%, which is quite a lot. But to be honest, the WordPress was in a quite good shape already regarding SEO before the migration. There were a few search console errors around 300, if I remember well. We managed to reduce those numbers only to 7. By the time the team got really keen on improving the SEO, so they were just fixated on this. So we managed to get high numbers in Lighthouse in accessibility, performance and SEO as well. Here are the results. You can see that the organic search is measured at the same time period as we showed a screenshot about the performance. So within that five months, we got that up to 24.5%. Yes, some statistics, so we of course took an open source approach. So when we had to fix something, we filed a patch to Trooper org. This way we filed a patch for content moderation to core. We had to fix some bugs in the Yoast module about the publication date. We had to fix some things also in the Thunder Admin team. We contributed back this module, this easy Google Analytics counter. And we ported the Contextly module to Drupal 8 and extended it. So at the end, we still use 49 contributed modules, which is not a low number, but it's a much lower number compared to the WordPress plugins. We used earlier and I think these modules are in a very good and manageable shape now. We also built eight custom modules. We implemented a full AMP team, full AMP support. Yes, one of our colleagues got addicted to this and checked the search console every night. And this is a weird hobby, but yes, at the end it resulted in a very good implementation coverage. We use a Thunder Admin team, and of course we built a frontend team for the genamica. So let's take a final look at the summary. If you see there are more likes in the Drupal than in the WordPress, but I guess this is normal if you make a site remake. So you tend to improve the original site. So maybe if it would be remade on the WordPress, there would be more likes at the end also. But one more time I would like to emphasize that this is not a generic comparison between WordPress and Drupal. It's specific for the genomica.com. And maybe the conclusion of this summary could be that with a lot of work you can improve anything you have. Especially if you have a good foundation like Drupal. Okay, so lessons we learned. During the migration it's very important to treat the migration as a separate project or at least dedicate plus one person for the migration. We really made this mistake that we thought that it would be great if the same scrum team will handle it. Migration can be very tricky, and we had to return over and over to the migration, so it was hard to manage. Then AMP was worth it to implement. It also took much more than we thought originally, but it's worth it. It doesn't have a direct impact on search ranking, but at the end with much better performance, Google gives better results for faster pages and AMP pages are the fastest possible. So at the end it has an impact on SEO. Also it was very important that we took an agile approach and also our client was very flexible on finding alternative solutions, dropping things. So this way we really had to good leverage all the power of Drupal and didn't stuck with trying to reimplement exactly what was available in WordPress. Then we found these two providers which turned to be really good. This was our first project with Pention and it performed really well. Especially the FCDN, and the Elgólia Search, unfortunately that's also a paid service, but it's very impressive how it provides all these real time result pages and search suggestions and so on. At the end a few key takeaways. We made a mistake that we thought that three members of our team will be enough for the project, but it turned out that we need more for them. So as the number of the involved members rises, then we'll have time spent on the project too. So you have to keep this in mind and you have to inform about this your client as well. Then the research and discovery, it's not enough to have a research phase before the project. You need to get back to this with every new feature and just rethink what you have done so far. And last but not least, the client really matters because a remake can be tough. But if your client is flexible enough and open minded, then it makes your life much easier. But fortunately our client was really open minded and flexible. So he is also here tonight. So then if you don't mind to come up to the stage and just say hi. We have not rehearsed any of this at all. I'm going to tell you straight off the bat, we did not want to do this. I've been a long, long time WordPress user, but I was dealing with spaghetti soup. And we were never going to be able to optimize it ever. And the development team that we had at the time, they were absolutely adamant. We're a WordPress house, if you don't like it, go away. And it's like, OK, fine, we're going to go away. And with this, I had experienced a Drupal back in Drupal 5, Drupal 6. I hated it and I hated all of you because the community was absolutely terrible. So that was my first problem. The second problem was that one of my business partners had extensive practical use of Drupal 6 and 7, I think. And he hated it. So we were taking a huge risk. And so the way that we approached it was to say, or at least the way I approached it was to say, if my users are comfortable with what you deliver, everything else will be fine. So that was really what we focused on more than anything else. Now, to a degree that meant kind of in some sense is replicating the WordPress UI, right? But, you know, so what, right? I certainly wasn't going to use that block crap. You know, we needed something that my guys could pick up and run with straight away. And it turned out to be a non-event in the end, which I think says a great deal, quite frankly. So that's kind of it, really. Thank you. Is that good enough? Thanks. That was it from our side, and we ran out of the time. This is the last session, so maybe if you have some questions, just go ahead. Did you use Fonder as a distribution? No, no. We only used the tender admin theme. Why? Why didn't you use Fonder as a distribution? Why didn't we? We checked, we created a demo installation, and we checked, and then at the end we decided to build. So we usually try this minimum approach that we install a minimal installation, and we install only those things, what we really need. And there were some elements in Thunder, which we thought that it won't be needed. And it was easier this way. Yeah, for example, the paragraphs. So it would have been harder to get rid of the paragraphs than just using the admin theme. Did the Thunder admin theme work out of the box, or did you have to fork it and change stuff? No, we didn't have to fork it. We fired a patch or two, but it was working. Yes, it's good. But maybe if we could start now, we would pick Clairo rather than the Thunder admin UI, but the Thunder admin UI is also great, and it's very good that it's like a clean editorial UI. Anyone else? How long did you take the project? We started in the beginning of January, and the launch was on the 6th of May. That and that. Is it that or is it that? No, maybe it's all right. OK. Thank you very much.