Hi Nate, Jen, team and fellow developers -

I have a media publishing website on D7 - https://www.truthunity.net - where I am the only authenticated user. My question is how difficult it would be to have PHP Filter available for Backdrop.

I have no idea how complicated this would be to do, just asking if it's a big hurdle.  I'm also aware of all the warnings about allowing PHP scripts in the body field and I'm open to alternative techniques, but porting from D7 will require something because a few short, utility like PHP scripts are all over hundreds of nodes.  Here's an example:

/**
 * Function called from node to obtain the path to the Amazon Content Delivery Network
 *
 * Usage:
 *
 *   <?php bizmark_cdnpath(); ?>
 *
 */
function bizmark_cdnpath() {
    echo 'https://s3.amazonaws.com/truthunity/';
}

I've got similar utility scripts that embed menus in nodes, embed JW Player in nodes, etc. They are all short and used repeatedly in similar nodes.

I'm open to funding the request and am shooting for $500 or less. 

Let me know your thoughts. Thanks so much

Most helpful answers

The PHP filter is a swiss army knife that enables site builders to satisfy a few unique requirements quickly and easily. There's an argument to be had about whether it makes sense to compartmentalize functionality (ie. a page shouldn't perform logic, it should be a module),  and there is another important argument about how the PHP filter is clearly a security concern.

However, in practice it often makes business sense to simply put 3 lines of PHP code in a node to meet objectives. Perhaps the goal here should be to create an enhanced version of the PHP filter that defaults to a more secure configuration.

I have working code of a safer version of the PHP filter that works by allowing users to create functions in a custom PHP file, and then they are able to call only those functions from the body of content. This way malicious attacks can't execute PHP code from the database, and also all custom functions are compartmentalized into a file.

It looks like this:

In the content of a node you add a token, something like: [custom_php render_adjusted_date 'm-Y']

Then in a custom PHP file you have this function: custom_functions_render_adjusted_date($format)

The PHP filter inserts that function into your node and performs a php_eval. The result is the equivalent of inserting your desired PHP code into the node, except that you keep the actual PHP code in a separate file, and the plugin can only trigger functions found in that file.

If this sounds like it would be helpful, I'd be happy to contribute the module.

I've got similar utility scripts that embed menus in nodes, embed JW Player in nodes, etc. They are all short and used repeatedly in similar nodes.

 

Em... there are several ways I think you can do if PHP code is unavoidable in your nodes. First you can override the node template and place your PHP code in there. For example, let say your content type is named as "blog", here the steps:

  1. Copy the node template from the node module inside the core located in "\core\modules\node\templates\node.tpl.php" to your sub theme folder and rename it to node--type.tpl.php, e.g. node--blog.tpl.php (ref: Creating themes under "Add template files")
  2. Open the node--blog.tpl.php and add your php code as many as you wish.
  3. Flush all caches.

In this way, all your blog's nodes will have your CDN and JW Player added and you only embed once! No repetition!

 

The other way is to create a block and again, override the block template, throw all your codes in and assign the visibility. Here the steps though it involves a bit more steps, :

  1. Go to Structure > Custom blocks > Add custom block. E.g Admin label: "My blog", and you will notice next to the input field there's a "Machine name", you can edit this name if you need. Whatever you name it, remember and job down that machine name. 
  2. Save block
  3. Copy the default block template from the layout module from core which located in "core\modules\layout\templates\block.tpl.php" to your sub theme folder to override.
  4. In your sub theme folder, rename the block template block.tpl.php to block--block--machine_name.tpl.php, e.g block--block--my_blog.tpl.php
  5. Open your block--block--my_blog.tpl.php file and embed your php code there.
  6. Flush all caches
  7. Go to any of your layout and assign the block to a particular region and set the visibility to show only in your blog content type.

Now, if you go to any of the blog node, you should be able to see the output of the php code you have embedded in the block. If not working, double check the block's machine name and remember to flush the cache!

I think Drupal has some similar Template (theme hook) suggestions you can try and some will work on backdrop as I can not find similar documents or tutorials in backdrop in a greater details on template suggestions. If anybody know please post it here. Hope it helps! Keep it up !

 

 

 

 

Comments

Hi there, you'll face stiff opposition to this, as I'm sure you expect; no one's going to want that module in the contrib list. But if you just  grab the php module from D7 core and run it through https://github.com/backdrop-contrib/coder_upgrade it may just work. At least it'll be a start and you can ask for help from there.

