Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
When trying to access the pdf-view page I get this error:
Fatal error: Call to undefined function php_eval() in C:\wamp\www\drupac\sites\all\modules\views_pdf\views_pdf_template.php on line 476
(however I can see the pdf page using the 7.x-1.x-rc1 version)
Comment | File | Size | Author |
---|---|---|---|
#31 | php_eval-1513490-31.patch | 298 bytes | killua99 |
#28 | views_pdf-undefined_index_function-1513490-28.patch | 971 bytes | psicomante |
#16 | views_pdf-1513490-16-conditionnal_php_eval.patch | 1019 bytes | Simon Georges |
#13 | conditional_php_eval-1513490-13.patch | 1.02 KB | idflood |
#7 | views_pdf-add_required_module_to_deps-1513490-7.patch | 298 bytes | firebird |
Comments
Comment #1
zoraxSame issue,
I use Commerce PDF Invoice with.
I can enter in the view UI, but can't generate a pdf
Comment #2
maddin2007 CreditAttribution: maddin2007 commentedI am not deep enough in Drupal, but a workaround is to use the standard eval-function from php ... works for me fine ... not to use the php_eval() from drupal.
Just replace in the 2 lines in the views_pdf_template.php "php_eval" with "eval" and it works. (line 476 and line 506)
Comment #3
zoraxIt works for me!
thanks a lot!!
Comment #4
drupadawan CreditAttribution: drupadawan commentedI don't know if there is a particular reason why the 'php_eval' is used instead of 'eval', maybe it can be changed in the module?
(but I thought I had read somewhere that it was used for security reasons, to sanitize the code or something? if so changing it would be unwise..)
Comment #5
farald CreditAttribution: farald commentedQuickfix: enable core php_filter module.
But; I don't think php_filter should be a required module for views_pdf for the sole purpose of providing php_eval().
I vote for using regular eval instead. Here's a patch.
Comment #6
farald CreditAttribution: farald commentedComment #7
firebird CreditAttribution: firebird commentedIf it's absolutely needed to use eval(), we should keep using php_eval(). It's got a couple of features that have been added there for a reason, see the API docs: http://api.drupal.org/api/drupal/modules!php!php.module/function/php_eval/7
Requiring a core module isn't bad at all in my book, the only problem is that the required module should be listed in the dependencies. This patch adds that.
Comment #8
idflood CreditAttribution: idflood commentedGot the same error, enabling php module fixed the issue. So patch in #7 looks good.
Comment #9
idflood CreditAttribution: idflood commentedComment #10
wusel CreditAttribution: wusel commentedI have the same issue.
But to enable the module "PHP filter" is not a good way. This may open new security-risks.
Wusel
Comment #11
idflood CreditAttribution: idflood commented@wusel: It will be a security risk if it is added to the filtered text format for instance. But I think that simply enabling the module isn't a risk by itself.
Comment #12
wusel CreditAttribution: wusel commented@idflood:
I think, if the module "PHP filter" is necessary, then is must be enabled for ALL users at "admin/people/permissions". That would be a big security-hole.
If the patch at #5 would be wrong/insecure, then there must be a solution to avoid this problem. All of my other modules never need the module "PHP filter", so why should this be different to use this module?
Wusel
Comment #13
idflood CreditAttribution: idflood commentedThe php_eval() function doesn't check for user permission. So it should not be necessary to enable it for all users.
On a side note the eval_before and eval_after variables are empty by default so it looks like eval is not required at all by default.
So with that in mind here is a patch with a different approach.
Comment #14
s.Daniel CreditAttribution: s.Daniel commentedWorks as well and it's a better solution in my opinion. PHP input through the UI is always something I would like to see avoided but is better than a http 500 error that you currently get without php module.
Note: The php module is about to be removed from core in D8 http://drupal.org/node/1203886 .
Closed http://drupal.org/node/1457864 as duplicate.
Comment #15
Simon Georges CreditAttribution: Simon Georges commentedCross-referencing #1910156: User of php_eval() instead of eval() prevent variable manipulation..
Comment #16
Simon Georges CreditAttribution: Simon Georges commentedWhat about using
module_exists()
instead ofmodule_load_include()
?See attached patch. If there's a consensus with it, I'll commit it.
This patch is part of the #1day1patch initiative.
Comment #17
Simon Georges CreditAttribution: Simon Georges commentedComment #18
vegansupreme CreditAttribution: vegansupreme commentedThis patch doesn't work for me. It is an improvement, in that PDF rendering continues, but the PHP doesn't get evaluated/executed.
Comment #19
maxplus CreditAttribution: maxplus commentedHi,
after I enabled the php filter and added permission to the needed roles, my problem was solved
Thanks
Comment #20
vegansupreme CreditAttribution: vegansupreme commentedStill can't get it working. I have PHP filter, and all users have full permissions (on dev site)
Comment #21
Simon Georges CreditAttribution: Simon Georges commented@vegansupreme Did you add other patches (like the one that have recently been committed to the -dev version)?
Comment #22
vegansupreme CreditAttribution: vegansupreme commentedI only applied this patch to the latest dev version (7.x-1.0+5-dev)
Comment #23
vegansupreme CreditAttribution: vegansupreme commentedI tried this on another host. Still, any PHP code I enter has no effect. I've tried it in PHP 5.3 and 5.4. PHP filter is enabled and permission granted to all users.
Comment #24
haegar der schreckliche CreditAttribution: haegar der schreckliche commentedIt's the same problem for me. With the patch the fatal error is gone but the "PHP Code Before/After Output" is not evaluated.
Comment #25
Simon Georges CreditAttribution: Simon Georges commentedDoes anyone know why there was a switch from eval() to php_eval()?
Comment #26
firebird CreditAttribution: firebird commentedSimon, see comment #7 and http://api.drupal.org/api/drupal/modules!php!php.module/function/php_eval/7
Comment #27
vegansupreme CreditAttribution: vegansupreme commentedIn the API documentation, it says
But isn't this exactly what we need to do for basic page layout, for example
$x=3;
? Is that not overwriting a variable?Also I noticed that the code needs to be wrapped in
<?php ... ?>
which is the opposite of how PHP was previously handled. Even still, I can't get it working.Comment #28
psicomante CreditAttribution: psicomante commentedThis notice has been popped up in our site.
However i fixed this error because it is related to #13
Comment #29
garphy CreditAttribution: garphy commented@vegansupreme : +1, regarding #27.
The reason of eval_before/eval_after to exist at all is to allow an alteration of the variables passed to TCPDF API.
We switched back to eval() on our production code bases.
If there's a general consensus for not using eval(), it'll be mandatory to design an alteration API.
Maybe any variables passed to TCPDF should be kept in a context array/object that can be altered with drupal_alter() hooks (ala theme variables).
Comment #30
killua99 CreditAttribution: killua99 commentedExist a patch to handle this issues and others. Please see #2032189: Multiple issue fixing in a single patch and review others issues patch.
This is RTBC, and ready to apply.
Comment #31
killua99 CreditAttribution: killua99 commentedThe solution it's required the PHP core module, because we need that wrapper.
Comment #32
killua99 CreditAttribution: killua99 commentedAnd committed
Comment #33
garphy CreditAttribution: garphy commentedWell I think we're doing it wrong in that issue.
AFAIK somebody must have wanted to follow some security practice by killing theses two eval()s and replace them with hardened drupal's php_eval().
But let's step back : php_eval is there to sanitize and safely evaluate arbitrary and potentially unsafe code and capture its output to return it. On top of that, it prevent evaluated code from altering any variable of the calling context.
Look at the code ! We're even not retrieving the return value of php_eval so the whole process is pointless. (Until someone come with a valid use case)
eval() is (was) there to allow usages of TCPDF that the original maintainer couldn't have predicted but it clearly demonstrate a lack of a clean API here (hook, drupal_alter, plugin, ...)
IMHO the best thing to do is to eventually revert back to eval while we can design a more elegant extension mechanism.
That change bothered any concerned developper that I know and nobody can explain why we introduced it. Let's revert all that stuff.
Comment #34
killua99 CreditAttribution: killua99 commentedStay this close while we do a hook/alter/theme. We know eval it's dangerous. So php_eval will stay until we replace it.
We have 4 post with the same problem the php_eval and eval.
Comment #35
garphy CreditAttribution: garphy commentedI don't get it.
1. if you think vital to remove any eval() from the code then you can simply remove them. The php_eval() calls are useless. They do *nothing*.
2. There's many of us relying on this feature which is now consequently broken. this is a big regression and as we have not yet designed a replacement, you should put back eval() and clearly state that it's deprecated and pending removal.
Comment #36
candelas CreditAttribution: candelas commented:)
thanks for using your time resolving this.
now the feature doesnt work (i was trying to use it) and it is very needed to correct interpretations from html to pdf with php searches or other functions.
if not, it should be out from the interface for people trying to use it.
i tried with php_eval and without. i have php filter module enabled.
Comment #37
candelas CreditAttribution: candelas commentedafter digging for knowing why i couldnt use $content, i found in views_pdf_template.php line 495
but i dont find any place where that varible is defined. if i change
to
manipulations on $content work.
i have the php filter module enable i realize that its better php_eval but it doesnt work in my case (last dev).
Comment #38
garphy CreditAttribution: garphy commentedYou can set the variable value in your settings.php
I didn't bother to provide an administrative UI for that as it's obviously a temporary solution.
Comment #39
candelas CreditAttribution: candelas commented@garphy in drupal there are many kinds of users, and not all as good techs as you :)
i suggest that if you do a thing like that, at least, put in documentation (like that you dont need to make the interface part). that would avoid time to people that starts to use this module or is a front-end developer.
at the moment, as i am not as good tech as you, i dont understand why if i have the php filter module enabled things like
doesnt work (i dont put the php part) unless i remove php_eval and put only eval.
i am following this issue at https://drupal.org/node/2040739 with very good work from killua99. it looks like this module is going to be bug cleaned at least and very useful :)
i am using it for commerce invoice and i think many people making commerce sites or views are going to be interested.