Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By jim0203 on
Following all of the stuff at Drupalcon Paris about Drupal moving from a service to a product that is friendly for end users, I was having a discussion with a friend of mine who has used Drupal in the past. He isn't a developer or coder but he's not non-technical, either.
He was using Drupal a little while back, when a lot of modules hadn't been upgraded to Drupal 6. This was a source of some frustration to him, as it has been to other users. What also frustrated him, however, was the lack of compatability between modules written for Drupal 5 and Drupal 6 core.
My reaction was to explain why this isn't possible: changes to the API in core necessitate a complete rewrite of modules. His point was that this is different to how other systems work: he was familiar with operating systems like Windows which usually support programs written for earlier versions. Think of Drupal core as the operating system and contrib modules as the programs and you get a good picture of what my friend expected should happen.
So, my question is: would it be possible to write some kind of compatability layer that allowed modules for D5 work in D6, and modules for D6 to work in D7?
Comments
First, yes, anything is
First, yes, anything is possible. But is it worth the effort?
If the modules aren't ready for the version, there's nothing forcing anyone to upgrade to that version. The work to make a compatibility module would probably be enough to upgrade a large number of popular modules to work with the next version.
Also, I remember reading something from Dries about the design philosophy for Drupal. That concept of moving forward was a conscious decision.
So, while it's possible, I think it's highly unlikely that anyone with the knowledge to do so would ever want to create such a module. Unless someone wants to pay. Then there's achance someone would undertake the task.
I totally take your point and
I totally take your point and agree that this would be a big task (can anyone specify exactly how big?).
However, it would have two huge benefits:
(1) We would never have the disaster that we had with Drupal 6 whereby many of the contrib modules didn't work on day 1. I know that D7CX is partly going to fix this, but a compatability layer module would completely fix the situation for those modules which didn't have upgrades on day 1.
(2) It would allow people to upgrade to a newer version of Drupal and gain the new functionality of the new core, and the new functionality of new modules, without worrying about losing existing functionality.
But I guess the macro view is perhaps the most important: if we are going to follow Dries' lead from Drupalcon Paris and start changing Drupal from a service into a product, then we have to build Drupal so that it works how people expect it to work. Most users take their cues from operating systems where upgrades are concerned, because that is what they are used to upgrading. It is off-putting, therefore, for users to lose a massive amount of functionality when they upgrade core.
There may be an architectural or design reason why this hasn't been thought about yet, but I can't find one - would be great to be enlightened.
It's done this way for the
It's done this way for the purpose of keeping the code slim. Having to re-write the Drupal core to make it backwards compatible would add a lot of bloat to the system.
Contact me to contract me for D7 -> D10/11 migrations.
I'm not saying that Drupal
I'm not saying that Drupal core should be rewritten to be backwards compatible - that would be awful - but that a separate layer provide backwards compatibility if the user requested it. Surely this could be provided as a module?
Maybe/probably, but it would
Maybe/probably, but it would have to be a pretty hefty module, as it would have to basically be programmed to deal with all the differences between any two (or more) versions of Drupal, with the proper steps to converting to the newest version.
Contact me to contract me for D7 -> D10/11 migrations.
Indeed - there would
Indeed - there would certainly be performance implications.
But I guess my core point here is that this is how people expect Drupal to behave. So, if we are to follow Dries' lead and move Drupal towards becoming a consumer product, isn't a compatibility layer necessary?
I'm aware that this might be a big project, but can anyone who has worked on Drupal core help to specify exactly how big?
This seems to have died a
This seems to have died a death, so I've transferred the discussion to g.d.o at http://groups.drupal.org/node/26812