cellear's picture

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.

Comments

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?

jenlampton's picture

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?

 [...] mismatching PHP version [...]

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.