Zen Cart Issues

Dealing With Zen Cart Creating Many Log Files After Increasing PHP Version in Use

Changes in newer versions of PHP have led to more warnings being issued about code that isn’t correctly written for more recent versions of PHP. This is a more prominent issue for Zen Cart websites, since it can lead to the “logs” directory quickly filling with many files. That is something we have been dealing with quite a bit recently while working on upgrades of Zen Cart, which often coincides with switching to a newer version of PHP.

Making the situation more complicated is that the directory can also contain messages about errors, in which an issue with the website caused it to not function, alongside all those warnings of things that don’t currently cause the website to not function.

While changing back to the older version of PHP would stop those files from being created, if you are changing back to PHP version that isn’t supported anymore, you are reintroducing security risk. Though we should note, it has been quite a long time since a security issue in PHP was a major source of hacking.

More permanently dealing with the warning log files involves addressing what is being warned about. That starts with making sure you are using a version of Zen Cart that is compatible with the PHP version in use. From there, updating other software on the website may resolve issues, if the newer version has had changes made related to those. Once that has been done, that leaves you with other third-party code that needs to be updated. Those with some familiarity with PHP code or coding in general can probably handle making those changes. Others will probably want to find someone to handle that for them. With much of what needs to be dealt with, a prior familiarity with Zen Cart isn’t necessary.

While some of the issues we have run across are more complicated, most of the issue that need to be addressed are easy to fix. Take one common issue in our experience, usage of PHP 4 style constructors. The log files will provide a warning like this for that:

PHP Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; rialto_export has a deprecated constructor in /home/[redacted]/public_html/includes/classes/observers/class.rialto_export.php on line 9.

Opening the file listed shows that class rialto_export has a constructor of the same name:

class rialto_export extends base {
	var $client, $web_username, $web_password, $success_message = false, $error_message = false;
 
