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:

At this point I see no compelling reason to move to D8. If anything, it still lacks many of the small modules I use to build out sites.

We are a Drupal agency in Athens, Greece (netstudio.gr). We build a lot of e-commerce websites. So, even though we have built some (even big) websites on Drupal 8, it's only now the Drupal commerce got stable that we switch fully to Drupal 8 and we expect to publish many websites in Drupal 8 in 2018.

So, the Drupal 7 adoption really kicked off when Views was ported. Until that point, the shape of the line resembles the shape of the Drupal 8 line now. I guess the question is: what is the equivalent event that'll send Drupal 8 climbing straight up? Of course, it's possible that there isn't one, but I'm going to stay positive :-)

Maybe when there is a fully supported Drupal 7 to Drupal 8 migration path? Hopefully we're only a release or two away from that..

D7 really picked up after only 6 months, when Views was ported. But D8 is now 2 years old, and has not picked up. That is 4 X the time that it took D7.

I can guess that the complexity of D8, coupled with lack of modules and distro, as well as its bigger foot print in terms of resources made it all harder for smaller sites to find a compelling reason to move. But we do know most of that from the start with D8 being enterprise and all ...

I haven't moved away from Drupal, but I've put off getting into Drupal 8 until just recently because it didn't appear to be production ready. It's a real shame that it took so long because the move to a Symfony-based architecture is quite an impressive feat, and I think the future looks better than ever from a technical perspective. I hope that it can find success as a headless CMS. However, I've stopped contributing to Drupal due to lack of trust in the DA especially after the Larry Garfield case, so we'll see what happens.

I never even doubted the DA when I was working in 7. But now, it's so full of PC SJW types that politics has trumped the project. They are more interested in BS than actually moving forward. I was a paying member for many years. Not any more.

Driving away Drupal site builders by requiring Composer expertise was a really bad idea, but the developers making this decision simply don't realize the value non-developers/site builders bring to Drupal. But I don't think it's too late. Drupal 8 is an amazing tool for building rich web sites, and most of the times, you only need to add a handful of modules to build functionalities which required a truck load of modules in Drupal 7. But the technical skills required for Drupal 8 need to be more in line with Drupal 7, to make it more accessible and widen the adaptation.

There are several things in d7 that took one line to do, and now require 4 or even sometimes 10 or more. I keep here how it's the "proper way" and "you'll be better off", but never specifically why.

I can confirm, I have been building Drupal sites since Drupal 5, every six months or so I look into 8 as an option for a new site, in the end composer drives me nuts and back to Drupal 7 (and there are more modules for 7 too)

Out of curiosity, do you consider Drupal 7 site builders to be drush users in general? I found that I was often the odd duck out in any Drupal crowd for not having made drush a regular part of my workflow. I'm curious to know if folks see Composer as more inscrutable than drush, which I confess still confuses me on any given day when I'm trying to figure out which version(s) I have installed and which sites I maintain use which drush version. : P

Additionally, are you aware of the Ludwig project we (Commerce Guys) published to allow people to use a D7 / Libraries style approach to dependencies without requiring direct Composer use (cf. https://www.drupal.org/project/ludwig)? Would that help at all?

Last, we also have prototyped a Composer GUI to see if that would help folks even further ... do you think something like that would address Composer related concerns? I know bojanz and a group of folks got together to discuss this at DrupalCon Vienna, and I've reached back out to them to see about publishing the results / direction from that meeting so we can help address this shortcoming.

I'll be the first to admit I have "yet another CLI" fatigue, but I keep coming back to the fact that if we don't generally level up to using dependency managers, we're trusting every Drupal user to *be* the dependency manager ... and as human beings, we just aren't that dependable. : P

@rszrama: Thanks for taking the time to ask some questions, it means a lot.

I believe competent D7 and D8 site builders should use Drush. It is an extremely stable and reliable tool which just works, and does the job quickly and with no fuss, speeding up site building immensely. Composer is far more complicated than Drush, claiming anything else is just silly. Just read this article, it says it all: https://www.jeffgeerling.com/blog/2017/composer-and-drupal-are-still-st…

Still, in some developers minds "Drush and Composer are both CLI, and therefore site builders should just get with the program", sadly.

Ludwig might help, but requires that the individual module adds a Ludwig-file, as far as I understand? A Composer GUI might be a solution, I am very interested in hearing more about this, please share your findings!

mbaynton has made an interesting proposal, with a "composer repository that, by definition, contained only packages that were compatible with each other" (like fx Debian) to easier maintain compatibility, and not require Composer. Perhaps a solution? https://www.drupal.org/project/ideas/issues/2477789#comment-12310636

My two main points:
1. Don't force Composer onto site builders, which includes #2:
2. Keep Drush installable without Composer

Also, let me just repeat that Drupal 8 is an amazing web site building tool. The improvements since D7 are too numerous to mention here, but I think Drupal 8 is a real joy to build web sites with, as long as Composer can be avoided :-)

