Backdrop, as we all know, started as a fork of the Drupal project. The reason for doing so was largely to enable the enormous amount of work that had been put into the legacy Drupal architecture (7.x and earlier) to be maintained into the future, since Drupal 8 was adopting a very different approach based on Symphony and dependency injection.
Backdrop was never fully compatible with Drupal 7, since it was forked after CMI and other important enhancements had been folded into the codebase, and it has grown increasingly less compatible as rational but incompatible changes have been made. However, the basic code and most of the API is (I believe) still quite similar to Drupal 7.
To make it easier for people coming from Drupal to explore Backdrop, I propose two modules:
D7 Module Adapter
This module would allow Drupal 7 modules to be installed on a backdrop system. It would include something like the following features
- Look for Drupal modules in a specific location -- possibly sites/all/modules to maintain maximum compatibility.
- Present an interface that would allow the D7 modules to be enabled, disabled, and uninstalled.
- Allow modules with compatibility strings that say "core = 7.x" to be enabled.
- Provide "stub" functions for elements of the API that no longer exist in Backdrop. These generally won't implement the behavior of the removed code, but rather will throw an error explaining that they were called and what they did.
- Allow storage of configuration in the DB rather than in CMI, like D7 does.
The intent is to allow people with Drupal 7 sites to load everything they were using into a Backdrop site, where they could evaluate their options, such as porting modules, figuring out different ways to provide functionality, or deciding they can live without something.
D7 Theme Adapter
Similar to the module adapter, the theme adapter would permit a site builder to load Drupal 7 themes into a Backdrop site. Since D7 doesn't have a layout manager, the module would permit themes to control the page layout, and would read the page.tpl.php file. It's possible there might be a way to use the layout manager anyway, perhaps ignoring the page.tpl.php file, but I don't know if this is practical.
It's possible that both adapters could be implemented entirely with modules, but I expect that at least some core changes would be required to allow them to work.
Is there a complexity factor regarding mismatching PHP version that may affect this? If a person wants to port an older site that has either been using an older PHP version or wants to restore an old site that has not been used for a while (from backup or the like), can that be helped via these modules without having to establish a server enviroment and update the whole D7 environment before moving onto BD?
I love this idea -- thanks @cellear! Were you thinking about these going in core, or as a contrib project? Or maybe both -- start in contrib and then get moved into core once stable and tested?
Backdrop's minimum version is the same as the Date module in Drupal 7 contrib. If someone was running something earlier than PHP 5.3 (thus not using date module) it might be an issue...
Backdrop would throw an ugly red error on the status report (and in the admin bar) letting them know PHP was too old... but we should try it and see what happens.
I think they would both require changes to core, but perhaps not. If they worked well I think we would want them in core, although obviously not enabled by default. I'm pretty sure the engineering know-how to implement them would need to come from a core developer anyway.
Though the community agreed that this topic is important, the PMC has not chosen it as one of the first official Backdrop initiatives. Only two proposals have been selected, so more are likely to be added in the future. Please keep this topic in mind for the next proposal process, which will be shortly after 1.17 is released.
Thank God this wasn’t approved for this cycle — I would be in trouble if I had two initiative proposals approved at the same time! I’ll come back to this after completing the “theming” initiative.
Related to, but distinct from, this initiative: I’ve been pondering whether it would be possible to create a mechanism to use unmodified Wordpress themes in Backdrop. My initial investigations seem to show that it’s plausible, though I haven’t gotten a prototype working yet. I just wanted to mention it here, so that I (or somebody else, if anybody is interested) can come back and give it a shot.
I don’t anticipate being able to run a Wordpress site unmodified on top of Backdrop, but I think it’s plausible to get some or all of the Twenty-* Wordpress themes to run. A Wordpress theme is anchored by an index.php file, I think if we can get our html.tpl.php to include the index.php, populate the variables it expects to see, and fake the functions it’s looking for, it might work.
I haven’t thought through how the CSS paths would work, and I don’t think it’s realistic to cover the whole Wordpress API, but there might be a manageable subset that are called in the 20-* themes to make it worthwhile.