	function rialto_export() {

That can be resolved by renaming the function to “__construct()” like this:

class rialto_export extends base {
	var $client, $web_username, $web_password, $success_message = false, $error_message = false;
 
	function __construct() {

For most issues, doing an internet search on the warning message will bring up documentation on how to address it.

With our Zen Cart upgrade service, we now include resolving any issues being warned about in the “logs” directory at no additional cost. If there is a interest in a service for dealing with those separate from an upgrade, please contact us.

Web Host Caching Can Cause Changes to Websites To Be Applied in a Delayed Manner

When we are contacted about issues with websites, we often find that important details haven’t been provided at first, and asking for more detail is better than trying to jump into dealing with the issue. That far too often runs into another issue, people managing websites think they know what needs to be done, even though they don’t know how to do that, and don’t want to provide more details.

A recent example of the first part of that occurred when we were contacted by someone we had previously done work on a Zen Cart based ecommerce website for. They now had an issue where when adding some products to the shopping cart a message, “Whoops! Your session has expired.”, was being displayed, while others were added normally. While doing an initial assessment of what was going on, it looked like some pages were being cached from one session were then being displayed for others visiting the website.

They also had mentioned in the initial message that when editing products, they were not looking the same on the frontend as it was on the backend. We further inquired about that and the response made it sound like caching was in place on the website, as they described that there was a delay between changes being made to products and those showing up on the frontend. If we had known that at the beginning, we could more easily determined what was at issue. Once we inquired if there was any caching enabled, they were able to take care of that, and got their issue fixed with no charge from us.

Caching built in to web software or as an addon for said software is generally designed in a way that avoid these types of problems. When that is done in other places that isn’t always true and people managing websites don’t necessarily know the caching is occurring, much less would they understand the implications of that. We see problems because of that most often with web hosts providing caching, but we also sometimes see it with security services that also include caching.

That is a good reminder that service providers should be more careful about caching usage, but also that talking to someone with more expertise and answering the questions they asked can lead to a better result than going it alone or dictating how something should be handled that you don’t have expertise in.

Dealing With Incorrect Results in Zen Cart’s Best Products Purchased Report After Upgrade

While the Zen Cart team usually resolves bug introduced in to new versions quickly, an issue with the Best Products Purchased report has existed for over two years. The issue produces obviously incorrect data in the report. Here was the result it was producing on a website we just upgraded to the latest version of Zen Cart, 1.5.7c:

While there are only 7 products shown, the stats at the bottom of the table say there are 20 shown out of 27,899.

Previously the report showed three products:

The different result is due to a change made to the query used to get the relevant data from the database. The comment included with the changed code that caused this is “new query uses real order info from the orders_products table, and is theoretically more accurate”. The results are clearly not always more accurate, though.

A quick fix for this is to restore the SQL query used to generate the results as of the last working version, 1.5.5f. In the file /[admin directory]/stats_products_purchased.php, the relevant line to change looks like this in version 1.5.7c:

          $products_query_raw = "SELECT SUM(products_quantity) AS products_ordered, products_name, products_id
                                 FROM " . TABLE_ORDERS_PRODUCTS . "
                                 GROUP BY products_id, products_name
                                 ORDER BY products_ordered DESC, products_name";

The previous version looks like this:

  $products_query_raw = "SELECT p.products_id, sum(p.products_ordered) as products_ordered, pd.products_name
                         FROM " . TABLE_PRODUCTS . " p, " . TABLE_PRODUCTS_DESCRIPTION . " pd
                         WHERE pd.products_id = p.products_id
                         AND pd.language_id = '" . $_SESSION['languages_id']. "'
                         AND p.products_ordered &gt; 0
                         GROUP BY p.products_id, pd.products_name
                         ORDER BY p.products_ordered DESC, pd.products_name";

Dealing With Slow Loading of Zen Cart Admin Dashboard in Zen Cart 1.5.7

While working on a recent Zen Cart upgrade, we ran into an issue where the admin dashboard went from loading nearly instantaneously to taking at least 5 seconds to load in Zen Cart 1.5.7. The page loading would pause when the “New orders” section was next to be shown, so that seemed to be the source of this. That seemed to either be because of a bug or a change that significantly increased the amount of data being processed.

It turns out to be the later, as Zen Cart 1.5.7 by default queries attribute data for products when generating that section, which can significantly slow things down in some circumstances.

As of Zen Cart 1.5.7a, there is a simple way to disable that and return to previous load times for those that don’t require that data to be queried. In the file /[admin directory]/includes/modules/dashboard_widgets/RecentOrdersDashboardWidget.php, near the top is the following line:

$includeAttributesInProductDetailRows = true;

Switching that from “true” to “false” will disable the queries and restore the previous load time.

Excessive Debug Log Files Can Slow Down Zen Cart Admin Area

We recently ran into an issue while working on an upgrade of Zen Cart website, which seems worth sharing in case someone else runs into a similar issue.

We had first done a test of the upgrade using a copy of the website we made through FTP access and placed into a directory on the existing website. Everything worked fine with that test copy of the upgrade. Then after the production website was upgraded the client was noticing that there very long load times for pages in the admin area of Zen Cart. That wasn’t happening on the test copy and apparently that hadn’t been happening on the production website before the upgrade (though we couldn’t confirm that). Seeing as the two websites should be identical that didn’t seem to make sense.

We then stumbled in to the answer. In trying to debug things we found that over FTP we couldn’t see all of the debug log files in the /logs/ directory for the website, as there was a limit of 8,000 items being shown, which also meant the test copy only started with that many items. We couldn’t see how many files there were in the production website’s directory as in the file manager in the cPanel control panel for the website the amount of files was apparently too many for it to be able to display any files in the directory. When we temporarily replaced the /logs/ directory on the production website to be able to see the latest entries, we found that the page load time in the admin area were no longer so slow.

What looks to have been happening is that when visiting an admin page a new file was being created to warn that the setting for where to place log files of the parse time was invalid and the amount of files in the directory was slowing creating that file, leading to the slow load times. So clearing out the old debug log files would solve such a situation, but if there are lots of debug files being generated dealing with the cause of those is important as the files count will just start growing again if that isn’t dealt with.

Fixing Zen Cart Admin Login Redirect Loop Caused By Forcing Website to Be Served Over HTTPS

We recently had someone come to us for Zen Cart support after they could no longer log in to the admin area of Zen Cart after their web host configured it so their website would always be served over HTTPS. When they tried to log in they were redirected back to the log in page without any error message being shown. While there are some other issues that can cause that same type of redirect to occur, in the situation where that change to serve the website over HTTPS has been made, what we found would fix this is to update the configuration file for the admin area, which is located /includes/configure.php in side of the admin directory (whose name varies from website to website), to use the HTTPS address for the website.

The relevant portion of the configuration file for a website using a recent version of Zen Cart is below:

/**
 * Enter the domain for your Admin URL. If you have SSL, enter the correct https address in the HTTP_SERVER setting, instead of just an http address.
 */
define('HTTP_SERVER', 'http://www.example.com);
/**
 * Note about HTTPS_SERVER:
 * There is no longer an HTTPS_SERVER setting for the Admin. Instead, put your SSL URL in the HTTP_SERVER setting above.
 */

Changing the “HTTP_SERVER” setting to start https:// instead of http:// resolves this as the proper address is used when handling the log in.