Zen Cart

Handling Errors in Modules Caused by Zen Cart 1.5.3’s Change to the mysqli Extension

For the most part, the changes introduced in Zen Cart 1.5.3 have little impact on add-on modules in use, but we have found that one under the hood change is causing some problems. Previous versions of Zen Cart connected to the website’s database using PHP’s MySQL extension, starting with Zen Cart 1.5.3 the connection is instead made using PHP’s MySQL Improved (mysqli) extension. This change was needed at the very least to future proof Zen Cart as the MySQL extension was deprecated in PHP 5.5 and will be removed in a future version. For most modules the change has no impact, either because they don’t interact with the database or because they interact with it though Zen Cart’s database abstraction layer, so they don’t have any direct interaction with the database extension in use. In doing upgrades to Zen Cart 1.5.3 we have found that some modules, including the popular Easy Populate CSV and Super Orders, have direct interaction with the database using the MySQL extension. Because Zen Cart 1.5.3 is no longer using the MySQL extension to connect to the database, errors like the following will be shown when a module tries to utilize MySQL extension based functions:

Warning: mysql_query(): Access denied for user ‘root’@’localhost’ (using password: NO) in [redacted]/orders.php on line 1229 Warning: mysql_query(): A link to the server could not be established in /[redacted]/orders.php on line 1229 Warning: mysql_fetch_array() expects parameter 1 to be resource, boolean given in [redacted]/orders.php on line 1230

The quick solution to this type of error is to create a MySQL extension based connection for the module’s code to utilize. This can be done by adding the two following lines near the top, but below the line “<?php”, of the file with the error:

mysql_connect(DB_SERVER, DB_SERVER_USERNAME, DB_SERVER_PASSWORD);
mysql_select_db(DB_DATABASE);

The first line makes a connection to the database server listed in your configure.php file and the second will select the database listed in the configure.php.

A more permanent solution would be to modify the module’s code to utilize Zen Cart’s database abstraction layer, if possible.

Is it Time to Upgrade to Zen Cart 1.5.3?

It has now been a couple of months since Zen Cart 1.5.3 was released and we have now handled enough upgrades to the new version to provide our insights on the question that has been coming up when discussing upgrading Zen Cart with clients, is it time to upgrade Zen Cart 1.5.3?

Let’s start with what is new in Zen Cart 1.5.3. One of the big changes is that version 1.5.3 supports PHP 5.4, 5.5, and 5.6. The new version includes some security enhancements, including better password hashing. It also includes numerous bug fixes and some performance enhancements. You can find the full list of changes in the release announcement.

We have run into couple of issues when doing upgrades to 1.5.3. The first is that many addon modules do not officially support Zen Cart 1.5.3 yet. For some modules they may not need any changes and their maintainer just hasn’t bumped the Zen Cart version supported. Others that modify core Zen Cart files will need to have updated versions of those files included, until they do that you can use those with 1.5.3 if you apply the changes they make to those files to the versions of the file include with 1.5.3. Others need to be modified to work with Zen Cart 1.5.3. The second issue we have found is that some changes in Zen Cart 1.5.3 will require making changes with your current setup, for example changing the time zone now needs to be done differently and custom templates may need to be changed to support more secure redirect links.

With the basics set out, below we provide on advice on whether it is time to upgrade depending on your current situation:

Running Zen 1.3.9, 1.3.8, or older

If you are still running Zen Cart 1.3.9, 1.3.8, or and even older version you are overdue for an upgrade at this point so you should probably go ahead with the upgrade now. While issues with modules and 1.5.3 could cause some issues, you are going to probably run into module issues that will have to be dealt during testing when upgrading from those versions to any version of Zen Cart 1.5.

Need to Be Using a PA-DSS Certified Version of Zen Cart

Zen Cart 1.5.0 continues to be the only version to be PA-DSS certified, so for those that need that for PCI compliance purposes should remain on 1.5.0 for now. In the release announcement for 1.5.3 it says that a new PA-DSS certified version should “hopefully” be released in “only a couple months”.