Ditto, Site Builders Love Drush!!! It just works! It has generally maintained excellent backwords compatibility, was easy to use, and FAST! Composer is dead dog slow. I know there are modules, and themes that have tapped into use Drush to pull in required libraries, which usually works, but I am also fine with going and just downloading libraries as needed. It was helpful to know what was going into a project, and the versions used. I was in control of what was used. Composer just starts grabbing things and then complaining about things missing, but not being very helpful.

I don't see a GUI being all that useful, unless it can make painfully obvious what commands are needed to accomplish a certain task, something I struggle with on Composer. But also remove remove or make it easy to deal with the problems that occur when dependencies change that are chained in, and you have no idea what they are there for. It is hard to imagine that a GUI would make things any faster either, however if it could give some feedback on how long something was going to take, I would know if I could go take a nap or something while it finishes.

Drush changed my life in a great way, Composer has been a train wreck.

Drush changed my life, in a good way. i'm a designer FE person but have been able to be very confident on CLI and using drush in particular, was able to do an enormous amount on d7 on my own, as well as in small teams. Composer is an answer to .. what problem??? It has been a nightmare. Unlike D7, D8 requires me to work in a larger team and so is only suitable for larger projects - which right now i have - that's ok - up to a point - but even then, Composer has been horrible, not just for me but also for my back end people. Everything that was simple in drush, is now a tortuous process we just put off.

Twig is a waste of space - a new syntax to learn for no noticeable gain. D8's Form Display Views however have been the making of a great node form intensive project we're working on now - so we're loving that. A bean based block system that works (unlike the d7 incarnation), that's good, and we are looking forward to using bigpipe.

But with so much that has been great in d7, d8's pain points just make it not worth using for most of my clients, and i've reluctantly moved to wordpress for smaller projects.

D8 has been a horrible own goal on the part of Drupal's leadership. Chasing the enterprize, without any consideration of smaller players, (effectively the drupal's wider contributing community) - has been very very short sited, and sad. The web is a poorer place for such hubris and, a heap of small shops and community organisastions hitherto devoted to drupal have bloody noses.

I have used drush for a very long time. Only recently have I gotten into the weeds of drush versions. Drush used to just work, with the latest Drupal 8.4.x version requiring Drush 9 installed locally and then I need Drush 8.x installed globally or maybe that isn't supported --I dunno, the documentation is a bit of a mess when it comes to installing drush now. Then there is drupal console --which I am still up in the air about. It is nice for scaffolding, but it is such a PITA to install and run I don't know if I will use it.

Composer can be simple, but it can also be really complicated. Drupal + Composer can be simple too. No one is talking about how to do this stuff simply anymore . If anyone brings up a simple and effective way to just run Drupal they are chastised for disobeying the laws of best practices. We need to stop putting so much weight into teaching people the right way and get back to teaching people what they can accomplish.

You are spot on. I would also add the fact that the lack of availability of D8 versions of major modules such as the Rules module also contributes to the sluggish implementation of Drupal 8. Two years out and the Rules module is still not ready for primetime in Drupal 8. What a shame.

Downsides of the Drupal 8 focus on "enterprise" priorities were evident from early on, though comments from those of us raising these issues were, shall we say, not particularly welcomed by many figures in the community.

