While this article focuses primarily on the state of Drupal “contrib” (modules and themes which are not part of the “core” Drupal download), it also takes a look at the greater “State of Drupal” in terms of sites known to be running on some version of Drupal, comparisons of the rate of uptake after Drupal 6 and Drupal 7 release, and a small case study involving attempting to perform a “major upgrade” from Drupal 6 to Drupal 7 on a site using a significant number of contributed modules.

The recent history of Drupal core usage

As a starting point, I think it is helpful to look at the recent history of Drupal core usage and compare the uptake of Drupal 6, after its release, with the uptake of Drupal 7. On June 22nd, 2008, when Drupal 6.0 was released, there were already significantly more sites using Drupal 6 than Drupal 5 (almost 32,000 on Drupal 6 vs almost 17,000 on Drupal 5). Both core versions of Drupal steadily gained users for a time, with Drupal 5 reaching a peak of about 24,000 sites about 7 months later, but by that time Drupal 6 was running on more than 100,000 sites. By late July 2009 (a similar point to now in terms of months after the major version release), Drupal 5 usage had dropped to about 20,000 sites and Drupal 6 was running on more than 160,000 sites; more than eight times as many installations. Since then, Drupal 5 usage has tapered to about 7,000 sites; a bit more than 1% of total Drupal usage (please note: it’s likely that many of the existing Drupal 5 sites do not report usage back to Drupal.org).

Now let’s look at the usage of Drupal 6 and Drupal 7 since the time of Drupal 7’s release. Drupal 6 peaked with about 355,000 sites, shortly after Drupal 7’s release in January 2011. At that time Drupal 7 was running on about 24,000 sites, a fraction of Drupal 6 usage at that time. Since then, while sites running on Drupal 7 have steadily increased to their present values, about 280,000 sites, Drupal 6 has hovered around the same value, drifting between about 320,000 and 350,000 sites, but not yet significantly dropping. Almost 13 months after Drupal 7’s official release, we still have more sites running Drupal 6 than Drupal 7 (and I suspect that a significant percentage of the Drupal 7 sites are in development rather than production). But what does this really say? Let’s look a bit closer at the numbers and trends:

Note: I banged this graph out in Excel since the Google chart of Drupal usage, normally displayed on project pages, seems to fail as “too large to process” for “core” usage statistics.

Drupal usage has grown by leaps and bounds since Drupal 6’s release. In June 2008, there were fewer than 50,000 sites using Drupal 5 and 6 combined. Now, a bit more than three-and-a-half years later, there are more than 615,000 sites running on some version of Drupal — more than a 12-fold increase in that time period! A year ago, this figure was less than 400,000, so Drupal 7 sites make up a large proportion of the more-than-200,000 Drupal sites added since then. The growth was steeper after Drupal 6’s release, but we still did not have 200,000 sites, total, by July 2009. In any case, it’s safe to say that for most use cases, we have the modules necessary to build a good site based on Drupal 7, so if you are hesitant to use it, don’t be. There are many great advantages to Drupal 7 and with the continual improvement of the contributed modules, we should probably build new sites on Drupal 6, only if modules critical to the use case are lacking for Drupal 7 (or if the “new” site is another site in an existing Drupal 6 “multi-sites” installation). Even if a “critical” module exists for Drupal 6 and not yet for Drupal 7, it may still be worth building the site on Drupal 7 if you have the coding experience to port the Drupal 6 module to Drupal 7, which would help alleviate the current issue that many significant modules are not yet available for Drupal 7.

State of Drupal 7 contrib (modules)

Good news: Almost all “Top 100” Drupal 6 Modules are ported to Drupal 7

The good news, especially for site builders creating a new Drupal 7 site, is that most of the top 100 modules are ready for use on Drupal 7. Nine of them are redundant (now included in “core”), 43 have “stable” releases, 23 have beta or RC, 11 have an alpha release, and 9 are in “dev” status, while a couple others recommend using another module which performs similarly.

The topic of Drupal’s backward compatibility issues has come up in various ways over the years and has been an issue of debate in most cases. When we responded to Dries’s “State of Drupal 2011” survey, only about 8.2% of the community members who responded indicated that improving backward compatibility was one of Drupal’s “biggest challenges”. But this is actually a pretty large number of respondents, considering that there were 19 other options for the question, and we could only select three, and also considering that the majority of those who took the survey might not represent the majority of Drupal stakeholders who would most benefit from improved backward compatibility: people who might not work with Drupal full-time, and might not personally maintain any code, and who want to upgrade their sites to the next major versions, but cannot do so easily because of missing modules and the fact that, regardless of whether a module might be very close to compliant with the next major-version API, modules are only for one major Drupal version.

