Docs: Dual Drupal 7/Backdrop CMS compatibility

[wizonesolutions]

Describe your issue or idea

https://api.backdropcms.org/node/28621 suggests that a contributed module can support Drupal 7 and Backdrop CMS simultaneously, but I'm wondering if this is still practical, or if that was more viable earlier in Backdrop's life. Since the Variable system has moved to CMI, how would that actually work in practice? Is there a contributed module or something that can map the two so that I don't have to have my code diverge too much? I know that there's a Drupal compatibility layer in general that lets me use the old functions...

Also, there is talk about having an update hook for people going from Drupal 7 to Backdrop...how would I test that in practice? Would I update my hook_update_last_removed() implementation each time I added a new update hook in the Drupal 7 version as well?

Thanks!

[herbdool]

I think the only approach is to have the Drupal and Backdrop versions in different branches. I think you have to since the .info are different, and add you mention, you might need an upgrade hook in the install file.

[klonos]

Yeah, I'd use two separate branches. Same as you would do for a D7 and D8 version of a module. Or more fitting in this case, the 7.x-1.x and 7.x-2.x versions of the same project.

[wizonesolutions]

That answered my question. It'd perhaps be appropriate to remove references to that at this point in the docs, just as not to imply that it's feasible for all but the simplest ports.

[klonos]

@wizonesolutions can you please point which part of the documentation in https://api.backdropcms.org/converting-modules-from-drupal was confusing for you? We should address this properly so that others do not get mislead in the future.

[wizonesolutions]

@klonos Must've been this:

Core modules removed

There are several modules that were included in Drupal 7 that have been removed from Backdrop (see complete list ). If your module implemented APIs for any of these modules, those hooks can be safely removed.

Leaving these hooks in your code will not affect a Backdrop module in any way, since the code will simply not be called. You may leave them in place if you would like to be able run the same module on both Drupal and Backdrop sites.

[klonos]

Well, this bit talks specifically about certain hooks for D7 core modules that were removed from Backdrop core. I cannot think how we could clarify this more. Suggestions?

[wizonesolutions]

The third paragraph — it implies that one could run the same module on Backdrop and Drupal 7. This is possible for simple modules, but probably not most.

[klonos]

I see what you mean now @wizonesolutions. It's this bit:

You may leave them in place if you would like to be able run the same module on both Drupal and Backdrop sites.

@jenlampton, @tomgrandy, I have tried to rewrite that entire paragraph, but I did not come up with anything good. As a long-time Backdrop user, it makes perfect sense to me, but when I try to put myself in the place of a Drupal newcomer, it is misleading. Do you guys have any ideas how we could improve this part of the documentation?

I keep coming around to the realization that in order to avoid misunderstandings, it might be best to state that the best practice is to either keep separate repositories for D7 vs Backdrop versions of modules, or to create different branches for them. We can keep the "Backdrop will ignore any D7 API calls" part, but we should remove the "be able run the same module on both Drupal and Backdrop" part (or replace it with something less ambiguous).

[jenlampton]

Since the Variable system has moved to CMI, how would that actually work in practice?

@wizonesolutions In practice, you could choose to leave your Drupal 7 variables as variables in Backdrop too, and sites using the "Backdrop compatible" module wouldn't be able to use config management for those settings. That "compatible" module could still call all the drupal_ namespaced functions too, so the code for both systems could remain nearly identical.

Alternatively, a "Built for Backdrop" version of the module would use config instead of variables, and call the backdrop_ namespaced functions instead of the drupal_ ones. This is where your code starts to diverge, and we recommend a second branch for these changes, in the same way you have a Drupal 6 branch and a Drupal 7 branch for the same module.

Not all Drupal 7 modules can function in a "Backdrop compatible" state, as there are some APIs that have changed beyond variables to config and function name changes. But, if your module provides a block, a field formatter, or just alters something, the chances are good that you could choose to do either a "Backdrop compatible" or "Built for Backdrop" version, or both!

@klonos If I have time, I'll take a look at that language and see if there's a way we can clear it up. Maybe what I wrote here could be of use?