Back in 2013, Nate Haug was one of the first to forecast a decline in Drupal usage with the advent of Drupal 8, https://backdropcms.org/news/dont-panic. His "hypothetical growth chart" showed a significant dropoff in usage following the release of Drupal 8 as small scale sites and their developers were left behind. At the time his prediction was highly unorthodox. As late as 2015, Drupal promoters were confidently forecasting a big upsurge with the new version. (Though, it must be said, Nate's hopeful projections for Backdrop look less prescient from today's vantage point.)

As so often happens, the once heretical has become commonplace. Unlike four or five years ago, now no one faces backlash in the Drupal "community" for remarking on the obvious: that catering to enterprise users will leave many out of the picture ("Have We Reached Peak Drupal?", https://www.previousnext.com.au/blog/have-we-reached-peak-drupal). The difference is existential. When a dynamic is only nascent, it's easy to dismiss or attack those who point it out. Once it occurs, it's too late to deny.

Or, unfortunately, to prevent.

Drupal 8 is a product made by big companies to big companies, and only then are using it. Two years and we do not have a migrate path, we do not have a stable backup module, we do not have many many small modules that we used with drupal 7, now it is almost impossible use it without composer, and it is gettings worst.

Upgrading a Drupal site from 5 to 6, 6 to 7 was relatively easy. This is far from the case with Drupal 8. If site owners wants to stick with Drupal and move to Drupal 8, they need to invest a lot more, which requires more time.

Of course, they can upgrade to Backdrop CMS, which is better than Drupal 7.

"Upgrading a Drupal site from 5 to 6, 6 to 7 was relatively easy."

Upgrading modules from 5-6 and 6-7 was relatively easy. The api's moved from one to the other pretty well. Drupal 8 doesn't have equivalents to many of the D7 APIs. Upgrading module requires nearly complete re-architecture of the module. Much like Updating a D6 module to using D7 entities did.

Drupal 8's theme engine is completely different as well. Also adding to the frustration.

But, upgrading a site from a major version of Drupal to the next major version was never relatively easy.

> upgrading a site from a major version of Drupal to the next major version was never relatively easy.

No, it was insanely easy.

Build new site, export old data, import new data.

Done.

ANY site could be upgraded from D5 to D6 or D6 to D7 in less than a 1,000 lines of PHP. 75% of which was reused from the last site you upgraded.

From my point of views Drupal 8 isn't ready for productive use as so many standard features are missing or not completed. I am referring to things like datetime range fields and it's integration in views for example. If you start to migrate an Drupal 7 site to Drupal 8 or a new Drupal 8 site from scratch you would always check first, whether or not the modules you might need are already ported, but by no means you would expect simple features like this be incomplete. An other thing is Composer integration. While it is understandable that this is better than a home brewn solution it ads much complexity specially for those, who used to use Drush to maintain there sites.

At DrupalCon Denver we were told about the Symphony and Composer changes, but not to worry, only Core Devs would need to use those tools. That hasn't panned out. Developing small D6/7 sites was practical and easy. D8 is so much more complex, that I think a lot of those small, easy to deploy sites, that can really prop up a graph, have moved elsewhere. While Composer may be great for Devs, it is a royal pain for site builders. I hate it.

Why do you need to use composer? I personally use it and love it and think it makes for a better workflow but I fail to see why it is essential in Drupal 8. You don't need to use composer. You can download and install modules using Drush (tell me you're at least using Drush?) - drush dl or drush en , or just manually - download the tarball/zip file and uncompress to your modules/contrib directly. What's changed? Genuine question, as someone who uses composer and has a workflow with composer.

I love Drush!! and use it any time I can. Remember the video "Drush: More Beer, Less Effort"? Composer is ridiculously slow, Drush is fast. Every time I come back to a site that I used Composer on there is a slew of dependency errors that take hours to sort out. Some modules like Address, require Composer, and I know there are others. I lose more and more work to Wordpress, It is hard to compete on smaller projects. I think Drupal is a better product, but it has become very complicated, very expensive to work with, and a big pain to maintain. Whitehouse.gov just dropped Drupal for Wordpress, sighting this very reason. I used to be able to hack together basic modules in D7, but D8 makes my head spin. The decision to drop upgrades in favor of Migrations was a huge mistake. One that I know has been walked back, but is probably too late. I am at the point, that I am considering abandoning Drupal. It just isn't the tool I fell in love with in D6, and more so in D7.

