I think we should discourage use of anything that involves storing PHP in textareas - could we add support for bad_judgement here or is that too harsh?
See also #786208: Support PHP module.
I think we should discourage use of anything that involves storing PHP in textareas - could we add support for bad_judgement here or is that too harsh?
See also #786208: Support PHP module.
Comments
Comment #1
inforeto commentedThe ideal would be a way to export the custom code into the equivalent filter to put it on your custom module.
Just like we can export the whole view to have it on disk, which also helps performance not only security.
So far it requires permission to edit views, but otherwise is the same task for any other place you can add php.
These include page snippets with the php filter permission, the contemplate module, adding actions, etc.
Comment #2
jjclint commentedIt's true that other drupal elements apply php in text fields, but I agree with Catch - some valuable information regarding possible security hazards will be quite useful.
That being said, it seems the obvious and simplest way to reduce the risks is exporting the code with features
(http://drupal.org/project/features) or something similar. So perhaps the module description can just inform users about that option.
Comment #3
justindodge commentedThe project page already recommends using code handlers:
To me, making an actual dependency on that joke module would be excessively obtrusive - I think we're big kids here and I think people can make an appropriate decision how to use the given the information.
My personal opinion is that there are plenty of use cases for this module that don't require "bad judgement", in fact I think my employers would call it bad judgement to spend disproportionately large amounts of time writing views plugins for certain tasks that are more appropriately handled quickly and easily with an alternative solution. Of course, we're talking business logic here rather than engineering logic, but sometimes the situation calls for that. The point is, people have to decide for themselves and no amount of redundant module dependencies are going to change that, they will just needlessly increase the amount of effort required to implement the solution that the circumstance requires.
Sorry for the mini-rant.
Comment #4
Joel MMCC commentedWould it be feasible to have some sort of “Bake into Custom Views Handler Module” feature, that would take code that you’ve written and tested using Views PHP, and automatically export it into a properly formatted Custom Views Handler Module?
Then Custom PHP can be used for quickie development, and only “baked” Custom Views Handler Modules exported from it would be used in staging or live sites.
I could see this being implemented as a “Bake” button on each Views PHP UI form (for a Field, Filter, Sort, Area, etc.), or as a utility (perhaps using Drush?) that collects all Views PHP instances found either in a single View Display, all Displays in a given View, or site-wide, and collects them into a single Custom Module with multiple Views Handlers. Assuming it has write access to the necessary directories, it would then write out the code into the proper places, replace the occurrences of the Views PHP with the new custom Views Handlers in the View(s), and then optionally disable Views PHP when done.
Should this be suggested as a separate Feature Request, Task, or Plan Issue?
Comment #5
liam morland