Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Referencing:
- #1910156: User of php_eval() instead of eval() prevent variable manipulation.
- #1513490: Fatal error: Call to undefined function php_eval()
There's quite some discussion about how to use php_eval vs eval and how to get rid of associated errors. However, could someone explain to me why we use php_eval or eval in the first place? I dug through the code and all I saw was php_eval being run on an array that is empty anyway. Besides that, there's usually a way to do something without eval. I like what views PDF could do for me but I don't really want to hand over a site to my client with the php module enabled as it could cause some serious damage if used wrongly.
Thanks in advance.
Comment | File | Size | Author |
---|---|---|---|
#2 | why_php_eval-2040739-2.patch | 3.37 KB | killua99 |
Comments
Comment #1
killua99 CreditAttribution: killua99 commentedWe can keep this post to discuss all about php_eval and eval stuff.
I need to speak with the other maintainers, and find the best solution to remove php_eval and and eval. This have to be done with some alter/hook system more save.
The others two post keep it close. Because that is the original design of the module. Maybe we need to do another version, and removing all this bugs and dangerous code.
Comment #2
killua99 CreditAttribution: killua99 commentedThis is a patch that have to be applied in the git branch 7.x-1.x
NOTE: For user that are not familiarity with git, please read the next. If you know what's git and work with it Jump to the next.
Install git if you haven't done yet. install git
Then follow the next code.
You have to replace the current module with git.
Explanation
Maybe with this image it's more easy to explain how to use this "fast solution" for this feature.
As you can see, I add two easy option to use the php_eval or the eval.
When you're using the php_eval you must write the <?php ?>, because this is completely evaluate like a PHP file, away form the current functions and so on.
Comment #3
KingdutchInstead of rushing for a patch could you explain the need for the funtions like I asked in my original question?
What I see at the moment is only to add extra content which could be simple HTML right? In that case a normal textarea that accepts HTML would be the solution and (php_)eval would no longer be needed.
Besides that I don't think this has major priority as there's nothing broken at the moment, it's just bad practice to use eval, mostly there's other options.
Comment #4
killua99 CreditAttribution: killua99 commentedSome people using it to run code, some people don't know how to make a module to make a preprocess or alter. So they use this php box to evaluate thing (not only HTML) and get the output they want.
I rush to create this patch, because people who use this feature with this patchs is broken.
Hope I explain the needed to keed the (php_)eval in this 1.x version. I want to remove it. But need to find options for those who use this feature.
Comment #5
killua99 CreditAttribution: killua99 commentedCan I leave this with needs review? for those who use this feature. (I know this need huge work)
Comment #6
KingdutchOk I understand why you'd want to keep the eval in there, I'll leave my personal opinion to the side.
Why would we want to use eval instead of php_eval? I think the original issue was that php_eval needed the php module. I think a better fix for that issue would be to add a help text to the render before/after field and (I hadn't even found those fields yet, hence my question as to where it was needed) that the php module must be enabled. This allows the php_eval code to be wrapped in an
(Not sure about the exact syntax). This means that the php module is no longer a requirement and the module will behave as expected for users entering php in that text field. If the php module was disabled the before and after input could even be rendered as is (which would mean that people not using the php module but still entering php code would see the plain <?php tags and people who didn't inject php code would see everything working as expected.)
I hope you understand my reasoning and proposed solution.
Comment #7
killua99 CreditAttribution: killua99 commentedThe module require core PHP module active, that issue was fixed put it in the .info file the lines dependencies = php. The default option or setup is with the php_eval so it's required. We don't need evaluate if the module is active or not because is a default behaviors of the module.
For the next version or big changes if we remove the eval to handle stuff or w/e the php module will be removed from the requirements. So no needed to evaluate this.
Comment #8
candelas CreditAttribution: candelas commentedthanks @killua99 i will test this today by sure and report.
very well documented, by the way. if you need help on documentation, i can give a hand :)
Comment #9
candelas CreditAttribution: candelas commentedthanks very much!
i could make the invoice that i needed to end one work with this release.
i could make it work with eval.
thanks a lot for your work and i will be pleased to collaborate on this module.
i think it is very good for invoices saved in the server and many people will use it :)
Comment #10
killua99 CreditAttribution: killua99 commentedDear fellow Drupal enthusiasts,
This issue is now lasting for a very long time in the issue queue and was unfortunately never solved. As Drupal is a open source project, everyone is helping on a voluntary basis. That this was not solved is nothing personal and means no harm. But perhaps no one had time to deal with this issue, maybe it is too complex, or the problem was not described comprehensibly.
But this issue is not the only one. There are thousands of issues on Drupal.org that have never been worked on or could not be processed. This means that we are building a wave that is unmanageable and it is a problem for the Drupal project as a whole. Please help us keep the issue queue smaller and more manageable.
Please read again, "Making an issue report" and see if you can improve the issue. Test the problem with the current Core and modules. Maybe the problem doesn't exist anymore, is a duplicate or has even been solved within this issue but never closed.
Help can also be found for it on IRC and in the user groups.
In order to close this issue, I have set this issue to "Closed (won't fix)".
If there is new information, please re-open the issue by changing the status to active.
--
This issue was edited with the help of Issue Helper
Comment #11
killua99 CreditAttribution: killua99 commentedOps ... I use an automatic button to close the issue but actually is fixed.
Comment #12
kumkum29 CreditAttribution: kumkum29 commentedHello,
i used this patch (why_php_eval-2040739-2.patch ) on the last dev version of views pdf. I get new errors in views admin page :
When i generate a view pdf, fields no longer appear...
Thanks.
(i use php 5.4.4)
Comment #13
killua99 CreditAttribution: killua99 commentedI hope with the next compiling dev it will be fixed. You can pull the last dev branch ?
Comment #14
candelas CreditAttribution: candelas commentedi got today last dev and works perfect for me, without warnings. i had to clear cache. PHP Version 5.3.10
i can use eval in a field with
$content = strtoupper($content);
@kumkum29 do you have php filter module enabled?
Comment #15
candelas CreditAttribution: candelas commented@kumkum29 can you test only with one field and $content = strtoupper($content); in "PHP Code Before Output" please? maybe the problem comes from other thing.