Web Hosting Account Switching to PHP 5.4, 5.5, or 5.6

The number one reason we are hired do Zen Cart upgrades is that version currently being used is not compatible the version of PHP that the web server the website hosted on is being upgraded to. With the recent end of support for PHP 5.3 web hosts should be moving to at least PHP 5.4 soon (though many web host are only now transitioning off of PHP 5.2 despite support ending in January of 2011). Zen Cart 1.5.3 is the first release to support PHP 5.4, 5.5, and 5.6 so anyone moving to those versions of PHP should upgrade.

Running 1.5.0 or 1.5.1

If you don’t need to upgrade for the new versions of PHP, don’t have an urgent need for an of the bug fixes or improvements, and use a lot of modules you may to want hold off until more modules are updated for Zen Cart 1.5.3. Otherwise, it would be a good idea to do upgrade now.

Companies Trying to Sell Unnecessary Work Along With Needed Web Software Upgrades

When it comes to the security of websites, often the basic security precautions are not being taken. This year we have looked at data showing that many Joomla, Drupal, and WordPress based websites are not being updated in a timely manner, which leaves them at risk from vulnerabilities that have been fixed in subsequent releases. Companies involved with the development or maintenance of websites should be trying to do more to make sure that websites are kept up to date, but a couple of recent situations showed there are some companies out there trying to use people’s needs for updates as an opportunity to sell them unneeded work instead. Below we will take a look at those and provides some advice on preventing being taken advantage of in that type of situation.

Magento Doesn’t Require Incremental Upgrades

While recently discussing a Magento upgrade with a potential client they mentioned that they had tried a test of the upgrade that had had problems and that other companies that they had talked to had told them that the upgrade has to be done through a series of incremental upgrades to prevent that type of thing. That is, instead of going from their current version of 1.5 directly to 1.9 the website would need to be upgraded from 1.5 to 1.6 then to 1.7 then to 1.8 and finally to 1.9. When we heard that we were perplexed, not only are incremental upgrades not needed but in looking over lots of material on Magento upgrades (due to our having dealt with probably about everything that can go wrong with a Magento upgrade) we have never even seen doing that suggested. It also wouldn’t have had any impact on the problems they had. Doing those incremental upgrades was going to increase the cost of the upgrade, which seems to be why the companies would be claiming it was needed.

If incremental upgrades were needed you would expect it to be in the official upgrade documentation, which it isn’t. To better understand why that isn’t needed lets break down the upgrade. The upgrade involves changing two things:

The first is replacing the old Magento files with the new ones. If you directly upgrade to the new version or do incremental upgrades you will end up with the same files in use. The incremental upgrade might leave some left over files that are not used in the new version. So for this part of the upgrade the incremental approach adds nothing.

The second is updating the database to make it compatible with the new version of Magento. Magento will automatically make all the necessary updates from the version were running to the new version. So doing incremental upgrades would just split up the updates, but the end result would be the same updates running. We have never had any problem with database update caused by going directly from as far back as version 1.3.x to the latest version, 1.9.x. It is true to that sometimes servers have problems running through all the database updates, but there are better options for handling that then doing a bunch of incremental upgrades (doing the database portion of the upgrade on a separate server is very effective workaround provided you do this in your test of the upgrade first to insure it doesn’t cause any complications).

Websites Don’t Just Fail and You Can Upgrade Older Zen Cart Versions

The second situation was a lot more troubling. We were first contacted by a potential client about getting a quote for a Zen Cart upgrade and then they wanted quote to replace the store with a new Zen Cart installation. When we asked what was wrong that they needed a new Zen Cart installation they explained that another company had told them that their current Zen Cart installation “will fail and I will wake up one day and it will be gone” and they would need a whole new one. The idea that the website would just fail one day sounds quite scary, but it isn’t true. Websites don’t just fail like that. The only situation we could think of where something close to like that is if a web host upgrades to a newer versions of PHP then older versions of Zen Cart will stop functioning. That can prevented by upgrading to a newer version of Zen Cart. So why couldn’t they just upgrade? Well the other company was claiming that there Zen Cart installation was to old to upgrade. We have no idea why they would say that since the version in use, 1.3.9f, is much newer than versions we frequently do upgrades from. Either the other company, which portrayed themselves as Zen Cart specialists, didn’t have any idea what they are doing or they trying to trick people into unneeded work.

