Drupal 7: Ready or not?

At local Drupal group meetings I've been to lately, the big question among those of us who build sites with Drupal is (as you might guess): Is it time to switch to Drupal 7? I can't give you a simple yes or no answer to this question -- I think it depends on your situation, mainly due to the state of contributed modules and some key core bugs -- how disappointing! Drupal 7 was released on January 5 of this year -- it has been out for more than seven months -- and the D7CX (Drupal 7 Contrib Experience) pledge (which many signed and few fulfilled), and the promise to keep the core bug numbers down was supposed to mean that Drupal 7 (unlike Drupal 6) would really be usable on its release date. I'm not blaming the core developers or module maintainers for the fact that it wasn't -- we're all volunteers on the Drupal project. Fixing core bugs is not always the most exciting work, and updating a module from Drupal 6 to Drupal 7 (and providing a data migration path) is not exactly easy or automatic. But it's still a disappointment that for all of the hype about D7CX and the bug counts, more than seven months after the release of Drupal 7 I am still not convinced that it's time for everyone to switch.

So let's return to the practical question: Is it time for you to switch to Drupal 7? As I said above, I think it depends on your situation:

  • If you have a staff of programmers, and a large-budget project: Yes. If you are willing to expend enough effort, you can most certainly build a web site in Drupal 7 with whatever functionality you want, and it's a LOT better than Drupal 6 in many respects. But this case is a very small percentage of all Drupal projects.
  • If you are building a web site that doesn't need any contributed modules at all: Yes. You can almost certainly also upgrade an existing Drupal 6 site with no contributed modules to Drupal 7. But this case is also pretty rare.
  • If you have an existing Drupal 6 site with contributed modules (and a smaller budget): Probably not, although the answer to this is getting steadily closer to Yes, as module maintainers find the time (or someone funds them) to port their modules to Drupal 7 and/or build a data migration path.
  • If you are building a new site with contributed modules (and a smaller budget): Probably not. I'm sure many people would disagree with me on that answer, but having recently had the (dubious) pleasure of working on a couple of Drupal 7 website projects, I am sticking to that answer. Two problems I ran into on my recent projects will serve to illustrate:
    • Internationalization: if your site will be multi-lingual and uses Views, you will need the Internationalization Views module. However, as of this writing, it is completely unusable -- the base Internationalization module was updated recently, in a way that made Internationalization Views completely break (this will hopefully be fixed soon). And I ran into several other Internationalization issues as well, which don't have solutions on the horizon (beyond the expedient solutions I had to adopt: hack core, hack contrib, turn off validations that were causing me problems, etc.) (and I do mean hack! In the sense of ugly, rough cuts).
    • Complex queries: In several situations I'm aware of, there are some bugs in database queries that cause them to return no results. I've personally run into it when building Views with complex filters, and there is another reported core issue when using Search with content access permissions.

    If you are willing to do some programming or patching, you can probably get around these types of issues -- just don't expect everything to work well "out of the box".... Which I think was the promise/intention of the D7CX and bug count efforts?

In summary: although Core is getting better all the time, in reality you can't build most sites without using at least a few contributed modules (and most sites will want to use a custom or contributed theme, too). So maybe we need to concentrate more on the contrib ecosystem, and the impacts that changing Core have on Contrib, rather than just thinking about how to make Drupal core even more awesome, efficient, and usable. And (although everyone hates them), maybe we should consider even lower thresholds for bug counts, and count it as a critical bug if some change in Core breaks a bunch of contributed modules? Something to consider, anyway... Let's not have a multiple-month delay in Drupal 8 between its release and when I can definitely say "Yes, it's time to switch".

Tags:

Comments

Agree Completely

I agree with your conclusions completely. Working on a fairly large project, but with a limited budget for developers, Drupal 7 is not quite ready. This is mainly due to the fact that many contributed modules are not ready, and dedicated module development is needed to do many of the functions expected in Drupal 6. While it is getting closer, there are still MANY modules that are in dev, alpha and beta stages - 8 months after the launch of Drupal 7.

Great article! Hopefully some

Great article! Hopefully some enterprise will read this before plunging in Drupal. A team of PHP developers is almost always needed so don't go for Drupal if you don't plan on having developers as part of your group.

Another problem is that Drupal is highly deficient in regards to multilingual sites, probably because they haven't made the decision to make it part of the core. Until they do, and contributed module adopt it properly, Drupal will ber very difficult to adopt for big enterprises with clients using different languages.

Agree 100% (unfortunately)

What can I say more than I unfortunately can only agree to 100%. The examples you take up is very similar to my own experience blocking adoption of Drupal 7.

