Sluggish Drupal 8 Adoption Lags Even D6

We're just past the second anniversary of 8.0.0. To see how D8 is doing compared to prior releases, we put together the chart above, based on Drupal's usage stats page.

For versions 5.x, 6.x, and 7.x, each new release brought dramatically accelerated growth.

Comparatively, D8 has dropped off a cliff. Adoption is far below that of D7, and even behind D6.

Have you moved on from Drupal? Let us know in the comments! What are you using instead?

Filed under:

Yes, I have moved on for small projects, and the answer is really simple: https://www.drupal.org/docs/8/update/update-core-option-1

Option 2 (the one labeled as mid-level) has a bold warning that says:
WARNING: if you have installed any contributed modules with 3rd party dependencies using Composer, you need to use the other update options as these instructions will overwrite your vendor/ directory.

Which basically means you have to go to options 3 or 4, that involve drush and composer respectively.

In WordPress, my clients are a click away of having both core and their theme/plugins up to date. If there's a problem (hasn't happened for more than a year to any of them), they can go back to a backup that they also generated with one click. Also no need for update.php.

For big projects with customers that can afford to pay the maintenance bill I ask for, I go with D8.

i'm i site builder and i love drupal so much, its becoming my passion. but drupal 8 make it hard for me to migrate. many of the modules i needed are not ready yet or just recently available.

rules - this is the big one. site builders dont know how to code, so depending on Rules module is sooo critical

drupal commerce - just recently stable but without the integration of Rules. this is bad. now i dont know how to fully customize commerce without Rules.

migrate path - as we all know it

i know you all want to go for 'ambitious digital experience', i'm for it, but leaving site builders behind is a really bad idea.

the move to Symphony, Twig and Composer is the right direction. I have found D8 development fast and intuitive. TWIG enables people that didn't speak PHP before to write custom layouts and modules. Expecting even site builders to learn a basic command line infrastructure like Composer doesn't seem that big of an ask - - and there is a lot of whining going on. The nerve of the Drupal community to evolve and expect people to learn new skills?!

My theory is that the sales numbers from the fewer sites in D8 today just might be somewhat closer to what the D7 sales numbers were at its 2yr point. [total, wild, uneducated, unresearched guess]
To say it another way....
Drupal 8 sites are more "Ambitious" than previous versions and that can often mean more expen$ive. In my personal experience, the D8 sites I have worked on are magnitudes of order more expen$ive.
So... It is my suspicion that even if the larger Drupal shops are building less sites [maybe some are?] the increased price-tags could quite possible make up for it.
... Individual Results May Vary ...
DV

Drupal 6 & 7 were relatively easy to install and deploy without having any development knowledge ... for me learning Drupal 8 was a hard but rewarding slog ... there are still lots of issues the current update from 8.3.7 to 8.4 was incrediblely frustrating esp the issues with the media update and drush 9 ... much of my experience with drupal 8 lead me to believe that a lot of the releases are just not ready for production ... put I persist and being truthful I have to say that Drupal 8 is magnificent out of the box and if your installing from 8.4 up it is a amazing CMS its out of the box translation and media system is unsurpassed in any other CMS ... the plans for front end editing and layout discovery are very exciting.

I've brought this up several times over the past four years, but it would have been nice if there were two versions of Drupal 8: an Enterprise and a Lite version. The Enterprise version would have obviously been aimed at the big dogs Acquia was trying to attract and the Lite version could have maintained those who were successful in D7 but not ready to move to a full-blown and not-quite-ready-for-primetime D8. Yes, an Enterprise and a Lite version of D8 might be difficult to maintain, but how much difference could that have made in the adoption rate? Further, by offering a Lite version, perhaps Drupal would not have lost part of its user base who felt marginalized.

Drupal has always been dinged for being too hard to learn compared to other CMS out there. We argued that with that came power, flexibility and quality and we were somewhat right. With D8 we have doubled down on that... or octupled down on it more like. It is now hard to learn for experienced Drupal people. In trainings I saw Symfony people picking up Drupal 8 faster than Drupal people, though they complain that we don't have all the power of Symfony and error messages are a confusing mess -- more so for us old Drupal hands than them though. Even so, as before, if you endure the learning curve then you will love much of it. All the D8 experts I know would never go back to D7.