I agree that the gradual shift towards composer (it's by no means been a universally planned and agreed thing, more of a slow evolution) has been a bit of a barrier to DIYers (though it's not as big of a jump as some people see it to be, as long as you do the sensible thing and store all code in Git).

I do agree that site builders are more valuable than most of the community realizes.

A huge part of this is simply a tradeoff that organizations unwittingly make between quality vs. price. You can get a cheap WordPress site built in the low 5 figures. But what they don't realize is that the back-end will be near unusable, and you'll won't be able to easily change things in the future. To get the same site built in Drupal will be 1.5–3x the price, but it will be well thought out and the site will be able to more easily evolve over time as the needs of the organization changes. There's nothing fundamental in the technologies that causes this, it's just that the cheap-n-quick agencies primarily use WP, and the agencies that focus on quality are more likely to use Drupal. Currently price is the bigger factor that organizations are taking into consideration when choosing an agency, mostly because long-term quality is so hard to see.

But part of it is just that the landscape of the web has changed in the past 10yrs. In all parts of the web, people are much less DIY, and more likely to just use a SASS solution rather than build something from scratch, or hire someone else to build something from scratch. People don't blog anymore, they post to social media.

(Disclosure: I'm a Drupal 8 core committer and I work for Acquia. This comment reflects my personal opinion, not necessarily that of other committers or my employer.)

Thanks for putting together your chart. It's neat to see the timelines normalized to years since release. Thanks also for retrieving and including the data that goes back to Drupal 6's release in 2008. Drupal's usage stats page only displays data back to 2012, so it's nice to see the 2008-2012 data in your chart.

Just eyeballing your chart, it looks to me like Drupal 7's usage went from about 50K to 600K between 6 months and 2 years from its release (mid 2011 to early 2013), during which time Drupal 6 usage declined from about 325K to 250K (3.5 years to 5 years since Drupal 6's release in early 2008).

So as a rough approximation, perhaps about 15% of Drupal 7's growth in its first 2 years was from site upgrades from Drupal 6 and about 85% was from new sites adopting Drupal. So while I agree that releasing a stable 7->8 migration path is definitely important, I don't think that that alone addresses the disparity in the rate of new site adoption.

Frankly, I agree with @dalin that differences in the broader website market in 2016/2017 vs. 2011/2012 are potentially the biggest factor: SaaS solutions from WordPress, SquareSpace, and Wix, have captured a lot more of the small site market during this time, as well as many people opting out of small sites entirely and focusing their online presence exclusively on social media platforms.

I think this change in market conditions gives us an excellent opportunity to reflect on the questions of what is it that we want Drupal to be and who do we want it to serve? My own opinion is that I think it's fine for sites that get their needs met from WordPress, SquareSpace, Wix, etc. to use those tools. That might include the vast majority of websites on the internet. But I think there are a lot of organizations, like schools, libraries, museums, and businesses and non-profits of all sizes, that need more than what those tools offer, and for which Drupal could make a real difference in them accomplishing their mission. What I think will really help these organizations the most is distributions tailored to the kind of website they need. I'm extremely excited by the Drupal 8 distributions coming out for YMCAs, volunteer communities, and others, and I would dearly love to see that flourish into thousands of great distributions, collectively serving millions of websites, over the next few years.

In my opinion, Drupal 8 is a much improved platform to build and maintain distributions on than Drupal 7 was for two reasons:
- There's much more provided by core, including configuration management, views, wysiwyg, content and configuration translation, and soon: workflows, layouts, and media. This will hopefully significantly ease the maintenance burden on distribution builders who previously had to assemble these capabilities from dozens of contrib modules and keep them updated and compatible with each other.
- From here on out, upgrading modules from one major core version to the next will be far easier than they were from 6 -> 7 and 7 -> 8. I think this paves the way for true sustainability of distributions.