jenlampton's picture

Hi @gippy, and thanks for the question.

I'm afraid @docwilmot is right that we won't want to see that module appear on the module installer for Backdrop users, but to answer your question...

how difficult it would be to have PHP Filter available for Backdrop?

it wouldn't be very difficult. A core module is just a module like any other, and upgrading it should be just as straightforward. Using the coder_upgrade approach mentioned is a great way to give it a quick try. I suspect that will get you most of the way there.

Once you have made the port, however, we would like to see that project in the backdrop-contrib group on GitHub. I expect there will be others coming from Drupal 7 who may also believe that they need the PHP filter module.

That said, it would be best for both you and your site, if you coud stop using the PHP filter module. I'm happy to read that you are open to going this route :)  Here are some ideas for your rebuild:

  • I don't know what you're using the Amazon CDN for, but maybe it doesn't need to be placed into a node body?
  • In Backdrop menus can be placed using Layouts
  • Most video and audio players have HTML embed codes, and don't need PHP
simone960's picture

I've got similar utility scripts that embed menus in nodes, embed JW Player in nodes, etc. They are all short and used repeatedly in similar nodes.

 

Em... there are several ways I think you can do if PHP code is unavoidable in your nodes. First you can override the node template and place your PHP code in there. For example, let say your content type is named as "blog", here the steps:

  1. Copy the node template from the node module inside the core located in "\core\modules\node\templates\node.tpl.php" to your sub theme folder and rename it to node--type.tpl.php, e.g. node--blog.tpl.php (ref: Creating themes under "Add template files")
  2. Open the node--blog.tpl.php and add your php code as many as you wish.
  3. Flush all caches.

In this way, all your blog's nodes will have your CDN and JW Player added and you only embed once! No repetition!

 

The other way is to create a block and again, override the block template, throw all your codes in and assign the visibility. Here the steps though it involves a bit more steps, :

  1. Go to Structure > Custom blocks > Add custom block. E.g Admin label: "My blog", and you will notice next to the input field there's a "Machine name", you can edit this name if you need. Whatever you name it, remember and job down that machine name. 
  2. Save block
  3. Copy the default block template from the layout module from core which located in "core\modules\layout\templates\block.tpl.php" to your sub theme folder to override.
  4. In your sub theme folder, rename the block template block.tpl.php to block--block--machine_name.tpl.php, e.g block--block--my_blog.tpl.php
  5. Open your block--block--my_blog.tpl.php file and embed your php code there.
  6. Flush all caches
  7. Go to any of your layout and assign the block to a particular region and set the visibility to show only in your blog content type.

Now, if you go to any of the blog node, you should be able to see the output of the php code you have embedded in the block. If not working, double check the block's machine name and remember to flush the cache!

I think Drupal has some similar Template (theme hook) suggestions you can try and some will work on backdrop as I can not find similar documents or tutorials in backdrop in a greater details on template suggestions. If anybody know please post it here. Hope it helps! Keep it up !

 

 

 

 

The PHP filter is a swiss army knife that enables site builders to satisfy a few unique requirements quickly and easily. There's an argument to be had about whether it makes sense to compartmentalize functionality (ie. a page shouldn't perform logic, it should be a module),  and there is another important argument about how the PHP filter is clearly a security concern.

However, in practice it often makes business sense to simply put 3 lines of PHP code in a node to meet objectives. Perhaps the goal here should be to create an enhanced version of the PHP filter that defaults to a more secure configuration.

I have working code of a safer version of the PHP filter that works by allowing users to create functions in a custom PHP file, and then they are able to call only those functions from the body of content. This way malicious attacks can't execute PHP code from the database, and also all custom functions are compartmentalized into a file.

It looks like this:

In the content of a node you add a token, something like: [custom_php render_adjusted_date 'm-Y']

Then in a custom PHP file you have this function: custom_functions_render_adjusted_date($format)

The PHP filter inserts that function into your node and performs a php_eval. The result is the equivalent of inserting your desired PHP code into the node, except that you keep the actual PHP code in a separate file, and the plugin can only trigger functions found in that file.

If this sounds like it would be helpful, I'd be happy to contribute the module.

I think this would be helpful for a lot of use cases. Good idea, Jose!