But it's still a big obstacle and there are others. You pretty much have to buy an expensive proprietary editor with an excessive price and annual fee just to cope with the basics. Modules are lagging and some major modules have disappeared or are dormant, and just a few of those have been replaced by a new module. Minor core upgrades are hairy and always have bugs, usually in contrib modules, and both these modules and many patches take weeks or months to catch up. The codebase is either fragile or contrib makes it seem that way and odd crashes/errors are common. Most new modules I install add new incoherent errors to the logs demonstrating that even the module developers are struggling.

Our site has been live 15 months and in development from 21 months ago. We needed about 17 patches to get our bleeding edge site to work decently, but all this time later most of them are still needed, including all three core patches.

Movement is slow all over. This is also reflected in how attendance at DrupalCon is down and the European DrupalCon has been killed, which in turn hit the DA hard.

User group meetings have shrunk and the community part of the community seems to be considerably smaller too. D6 and D7 left freelance designers, hobbyists and even many freelancers behind. D8 seems to be leaving small organizations and even small dev teams behind. Many of them were making big contributions. With version 8 Drupal has become a tool for teams, vendors and bigger businesses who don't care about community, and all of that other community richness and diversity that made Drupal strong in the past is now diminished or gone.

Conversations I've had with DA people or leading Drupal people are met with denial, indignation, even surprise and feelings of betrayal, but I'm asking because I care.The next year will be key, I think, but the signs are iffy.

Not a big surprise that Drupal 8 adoption lags behind other versions. Compared to Wordpress, it's not hard to spot the missing features users want that are now missing from Drupal - but used to be part of d7.

Feels like d8 is an attempt to solve problems that only exist at the enterprise scale, while making things hard for the small non-profit, e-commerce, and social sites that made it popular in the first place. The problem with that, of course, is other, more specialized platforms like Adobe Experience Manager and Oracle are a couple generations ahead on many of the things Drupal 8 aspires to do. Each of these platforms has very customer-focused product teams improving defects that used to cause organizations to consider their options. While d8 might be competing in that market, it would need to move several steps ahead on web services integration, multisite (read: organic groups), rules, and integration with metrics platforms to thrive. Just the fact you get better metrics from an out-of-the-box AEM install is a huge deal for media companies, the cost of getting the same details from multiple analytics platforms is often equal to the cost just to implement d8 over the course of a year.

Abandoning d8 and merging with backdrop to create a d9 release would not be a bad idea to consider. The enterprise market can be taken on a lot more effectively with a healthy, robust group of contributors, which doesn't seem to exist now. A merge won't happen, of course, there are a few too many egos involved and prominent developers with blinders on. But it's still worth discussing.

What a comment thread! I find myself disagreeing with many of the posts here. We've launched over a dozen Drupal 8 sites in the past 18 months or so, and we find it really refreshing to work with. We still have another ~20 D7 sites we maintain, and we find ourselves cringing a bit when going back to work on them...

Usability is noticeably better on D8, and our clients appreciate it. Upgrading and migrating content to D8 is far easier than migrating to D7 ever was. Configuration Management has a learning curve and some big gotchas, but is a huge improvement over our previous features-driven deployment. Commerce (now that it's finally out) is much quicker and easier to get going. There are definitely some rough spots that involve going to code, and many places where code is the solution instead of a module -- but coding with Drupal Console, plugins, and a cleanly defined API is a dream, compared to D7 and earlier.

I characterize all of this as growing pains. Drupal 8 has reached a level of maturity and robustness that is far better than earlier versions -- however changes in the broader marketplace and repeated traumas of multiple major version updates that turn into ever bigger projects have driven away much of the earlier Drupal market. Now Drupal is better than ever, but has a tarnished reputation.

As we see more and more successful, sophisticated projects launch, I'm confident Drupal 8 will grow -- perhaps more slowly than previously -- but its future is very bright.

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <cpp>, <java>, <php>. The supported tag styles are: <foo>, [foo].
  • Web page addresses and email addresses turn into links automatically.
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.