During the initial release of Backdrop CMS a number of Drupal 7 modules or features were removed as a part of the fork because they were not consistent with the goals and philosophy of the project. One of these items was the PHP module, which allowed users to execute PHP code through the user interface. This has always been a controversial module because of the security implications and the Backdrop community decided that having this module in core was an unnecessary risk for users that might not understand the implications of enabling it on their sites.
Here is a StackExchange discussion on why it's a bad idea to use this module.
However, from time to time we get requests in the Backdrop community for this module which some folks still consider to be a useful and convenient tool, especially on small sites where editorial access is highly restricted.
This afternoon, I took a quick stab and porting this module to Backdrop to satisfy those users who really want this option, but also to satisfy my own desire to see if this would be something I was able to do.
A quick look at the module made clear that there isn't all that much code involved, which is always a good sign when porting a Drupal 7 module to Backdrop. There are really only 4 files involved.
- php.info (easily converted to Backdrop with the Coder Upgrade module - or by hand).
- php.install (only 45 lines of code)
- php.module (147 lines of code, much of which is related to the help module or filter tips, neither of which would be critical to make this function).
- php.test (for my purposes, it's not really important to port the tests which are mostly there because this module was in Drupal 7 core).
I've only done a few Drupal 7 to Backdrop CMS ports, but the first step for me is to run the code through the Coder Upgrade module. I have a Lando installation of Backdrop CMS set up and configured for exactly this purpose (just install the module in a Backdrop site and enable it). The process to use the Coder Upgrade module is:
- Upon installation of Coder Upgrade, it will create a coder_upgrade directory inside of your standard Files directory for Backdrop. Drop a copy of the module you wish to port into the 'old' directory.
- Find the module you wish to port at `/admin/config/development/coder-upgrade` and click on 'Convert Files' button.
- Find a copy of the converted module in the 'new' directory at files/coder_upgrade/new and move it into your contrib modules directory for testing.
My next step was simply to install the module and see if it works. Sometimes, it's just this easy.
On this occasion I tried enabling the module and got the following error:
The error suggests that Backdrop is looking for the backdrop.filter_format table that does not exist. Since Backdrop has moved most configuration to .json files and I was pretty sure that text filters use their own config files, this seemed like a good place to start. I checked the active config directory inside of the files directory and found that the three default text formats all have config files and I would probably need to make sure that one was created for the new php filter.
I checked the standard.install file inside of the Standard Install Profile in Backdrop core and found the code to generate the two main default text filters. Assuming that the full (or raw) html filter is much closer to what I would be looking for, I simply copied this code into a newly created hook_install function inside of the php.install file for my new PHP module and commented out the old 'php_enable' function which I assumed would now be redundant (and wrong for the Backdrop way of doing things).
Next, I had to modify the install code I had just moved into php.install to make it work, changing references from 'full_html' or 'raw_html' to 'php'. I then disabled and re-enabled the PHP filter module without any errors and confirmed that a 'filter.format.php.json' file had been created in my config directory.
Next, I tried to create a new page node and found that I did in fact have a PHP filter text format available to me. However, upon testing it did not work as expected. I went to /admin/config/content/formats/php to check the configurations for my new PHP text format and found that there was a PHP Evaluator filter available but not enabled, so I enabled it, saved my changes, and tried to create a page node with PHP once again. This time it worked as expected.
I had a working port of the PHP module from Drupal 7.
This left me with a few clean up functions.
- Deleting the code I commented out, now that I was sure I didn't need it anymore.
- Deciding if the code in php.module related to hook_help and _php_filter_tips is still helpful or relevant. The help module was also removed from Backdrop, so hook_help can be removed. Any necessary help text should be hard-coded into the module or included in the readme.md file.
- Create a readme.md file with all the necessary info (see example).
Moving to Backdrop Contrib on Github
We'd love to get all your ports, even if they are only in progress, into the backdrop_contrib group on Github. If you are not yet a member of the contrib group, you will need to apply. Check here for all the information you should need.
Creating a Release
Under normal conditions, you may want to have others test your module before creating a release that will show up on backdropcms.org, but ultimately the decision is up to you based upon your own testing. In this case, I have no intention to create an official release for this module, because of the security implications. The module is now available along with all the other Backdrop contrib modules on Github.org. BUT, it will not be available on backdropcms.org or in the project browser.
Here it is: https://github.com/backdrop-contrib/php
Other useful resources:
- Converting modules to Backdrop from Drupal 7, Backdrop CMS Documentation
- Porting Drupal 7 Modules to Backdrop, Juan Olalla Olmo, Lullabot
Porting a Module to Backdrop - Basics (YouTube Video - 0:31), Nate Lampton