I am currently checking the deprecated functions of a software developed in older PHP. It was developed in 2006. And I've seen a lot of variables in this format $_SESSION[name] or $_GET[name].
The issue here is that it does not give error on the deployed site. But in my local it gives Notice: Use of undefined constant name - assumed 'name'.
I know that I can solve this by adding single or double quotes on each variable but there are a lot to edit. And I have no access to the server configurations.
Any idea why this does not work on my local. I use PHP 5.6.
EDIT:: I just want to know the reason behind.
Thanks.
In this kind of odd Scenario, you have a hint from the E-Notice: Notice: Use of undefined constant name - assumed 'name'. Since you don't have access to the server, (and until you do) You may simply create a temporal File say: _DEFINES.php and include it in your Scripts. Inside that File, you may just define those variables as Strings like so:
<?php
defined('name') or define('name', 'name');
defined('another_string') or define('another_string', 'another_value');
defined('yet_another') or define('yet_another', 'yet_another');
That way, you may have temporarily beat the nightmare...
NOTE: This is not much of a Solution... it is just a temporal work-around till you can fix the issue from the server-side....
Related
The PHP's documentation describes define() function with the constant name as a string. So it should be in quotes:
define('ANY_CONSTANT',1);
However I saw tons of examples with no quotes like this:
define(ANY_CONSTANT,1);
I also tested both ways in online PHP tester and both worked correctly.
Can anyone explain a little bit: is there any difference between those two methods? Is any of those better? In which circumstances?
Short answer: Yes you should.
If you don't, PHP will look for a constant with that name, not find one, and assume it's a string and use it as such. This will generate a notice in the error log, if you set PHP to report notices.
Using
define(ANY_CONSTANT,1);
will cause a warning:
PHP Notice: Use of undefined constant ANY_CONSTANT - assumed
'ANY_CONSTANT'
So you definitely need to use quotes.
(As always) It depends on the context:
define(ANY_CONSTANT,1);
is legal, since passing a literal (such as 'ANY_CONSTANT') is not mandatory - you could also pass a constant (such as PHP_OS aswell). You have to make sure not mixing up literals with constants.
Why it "works" for you is a dangerous approach, since in one case you might have simply forgot the quotation, but in another case you'd definitly wanted to use a constant. Hence the notices PHP will throw.
Notice: Use of undefined constant test - assumed 'test'.
I am not sure where this error came from. I am using the Widget Logic Plugin and is fully updated, but I can't seem to find where this issue is. Has anyone had this issue and know how to resolve it?
The most likely answer is that you have missed a $ on a variable called $test and used test in your code somewhere.
This is hard to verify without your code, but the error message you are referring to is what generally happens when a variable is written without the $ at the start - PHP tries to assume it is a constant of the same name.
The second option is that there is an array index 'test' with the missing quotes, i.e. $array[test] instead of $array['test'].
Edit: If you are not writing any code yourself, and using only using plug-ins, you might want to do two things:
See if you can find the error in their code (search for a variable called test without a $ in front of it
Raise a bug on their site, so that they can update it
I have an old application witch pops up an error at a certain location. The error is about an wrong set variable. Only from the error it is not possible to find the location where the variable is set wrong. Now my idea is to use reflections to find the location.
Is it possible to use reflections to find the code position at which a variable gets a certain value?
The idea: I have the name and the value of the variable. Now if both are matching a certain event should be triggered and echo the actual parsed file and line number.
Every ideas that help are appreciated.
Thank you,
-lony
P.S.: Is it possible even if the application is not really object oriented and uses a lot of spaghetti code?
I would be you do a debug_backtrace at the point where the error occurs and try to exploit the stack trace to see where the variable is changed. The debug_backtrace would give you a list of file included after it should be fairly easy to filter a list of line with a global search (i.e. grep)
var_dump(debug_backtrace())
if (variable == value) {
echo "variable equals value, line #whatever"+"<br/>";
}
Just place these at various points in code and see which ones display. Manually enter line numbers.
I found a solution to one of my problems.
The function debug_print_backtrace helped me finally debugging my spaghetti code. I found it by reading this post.
-Cheers
I'm currently working on a very large project, and am under a lot of pressure to finish it soon, and I'm having a serious problem. The programmer who wrote this last defined variables in a very odd way - the config variables aren't all in the same file, they're spread out across the entire project of over 500 files and 100k+ lines of code, and I'm having a hell of a time figuring out where a certain variable is, so I can fix an issue.
Is there a way to track this variable down? I believe he's using SMARTY (Which I can not stand, due to issues like this), and the variable is a template variable. I'm fairly sure that the variable I'm looking for was initially defined as a PHP variable, then that variable is passed into SMARTY, so I'd like to track down the PHP one, however if that's impossible - how can I track down where he defined the variable for SMARTY?
P.S. I'm in Vista, and don't have ssh access to the server, so 'grep' is out of the question.
Brute force way, because sometimes smarty variables are not directly assigned, but their names can be stored in variables, concatenated from many strings or be result of some functions, that makes it impossible to find in files by simply searching / greping.
Firstly, write your own function to print readable backtrace, ie:
function print_backtrace()
{
$backtrace = debug_backtrace(FALSE);
foreach($backtrace as $trace)
echo "{$trace['file']} :: {$trace['line']}<br>";
}
Open main smarty file (Smarty.class.php by default) and around line 580 there is function called assign. Modify it to watch for desired variable name:
function assign($tpl_var, $value = null)
{
if($tpl_var == 'FOOBAR') /* Searching for FOOBAR */
{
print_backtrace();
exit;
}
The same modification may be required for second function - assign_by_ref. Now after running script you should have output like that:
D:\www\test_proj\libs\smarty\Smarty.class.php :: 584
D:\www\test_proj\classes.php :: 11
D:\www\test_proj\classes.php :: 6
D:\www\test_proj\functions.php :: 7
D:\www\test_proj\index.php :: 100
Second line points to the place where variable was first assigned.
This sort of thing is the #1 reason I install Cygwin on all my windows machines.
grep myvariablename `find project_dir -name "*.php"`
I can't imagine programming without a working grep.
There is an interesting further option, ugly like hell but helpful if you are really lost.
If you would like to know where THE_NAME was defined, write lines like these on a place you are sure is run first:
error_reporting(E_ALL);
define('THE_NAME', 'Chuck Norris');
If later PHP will run the definition you are looking for, it will write a notice like this:
Notice: Constant THE_NAME already defined
in /home/there/can-rip-a-page-out-of-facebook.com/SomeConfiguration.php on line 89
Then you know that the definition you are looking for is in the file SomeConfiguration.php on line 89.
To have this working, you must consider
if there are HTTP forwards in the framework on the way to the code you set in
if there are further commands setting the PHP error reporting mode
So sometimes it helps to add some exit('here') in order not to blur the output. Maybe you have to narrow down a bit or you have to set error_reporting earlier, but you'll find it.
It's not a perfect solution, but I find agent ransack useful for searching large directories and files. Might help you narrow things down. The search results will allow you to read the exact line it finds a match on in the result pane.
If you use the netbeans editor just "right click" -> "go to Definition"
Or ctrl + click on the variable.
If the editor can't figure it out, you could fallback to the "Find in files" option.
Just use one of the available PHP IDEs (or a simple text editor like Notepad++ if you're really desperate) and search for the name of the variable in all source files (most PHP IDEs also support finding where functions/vars were defined and allow you to jump to the relevant piece of code). Though it seems weird that you don't know what piece of code calls the template (whether it's Smarty or anything else doesn't really matter). You should be able to drill down in the code starting from the URI (using any IDE which supports debugging), because that way you're bound to see where said variable is defined.
I've just upgraded to PHP 5.3 and started supporting an old website for a new client. It seems to use rather odd PHP code which I've not come across before.
Whilst trying to access $_GET or $_REQUEST variables, the developer has used the following: ${"variable_name"}
I get notices generated due to undefined variables (presumably because PHP is not parsing the ${"variable_name"} style code).
Changing this to $_REQUEST['variable_name'] works as expected, but I can't go through all their code and change it as the site is massive and uses proprietry layout methods.
Does anyone know if it's possible to switch on support for these tags / codeblocks? I've taken a look in PHP.ini and there is a mention of ASP style tags and short tags but enabling these has no effect (they look totally different anyway, I just thought it was worth a shot).
I don't think there is anything new with that syntax :
$a = 10;
var_dump(${"a"});
Works just fine ;-)
You problem is probably due to the fact that, before, register_globals was enabled (by default, if PHP <= 4.something), and is now disabled -- and that is good for security !
With register_globals set to On, any variable in $_REQUEST is automatically injected as a vartiable in your application -- well, actually, this depends on the variables_order configuration option, but this one almost always includes Get, Post, and Cookie, at least.
For instance, if there is a variable like $_GET['my_var'], you will also have a $my_var variable... And this one can also be accessed with the syntax ${'my_var'}
Considering register_globals is Off by default since something like PHP 4.2, and should disappear in PHP 6 (if I remember correctly), I would advise against re-activating it... at least, if you have the time required to correct / test the code...
Curly brace syntax for variables is an embedded part of PHP, and has been around for quite awhile. The reason it exists is to resolve ambiguities with arrays and object syntaxes when using variable variables.
From the manual:
In order to use variable variables
with arrays, you have to resolve an
ambiguity problem. That is, if you
write $$a1 then the parser needs to
know if you meant to use $a1 as a
variable, or if you wanted $$a as the
variable and then the 1 index from
that variable. The syntax for
resolving this ambiguity is: ${$a1}
for the first case and ${$a}1 for
the second.
It's a very handy syntax in several situations, such as using array or object variables while outputting something using heredoc syntax.
I won't reiterate the advice by others about using register_globals, I just wanted to expound on this unusual syntax.
The ${"variable_name"} syntax is practically the same as $variable_name, except that the contents of the curly braces are evaluated first. It is supported by all recent versions of PHP, even the beta versions. What is not supported by recent versions of PHP though is the support of registering $_REQUEST (and other) variables as global variables. There's a setting for enabling it:
register_globals = on
It is NOT recommended for production use because of security issues though. It may be easier to run you source through some 'sed'-like tool and replace the usages with regular expression.
The old server probably has REGISTER_GLOBALS on. So the weird brackets aren't the problem.
REGISTER_GLOBALS puts all the variables in $_REQUEST as regular variables in the global scope, meaning you can access $_REQUEST['test'] can be accessed like $test or ${"test"}
The bracket syntax is on by default, and I don't believe you can turn it on/off.
register_globals was likely switched on. {$variable_name} syntax is always on, but register_globals turns things like $_REQUEST['variable_name'] into $variable_name.
Avoid switching it on if at all possible, though - there's a reason it's been long advised against, and it's going away entirely in PHP6.
register_globals is deprecated as of php 5.3 and will be removed as of php 6.0. What you want to do is use the Refactoring feature found in most PHP IDE's (zendo studio 6+) to rename the variable to something more appropriate, ie $_GET['variable_name'].