While I appreciate the concern about priorities like the above being too "enterprisey", I hope that if it proves successful in enabling great distributions, then that will benefit sites of all sizes.

In addition to and regardless of the above, I do hope that we also figure out how to make Composer and some of the other difficult things about Drupal 8 easier and more accessible for everyone.

As others mentioned, drupal 8 just doesnt seem that stable to invest months of development time into it, only to find out it is missing key modules. Sure, we can code it ourselves, or hire someone to do it, but at what cost? Simply using d7 makes more financial sense. I have zero interest in composer. (I am a full time site builder and usually employee 1 to 2 programmers, a front end design person).

I've recently dropped Drupal for Craft CMS or Statamic for my freelance work, depending on the client's requirements. We still use Drupal at the agency where I work. Craft and Statamic are quicker, have less clunky interfaces, and most importantly, they have feature complete Media implementations out of the box.

Drupal 8 is a hot mess birthed from an arrogant clique who thought that various "unimportant stake holders" could be dismissed because they would either follow suit or vacate. People in today's world (especially those in IT) sure love mandates, and with Drupal, this came in the form of forcing Git, Composer, Drupal Console, Drush, and other stuff down peoples' throats. You can't even test out a module anymore in many situations without having those things, which is absolute idiocy. So is it really surprising that Drupal 8 adoption is a joke!?

Did they do all this because these things improved the overall user experience? Nope.
Did they show signs of caring about that when mulling over these mandates? Nope.

Even my grandmother of 80 years would've understood this: You don't turn your back on the people that put Drupal on the map. I guess the spear tip is hitting granite...still.

Hey Dries, instead of trying to be another Elon Musk wannabe that prances around a big stage in front of people at a big event talking about futurology topics, why not just stick with the fundamentals of the very system that allowed you to enjoy your current conflict of interest? A win-win for both the Drupal community as well as your company that you use Drupal to profit from.

Silent Majority makes very valid, simple points:
"Did they do all this because these things improved the overall user experience? Nope.
Did they show signs of caring about that when mulling over these mandates? Nope.
…You don't turn your back on the people that put Drupal on the map...."

Those are not unique perceptions, and it's healthy that they're expressed here.
More than this, drupal leadership needs to be listening not just to arguments, but to how the community is feeling. If there had been more sensitivity on that level from the get go, the d8 rollout may have turned out quite differently. It's not too late to change that - but it needs to be at a cultural, as well as practical (do something about composer, and not just a UI) level. Seriously examine the blockages to adoption for mid sized sites, fix them, and then reengage the community.

The bit comparing Dries to Elon may be mudslinging, but the rest is true. Complexity was introduced and *mandated*, FOR NO GOOD REASON. The net result is the same HTML/assets getting sent to the client, relatively the same UI principles for the site editors, but the build and planning time to implement those two has gone through the roof FOR NO GOOD REASON.

Why the hell did we get rid of a perfectly good system that worked great for everyone from the small end of town to the large end of town, in favour of something that seems to follow all the stupid buzzwords which most of us actively try and discourage in our businesses? None of this can be managed by one person anymore which doesn't just screw freelancers, it screws small IT departments who are almost always multidisciplinary to begin with. Companies turning over millions of dollars with typically 3 or fewer people working in their web department, now also can't build and maintain their own websites using D8 due to the sheer time constraints. So if companies turning over millions are struggling, how is anyone else below them meant to function? Drupal 8 is leaving freelancers, small business and medium business behind. That makes it a "top end of enterprise" solution, not even an "enterprise".

The move to Symfony was meant to bring about an ease of development due to a large chunk of the maintenance requirement being moved to Symfony. It was also meant to bring some Symfony developers to the Drupal world. So has Drupal 8 done either of those since it's release? Are we now not just at the behest of whatever direction Symfony wants to go? How much time has it taken to completely rearchitect Drupal core (let alone contrib) to run on Symfony, vs just iterating Drupal core, just to achieve a 0% change in the HTML/assets that are outputted to the client and a minimal change in editor UI?

This. Is. Ridiculous. It reeks of Magento. The only difference being that at the end of all of the pain of D8, you still do actually get something for it. You'd just better have a good friend base to wipe away your tears at 2am and tell you everything will be alright.

