Drupal 8 release was a lot of anticipation. It took a long time for it to be declared release ready, longer I think than anyone expected. I was really excited by the prospect of the CMS moving towards greater ease of use and tantalized by the promise that even more architectural improvements would be made compared to its Drupal 7 predecessor.

As that date got closer and was no longer getting pushed back it became slowly apparent that there would be some fundamental changes to the codebase, however I’m sure I was not alone when I learned to what extent those changes were going to be.

Preliminary change assessment

I was very excited by the prospect of the code becoming more object orientated, Drupal has historically been a very difficult platform to learn with a steep learning curve and minimal sometimes outdated and scattered documented. Perhaps now that it will be object orientated it will be easier to understand? Apply more typical (or at least immediately obvious) design patterns?

The switch over to TWIG was an interesting departure. TWIG is fine, but maybe I’m the rare few who doesn’t really see the benefit of TWIG over PHP. It doesn’t really matter to me if I am writing <?php or {% or {{ in the end I am pulling some variables and perhaps doing some simple logic on my View ie Template layer. But if this was the only thing to adapt, then great – I’m sure if everyone loves it I’ll get the value in it soon enough.

Things started to change when we went ahead and built our first Drupal 8 site about 6 months ago. At the time (hopefully things have improved?) There was a poorly documented Migration module you could install and run to port your Drupal 6 or Drupal 8 code. I scratched my head how Drupal 8 could be considered released if there wasn’t a properly functioning migration path for Drupal 6 – especially since Drupal 6 was being changed to end-of-life. But so be it, I ran the Migrate module and zhaazaaaam….

A completely unmanageable bloat in the database of extra properties, tables and rows. Turns out “migrate” doesn’t import the data, it maps it and does mapping from old to new tables – or something to that effect. Resulting in a module you can’t turn off and a database that is – for a new site that you want to keep clean – anything but tidy and simple.

Rather than live with this, it made more sense to code our own export-import process, because Node export-import module was still not ported to Drupal 8 [another very surprising missing feature]. For those curious: as of this time of writing, the module still doesn’t exist for Drupal 8.

We had too many nodes to do it manually, but the site was simple enough it made much more sense to remake the content types, map the data and then migrate the data across the tables. The code we used for custom Drupal 6 export to Drupal 8 import mapping is being linked to from this post, on the odd chance it could benefit others. Naturally you will need to change your properties to match the content type you are using – so this code is more of a jump-start than a boxed solution.

Theming begins

So now I jumped on the chance to migrate the theme over from Drupal 6 to 8. Rebuilding the theme wasn’t too bad, converting things over to the new formats and TWIG was relatively straight forward. What really got me though with the new system was how sensitive it now is. If you make the slightest typo in a file, your entire site will suffer a WSOD. It took a few moments to change our set up to be more friendly for development. It’s the sort of setup work you would ideally like to see pre-built in the system which you then can turn off in a production system.

It isn’t easy to remember everything we did here to improve the development experience, so here are the known steps we took to make development smoother for Drupal 8:

What I mean by the later is things have become much more prone to totally crashing from a typo or misconfiguration. My colleague informed me that this was largely due to switch to Symfony. Not being an expert at Symfony, I have to defer to him.

TWIG at times I found pretty limiting. Like if you are in a TWIG file it is seemingly a lot hard to dig at available options and properties than you would if you are using PHP, let alone modify them [outside of piping it to a simple filter].

Performance woes begin

At this point we start to work with Devel to do some theme value alterations. Nothing crazy, we just need to remove or add properties to containing HTML or set a default value from the theme layer. In Drupal 6 or 7 I would turn on Devel, throw in a DPM on the variable in question, click through the array or object, find the value and then utilize it in my code.

I activate the module, throw my variable into it and… total page crawl. Then a mem overflow. No problem, let me increase it. I’m used to Drupal needing up to 256MB so I bump it up. Oh wait, I see in the error that it needs more than 512MB to run DPM()? That’s really crazy. I check my function, all I am doing is displaying the value of a View row, something I’ve done many times before in older versions of Drupal, and the query itself is quite simple with only 10 results.

So I increase it to over 600MB and try to run DPM. My entire computer grinds to a halt, eventually I get a result and the entire DPM tree is expanded, and enormous. If the tree was at least collapsed I could expand it to find what i am looking for, but because it is all expanded by default it very time consuming to even get far enough down to find what I want.

Eventually I find my value, but then I need to debug and half of the time my browser wants to choke than display the value.

Ultimately I asked another Drupal developer for insight, can’t be the only one with these issues? I’m curious what your experience has been, but so far everyone I’ve talked to has memory problems when trying to inspect the new objects using DPM – which makes developing for the new CMS a lot more difficult.

We ended up coding a pure Views-based solution for the CSS injection, then hitting an issue where Video fields can’t include iframes because of input filtering and finally landing on Display View modes instead… phew.

Researching performance

So this led us to dig deeper into Drupal 8. What is going on with performance? Why is DPM dieing? Is the code simpler now or more complex?

Some quick googling revealed we were not the only ones seeing performance drops with Drupal 8.

Forking Drupal

We then learned about a new spin-off CMS called BackDrop and we read some interesting articles about BackDrop vs. Drupal 8.

But how could this be? Why are people forking Drupal?

The direction of Drupal

Now I am the last person to be an authority on this, I’m just a developer who hears things and from that draws some conclusions – so take this with a grain of salt and add a comment here if you know more than I do. But from what I’ve been told, Drupal is going Enterprise. I’ve noticed a trend over the last 6 years I’ve been a part of this community that small shops are disappearing, freelancers are being converted to employees and customers are getting bigger.

If you read articles about the performance demands of Drupal 8, they are usually supplemented by solutions that make the system perform better, at scale and with the correct hardware. Maybe you can get Drupal 8 to run on a shared low-cost host, but I have a suspicion this would be a death wish (we haven’t tried yet since we are running all our Drupal 8 sites on either a VPS, Cloud or custom Enterprise level hardware).

Does a non-profit have this option? What about small businesses? And what about all these Drupal 6 sites, are they all expected to buy a VPS now to run Drupal – and how do they migrate?

Honestly it all feels like a mess in business terms. I can’t tell you how many customers I know who are on Drupal 6 but now feel that they have no clear upgrade path.

Roads from here

Here are some of the questions I have at this point:

  • Will Drupal 8 become an easier migration path?
  • Will BackDrop CMS become the defacto solution for small and medium businesses?

For existing Drupal 6 customers, and we have quite a lot, the future is less clear. It really depends on the situation they are in but the options for them are:

  • Migrate to Drupal 7, then wait to see if we go from there to BackDrop or Drupal 8 down the line when things are more clear
  • Cross-grade off of Drupal 6 to a different CMS (or custom)
  • Rebuild in Drupal 8

For our larger clients, or for heavy App-drive features, it makes sense to go for Drupal 8 with supporting hardware. But for smaller businesses we are recommending that they switch to a different CMS if their website is not doing anything fancy [a blog, contact page and that’s basically it] – and up to Drupal 7 if the costs make sense or the site has some real logic going on.


I should end this by mentioning that these are just our findings and feelings about Drupal at the moment. Not everything is bad about Drupal 8 – there are things I really love about it (like quick in-place editing and far better Block-driven features). The problems I mention above could be just the transitional pains.

I do strongly question the decision to terminate all support for Drupal 6 when the migration path wasn’t even put in place yet [and thus prohibitively costly], but hopefully the community learns from this and doesn’t repeat these choices again in the future.

Hopefully 6 months from now everything will look brighter. I for one am curious to see what develops with BackDrop CMS and our newest hipster: Drupal 8.

Thanks for reading.