Return to Answer

The PHP-module and its associated PHP filter may create security holes when used improperly.

The main reasoning behind the advice you've read about having it disabled on production sites, and it being removed from core in Drupal 8, is that it lowers the bar for creating PHP, making is simpler for non-programmers and unskilled programmers to add PHP to a site's code base (in particular, PHP code that don't sanitize user input).

However, the main risk is that by enabling it, some unthinking admin may give access to the PHP-filter for all users (not only the trusted user #1).

Given improper use, the site can be compromised by any script-kiddie. By leaving the PHP module completely disabled, you've eliminated that risk.

However, that being said, the PHP-module is useful in some situations (as you've discovered), and I think that it is over-cautious to never having it enabled on a production site. As long it is only allowed for user #1 (i.e. the implictly trusted super-admin), and the PHP that is added is safe (for the record, the code proposed at Create a Rule to Evaluate If a Logged-in User Has Created Content of Type X is safe, then the site is not put at risk by having it enabled.

Just thread carefully, and make sure you you know enough about Drupal to understand that the PHP-filter should not be enabled for "Filtered HTML" or any other text format that untrusted users area allowed to use, and that the code you add using it must by itself be safe.

PS: Some people seem to think that it is somehow "better" if non-programmers add PHP to a site by writing a custom module instead of having it in the database. IMNSHO, it makes little difference where you keep it. A non-programmer is unfortunately perfectly capable of creating unsafe PHP anywhere. Having the unsafe PHP inside a file instead of inside the database will not save you if the PHP-code happens to be unsafe in the first place.

The PHP-module and its associated PHP filter may create security holes when used improperly.

The main reasoning behind the advice you've read about having it disabled on production sites, and it being removed from core in Drupal 8, is that it lowers the bar for creating PHP, making is simpler for non-programmers and unskilled programmers to add PHP to a site's code base (in particular, PHP code that don't sanitize user input).

However, the main risk is that by enabling it, some unthinking admin may give access to the PHP-filter for all users (not only the trusted user #1).

Given improper use, the site can be compromised by any script-kiddie. By leaving the PHP module completely disabled, you've eliminated that risk.

However, that being said, the PHP-module is useful in some situations (as you've discovered), and I think that it is over-cautious to never having it enabled on a production site. As long it is only allowed for user #1 (i.e. the implictly trusted super-admin), and the PHP that is added is safe (for the record, the code proposed at Create a Rule to Evaluate If a Logged-in User Has Created Content of Type X is safe), then the site is not put in jeopardy by having it enabled.

Just thread carefully, and make sure you you know enough about Drupal to understand that the PHP-filter should not be enabled for "Filtered HTML" or any other text format that untrusted users are allowed to use, and that the code you add to the HTML-textarea using this feature must by itself be safe.

PS: Some people seem to think that it is somehow "better" to add PHP to a site by writing a custom module instead of having it in the database. IMNSHO, it makes little difference where you keep it. A bad programmer is unfortunately perfectly capable of creating unsafe PHP anywhere. Having unsafe PHP inside a file instead of inside the database will not save you if the PHP-code happens to be unsafe in the first place - even if you've paid somebody to create it for you.

The PHP-module and its associated PHP filter may create security holes when used improperly.

The rationale behind the advice you've read about having it disabled on production sites, and this is why it is removed from core in Drupal 8, is that it lower the bar for creating PHP, making is simpler for non-programmers and unskilled programmers to add PHP to a siteæs code base.

However, the main risk is that by enabling it, some unthinking admin may give access to the PHP-filter for all users (not only the trusted user #1). In addition, because it gives non-programmers the ability to write PHP, you run the risk of some non-programmer using it to write unsafe code (e.g. code that don't sanitize user input). With improper use of the ability to add PHP the site can be compromised by any script-kiddie. By leaving it completely disabled, you've eliminated that risk.

However, that being said, the PHP-module is useful in some situations (as you've discovered), and I think that it is over-cautious to never having it enabled on a production site. As long it is only allowed for user #1 (i.e. the implictly trusted super-admin), and the PHP that is added is safe (for the record, the code proposed at Create a Rule to Evaluate If a Logged-in User Has Created Content of Type X is safe, then the site is not put at risk by having it enabled.

Just thread carefully, and make sure you you know enough about Drupal to understand that the PHP-filter should not be enabled for "Filtered HTML" or any other text format that untrusted users area allowed to use, and that the code you add using it must by itself be safe.

PS: Some people seem to think that it is somehow "better" if non-programmers add PHP to a site by writing a custom module instead of having it in the database. IMNSHO, it makes little difference where you keep it. A non-programmer is unfortunately perfectly capable of creating unsafe PHP anywhere. Having the unsafe PHP inside a file instead of inside the database will not save you if the PHP happen to be unsafe in the first place.

The PHP-module and its associated PHP filter may create security holes when used improperly.

The main reasoning behind the advice you've read about having it disabled on production sites, and it being removed from core in Drupal 8, is that it lowers the bar for creating PHP, making is simpler for non-programmers and unskilled programmers to add PHP to a site's code base (in particular, PHP code that don't sanitize user input).

However, the main risk is that by enabling it, some unthinking admin may give access to the PHP-filter for all users (not only the trusted user #1).

Given improper use, the site can be compromised by any script-kiddie. By leaving the PHP module completely disabled, you've eliminated that risk.

However, that being said, the PHP-module is useful in some situations (as you've discovered), and I think that it is over-cautious to never having it enabled on a production site. As long it is only allowed for user #1 (i.e. the implictly trusted super-admin), and the PHP that is added is safe (for the record, the code proposed at Create a Rule to Evaluate If a Logged-in User Has Created Content of Type X is safe, then the site is not put at risk by having it enabled.

Just thread carefully, and make sure you you know enough about Drupal to understand that the PHP-filter should not be enabled for "Filtered HTML" or any other text format that untrusted users area allowed to use, and that the code you add using it must by itself be safe.

PS: Some people seem to think that it is somehow "better" if non-programmers add PHP to a site by writing a custom module instead of having it in the database. IMNSHO, it makes little difference where you keep it. A non-programmer is unfortunately perfectly capable of creating unsafe PHP anywhere. Having the unsafe PHP inside a file instead of inside the database will not save you if the PHP-code happens to be unsafe in the first place.

The PHP-module and its associated PHP filter may create security holes when used improperly.

This is the rationale behind the advice you've read about having it disabled on production sites, and this is why it is removed from core in Drupal 8.

The main risk is that by enabling it, some unthinking admin may give access to the PHP-filter for all users (not only the trusted user #1). That is indeed improper use, and a site where it is used like can be compromised by any script-kiddie. By leaving it completely disabled, you've eliminated that risk.

However, that being said, the PHP-module is useful in some situations (as you've discovered), and I think that it is over-cautious to never having it enabled on a production site. As long it is only allowed for user #1 (i.e. the implictly trusted super-admin), then the site is not put at risk by having it enabled.

Just thread carefully, and make sure you you know enough about Drupal to understand that the PHP-filter should not be enabled for "Filtered HTML" or any other text format that untrusted users area allowed to use.

The PHP-module and its associated PHP filter may create security holes when used improperly.

The rationale behind the advice you've read about having it disabled on production sites, and this is why it is removed from core in Drupal 8, is that it lower the bar for creating PHP, making is simpler for non-programmers and unskilled programmers to add PHP to a siteæs code base.

However, the main risk is that by enabling it, some unthinking admin may give access to the PHP-filter for all users (not only the trusted user #1). In addition, because it gives non-programmers the ability to write PHP, you run the risk of some non-programmer using it to write unsafe code (e.g. code that don't sanitize user input). With improper use of the ability to add PHP the site can be compromised by any script-kiddie. By leaving it completely disabled, you've eliminated that risk.

However, that being said, the PHP-module is useful in some situations (as you've discovered), and I think that it is over-cautious to never having it enabled on a production site. As long it is only allowed for user #1 (i.e. the implictly trusted super-admin), and the PHP that is added is safe (for the record, the code proposed at Create a Rule to Evaluate If a Logged-in User Has Created Content of Type X is safe, then the site is not put at risk by having it enabled.

Just thread carefully, and make sure you you know enough about Drupal to understand that the PHP-filter should not be enabled for "Filtered HTML" or any other text format that untrusted users area allowed to use, and that the code you add using it must by itself be safe.

PS: Some people seem to think that it is somehow "better" if non-programmers add PHP to a site by writing a custom module instead of having it in the database. IMNSHO, it makes little difference where you keep it. A non-programmer is unfortunately perfectly capable of creating unsafe PHP anywhere. Having the unsafe PHP inside a file instead of inside the database will not save you if the PHP happen to be unsafe in the first place.