When I first came across Drupal, towards the end of Drupal 5's lifecycle, it was in a reasonably close competition in terms of popularity with Wordpress. Over the years Drupal has steered an increasingly niche course and taken a number of what I'd term strategic mis-steps that have brought the project to where it is today. I would term that current position as being overly narrowly focussed, developer-centric (as opposed to being market-centric), and of decreasing utility to many. As a site builder rather than a developer (see dalin's comment above) I would characterise some of these mis-steps as being typical of software projects that are driven not by the user base or the perceived needs of the market, but by the core developers. Maybe those making the key strategic decisions thought they were doing the right thing, although I'm struggling to see the rationale from my perspective. My primary focus is on enabling clients to get the best from CiviCRM, and that currently does not include using Drupal 8. I can't currently see me recommending Drupal 8 to a client for some years yet, if ever. If Drupal 7 is ever killed off, I'll most probably move to using and recommending Backdrop CMS.

Having chosen D8 for my main project a few months ago, it has been a ruff journey. I like Twig a bit, I can live with Symfony. I like the renewed Drupal backend. But I find that Composer is unreliable and demanding. Also if you follow the rather confused documentation you end up mixing Composer workflows with Drush commands and Drupal console. I claim that mixing these broke my site completely more than once during development. So I now only use Composer. It has helped but updating core and modules still feels rather scary. Compare that to updating D7 with Drush, which I always have found to be very reliable, a bit like running apt dist-upgrade. I felt comfortable doing that. Not so much doing anything with composer. I realize of course that D8 is more complex, being 10x the size of a D7 install. But that complexity has a steeper price than the reward if you ask me. Maybe we should have a D8 light? But I guess there is no way back. I like what I have built using D8 and it does feel good now in development. But I am not looking forward to administering updates in production with D8:s composer.
I have a feeling that the slow migration of modules, that is still holdning D8 usage back, has more than a little to do with the rather uncomfortable environment D8 presents to a dev.

Most every D7 site we build relies on Rules in some way. We're building lots of e-commerce these days, even for organizations that don't really sell to the public (like private member sites). Commerce just recently became stable for D8. But, without Rules there is nothing to tie it all together.

We've built some CMS sites that don't require much in the way of custom workflows in D8, but I would say 95% of our projects are, and will remain, D7. Our customers are small, they are not going to pay us to spend time to move to D8 only to have the same basic site they had before.

We're a technical shop. We had a handful of non technical partners we used to work with on Drupal projects. Unfortunately none of them got on the D8 bandwagon and have abandoned Drupal in favor of WordPress. That has cost us business for sure.

I think it's pretty simple to me why D8 doesn't have as fast an adoption as previous versions: the necessary components that make many modern websites relatively easy to build just don't have contributed modules with stable D8 releases. There's currently no easy way to import content from a spreadsheet (which 80% of the Feeds/Migrate survey said they used) because Feeds isn't ready. In order to import content with the Migrate module, you need to know how to use the command line, which is a huge barrier for non-advanced users. Calendar, Rules, Simplenews, etc. don't have stable releases. If you want to build a site with a calendar and newsletters (without paying for another service), you have to choose D7.

And it was incredibly frustrating. Contrib modules which we depend on like Feeds are not even close to ready. Way before starting the project, I did a module inventoy and looked to see if contrib modules we depended on had been ported yet, but even if they have many of them are missing critical functionality. If I had known the contributed module landscape was so far off, I would not have started the project until 2018.

After all that, and launching the site New Relic is now telling me that the PHP execution time is 400-500 ms more than we were seeing on D7. Hopefully upgrading to PHP 7 will get some of that execution time back, but that would have been true for D7 as well.

The complexity of the D7 sites that have grown up over the years is much more than anything we saw in D5 or D6. If the same level of sophistication had existed in D6, then the upgrade would have been much more difficult to move to D7. We're now seeing highly complex D7 systems that require upgrades... and the cost just doesn't justify things yet.

Drupal does not have as a goal anymore to be usable by a single developer. I think this is a huge mistake for 2 reasons:
1) Apparently, Drupal is losing a lot of developers. The low Drupal 8 adoption rate may well be more to losing developers than waiting to switch from Drupal 6/7.
2) Less obviously, but importantly: there is less motivation to improve Drupal technical and documentation quality. Developing a moderately-complex site shouldn't be that difficult; Drupal's goal should be to make developing moderately-complex sites doable by a single developer, and enterprise sites possible by teams.

