At ClikFocus, we have been following and playing with Drupal 8 for more than a year. This led to our decision to build clikfocus.com on Drupal 8; it really forced us to dig in and experience some of the coolest features that Drupal 8 has to offer and we wanted to get our feet wet. We knew that if we worked through challenges and mistakes on our own system, we’d then know how to our help clients and coach them through their own migrations. The more we dug in, the more we loved D8. It’s a pretty drastic change from Drupal 7, much more so than the shift from Drupal 6 to 7, but the power and flexibility it offers is undeniable.

Drupal 8 was officially released back in November of 2015, but there is still a lot of work that needs to be done. In our opinion, while Drupal 8 core is stable and has great capabilities, it's probably not /quite/ ready for production use cases beyond more basic sites; this is simply because there are still a number of contributed modules that are yet to be ported, but more are coming along every day. While Drupal 8 is awesome and was extremely exciting to build on, building our site on it was not without its challenges.

Migration

What we love

Migration is in Drupal 8 core now, but it’s still experimental. That said, we were impressed by how well it did work. All the content, etc. from our Drupal 7 system came over really well, including content types, taxonomy, users and comments. Our previous site was pretty simple, but still was something that had evolved for years, so seeing everything come over was great.

Gotchas

Where the migration process was a bit of a letdown was that the Migrate UI didn’t let us make just a few simple tweaks to our data like we were used to doing in Drupal 7. As a part of rebuilding in Drupal 8, we wanted to rework several parts of the site: remove some old fields, re-architect some of our categorization, rename some fields, and remove some unpublished content. Having to write a few classes, hook, and post process scripts slowed us down more than it would have in the past. For some of the content and fields we didn’t want, we ended up just deleting things after the migration was complete, rather than writing code.

Framework Upgrades

What we love

With the integration of Symphony as a base framework, Drupal really feels a lot more grown up. Don’t get me wrong, Drupal has long been an enterprise platform. However, now it not only has enterprise capabilities, it feels more like a traditional enterprise platform. I’m really excited to see what this means for the growth of Drupal’s developer base. We’ve struggled to find Drupal developers in the past, and I really think that this change will help more of the right kind of developers to join the community.

By tying MVC and OOP concepts more closely into the platform as a whole, I think it’ll help many who had found Drupal confusing to reconcile some of the complexities. The complexities are still there (they have to be), but I think they will look much less like spaghetti code “hooks” to the casual observer. I have to be honest here though, I’m definitely still ramping up to everything.

Gotchas

At the same time, I do see Drupal 8 being much more difficult for hobbyists to ramp up to. I’m actually not sure anyone who’s ramped up to Drupal would still be considered a “hobbyist,” but Drupal 8 will definitely increase the ramp up inexperienced programmers. If MVC and OOP aren’t already familiar concepts, learning Drupal will be a much bigger leap than before.

Another thing that took a bit of getting used to coming from Drupal was tracking down the Namespaces for various core functions. It was easy enough to get used to, but a massive chunk of helper functions have been moved into classes, it’s just a bit more cumbersome to use. A simple example of this was Drupal 7’s element_children() function, in Drupal 8:

Configuration Management System

What We Loved

Wow, the Configuration Management system in Drupal 8 is fantastic. Like most Drupal shops, we work as a team, and configuration has been a major hurdle for any Drupal team to overcome for years. The Configuration Management system was a welcome solution to our formerly rather complex process (consisting primarily of Features to take advantage of version control, and filling in gaps with a variety of other methods).

One of the incredible things about Drupal is just how configurable it is. Being able push just about the whole site’s configuration around with Git and easily merge it has been a huge win, it’s sooo much faster and less of a headache. Surprisingly, we actually haven’t encountered very many issues with this system.

Gotchas

While it’s been mostly smooth sailing with the Configuration Management system, we did hit a few snags. The main thing we ran into was once we went into production. In the past, we would leave production settings out of Features and leave them in the database or force them in settings.php. Now that all configuration is in configuration files, this doesn’t work. We accidentally pushed some development settings into production when we pushed everything we had been working on and imported it into production. It’s relatively simple to work around this, by still using settings.php (and just paying more attention).

Another thing that has caught us off guard is that a few modules, such as Entityqueue and Display Suite (still in development) have caused configuration exports to produce invalid configuration. I won’t go into the details on cause, but this prevented us from importing any config at all, not just the one file that had an issue in it. Once we cleared up the issue it was fine, but it was a bit of a pain to have everything else held ransom by it.

Entities

What We Loved

Drupal 8 moves many more pieces into the Entity system, which is another big win. What Drupal 7 started with the Field API was taken to a new level in Drupal 8. It really beefed up the capabilities of the whole Entity system by considering forms a display. Even the core Contact module is now entity based, which means that simple needs that were almost unattainable in Drupal 7—like building a View of all Webform responses—are baked right into core. The flexibility this architecture allows for is exciting.

Gotchas

I actually think I love everything about the Entity changes in Drupal 8. The one thing that may be challenging with Drupal 8 Entities is its wholehearted shift to Object-Oriented Programming. With Drupal 7 you could get by without taking advantage of OOP in the Entity API. Now you can’t, but (as was the goal) those familiar with generally accepted best practices in the software world at large will feel more at home.

General Takeaways

Contrib Modules Are Still Maturing

The main hurdle we kept hitting was the lack of contributed modules. When we started into the process, only around 25 of the top 100 modules had non-dev releases (though 19 of them were baked into core). More modules are being ported every month though, thanks to a great development community and Acquia’s D8 Module Acceleration program. Many of the things we’re used to doing with ease turned out to be projects, others we scrapped as we prioritized. This will change with time, and we expected nothing less, but it did validate that it hasn’t passed Drupal 7 just yet in terms of its module-base. It’s definitely for early adopters (like us!) or simpler sites for just a bit longer. If you’re used to building in Drupal 7, make sure you look up the modules you’re used to taking for granted. Many modules have replacements that are ported to D8, others you may need to put a stop-gap measure in place in the interim.

Drupal 8 is Awesome

I can’t cover everything we loved about moving to Drupal 8 in a single post, but moving to Drupal 8 has given us a much more powerful platform to build on, despite some of those areas where the community hasn’t quite caught up to where Drupal 7 was. Drupal 8 is noticeably much faster, even on our local environments where me made no efforts to improve performance. Plus, Drupal 8 gave us the tools to build a great looking site, which definitely would have been harder to pull off in Drupal 7. The addition of Twig was a huge win, letting more of our team play around with our theme in development and experiment with ideas we ended up incorporating. Ultimately, I think we were pleasantly surprised at just how much power we had with Drupal 8; I can’t wait to start building some more complex Drupal 8 sites.