Drupal 8: My Experience Crossing The Chasm With Sooperthemes
Drupal 8 adoption has been very slow, and many people have been putting it off. Some even gave up on Drupal because of D8's (perceived) complexity, focussing their career or hobby on easier CMS software. The past 3 months I've been fully engaged in embracing Drupal 8 and moving my premium Drupal themes along with the supporting ecosystem of modules, installation profiles, and infrastructure to Drupal 8! Going forward we will develop and maintain our products on both Drupal 7 and Drupal 8.
It's been an interesting but also difficult journey and I'm writing to tell other Drupal professionals (and hobbyists) about my experience. I divided this long read into several chapters so you can skip to whichever topics you care about most. If this topic is important to you, please do comment and share your thoughts and experience!
Theming: Easier and Better But Completely New
Drupal 8 uses a new templating system for theming called Twig. While skeptical at first about having to learn a new language, I've grown to like Twig a lot... but to be very frank I would have been totally OK with keeping PHPTemplate in Drupal 8. It's what I've been using for 10 years and it's what I know. My Drupal 7 theme is full of preprocessing, custom features, and integrations with certain modules, and it's all coded in PHP. The transition to Twig means there is a huge amount of work for me to not just convert templates but also re-architect all the logic and features in the theme. I'll say that Twig works great and has a bright future but I'll also say that I can empathize with all the Drupal themers who are unhappy about having to learn a whole new way of working.
Theme Settings
If you develop base themes or premium themes like I do I have some good news as well: Theme Settings are largely implemented the same way. For me this means that many hundreds of lines of FAPI code for the 200+ theme settings in my flagship Glazed Theme can be copied and pasted into the Drupal 8 codebase and 80% of the form generating code just works. Of course the code that reads the theme settings still has to be ported from PHPTemplate, preprocessing and custom PHP to use Twig and Drupal 8's APIs.
Logic Inside Twig Templates
The most confusing thing when starting out with Twig was that all logic for printing classes happens right inside the Twig template. For years I've been telling people to use preprocess functions for any logic, whether it be if/else or some code to retrieve a field value. In Twig any logic related to printing template code (that includes classes and other attributes) goes right into the twig template. I'm not yet entirely happy about have a lot of logic in my template files. Then again I can also imagine that to the unitiated the Drupal 7 architecture with classes being added in preprocess, or process functions that can be in multiple locations could be even more confusing.
To show you what I mean here is an excerpt of my html.html.twig template:
{%
set html_classes = [
theme.settings.sticky_footer and not theme.settings.boxed_layout ? 'html--glazed-sticky-footer',
]
%}
{%
set body_classes = [
'html',
logged_in ? 'user-logged-in',
not root_path ? 'path-frontpage' : 'path-' ~ root_path|clean_class,
node_type ? 'page-node-type-' ~ node_type|clean_class,
db_offline ? 'db-offline',
theme.settings.navbar_position ? 'navbar-is-' ~ theme.settings.navbar_position,
theme.has_glyphicons ? 'has-glyphicons',
theme.settings.header_position ? 'body--glazed-header-side' : 'body--glazed-header-top',
not theme.settings.header_position and not theme.settings.header_style == 'overlay' ? 'body--glazed-header-not-overlay',
not theme.settings.header_position and not theme.settings.header_style == 'overlay' ? 'body--glazed-header-' ~ theme.settings.header_style,
not theme.settings.header_position and not theme.settings.header_top_sticky and theme.settings.header_top_fixed ? 'body--glazed-header-fixed',
]
%}
<!DOCTYPE html>
<html {{ html_attributes.addClass(html_classes) }}>
<head>
<head-placeholder token="{{ placeholder_token|raw }}">
<title>{{ head_title|safe_join(' | ') }}</title>
<css-placeholder token="{{ placeholder_token|raw }}">
<js-placeholder token="{{ placeholder_token|raw }}">
</head>
<body{{ attributes.addClass(body_classes) }}>{{> Some templates, like my menu--main.html.twig template that is responsible for rendering dropdown menus contain more advanced logic, including a powerful Twig tool called a macro. The ratio of markup to logic is so low in this template that it kind of seems to defeat the purpose of having a templating system. Then again, if I look at the equivalent of PHP code I've had to write in its D7 counterpart it's equally cumbersome.
Despite my reservations about twig, looking back at the work I've done so far in porting my theme to Drupal 8 (it's about 75% done) I'm creating a more maintainable, better product. And that's what Drupal 8 is all about. There's some pain in migrating all your work but in return you get what I believe is a more solid and maintainable theme.
Site Building: Pretty much the same
For a CMS that was basically built differently from the ground up, the authoring and site building experience is surprisingly similar to Drupal 7. You're still going through the same steps and forms to create content types, taxonomies, views, nodes etc. This is because the idea of Drupal as a flexible and powerful CMS has remained the same. For Drupal 7 users who didn't do much coding before, not much will change when upgrading to Drupal 8. Without investing at all in learning new things you can hit the ground running and install a nice Drupal 8 theme or distribution and it's business as usual.
Module Development: Definitely harder
Building Drupal 8 modules is not rocket science. It's just that there is a lot to learn before you're fluent at it. New APIs, more complicated object oriented architecture, services and plugins. The learning curve is steeper and higher than ever. However, if you start small, read the docs, and copy code from the examples module it's doable. The learning process very much reminds me of my first experience building my very first Drupal (5.x) module.
This is why I decided that building our most complex Drupal 8 modules should be handled by experienced Drupal 8 experts and not me. While I started upgrading some tiny modules as well as our theme I contracted Ivan (Chi on d.o.) and Jay Friendly (Jaypan on d.o.) to build the Sooperthemes Portfolio and Glazed Drag and Drop Builder modules... completely written from the ground up for Drupal 8's architecture. Without their help there's no way I would have upgraded these modules myself without first spending at least 2 months learning Object Oriented Programming and the inner workings of Drupal 8. If anyone is looking to consult about Drupal 8 upgrade work I can highly recommend both Ivan and Jay. Jay is currently writing a book on Drupal 8 development that is targeted at Drupal 7 veterans as well as completely new users.
Development has been in full swing for the past 2-3 months and it has been the most intense and sometimes stressful time in my years building Sooperthemes products. All of our products are now almost finished but still being tested and refined. It has been a great learning experience but also a great lesson in technical debt and the reality of Drupal 8's complex architecture. For me personally with my background in theming, design, and marketing I feel intimidated by the complexity introduced by Drupal 8. Conversely I feel that my customers will have more easy to use, solid, reliable and performant website thanks to Drupal 8. Luckily for many of my customers the whole point of my products is that you can build and customize everything without coding, using our Drag and Drop tools and extensive theme settings.
Plugins, Services, Controllers, and Schema Metadata
That is a list of some of the software architecture concepts I've had to get acquinted with in the short time of 2 months. I can't say that I've learned these concepts just yet. In Drupal 7 understanding the hook system and Forms API could really get you a long way building even very large Drupal websites. In Drupal 8 not so much.
Before I started feeling like I'm on a learning curve, I ran into a wall. Drupal 8 really demands you delve deeper into software architecture than before. It's hard but the beauty of the new system is that as you're learning Drupal you're also learning Symphony and proper Object Oriented Programming design patterns. Those who can make the neccesary investment of time and energy will come out of it with skills that are valuable beyond the Drupal ecosystem.
Installation Profiles: Similar But Better
Installation profiles are a critically important part of our business at Sooperthemes. We don't just sell themes, we develop, support, and maintain all the Drupal code that brings our designs to life. For our customers this means they can download a turn-key installation profile that contains their selection of designs, features, and demo content.
For us this means we maintain a ton of configuration, demo content, and modules, and wrap it all into installation profiles. We even provide an interface to generate customized installation profiles and install them on your hosting fully automatically. My experience so far with Drupal 8 installation profiles has been great.
Demo Content
A notable improvement is the great support for demo content in Drupal 8 with help of the Default Content module. In Drupal 7 the go-to module was UUID Features. Over the past years I've spent many hours fixing bugs, implementing file support, and patching up poor support for referenced entities and menu links in Drupal 7's UUID Features code.
The Drupal 8 Default Content module is still in alpha and if you're doing a lot of default content work you still might need to hit the issue queue and download (or contribute) a little patch but this module already feels more stable than the UUID Features suite. D8 and Default Content also import content faster, allowing even the lowest of low-end hosting to install our bulkier demo installation profiles.
Configuration
I've read that Features is still a thing in Drupal 8 but I've not yet found the need to try it out. Whereas previously we used Features to package all our CMS components into modules this is now done with Drupal core's configuration system. It's working well so far. Automatic exporting of configuration and dependencies into modules is done using drush, and we can now split optional and required configuration which is also great for components that include lots of views that add value but are not indispensable. I did experience some quirks with optional configuration not being installed during the profile's installation process even while dependencies were certainly met.
Media: Work In Progress
It took many years for the Media module to have a stable (2.x) release in Drupal 7. Drupal 7 Media works great and it handles drop-in file uploads, multi-file uploads and various media gallery browsing features excellently. In Drupal 8 great work is being done to bring Media features into core. I'm a big fan of the initiative but I'm also concerned about how to provide provide future proof media featurs in my installation profile right now.
Drupal 8 Entity Browser
At the moment of writing this, the successor of the Media module is Entity Browser. The module File Entity Browser (it builds on top of Entity Browser module) will give you a media library popup browser similar to the D7 media module's browser. Installing this module requires 5 modules (dropzonejs, embed, entity_browser, entity_embed, and file_browser) and 3 external libraries: dropzone, imagesloaded, and masonry. Part of the Drupal 8 media initiative is to include features similar to what the File Browser module provides in core, but in a cleaner architecture with fewer dependencies.
A module similar to File Entity Browser is Media Entity Browser and the major difference is that it uses the more flexible Media entity as opposed to the file entity. What exactly this means and how all this will be upgraded to the new Drupal 8.4 core features, I'm not sure. Therefore I decided to launch my distribution and products without image re-usability on Drupal 8.3. To protect my customers against potentially needing complex upgrade processes I'll hold off on advanced Media management until Drupal 8.4 comes out. It's planned to come out late this summer and I'm looking forward to it.
Improvements In Documentation
This is not really a Drupal 8 improvement as much as it is a Drupal.org improvement. The quality of documentation available to day is so much better than on the day Drupal 7 came out. The new documentation page design immediately gives more credibility to the content and the content is carefully curated and better written. Even though this is not really a feature of Drupal 8 it certainly is a great benefit to those starting to learn Drupal 8 today.
I also want to give a shout out to Drupalize.me, who are giving away free subscriptions for their premium training videos to people who have contributed on Drupal.org. Terms and details.
My Prediction: Drupal 8.4 Will Bring Up The Numbers
I see Media features as the #1 core advantage of WordPress over Drupal. Other major weaknesses of Drupal are a leaner offering of themes and niche-specific tools like portfolio plugins, drag and drop building options, and other fancy add-ons. But those can be fixed by contrib projects and through premium themes. Media is a challenge that took too long to get right in Drupal 7. It was only several months ago the Drupal 7 Media module had it's first truly stable Drupal 7 release. Thanks to this development, we can now expect to see more niche-specific add-ons for the Media module as there is a stable API to build on top on. Next week I will blog about the release of such an add-on module that Sooperthemes has co-sponsored and co-developed.
If the Drupal 8 Media Initiative is executed according to plan Drupal 8.4 will bring features to that will appeal strongly to the masses of Drupal site builders who are unable or unwilling to create custom configurations for Entity Browser. Drupal 8's more rapid emergence of a stable Media API can awaken growth of Media contrib modules that make the lives of content creators and site builder easier.
Sooperthemes Drupal 8: Upgrade Status
To those who are waiting: Please be patient as we're finishing up and fine-tuning. I meant to release a public beta of some products this week but I decided it's better to focus on finishing the components that are currently <90% done. I'll re-evaluate the possibility of public beta testing next week, and the week thereafter.
| Sooperthemes Products | Drupal 8 Upgrade Progress | %_of_total** |
|---|---|---|
| Glazed Theme | 75% Complete | 25% |
| Glazed Drag and Drop Builder | 95% Complete | 25% |
| Sooperthemes Portfolio (replacement of D7 glazed_portfolio) | 90% Complete (only missing hover effect designs) | 15% |
| Sooperthemes GridStack | 95% Complete | 5% |
| Glazed Helper | 75% Complete (only missing Page Design tools) | 7.5% |
| Glazed Drupal CMS Distribution (drupal.org/project/cms) | 95% Complete (finetuning, future-proofing) | 10% |
| Demo Content and Installation Profiles | 0/15 Completed (pending completion of above) | 5% |
| Product infrastructure* | 50% Complete | 7.5% |
* demo sites, trysooperthemes.com, automatic installation profile testing and provisioning, support forum, etc. The kind of stuff you don't think about before starting a big Drupal 8 upgrade project.
** Estimated proportion to the total amount of work of all items in the table