I'm a Drupal newcomer. I waited until D8 was a couple of years old before I dived in, so that the modules I believed I would need would be ready. But having been battling to learn Drupal from scratch and build my site for a couple of months, I keep running into modules that had matured on D7 but have not been ported to D8, or still have only early development versions. I'm talking about things like Taxonomy Manager. And many modules at the alpha or beta stage don't seem to have had any development for the last few months, and look like they may never make it to a stable release. I'm at the point of considering D7, despite being a newcomer, or moving onto something else.

Another thing I have noticed is a dearth of user-to-user support for Drupal these days. For example lots of questions remain unanswered on the post-installation forum at drupal.org. Then there's the documentation....

I work for a government contractor. Supporting the website is a small assigned duty with few hours budgeted for any work. I am primarily a Java developer. I think that I would have to come up with a compelling reason to migrate, like Drupal 7 support was ending. Support ending for Drupal 6 was the motivation for me to migrate to Drupal 7. The hardest part of that migration was that the site's theme was derived from a theme that was not supported in Drupal 7. I had to find another theme and customize it. I didn't design the original theme and I didn't know PHP. It was a significant hack effort to get it to work.

Beyond that, there are modules which have not been ported to Drupal 8 yet. I lack the skill set to create my own module.

I am rebuilding my D8 site in Backdrop. In 2018 my DA money will go to Oakland. Composer prevented me from updating modules twice this year, once in March at Drupalcon, more recently because of Drush going to v9 going to 8.4 was impossible. I’ve had enough.

I'm a Drupal newcomer. I waited until D8 was a couple of years old before I dived in, so that the modules I believed I would need would be ready. But having been battling to learn Drupal from scratch and build my site for a couple of months, I keep running into modules that had matured on D7 but have not been ported to D8, or still have only early development versions. I'm talking about things like Taxonomy Manager. And many modules at the alpha or beta stage don't seem to have had any development for the last few months, and look like they may never make it to a stable release. I'm at the point of considering D7, despite being a newcomer, or moving onto something else.

Another thing I have noticed is a dearth of user-to-user support for Drupal these days. For example lots of questions remain unanswered on the post-installation forum at drupal.org. Then there's the documentation....

This is just a testament to the success of D7. Why change when what you have now is working so well?

The time it takes to migrate existing sites properly to Drupal 8 is sometimes a yearlong project, or longer in the case of large D7 installs. Once these projects start finishing I think adoption numbers will change. It really hasn't been that long since some of these sites have started becoming possible due to the slower release of contrib stuff. I have already completed one yearlong project and am working on another. I'd say the upside is way, way more than keeping things on the aging D7 platform due to a lot of factors.

Some people haven't even started that yet, and apparently a lot of people don't plan to. Which should be fine because D7 is still out there and supported.

Btw composer is a poor excuse for people not picking up D8. If you're in this space you should be learning new things. Drupal stopped trying to be Wordpress at least 5 years ago.

I absolutely loved Drupal 6 and 7 and the power it gave site builders to do almost anything they could dream of doing. I could easily put together a small Drupal 7 site for a client pretty quickly and at reasonable cost.

I keep waiting for Drupal 8 to have modules like Rules and Feeds. While they aren't in beta yet I don't feel that I can build client based sites using them. I also agree that using Composer is a bit of a pain.

I do a lot of work for small not for profit organisations. They wouldn't even be able to conceive of a website costing over five figures For simple sites that don't need complex data models I just just Squarespace or use WordPress these days. I never thought I would see the day when I choose WordPress over Drupal!

At the end of the day most of my clients don't really care what CMS they use. They just want something flexible, robust and easy to use and update.

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.
CAPTCHA
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.