I'm using a PHP4 implementation of SimpleXML, which uses the built-in xml_* functions from PHP 4. I have an odd problem that I'm unable to diagnose due to no error reporting on the server and not being able to turn on error_reporting.
I've modified the Parse() function to include this:
[stuff here to initialise the parser]
echo '<textarea rows="8" cols="50">', htmlspecialchars($this->xml), '</textarea>';
$parsed = xml_parse($this->parser, $this->xml) or die('error with xml_parse function');
The textarea displays the XML fine, and the XML itself is perfectly valid. But the page stops right after that and doesn't appear to call the xml_parse function, or output the 'die' message.
Should also add that this works fine on other pages, it just appears to be a problem with this particular page for some reason.
What could be happening here? Are there other ways to debug this?
Yes, you can debug this by adding this to your script:
error_reporting(E_ALL);
Thus will turn on error reporting.
Also, using ‘or die‘ only works if the function call before it returns a falsey value. In the event of fatal errors, it doesn't help.
Try to set the error reporting on and see what error comes though, it is likely there is some fatal error coming up:
ini_set('display_errors', true);
error_reporting(E_ALL);
Try getting the XML specific parser error message:
echo xml_error_string(xml_error_code($parser));
IIRC, these are not output by default no matter what your error reporting is set to.
Reference:
xml_get_error_code
xml_get_error_string
It seems that the problem was due to the XML being too big for the parser. Since we can't turn on error_reporting there was no way to get proper debugging info.
I decided to use a separate script the generate the HTML for the page, to avoid issues with the page going down occasionally.
Related
I'm attempting to debug the PayPal review process in Magento. Every time I try to dump the following variable I get a white page:
//the variable declaration:
$shippingAddress = $this->getShippingAddress();
//the dump that breaks the page:
<?php echo '<pre>';print_r($shippingAddress);echo '</pre>'; ?>
I also tried with a variable on the page that was being used for something other than if statements.
//this variable displays results
<?php echo '<pre>';print_r($billingBlock->setShowAsShippingCheckbox(true)->toHtml());echo '</pre>'; ?>
//however, this one does not:
<?php echo '<pre>';print_r($billingBlock);echo '</pre>'; ?>
I was just wondering what might cause my var_dump to break the page? How do I see what is in the object if I can't dump it?
First, PHP never "just white pages". When you get a blank screen, that means PHP's execution has halted fro some reason. However, unless your server has been configured to not log errors, the PHP error log or the Magento exception log should have an error for you.
As far as your specific problem goes, many of Magento's objects contain reference to a large amount of information — and sometimes the references are circular. PHP's var_dump and print_r functions will blindly follow these circular references and attempt to print everything out. This eventually leads to PHP using more memory than is allowed by the memory_limit ini setting, and execution halts.
Most PHP professionals use the xDebug extension to work around this. The xDebug extension has a modified var_dump that will limit the amount of information dumped, which prevents the above memory limit problems. The xdebug.var_display_max_children, xdebug.var_display_max_data, and xdebug.var_display_max_depth ini settings are the ones you'll want to tweak if xDebug's still not helping with the memory limit problem. (some PHP distributions have these set too high initially)
If that's not a possibility, a little caution with your var_dump's can still help.
Use this to figure out the variable type
var_dump(get_class($thing));
If it's a Magento object, use this to see its data keys
var_dump(array_keys($thing->getData()));
And then output individual data members with
var_dump($thing->getData('key_name'));
var_dump($thing->getKeyName()));
A PHP parse and fatal error would produce this. You may want to have a look at your error log.
You could try adding the following lines to the beginning of your php files (just after the opening PHP tag "
ini_set('display_errors',1);
error_reporting(E_ALL);
I want to migrate code from PHP 5.2 to 5.4. This worked fine so far except that all the code I use makes extensive use of just using an object with a member without any initialisation, like:
$MyObject->MyMember = "Hello";
which results in the warning: "Creating default object from empty value"
I know that the solution would be to use:
$MyObject = new stdClass();
$MyObject->MyMember = "Hello";
but it would be A LOT OF WORK to change this in all my code, because I use this many times in different projects. I know, it's not good style, but unfortunately I'm not able to spend the next weeks adding this to all of my code.
I know I could set the php error_reporting to not reporting warnings, but I want to be able to still get other warnings and notices. This warning doesn't seem to be effected by enable or disable E_STRICT at all. So is there a way to just disable this warning?!
Technically you could do this by installing your own error handler for warnings. From inside the handler check the string error message; if it's the one you want to suppress then return true, otherwise return false to let the default error handler do its thing.
However I would still recommend doing the right thing and manually fixing your code wherever this misuse does appear because, if nothing else, it gets you into the correct habit. Unless this is paid work (in which case there usually are concerns that override purity of implementation), consider this as a lesson and do the right thing.
I know I could set the php error_reporting to not reporting warnings, but I want to be able to still get other warnings and notices.
Don't disable the error reporting, leave it at an appropriate level, but disable the display_errors directive:
ini_set('display_errors', 0);
There's no reason to print notices to the screen in production.
Then as Jon said, use a custom error handler if you aren't already, example:
function my_error_handler($error_level, $error_message)
{
// write error message to log file
}
set_error_handler('my_error_handler');
You can pass in the error reporting level to the second param of set_error_handler. This way you can take your time and do the right thing, which is fix the code to stop generating notices.
If you're moving a lot of sites over to 5.4, you can probably have your server admin turn off display_errors in php.ini until you have enough time to fix everything. Better yet, stage everything and fix it before upgrading, but that may not be an option.
you really could use an IDE for php and try to do this:
Search for $MyObject->MyMember = "Hello";
Look for the results and if it brings the right things, try to replace that with:
$MyObject = new stdClass();
$MyObject->MyMember = "Hello";
So maybe the IDE would do the long work for you...
I had the same problem i handle it like bellow in production environment
\error_reporting(\E_ERROR);
I have to say that my application doesn't need/generate errors, it's on a very controlled environment so doing this wouldn't hurt much, but if your application is an error prone one you should have you own error handler and with a proper regex and preg_match ignore the “Creating default object from empty value” warning and log/prompt others at your discretion.
I have a weird problem, I am using print_r($obj) in Joomla YOOtheme ZOO extension and it returns a blank page. it just act as die() !
it should output the object but it does not.
Please note that print_r() is working fine with some other objects and variables.
I am using XAMPP on Windows.
Any help?
Upon executing print_r() and var_dump(), the page is just blank, no error, view source shows:
<html>
<head></head>
<body></body>
</html>
Error reporting is turned on.
It is posible that $obj is too big to load, and grabs a lot of memory after which the script stops to work.
Thanks
Is error reporting turned on?
If not add to your code:
ini_set("display_errors", "1");
If it's outputting nothing, $obj contains nothing. Try var_dump() instead. Also, make sure you're seeing all errors that PHP is producing:
ini_set('display_errors', 1);
error_reporting(-1);
So - strange situation I got here.
The statement error_reporting(0); has been giving me a server 500 error.
However, error_reporting(1); works just fine..
And its killing me, too many warnings for some of my URL validators. What's up with this? Any idea on how this can be fixed?
First of all, I'm sorry if I behave "smartass", but I have to tell you that if there are warnings, you should consider to fix them instead of just reduce them to silence... :)
Junk PHP code let bad things happen, and you won't like it. I understand 80% of the PHP code around is junk, but really try to fix that library, if it's not huge.
We can however try to solve the problem if you just make a simple .php file, with only one line:
<?php
error_reporting(0);
?>
and test if it fires the error. If it doesn't, the problem is not caused by error_reporting, but just triggered by it, and there's some sick stuff going on elsewhere. :)
try error_reporting(E_ALL); and ini_set("display_errors","On"); and check the errors that occur. After you fix those, there shouldn't be any problem.
Good luck
Shai.
P.S. i would be guessing for almost 100% that you use Chrome, because for some reason chrome would sometimes just show its own error screen instead of showing error messages. So also try another browser just to check the errors.
error_reporting()'s value is defined with constants, so don't use direct value to set it.
If you had used the constants, you would have noticed that none of them have 0 as value.
If you want to report all errors, there is an exception to the rule : use the value -1 :
error_reporting(-1);
Source : http://us.php.net/manual/en/function.error-reporting.php
And consider fixing all warnings! (and even notices if possible)
Note : the -1 value is used to be sure that even if more error code are added, they are all included.
I want to do my proper error generator when i'm programming (HTML + PHP).
How can i take the line, when i have an error, and put in a variable?
Example :
echo " Error # 03: variable undefined line #".$line." ";
Thanks.
the variables you'd be looking for are:
__LINE__
__FILE__
__FUNCTION__
__CLASS__
there is a predefined constant, __LINE__ that contains the line where it was actually called.
However, I guess that trigger_error() function perfectly fits "error generator" term, thus being exactly what you're looking for.
It will not only show you a line and a file and a timestamp, but also will follow general behavior of PHP error reporting settings, which is very important - you should never echo errors implicitly but rather put it into standard error stream
for the custom error handler there is also a debug_backtrace() function.
Assuming you are referring to PHP compile time errors and warnings, the line number is automatically displayed. Since these messages are generated at compile time (and as such can cause the script not to execute fully) I would recommend using the default messages rather than using a custom solution.
If PHP is not displaying the error messages, use the following code to display all of the PHP error messages and warnings on a page:
error_reporting(E_ALL);