The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Great module, thanks!
Given how it's increasingly sniffed upon to execute UI entered php in D8 world, I wondered if it would be a good idea to move the PHP formatter support into a submodule. This way anyone who frowned on it for security reasons could avoid enabling it in the first place?
Comments
Comment #2
decipheredI will be putting granular permissions in place so only users with permission for a specific Formatter Type will be able to make said formatter type.
Given that a normal Formatter in code is PHP it makes little sense to consider a PHP formatter a security risk, however the difference is that a user can do this in the UI rather than in the file system. Said permissions somewhat negate that issue.
You're not wrong to suggest that it could be a sub-module to further negate concerns, but I'm not sure if that is in the best interest of the module as it is the most powerful Formatter type available and as a sub-module it would be easy to overlook, vastly reducing the power of the module in whole.
Comment #3
jonathanshawAll good points. For what it's worth, my sense is that the module's adoption would be helped, not hindered, by moving php to a submodule. A few thoughts ...
1) The community seems very sniffy these days about the PHP text filter in D7, which presumably is the same set of security concerns. So you might get more recommendations for the module as a whole if it wasn't tarnished with this security concern (justified or not).
2) If I look at my own experience, I tend to find out about module's features mostly from the project page, which advertises submodules features just as well. Submodules are always very visible and obvious to me, and the functionality offered by a php custom formatter is very self-explanatory - it's not something that has to be seen to be understood.
3) If you have a Twig type that delivers much of the power of php for most use cases, with none of the supposed risk, it would be a shame to have its adoption hindered by unnecessary security concerns.
Comment #4
decipheredMaybe. I think it comes down to the Twig formatter type, if that proves itself to equal the power of the current PHP formatter I will likely consider this request more closely, but I haven't started looking at said formatter type yet due to the other higher priority parts of the port (which there are now less and less).
Comment #5
decipheredTwig formatter type exists now. I would appreciate some feedback on it, after which I will strongly consider moving the PHP engine into a sub-module.
Comment #6
geek-merlinLike other agencies we have some projects with very high security concerns. A common requirement for projects these days is, let's call it, php-escalation-free. Meaning: Given i have Admin/User1 privileges, i can not pwn the whole server via php execution. Devel moved out its php submodule for this reason. Note that this must be a separate project, otherwise User1 can simply enable the php submodule.
Devel issue: #3005475: Remove Execute PHP feature