Protecting Yourself

There are two good options to make sure you don’t get taken advantage of in situations like this. First, when you are looking into having an upgrade done contact multiple companies to discuss what they would do in the situation. In these cases when the suggested unneeded work was brought up we were able to explain why it wasn’t needed. The second is to ask in the forum for the software if what the company is telling you is accurate. From what we have seen the information in those forums is generally accurate and in the type of situations we described we are sure someone would have explained that what is being said by the companies isn’t true.

Setting The Time Zone in Zen Cart 1.5.3

By default Zen Cart uses the time zone of the server the website is hosted on as the time zone for the store, which often isn’t the preferred time zone. In the past changing the time zone required modifying the server or using a module (either the Time Zone Offset module or the subsequent Time Zone Fix module). With Zen Cart 1.5.3 all you have to do to set the time zone is to add your preferred time zone in the file /includes/extra_configures/set_time_zone.php on the line:

$TZ = ” // eg: ‘Europe/Oslo’

For example, if you are in Sydney, Australia you would change it to:

$TZ = ‘Australia/Sydney’ // eg: ‘Europe/Oslo’

The full list of time zones values available can be found at http://www.php.net/manual/en/timezones.php.

If the setting has properly configured your preferred time zone will be shown at the top of the Zen Cart admin pages:

Zen Cart Admin Time Zone Displayed

For those currently using the Time Zone Fix module to set the time zone, you will need to switch to the new method when you upgrade to Zen Cart 1.5.3 as the module no longer functions in 1.5.3.

Outdated Software Running on Websites of WordPress and Other Web Software

When the makers of web software talk about security they always emphasize the importance of keeping software updated. One of the developers of WordPress said it this way “The only thing that I can promise will keep your blog secure today and in the future is upgrading.” Keeping software updated is good advice, but isn’t advice that the software makers, including WordPress, always follow themselves.

We recently mentioned a pretty egregious example of this from OpenX. Their blog, where they recently said it is critical to keep software up to date, is running a version of WordPress that is over three years out of date. Also, the main portion of their website appears to be running a version of Drupal that is over a year out of date.

MediaWiki, the software the powers the Wikipedia, is run on portions of many web software websites so we decided that it would be a good choice to see if software makers are keeping other people’s software running on their website up to date. There are several ways to check what version of MediaWiki is running and the easiest way to check for outdated MediaWiki installations is to use our Meta Generator Version Check web browser extension, available for Firefox and Chrome. The extension will show a warning icon when a web page has a meta generator tag from an outdated version of web software.

For those not familiar with MediaWiki they currently provide security updates for the two most recent releases 1.17.x and 1.18.x. The most recent version of those releases 1.17.2 and 1.18.1, both of which were released on January 11. We update our web browser extension a month after a new version is released, so until then it will check for MediaiWiki versions below 1.17.1.

Before mentioning the websites running outdated versions it is worth noting that one website we checked was actually up to date. TYPO3’s TYPO3Wiki is running 1.18.1.

WordPress

The WordPress Codex is the most out of date as it is running 1.15.5, which is two supported releases out of date. Support for 1.15.x ended in December of 2010.

Zen Cart

The Zen Cart Wiki is one supported release out of date and running a version, 1.16.2, that that is three minor updates out of date. Support for 1.16.x ended in late November of last year.

Joomla

Joomla! Documentation is one supported release out of date and running a version, 1.16.4, that that is one minor update out of date.

phpBB

The phpBB Development Wiki is at least running the most recent version of 1.16.x, 1.16.5, but that release is no longer supported.

Moodle

MoodleDocs is at least running a supported release, 1.17.x, but the version, 1.17.0, is two minor updates out of date.