Hi David,
This may be no big deal since things appear to be functional, but I thought I should ask here. I'm seeing a few errors listed in my php error log (2 sites) that reference specific lines in files. I don't have errors turned on in configuration files, these are coming from the server.
Here are a few examples:
[16-Feb-2019 08:14:39 UTC] PHP Warning: mysqli_fetch_array() expects parameter 1 to be mysqli_result, boolean given in /home/account/public_html/shop/includes/database.php on line 36
"/includes/database.php line 36" =
while($row = mysqli_fetch_array($result,MYSQLI_ASSOC))
[16-Feb-2019 08:14:39 UTC] PHP Warning: mysqli_num_rows() expects parameter 1 to be mysqli_result, boolean given in /home/account/public_html/shop/includes/database.php on line 41
"/includes/database.php line 41" =
return mysqli_num_rows($result);
I am still on the old 13/03a with the Forward Compatible Patch package. Just wondering if there's something I missed or if I need to do something with php.ini settings? I did not notice any errors and checking server logs for that date/time showed nothing unusual.
No hurry on this, more of a general "why did this happen?" question.
As always, thank you so much for a super resource and great support.
2fer
Thank you David,
You are probably right. It did not seem to be synched with anything automated or anything I was doing, but yes, they don't seem to take 404 as an answer.
I will edit the search.php as you suggest.
Thank you again!
2fer
Hi David,
I had left a reply earlier to let you know I would take those suggested steps. But when I opened the search.php file neither of those lines was found.
if ($resultCount) is nowhere in the search.php file. Neither do I find the replacement:
if ($numRows)
Years ago we sort of customized that file so that it would return 404 headers for items/URLs not found rather than the "noresults" page.
I did not recall that myself until I opened the file. At line 310 there is different code for formatting. This section might help, it is from line 284 to 320:
$sql = "SELECT SQL_CALC_FOUND_ROWS id,COUNT(id) AS numMerchants,MIN(price) as minPrice FROM `".$config_databaseTablePrefix."products` WHERE ".$where.$priceWhere." GROUP BY search_name";
$orderBySelection = $orderByDefault;
}
break;
}
if (isset($orderBySelection[$sort]))
{
$sql .= " ORDER BY ".$orderBySelection[$sort];
}
$offset = ($page-1) * $config_resultsPerPage;
$sql .= " LIMIT ".$offset.",".$config_resultsPerPage;
$numRows = database_querySelect($sql,$rows);
$sqlResultCount = "SELECT FOUND_ROWS() as resultcount";
database_querySelect($sqlResultCount,$rowsResultCount);
$resultCount = $rowsResultCount[0]["resultcount"];
$totalPages = ceil($resultCount / $config_resultsPerPage);
$banner["h2"] = translate("Product search results for")." <i>".htmlspecialchars($q,ENT_QUOTES,$config_charset)."</i> ";
if ($resultCount && ($page <= $totalPages))
{
$resultFrom = ($offset+1);
$resultTo = ($offset+$config_resultsPerPage);
if ($resultTo > $resultCount) $resultTo = $resultCount;
$banner["h2"] .= "(".translate("showing")." <strong>".$resultFrom."</strong> ".translate("to")." <strong>".$resultTo."</strong> ".translate("of")." <strong>".$resultCount."</strong>)";I hope that can help.
Thank you,
2fer
Hi,
That modification would actually mitigate the scenario I had suspected so it doesn't look like it's that. What you could do - but only temporarily is to modify includes/database.php so that the script exit()'s immediately after an error so that you can capture the output before it becomes hidden by the output. To do this look for the following code at line 31:
print "[".$sql."][".mysql_error()."]";...and REPLACE with:
print "[".$sql."][".mysql_error()."]";exit();Then enable database debug mode at line 6 of config.advanced.php:
$config_databaseDebugMode = TRUE;Then have a good look around covering all page types of your site and hopefully you can capture the error. If discovered but you're not sure from the output what the problem is let me know what is displayed and I'll check it out further with you...
If not immediately discovered don't forget to disable debug mode by changing back to FALSE in case it is affecting your site. Note that the above is for SELECT queries, if you have any modifications that cause UPDATEs or INSERTs you can add exit() to line 54 of includes/database.php exactly as above and check of any write errors...
Cheers,
David.
--
PriceTapestry.com
Hi David,
Using the changes suggested, I have managed to see an error Or something, anyway. It did not occur during use or search, only when I logged in as admin and did an import of an unchanged datafeed.
I can't post that here without repeating the contents of the datafeed, but basically it starts with "[INSERT INTO.." (then the db name and SET filename...) then starts with the contents. At the end of all fields, it shows " dupe_hash='b09a7614e32c0ab2c0bded7a0e3c177a' ][Duplicate entry 'b09a7614e32c0ab2c0bded7a0e3c177a' for key 'dupe_filter']" and then proceeds with the next line in the datafeed. The error I saw on screen ended after 5 lines of the datafeed.
Weirdly I noticed that the datafeed seemed truncated (beginning a new line) at a particular cell of the datafeed where I have a search/replace filter that was only added yesterday. The feed was imported after that filter was added. I added a similar filter to each of 7 other feeds. It is about 150 characters that includes html. I do not think that is the cause of the previous error messages from the server because they were not there before and do not exist on the other site where I see the same errors I posted in the first post.
I now see a new/different server php error message:
[05-Mar-2019 18:33:14 UTC] PHP Warning: Cannot modify header information - headers already sent by (output started at /home/account/public_html/shop/includes/database.php:54) in /home/account/public_html/shop/admin/feeds_import.php on line 31
I've edited out the "$config_databaseDebugMode = TRUE;" to False after this. I also put back the previous version of includes/database.php file.
I hope this helps locate the cause.
Thanks again!
2fer
Hi David -
OOps! I left out one important detail!
That line 31 did not contain the code you show, it is similar, but the includes/database.php I am using is from the Forward Compatible pkg and the actual line 31 reads:
print "[".$sql."][".mysqli_error($link)."]";
rather than:
print "[".$sql."][".mysql_error()."]";
so I don't know if the change to:
print "[".$sql."][".mysql_error()."]";exit();
showed what it was supposed to show.
I hope this helps.
2fer
Hi,
Ah - the warnings are down to the duplicate prevention mechanism which utilises a unique key on the dupe_hash field, and if the key already exists the warning is raised. This is suppressed in later distributions using INSERT IGNORE. To apply to 13/03A edit includes/admin.php and look for the following code at line 376:
$sql = sprintf("INSERT INTO `".$config_databaseTablePrefix.$table."` SET...and REPLACE with:
$sql = sprintf("INSERT IGNORE INTO `".$config_databaseTablePrefix.$table."` SETCheers,
David.
--
PriceTapestry.com
Thank you David,
I'll get that edited and uploaded today.
It is great to have such support!
Thank you,
2fer
Hi,
That sounds like (13/03) a search engine requesting the page of an index result set (merchant, category or brand) that no longer exists, but lower page numbers still do. To correct, edit search.php and look for the following code at line 310:
if ($resultCount)...and REPLACE with:
if ($numRows)Cheers,
David.
--
PriceTapestry.com