back to article Drupal looks beyond open source zealots

Every few years, Drupal violates one of the industry's most sacred rules: don't break your APIs. The next version of the popular open source content management system – Drupal 7 – will do just that. And more. It will offer a redesigned user interface that targets – gasp! – non-technical users. It will hide features that devs …


This topic is closed for new posts.
  1. Franklin
    Thumb Down

    A title is required

    I considered Drupal, among other CMS solutions, for a very large Web site I just built. Actually installed it alongside a couple of others for testing and evaluation purpuses before committing to building the site, in fact.

    In the end, I rejected Drupal for lacking only a single feature that the site required: the ability to create multiple templates, and then to assign a template to each page. The site is comprised of several sections, each of which has its own look. Drupal appears to lack the ability to say "This page and this page get THIS template; that page, that page, and that page get THAT template; and these pages get this other template over here."

    1. Anthony Cartmell
      Thumb Up

      Template file naming convention

      You can do this, there's a template file naming convention. Not that well advertised, I grant you, but the theme developer module can tell you what template file names and theme function names are candidates for any item on any page.

    2. Irk

      Page templates are easy in Drupal

      It's all inside the theme. The first is page.tpl.php, then you can have page-front.tpl.php, page-news, and on and on. If you want something node specific then it's node.tpl.php, node-blog.tpl.php, and so on. If you make a custom field that can be TPL'd too. The naming system can sometimes be easy to guess at, but in case of confusion you install the Devel module and turn on Theme Developer - it'll give you hints at tpl files for any element on the page you click.

      Given, you've already picked something else to use for your site, but I wouldn't want someone in the comments thinking Drupal couldn't implement a feature that I use for at least 85% of the time that I'm at work in theme development. Also, a lot of the template work can be bypassed with Views, which will be in D7's core along with CCK.

    3. JeffV

      No title is required

      In fact there are at least two ways to do this that immediately spring to mind, and possibly as many as five, depending on the amount of customisation required.

      Page template naming, template programming using a section identifier, Context module, Composite Node module, Panels module. And if you want to be much more exotic: multisite installation with shared sessions, multisite with shared database, multisite with Domain Access.

      And I reckon that's probably not a complete list. It is _very_ unusual in Drupal that you are the first person to be facing a particular problem.

      Drupal has served us well for sites with more than 80,000 pages, at moderate traffic levels. And with some work on the caching infrastructure it can deal with quite heavy traffic.

  2. Jeff 11
    Thumb Down

    Not worth upgrading if you run a serious site

    I wish Drupal 7 had gone with the OOP approach. That alone would've made it worth upgrading to and justified breaking compatibility with pretty much every contribution under the sun for v6. Being able to extend the system core instead of having to break/patch it *forever more* as they release their own updates would have made it displace ezPublish as the (technically-speaking) best product and made community contributions that much richer.

    But for v7 they've just mashed up their API for no good reason, and their decade-old approach to UI design is still ingrained, so Drupal has no place in the enterprise sector.

    1. JeffV

      There's more to it than that

      Drupal uses OOP in specific places - for instance the Views module (a graphical point-and-click query generator). But beyond that, it's always had an object approach - for instance, the key content type, node, is an interface in the object sense: by implementing the interface for any new content type you care to make automatically gains all the advantages of being a node - the revision system, searchability, taxonomies, and much more.

      But it doesn't use OOP to do this. It uses naming conventions for overrides and extending, rather than a pure object system. It works this way for a few reasons:

      - while the API is not frozen, in practice it almost always evolves, which is to say that many, if not most Drupal 6 modules will probably work on Drupal 7 with only minor changes. Certainly that was my experience of all the transitions since 4.5. A change to pure OOP would have made module upgrades a great deal more difficult.

      - it runs on a wide variety of platforms - everything from shared hosting to the cloud, and with a wide range of PHP versions; Drupal 6 continues to support PHP 4.4+ as its minimum requirement. But before PHP 5, OO was not robust. Taken together with the previous point, it would not be sensible to introduce OO as a language structure in a big way into the core for D7.

      But I'm certain that Drupal will continue to use more and more OO structures with the improvement of the performance of OO in PHP, and as the need to support Drupal 6 fades.

      Where there are API changes, it's not 'mashed up for no reason'. There are major advances in the capabilities which mean the API needs to evolve - for instance the database now has a much better abstraction layer. As a result there is support for SQLLite, an experimental module for using MongoDB, and work going on on SQLServer support.

  3. RISC OS

    TYPO3 5

    will kick drupals arse.

  4. Petrea Mitchell
    Thumb Up

    It depresses me that this is news...

    ...but kudos to them for doing real usability research.

    1. JeffV

      Conference in Copenhagen next month

      I suspect that this article came out of some PR: we have this year's European conference in a month. A punt that appears to have been cut/missed/dropped from the article.

      We hold two conferences each year - one in Europe and one in the USA. Last USA was about 3,000 attendees, I think. Something like 600-700 registrations so far for Copenhagen.

      I'm not sure about the Reg policy on links, so I won't. But if you are interested in the details, search on drupalcon.

      Disclosure: you can probably tell from this that I work on Drupal.

  5. Anonymous Coward

    A year to fix 114 bugs?

    If it takes a year to fix 114 bugs, maybe they should hire some professional developers.

    1. JeffV

      That figure is not entirely representative

      The 114 bugs were/are critical blockers to release.

      The critical list includes things that some people might not think critical, for instance the performance improvement issue 'Lazy-load JavaScript and CSS via AJAX framework'.

      You might get a better feel for the amount of work that's gone into version 7 if you look at the number of issues closed in the last year. Excluding feature requests and support requests, about 2,500 have been dealt with.

      Drupal 7 will be released when it's polished though I think there are already some light-use sites already using it in production. But of course that's foolhardy for any site which matters. Meanwhile Drupal 6 and 5 continue to grow. Last week there were about 5,000 modules available, spread out over those two versions.

      And I'm pretty sure the bulk of us working on Drupal are professional.

      Thanks Reg for covering Drupal.

  6. Ian Tresman

    Great product, but no steering wheel

    Drupal is great, and it can be made to do anything. But out of the box, you can't upload a couple of images, give them a caption, and place them where you want. That's the problem.

    1. JeffV

      Or perhaps no wing mirrors

      One of the improvements in Drupal 7 is to move image handling into the core.

      Drupal is heavily darwinistic. It's also very modular. Before something goes into core, it's implemented as a module. Actually, typically there are several competing modules implemented. Eventually the best ideas embodied in these are brought into the core as a common framework that lots of modules can use.

      Almost all the major features in Drupal have evolved this way as responses to user needs, and it's one reason that Drupal hits a sweet spot.

  7. Irk

    Looking forward to it

    Sounds like D7's going to do a lot of the things that my customers demand so regularly that we implement it by hand-coding or with a lot of tweaks anyway. Most devs I know are actually pretty excited about the move to D7 because of this and because a lot of tasks will potentially become easier and more streamlined with this version.

    Still, waiting it out before adopting D7. Most popular modules have already have upgrades to it, but it's always good to sit back and watch the guinea pigs toil for awhile. Something I learned from first-gen Apple releases!

  8. edde

    Drupal 7 is going to be great.

    @franklin: There are contributed modules for that. is one of them.

    @Jeff 11: More OOP would have been nice yes. Drupal is moving in that direction. The new database support, based on PDO, is OOP for example.

    @Anonymous Coward: Please learn to read, it wasn't one year it was from April. Plus, it is 114 critical issues. Some bugs are easy to fix while others are much more difficult. Drupal is a big project and there are also almost 7,000 modules for it.

    Other than that, I have been running my personal blog,, on Drupal 7 alpha 5 for almost two months now without a hitch. Including posted a lot about the experience about it.

    It works really great, but there are still things that needs to be ironed out. The upgrade path from Drupal 6 is what prevents it from going beta right now. It is almost there so with a little bit of luck there will be a beta within a few weeks.

    I have also followed the development of Drupal 7 very closely. The community is doing a fantastic job making it rock solid. I believe some of the delay is about that we want it to simply be perfect. But since Drupal is gaining momentum in the enterprise world I prefer a small delay compared to rushing it out.

  9. bogsheet

    Analysis of analygous

    Perhaps the legacy of the former imprinted in your brain resulted in the spelling of the latter... Or has digital made you forget analog?

  10. Anonymous Coward

    Excuse me...

    " A usability expert - Mark Boulton, who helped re-design the BBC's site - has also been hired to work on the Drupal 7 UX and"

    The man responsible for turning one of the most usable sites on the web to a utter fuck up of massive proportions is leading the way.

    Well Drupal, you are truely shafted.

    1. Graham Wilson

      @A. Coward - If what you are saying is correct then it's a worry

      If what you are saying is correct then it's a worry.

      The BBC's site is a real mess for all sorts of reasons, the most obvious being the poor default screen scaling and tight cluttered layout not to mention the difficulty of finding one's way about.

      Having evaluated Drupal on several occasions in the past, I rejected it for being too convoluted for quick and dirty stuff, so I would welcome a more easy approach.

      Actions are louder than words, we'll watch for the evidence in the released code.

  11. Reg Sim


    "The man responsible for turning one of the most usable sites on the web to a utter fuck up of massive proportions is leading the way.

    Well Drupal, you are truely shafted."

    I am not sure what the BBC's website was like before, but trying to use it now is not my fav experiance.

  12. guyweb

    Mark Boulton isn't responsible for the BBC website redesign

    Get your facts right! He wasn't responsible for the BBC website redesign. The team that did it were influenced by his work on website grids.

    However, he was involved with the Drupal 7 user experience enhancements. He did it in the open, engaging with the Drupal community. The user interface is dramatically improved as a result.

  13. blmille1

    NO CRAP!

    Why does this come as a surpise?!

    Every freaking time I've read anything about Drupal they warn you that the APIs will break--they go out of their way to tell you that.

    It doesn't take a genius to figure that out--and anyone who develops for Drupal knows that.


  14. Gareth

    Backwards-compatibility is overrated...

    Changing the API for new versions and providing legacy support (5.x is still officially supported) is acceptable practice for a young product. Perhaps when they have 10% of the Internet and are 10 or 11 releases in then it will not make sense.

    There is a trade-off between backwards compatibility and innovation. Drupal is really only in it's fourth major release (versions <4 were essentially a bunch of scripts used by Dries to run personal websites). To retain 100% backwards compatibility is a lot of work that is better directed towards innovating and removing issues that are holding back innovation.

    Look at what happened to DOS/Windows - 25 years on and we're only just getting free from poor decisions made at the beginning.

  15. Anonymous Coward


    "Every few years, Drupal violates one of the industry's most sacred rules: don't break your APIs."

    Look at it this way: they used to do it every six months or so...

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2021