However, I am sensing an increasing awareness in the community, on all levels, that more focus is needed to find ways of improving our processes and workflows to better this. Dries has introduced a lot of new changes, core initiatives, gates and other things. The Drupal ecosystem is growing and resources are expanding for the community to be able to introduce the necessary changes.

It will take time to get there, but we are on the way and hopefully things will only speed up from now.

As always, the key is: "it

As always, the key is: "it depends". If all you do is build brochure type of sites (traditional static sites), which is the majority of use cases, then Drupal 7 does the job very well out of the box RIGHT NOW, yes, even multilingual sites. For these types of sites, you don't need a lot of PHP programmers. What you do need are a few good technical people who understand the "Drupal way". Being a good PHP programmer does not necessarily makes you a good Drupal developer; you have to understand the "Drupal way" of doing things.

Enterprises and governments build the majority of their sites as brochure. The built-in multilanguage in D7's core is vastly improved over D6. I disagree with the comment that multilanguage is not built in core; it is. But does it need improvement? Sure, of course, there is always room for improvement ... and improvement in the documentation.

To sum up: If enterprises and governments want to use Drupal 7 to build MULTILINGUAL sites to replace their current static HTML sites, then go ahead. Drupal 7 will do the job with few technical people.

You don't need Internationalization Views

"Internationalization: if your site will be multi-lingual and uses Views, you will need the Internationalization Views module."

This is not correct. You can translate strings with just Locale module enabled.

multilingual sites with Views can be built despite rough edges

I built a D7 site that uses Views, i18n, References, Media, Panels, Calendar, Date, to name but a few of many contrib modules. There are rought edges. You have to take time to test well and go slowly because new releases or dev updates of one module often causes others to stop working in certain ways. And you'll still feel like your flying by the seat of your pants. But it can hold together in at least some use cases, with some work-arounds for things that might not work the way you'd expect or want.

In terms of the 'bug counts'

In terms of the 'bug counts' I think it's important to mention that these were only introduced a few weeks ago - after months of me ranting about how difficult it was to actually get bug fixes into Drupal 7 at all (the other part of that was webchick effectively not being able to commit /anything/ to D7 between March and June, unless Dries got to it first, which wasn't happening). If there were other promises to keep the bug counts low during the D7 cycle I must have missed them.

Had we started Drupal 7 with those thresholds, we would not have ended up with a two year code freeze. Whether those (and the gates) are enough to stop the same happening for Drupal 8 it is too hard to tell.

At the moment, despite some of us working 'overtime' to keep those bugs under thresholds, at best we're only manage to keep equilibrium with the bugs that are being newly reported. That is likely to continue for a few weeks yet at least unless a lot more people start helping with core bug fixing. http://drupal.org/node/1242856 is an attempt to improve that situation pro-actively.

I would not recommend to any one that they should upgrade an existing Drupal 6 site that they're happy with to Drupal 7 yet, unless they have a particular reason they want to upgrade (like taking advantage of new features, or wanting to refactor how the site works as part of the upgrade). Drupal 6 will be supported for 2-3 years from now, so there is still plenty of time.

I do disagree completely with not building new sites on Drupal 6. If you have a small budget, you have a small budget for upgrading too, and any site beyond the most simple is going to take quite a bit of effort to upgrade. So you're much better dealing with a few bugs in Drupal 7, for a site that will have a lifespan of 4+ years before it's unsupported, than building a site on D6 in the knowledge you'll need to upgrade it within the next 2-3 years (or run an unsupported version). That only really makes sense if you know you're never going to upgrade the site at all.

That's true...

True - upgrading from 6 to 7 later would be a high-budget item. Good point.

there are some bugs in database queries

Issue URLs? Your database maintainers are eager to help.

Issue URLs

Here are URLs of some specific issues I ran into in my last project:

i18n/views:
http://drupal.org/node/1232748
http://drupal.org/node/1238642

Database query problems (core/views):
http://drupal.org/node/1112854

Link translation:
http://drupal.org/node/949604

Complely Agree, drupal

Complely Agree, drupal contributed module are not ready, for example in a test views broken and, also uninstall it, it was impossible create a page wit a path (page not found).

Ubercart/commerce/ecommerce project

I'd like to add to this conversation that things will get increasingly hard when deciding to update a Drupal based shop. We did Dekbedovertrek webshop for example in D6+ubercart. Updating/upgrading is'nt only a matter of D7 ready, there's also the commerce module to become ready any moment. Is it taking over Ubercart? We use a lot of Ubercart related 3th party modules. Will they have a decent upgrade path for both D6>D7 AND UC>DC? I doubt that, from what I saw so far it will never, only core+UC core. Drupal can't afford to stand still. But is this total waste of development recources really needed?

Just my 2...