Today, let’s discuss why enabling the PHP filter has to be a very very carefully considered decision on a Drupal user’s part. Here’s an example of why you might want to enable the PHP filter that is disabled by default in the Drupal 7 core.
Say, you want to insert the following mix of text, HTML and PHP code (PHP snippet) into the body of a custom block.
Have a great day today!
The date today is:
Now, if you do not enable the PHP filter module, you may find that Drupal 7 prints out your PHP code instead of interpreting it. So, you enable the PHP filter and take some other related measures, and voila, your code goes to your database, and is interpreted exactly the way you want it!
Oh, if it only were that simple!
Unfortunately, adding PHP code in your database by enabling this PHP filter can cause you to get extremely unsafe sitewise. This is one major reason why you should create modules using the API and hooks instead. However, if you absolutely have to add code to your database, you could try to reduce the code to a simple function call. Thus you'd have the function itself in a module (and this would be tracked via SVN). But then you are only a little step from removing the need for the inline code anyway….
Go ahead, though, and make an informed decision based on the following inputs on what could go wrong, and what precautions you can take should you still need to enable this filter in the Drupal 7 core :
Issues due to enabling the PHP filter
Security
PHP code contained inside your database can cause serious security issues. Allowing your CMS to allow execution of PHP can allow hackers to use your server for sending spam, hosting malware, hacking into other sites/databases on your server, and even hack into other servers on the network that might be behind firewalls!
Additionally, if hackers come to know that your site can be used to execute PHP, this alone can make it more likely to be attacked.
In this context, do make sure to check out this rather scary article on how database login details might be hacked from Drupal once PHP Filter module is enabled. Although the article is all about how admins who have ‘misplaced’ their login details might be able to retrieve them, there’s no reason why a hacker should have any scruples about doing such stuff, too.
If you must enable the PHP filter to execute database-included code, be sure to take security measures necessary in such cases. One of the ways you can do this is by limiting users - which is the next issue I’ll discuss --
Limiting Users
After enabling the PHP filter, you might want to restrict the PHP filter to users you can trust. You wouldn’t want the risk of unintentional modifications, or additions to your code, or malicious/unsanctioned activity, would you? So you might want to create roles other than “administrator” for users who you’d like to prevent from accessing / handling database-included PHP code.
Unfortunately, even after limiting your users, any malformed or incorrect coding can not just break your website, but stop its functions altogether. The sad fact is that Drupal experts may not always be expert coders.
Moreover, limiting users might not work if there is a misconfiguration giving people access to a text format, block etc with PHP execution enabled. The misconfiguration cannot cause this sort of damage, though, if the PHP filter is not enabled.
Eval()'d code Problems
Now, database-included code is eval()’d code, which is problematic in more ways than one. For starters, it is much slower than PHP hardcoded in a file. Additionally, it decreases the ability to debug the code by decreasing its readability and creates difficulties in predicting the code path before runtime. This can have security implications that are none too pleasant.
Speaking of debugging, errors in eval()’d codes throw up error messages that don’t provide much help in identifying or locating the error. There’s a good chance you might have to go through your database manually to find and fix the error. Such errors might even be fatal in certain instances, for example, if the error is in a block that is displayed on all pages.
Now, if instead of using the PHP filter, you use a custom module that replaces specific text in the node content with the result of the code it executes (without using eval()), or that appends its own text to the body content of the nodes, any user could then edit the node without permission to add arbitrary PHP code which would be run by the PHP filter. This means you do not have to worry about limiting users, but it still means you do not enable the PHP filter.
Writing and Managing Database-Included Code
If you put php code inside the node body you are creating a big code maintenance problem. Writing and maintaining database-included code is harder because you’re working inside a textfield in your browser. Having your code in a module lets you use an editor/IDE with syntax highlighting, autocomplete and other functions that make coding easier, faster, and more importantly, facilitate increased accuracy. Further, code in your database is much harder to find.
What’s more, database-included code cannot be version controlled. When versions of Drupal change, and your APIs alter as well, you do have to port your code while migrating. If your code is in a module, it can be ported in advance, tested, and only then deployed on the new site. But code inside a node or a block will only work with the Drupal version in which you first created the code.
These then, are a few major reasons why enabling the PHP filter might get you a lot more than you actually wanted, and not all pleasant either. Do feel free to write in with your own views, and tell us what you think of enabling the PHP filter in Drupal.
