I'm redoing a large portion of my website to use older mysql_* extensions because they execute faster. Yes I know people say its not a good idea to use older extensions, but I need to go for speed since this code is part of the back-end operations to my website and I want to serve as many people as possible.
I do have a small issue after converting things over. Sometimes when I try to close a database connection I get a PHP warning of:
PHP Warning: mysql_close(): 33 is not a valid MySQL-Link resource in /path/to/script.php on line #
and the line refers to the code below:
function DBclose($c){
if (isset($c) && !mysql_close($c)){
error_log("DB handle is invalid/null. Called from ".debug_backtrace()[2]['function'].'->'.debug_backtrace()[1]['function']);
}
}
This only happens sometimes.
What I want to do is change only this warning so that it includes the function that called it. Maybe to something more like:
PHP Warning: mysql_close(): 33 is not a valid MySQL-Link resource in /path/to/script.php on line # called from parent function <function-name>
How do I fix this and still make it so that other function calls I make that begin with # will have no errors printed on screen?
I don't think you can change the message, however, you can check if it's a resource using is_resource()
Related
I need to get a file from SharePoint using phpSPO.
I use this code:
$authCtx = new AuthenticationContext('https://xxxxxxxx.sharepoint.com');
$authCtx->acquireTokenForUser($username,$password);
$ctx = new ClientContext('https://xxxxxxxx.sharepoint.com/sites',$authCtx);
require('settings.php');
$sourceFileUrl = "/path/to/excel.xlsx";
$targetPath = "/files/excel.xlsx";
$fileContent = Office365\SharePoint\File::openBinary($ctx, $sourceFileUrl);
But I get this error:
Deprecated: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in /var/www/www.mydomain.dk/vendor/vgrem/php-spo/src/Runtime/Http/Requests.php on line 137
Isn't phpSPO ready for php 8.0 or what could be wrong?
A deprecation is not an error. It's a hint to the author of the code that they will need to fix the code "soon" (i.e. within the next few years, when PHP 9.0 is expected to ship) so that it doesn't become an error.
If you want to identify what needs changing and contribute a fix, I'm sure the maintainer will appreciate the help.
If not, it is perfectly safe to completely ignore the message. If necessary, change your error configuration to ignore deprecations, or to ignore them within the "vendor" directory where third-party code lives, using something similar to this answer.
Suddenly, an application isn't any longer able to output ZIP files. An inspection revealed the cause: The first character of the ZIP is a blank, which breaks the ZIP format spec.
To track down this problem, I enabled CStatementTracer, which prints each line of executed code to a log file. Didn't help. [Remark: declare(ticks=1); doesn't seem to trap each line of executed code]
I then set an output handler like so:
function callback( $buffer ) {
$deb = print_r( debug_backtrace(), TRUE );
file_put_contents( './statementTrager.log', $deb );
return $buffer;
}
ob_start("callback", 1 );
Unfortunately, this handler isn't called at all.
Q: Does a generic / canonical solution exists, which identifies the file / line of PHP-code, which emits the first character.
A solution, that finds the loc whatever other code gets executed.
Remarks:
Not even a single PHP file is closed using ?>
Meanwhile I found the suspicious like of code: A blank in front of a starting
Still, I'd like to get hints regarding a programmatic solution. Preferrably a solution written in pure PHP.
https://linux.die.net/man/1/strace is probably the most reliable tool to find out where the output comes from. Assuming you are on Linux. There must be similar tools for other platforms.
Although it will not give you the line of the php code, you can analyse the context of system calls made before and after the offensive character was sent. Usually it is enough to identify where the problem originates.
It is quite time consuming process though. Should be used as the last resort.
After attempting to migrate our Wordpress site to the root, the page builder theme we're using now shows the majority of the pages as blank. The page builder theme uses rows and modules with the data stored in the _postmeta table of the database. I've checked the database and the page data for the builder is still there, albeit serialized. After migrating, I did do a search and replace on the database, which I now know wasn't a good move due to the serialized data. However, I've restored the database and the site/theme files to an earlier date and the issue still persists. The site is blank! :(
I've checked the error logs for the server, and I'm noticing 3 recurring warnings starting after the migration:
Warning 1
PHP Warning: substr() expects parameter 3 to be long, string given in /hermes/waloraweb013/b1721/blu.icweb4704n/test/wp-content/themes/cutting-edge/framework/spyropress-functions.php on line 105
Line 105 reads:
$text = substr( $text, 0, $length );
Warning 2
PHP Warning: Invalid argument supplied for foreach() in /hermes/waloraweb013/b1721/blu.icweb4704n/test/wp-content/themes/cutting-edge/framework/builder/spyropress-row-functions.php on line 382
The code for line 382 is:
foreach ( $rows as $row_ID => $row ) {
Warning 3
PHP Warning: Invalid argument supplied for foreach() in /hermes/waloraweb013/b1721/blu.icweb4704n/test/wp-content/themes/cutting-edge/framework/builder/spyropress-row-functions.php on line 332
Line 332 is also:
foreach ( $rows as $row_ID => $row ) {
I need help figuring out what could've gone wrong and still be wrong after restoring the site and the database to an earlier time, and without changes in of the Lines which now have errors. Is it possible that the database is caching? I've cleared my browser cache and restarted several times to no avail.
Any help or insight is greatly appreciated - we're talking about 8 months worth of work I really can't afford to lose.
Thanks in advance!
I have a huge XML file (114 KB/1719 lines; see the error message below why I say huge) and I try to read it as I have done with two similar files before.
The other two files load normally and are of comparable size the only difference being that the file in question contains Arabic text. So here is the PHP code:
$doc3 = new DOMDocument('1.0', 'utf-8');
$doc3->load($masternumber.'.xml');
And the error is:
Warning: DOMDocument::load() [domdocument.load]: Excessive depth in document: 256 use XML_PARSE_HUGE option in file: ...
Then $doc3 doesn't load the file. So I modified the code:
$doc3->load($masternumber.'.xml', "LIBXML_PARSEHUGE");
And I end-up with another warrning:
Warning: DOMDocument::load() expects parameter 2 to be long, string given in...
$doc3 is empty again.
What is wrong with it? The other files contain the same text in other languages and load properly but not this one? I am using PHP 5.3.9.
Use a constant, not a string.
$doc3->load($masternumber.'.xml', LIBXML_PARSEHUGE);
See the DOMDocument::load() documentation for complete details. The second parameter is a long integer representing the selected options from the list of constants.
Incidentally, if you need multiple options for any reason, it is done by combining them with the bitwise OR operator |
// Multiple options OR'd together...
// Just FYI, not specific to your situation...
$doc3->load($masternumber.'.xml', LIBXML_PARSEHUGE|LIBXML_NSCLEAN);
I keep getting an error on this code:
<?php
function encode_object(&$obj) {
foreach ($obj as &$current) {
if (is_string($current) or is_object($current) or is_array($current)) {
if (is_object($current) or is_array($current)) {
encode_object($current);
}
if (is_string($current)) {
$current = urlencode($current);
}
}
}
}
?>
This code has worked before but for some reason every time a run it I get:
Fatal error: Maximum execution time of 30 seconds exceeded in * on line 9
What I'm trying to do is be able to give it an object, search through it and encode all of the strings.
I have tried multiple times but keep getting the same error
I am using:
Apache 2.2.15.0
PHP 5.3.3
Windows 7 Ultimate build 7600
EDIT:
The input I'm entering is an error that, after going through this function, is meant to be converted into JSON and read by javascript through ajax.
The input in this case would be:
array("error"=>
array(
"error"=>"error",
"number"=>2,
"message=>"json_encode() [<a href='function.json-encode'>function.json-encode<\/a>]: recursion detected",
"line"=>22))
That is another error that i will worry about later, but it seems that when I put
$obj['error']['message'] = 'blah';
on the object before I send it, the code works fine. So there is something about
json_encode() [<a href='function.json-encode'>function.json-encode<\/a>]: recursion detected
that urlencode seems to be having a problem with.
If it has worked before, then it seems there's nothing wrong with the code, just that the objects you're sending it are large and are taking longer to process than the default execution time set in PHP.
The quick and dirty way to handle this is to use the ini_set() function:
ini_set("max_execution_time",840); (in this case, 840 is 840/60 or 14 minutes)
I've used this before on a query with a particularly large result-set, one which took at minimum five minutes to load, and build the HTML for the page.
Note, this will not work if your host has "Safe Mode" enabled. In that case you actually have to change the setting in PHP.ini. Otherwise, I use this quick and dirty roundabout fairly often for ridiculously huge parsing/processing tasks.