Drupal 8 - Developer’s and Themer's Impressions

I have been working on two Drupal 8 projects recently, neither of which have been published yet. One is a static site to Drupal 8 migration, that is still under way, and another a Drupal 6 to Drupal 8 upgrade project, that has been completed. Now that Drupal 8 has become stable and more modules have been converted to it, I am happy to say, that Drupal 8 is quite good and has some very good benefits for both a developer and a themer, as well as some rough edges. I will not be repeating here the usual enumeration of the new cool features that Drupal 8 has, but will rather tell you what stood out to me.

1. Drupal 8 is stable and is ready for production.

I remember using Drupal 8 just half a year ago - it was some release candidate. And it had rough edges all over it. It was very easy to break it, and in fact, almost every update did just that. Now that Drupal 8 is actually out and in version Drupal 8.0.3, it is quite stable and dependable. I have not experienced any unexpected WSODs or errors with it in the span of the last two projects, even though I see some cases in the issue queue. I guess that what it tells me, is that unless you have some edge case setup or edge use case, Drupal 8 will work stable and predictable.

Upgrade from Drupal 6 went well, even though it turned up quite useless without a few more contrib modules that facilitated the upgrade migration and made it work for me.

2. Upgrade destination needs to be empty.

If you have heard, Drupal 8 does not upgrade from Drupal 6 or Drupal 7 in the same way as previous versions did. In the past, you could upgrade the database against the new code base. In Drupal 8, it’s different. You no longer upgrade, but you migrate. Migration module has been moved into Drupal 8 core, and now, instead of taking an old database and upgrading it to a new version of code, you actually migrate the content and the files like you would if you migrated from another CMS.

Having done a few migrations in the past, I expected that it worked the same with Drupal 8 - you build up the functionality, content types, taxonomies, and all the rest, and then you map and migrate the old data into a new setup. But not so. You would need to do all that if you are doing a regular migration. But, when migrating older Drupal, you don’t need to recreate the configuration. In fact, your Drupal 8 site has to be as empty as possible before you perform your upgrade migration. Content types, vocabularies, config entities, blocks - are created automatically.

3. Not all fields can be migrated.

When migrating content defined by 3rd party modules, you need to make sure that your Drupal 8 module exists and supports an upgrade path. Otherwise, that data won’t be moved over. In my case, I had to write a custom module that migrated a custom date field data. Alternatively, you can write hooks and handle that via migration hooks.

4. Views do not get migrated.

Well, that’s it. Views are not getting migrated to Drupal 8 yet. You have to recreate them manually.

5. Block visibility options are a pest.

Drupal 8 no longer has a PHP for block visibility. Now, imagine a use case. You have a block. You need to display this block on some paths and on some content type pages. A piece of cake, right? Drupal 8 has settings for the paths and for the content types in the block’s visibility settings, right? Well, not precisely. If you both specify paths and content types in block visibility settings, you will have it show only when both conditions are true. So, if your path is taxonomy/term/1 and your content type is article, it won’t show at all.

Isn’t that a pity? You can create two identical blocks, of course. And then more identical blocks if you have more conditions. But that’s all you can do if you only use the core for now. Of course, in Drupal 7 you could use PHP for visibility, and that solved it all.

Now, there is still a workaround without creating copies of the same block. You will need to install contrib modules, however. One option is ctools (yeah, most of it is in core as you have heard, but not that important part that we need). So, you still need it. Another option is the block visibility groups module. They both work well to fix this... a usability bug, I believe, that’s what it is.

6. Multilingual Support - good! Too good?

Multilingual support in Drupal 8 is really good. Every block, every field, every term now has a language record in the database. Now, what happened to me - not sure if it’s some bug or feature, as they say. I had to switch to English while I worked on a Danish language site. Created some pages, created some blocks. Then, after I had everything working, I went and set the language setting on every page to Danish. And then an unexpected thing happened - blocks stopped showing. Terms views stopped showing. That was unexpected. I switched fully to Danish, and set all nodes and terms languages that had English to Danish. That did not help. I thought it was black magic, until I went and saw that the blocks and the fields has English in the database, and there was no place in the UI to correct that. I had to change it in the database.

Now, having the language system smart, but too smart, trying to outsmart you - it’s not very pleasant. But maybe I missed some secret setting - tell me in the comments.

7. The notion of Node is gone.

Remember the good old days when you were telling the client, “Now, you need to create a node…”? Remember, how geeky it was? Oh what? A “node”? Now, forget it. For the UI, at least. No more “node”, but “content”. Dear client, you need to create a content of type “article”. Now, that’s better! Not as scary!

There are still nodes on the back end - in code and in database. But no need to scare normal people with that stuff any more.

8. Drupal 8’s UI is not much nicer.

There has been a titanic work to rewrite and better the Drupal 8’s UI… Not sure what happened… It does not seem any better than that of Drupal 7 at all. Well, maybe some. But overall, everything looks like Windows 98, gray and 3d. Especially the excessive use of gray with the standard admin theme, especially with the tabs. Why on earth would you paint the backgrounds of text areas with gray?!

Also, there have been stats for years - people like Admin Menu. Was it so hard to include Admin Menu in the core, rather than persisting with the less useful admin panel, that people usually uninstall? (Of course, in Drupal 8, Admin Menu is getting dropped, and an extension for the panel that given it collapsible sub-items has been available as a contrib module). So, can live with that.

9. Drupal 8’s page load seems fast.

There have been some tests performed, both by myself and some other developers, that show, how Drupal 8’s pages have become about 1.5x - 2x times slower for anonymous users. However, Drupal 8 is still faster than Wordpress. Also, the difference is like 20 against 30 milliseconds. Visually, you won’t notice that Drupal 8 is somewhat slower. In fact, because Drupal 8 serves pages smarter, it may even seem snappier than Drupal 7 in some cases.

Therefore, my call here is to go with Drupal 8 rather with Drupal 7. Not only the difference slight, and would only show for very-very heavily loaded sites, but also access to better functionalities that Drupal 8 provides, is abundantly above that difference, in my mind.

10. Front end.

Front end in Drupal 8 has gotten smarter. A better separation between a front end and a back end developer has been drawn. Front end developers now get more freedom and flexibility, and back end developers have to less worry about how things will look ultimately.

What has driven that line of separation between the front end and the back end in Drupal 8 is the Twig templating engine. It allows some flexibility that the front enders will need, like, conditions and filters and enumerations, and it disallows those bad practices, when business logic could be included in theme templates, with database queries and all.

Front end has not simply become better in Drupal 8 - but it’s a leap forward, rather just than a step.

My overall impression with Drupal 8: I like it a lot.

Despite having some rough edges, and some modules still being in development, I overall enjoy Drupal 8 a lot.

  • Drupal 8 subjectively seems fast (if not faster than Drupal 7, then equal).
  • Drupal 8 has a relatively good upgrade path.
  • Drupal 8 is very flexible and extensible with OOP and hooks. Many things that were not possible or could not be extended in Drupal 7, are possible, and can be extended with hooks and subclassing in Drupal 8. That includes entities, menus, blocks, and if not everything else down to the very core.
  • Drupal 8 has even a more flexible entity architecture than Drupal 7 does.
  • Drupal 8 is very elegant in programming and theming. (Though it does have some rough edges in the former).

So overall, my answer to my question that I had asked a few months ago, “Should I seek an exit strategy because of where Drupal 8 is heading?” is “No, probably not.” I have been working with Drupal 8, I like it, I plan to stick with it.