It's 2013 out there. And hopefully, in about 8 months or so, we'll see another major Drupal release: Drupal 8. <woot> !
That also means (</woot> ) the end of the life cycle for the first massively popular Drupal series - Drupal 6.
That's right, if you decided to base your (then) new site on the latest stable version of Drupal just 2 years ago (ok, 2 years and a little bit, Drupal 7.0 was released on Jan 5, 2011), you will find yourself running outdated software. There are many reasons for that, including Drupal creator, Dries Buytaert, being the strong opponent of backwards compatibility restriction for development of future versions of Drupal; however, during his keynote at DrupalCon Munich he agreed that at least partial compatibility may be a good idea. For the stats lovers: there are still more contrib modules for Drupal 6, than for Drupal 7.
But let's put aside discussion about necessity of backwards compatibility. Take it or leave it, the fact is that contrib modules written for D7 (and D6, of course), won't work for D8. So the practical question is:
Is it possible to make older contrib modules work under Drupal 8?
Let's see how
Contrib modules can run only under the major version of Drupal they were written for, due to incompatible changes to API provided by Drupal core. List of API differences between last major versions can be found at http://drupal.org/update/modules/6/7 and http://drupal.org/update/modules/7/8.
API differences can be grouped into following sections:
- Hook system changes.. (If you're not sure what are Drupal hooks, good place to start is http://api.drupal.org/api/drupal/includes%21module.inc/group/hooks/7). Hook change names (hook_perm => hook_permissions), parameters (hook_menu), divided into series (hook_nodeapi => hook_node_*), disappear.
- Globals Widely used in D6 and D7, global variables $user, $language and others are replaced by context-aware, object oriented alternatives.
- Common API changes. Database abstraction layer, form generation etc. i.e. Drupal 8 introduces completely remastered bootstrap process. Some functions disappear, some functions change their parameters, some functions are added
As far as Drupal core doesn't allow enabling 6.x and 7.x modules, we will need 8.x module to cope with each section (I assume it is feasible, otherwise I wouldn't write this article).
- Hook system changes.. Our module will need to know hook translation map for all enabled "older" modules. Ideally that should work dynamically. For example, if we have 6.x enabled module that implements hook_nodeapi(), 8.x module must implement hook_node_insert(), hook_node_delete() etc., and in each of these hooks invoke 6.x's hook_nodeapi()
- Globals Our 8.x module has to set up and check status of global variables before and after calling 6.x/7.x hooks. I would introduce custom (non-stdClass) classes, something like this:
<?php
class BackwardsLanguage {
public function __set($property) {
// React on language change
}
public function __desctruct() {
// React on complete replacement of $language object
}
}
/**
* Implements hook_hook8()
*/
function module8_hook8($params) {
global $language = new BackwardsLanguage();
backwards_module_invoke('hook7', $params);
if (!($language instance of BackwardsLanguage)) {
// Language object replaced. Do something.
}
}
?> - Common API changes. Functions that do not exist in 6.x/7.x can be ignored. Removed functions have to be re-implemented. What about functions, whose parameters were changed? PHP does not support function overloading, but for that purpose, we can use namespacing. Obviously, that way we require PHP5.3+ for compatibility module to work, but that sounds as reasonable tradeoff
So, is that easy?
Hell no. Just look at the lists of 6=>7 and 7=>8 API differences. It's a huge amount of work. Not as huge as writing the new major version of Drupal, but still huge.
Is it worth it? I think yes, and I hope that legions of D6/D7 site owners/maintainers agree with me.
First steps
For the first step I'm going to choose (voluntary) one D6 and one D7 module, exclude them from the module list shown by default (if you do it today, you'll see scary red signs urging to upgrade them).
Then, I'm going to create module manage page similar to admin/modules, but working with legacy modules. Third, I'm going to make the chosen modules work. Four - repeat step three for all 7000 D6 and 6000 D7 modules... may be not. Well, let's see what happens on step three :)
Wanna help? Checkout my sandbox project, and let's promote it to the full project when it starts getting shape
Originally published at http://www.valthebald.net/2013/01/20/compatibility.html