I am having trouble with two parties giving me conflicting advice over our sites, which are being changed into Drupal. A Drupal consultant is saying very energetically that the way our programmer is using PHP is inappropriate for Drupal and a security risk. I remember distinctly at least one point about PHP being entered into the database. He says this is a "big no-no." My programmers are telling me...
"It’s not good to put PHP code if you are novice and dont want to figure out how to work with it. If it was all that dangerous or horrifically incorrect, why would Drupal even have the option of selecting input type as PHP? Its not a new product, and the current version is the 7th version of Drupal, and it still provides the option of letting you select input type as PHP code.... Also they suggest building a module for everything that we do using PHP code. However Drupal.org itself recommends not using too many modules https://www.drupal.org/node/1141442
Agreed PHP code is not good if it is to be maintained by someone with no tech knowledge or support, and using an off the shelf theme/ template. See, there are arguments both for and against using it
The only "security issue" with using PHP that I could find on drupal.org was that if someone who doesnt know PHP accidentally changes or updates something. The simple thing is if its to be used as a pure CMS to be run by non tech people, then I accept that PHP is incorrect, BUT, to run it that way there are a lot of other limitations too"
I am a "general" IT manager without coding skills, new to drupal, and I have no idea which one is correct. They are both quite adamant about it. Any assistance would be appreciated, and I apologize if this is incorrectly posted or anything.
Thank you.
Comments
Thoughts
See https://www.drupal.org/documentation/modules/php - it's not recommended to use the PHP filter.
There's the security angle. Also, from the design perspective, it makes debugging difficult. If you know that all code is in files, and all data is in the database, you know where to put debug lines if you need to troubleshoot your code - it's a matter of finding which file contains the lines to debug. If, on the other hand, some PHP code is in the database, it makes things a lot trickier.
It's also easier to ask a third party to audit your code for any security issues if all the code is in the directory tree.
You're right to avoid module bloat. But if you need to run extra code, it's no less bloated to put that code into the database. If anything, you lose some caching benefits by doing that. So maybe have one extra module, bespoke for your site, in which go all the custom blocks / pages / logic that you're needing.
You've been given the argument that Drupal is a mature product, so wouldn't offer the PHP filter if it was a bad idea. That's an interesting line of reasoning, except that Drupal 8 sees the removal of the PHP input filter to discourage people from using it. So, actually, as Drupal has matured, the community as a whole has decided that it's not a good way to build a site, so it's on the way out.
This signature is currently blank
James already covered it all.
James already covered it all. I just wanted to second his comments. Using the PHP filter is no good. If you need to run PHP, a Drupal module should be created, and Drupal APIs should be used.
Contact me to contract me for D7 -> D10/11 migrations.
Additional Comments
Since it resides in the database, you also cannot revision it nor can it ever be part of any code repository. It also becomes impossible to do any code review nor QA it properly. In some cases, you might be able to use Tokens to accomplish the same thing.
For your reference:
https://www.drupal.org/documentation/modules/php
https://www.drupal.org/node/2197965
https://www.drupal.org/node/615888
Aside from security there are speed concerns
PHP code from the database must pass through the eval() statement. For whatever reason in PHP Internals, eval() parses most code about 1 1/2 times slower than normal. It gets far worse with closures - eval() closures are about 3 times as slow as normal.
AP Code caches can't hold code pulled from the database, Drupal caching won't work on such code.
The option to inline PHP exists for rapid prototyping when speed is essential. It is not meant to be a permanent solution. And personally, I wouldn't lose a wink of sleep if the option was pulled from Drupal entirely - it just encourages lazy and bad coding.
personally, I wouldn't lose a
It's been pulled from Drupal 8, so it's good to hear you'll still be able to sleep :)
Contact me to contract me for D7 -> D10/11 migrations.
So it has. I've been banging
So it has. I've been banging away at more backend related stuff in D8 too much to notice. Still, in D7 it was a module, no doubt that module will resurface, for better or worse.