If this lack of API backward compatibility were common with Windows or Mac applications, or Firefox plugins, or just about any other software written for a platform, far fewer people would make these upgrades or they would wait a very long time to do so (and might end up changing operating systems or browsers to avoid the headache). The opposite is actually true in the case of Mac apps; Apple has historically supported legacy code and legacy processor types with compatibility bridges which, although not particularly great for performance, at least allowed needed software to run. Firefox and Safari, my two most-used browsers, regularly release major updates which don't break every plugin (at least with Firefox, some add-ons are identified as incompatible and disabled until a compatible version is released). And PHP deprecates functions, but usually doesn’t make it impossible to use code that worked in the previous major PHP release. But Drupal introduces major changes that result in developers having to learn a whole new API just to get their modules or themes ready to run again. This made sense in the past for a variety of reasons, at least back when Drupal was still in diapers, but there might be sufficient reason, now, to revisit the issue and explore whether this approach still makes sense in the foreseeable future.

Lest it sound like I think this approach was always a bad idea, I should say that I do understand the logic behind breaking compatibility, at least historically. Too much attention to backward compatibility and it limits innovation, more bugs creep in, and the code starts to bloat. There are even former Drupal developers who claim they now work on slimmer platforms in order to avoid what they consider too much bloat in Drupal, already. It’s doubtful that Drupal would be as popular as it is today if the core team had focused on maintaining backward compatibility in the API just to keep from breaking legacy code. But what worked in the early days of Drupal may not work so well when there are thousands of modules which are not considered high enough priority to port to the next major Drupal release and most larger Drupal sites seem to have at least one of those that they consider a necessity.

Bar chart from Dries’s summary of the State of Drupal 2011 survey results:
For the purposes of this post, I’ve marked up the image to discuss a few points. Yes, there are “only” 269 respondents who chose backward compatibility as one of Drupal’s biggest challenges. But it is also arguable that this challenge is directly related to many of the other challenges which ranked higher.

Okay, so the title of this post is a bit tongue-in-cheek (it’s a reference to a particular Drupal 8 usability issue); I don’t really think this misunderstanding is “universal” but there does seem to be a bit of confusion about when to expect Drupal 8. The confusion seems common among the greater Drupal user-base, and it seems to affect more than just new Drupal users and those evaluating or considering using it, but also Drupal stakeholders who have several years’ of experience. According to Dries, we should not expect to see Drupal 8 released for at least another 18 months. Yes, I’m aware that he was talking about 18 months after Drupal 7 hits its “productivity plateau”, and since he also indicated that he would announce when he thought we were at that plateau (and to my knowledge, he has not yet) it’s likely to be more than 18 months before we see Drupal 8’s release.

And yet, for the past few months, we have been seeing increasing questions about Drupal 8 (in the greater developer and discussion community); questions which make the assumption that Drupal 8 is very close to release; a couple examples of such questions:

One user wrote:
... I have several years working with Drupal 6 and I am thinking to start building sites and develop over Drupal 7, but it seems that Drupal 8 will be launched very fast. Is it best to wait some months and learn about Drupal 8?

• What are the differences between Drupal 7 and 8? (StackOverflow)
• What version of Drupal should I choose? (StackOverflow)
• Is it better to learn Drupal 7, or Drupal 8?

It’s easy to just think “Well, that’s just silly!” when we see one question like this, but when we see many such questions popping up, we have to know this points to some murkiness in terms of the Drupal release cycle.

Some time back, I promised another short article in the WYSIWYG set-up series for Drupal 7, one which covers BUEditor. First, we should note that the BUEditor is not actually “WYSIWYG”, but it offers some nice features which might make it a bit better than the WYSIWYG options, depending on your use case. It also does not integrate with the Wysiwyg module. You add it separately (and instead of Wysiwyg), but it does have some great supporting modules and code libraries. This article covers some of the basics about use and installation of the BUEditor on a Drupal 7 site (most of the information applies equally to Drupal 6, where the BUEditor module is also available). I’ve also got some good tips for some ways to extend the default button-set. (And you can download my modified button code here to easily import the buttons into a new editor profile.)