That Matt » Web Apps

Upgrading to Magento 1.4.1.1 from 1.4.0

Matt — Sun, 26 Sep 2010 17:18:40 +0000

I recently had to upgrade an installation of magento 1.4.0 to version 1.4.1.1. As anybody who’s ever tried to upgrade magento will tell you, the upgrade path is usually less than ideal (For some people the only way to upgrade from 1.3 to 1.4 was to manually export / import their data into a new installation)

As strange as it seems, it appears the most reliable way to upgrade an installation is to install the new version over a copy of the old version’s database. (Note, you should never attempt to install over the production database lest things go wrong!)

Here’s a quick guide on how I managed to get the installation in question upgraded, hopefully it’ll work for you too!

Get rid of any coupon codes

If you try and upgrade magento without doing this then the installer will fail with a “foreign key constraint fails” error. You should make a note of your codes so that you can re-add them to your upgraded store.

Copy the database

In my experience the fastest way to get a copy of the database is to use the mysqldump command on the server over ssh.

mysqldump -u{username} -p {database_name} > production_backup.sql

Obviously you should replace {username} and {database_name} with their appropriate values. You’ll also be asked for the db user’s password when the program connects to the mysql server.

If you don’t have shell access on your server then you can always use another tool such as phpmyadmin, but it’s slower and less secure.

Download a fresh copy of Magento 1.4.1.1

We now need to download a fresh copy of magento and put it in a separate place from the production site (e.g. testing.{yoursite}.com) where we can run the upgrade safely. See the magento wiki for more info on downloading magento from a shell.

From now on I’ll refer to the directory you extracted the code to as the “upgrade test” directory.

You should also create a separate database to run the upgrade on.

Modify the Magento Installer

One of the big issues with the installer supplied with magento is that they assume all of the tables it tries to create don’t exist (which isn’t the case). To get around this we run a quick find & replace in the root of the new “upgrade test” magento installation:

find . \
    -type f -name "*.php" \
    -exec sed -r -i  \
    "s/CREATE TABLE \`?\{([^}]+)\}\`? \(/CREATE TABLE IF NOT EXISTS \`\{\1\}\` \(/g" \
    {} \;

If you’re not familiar with sed, this command basically looks in php files for the string “CREATE TABLE {table_name} (” and replaces it with “CREATE TABLE IF NOT EXISTS {table_name} (“. You should execute it in your upgrade test directory, not in the production site dir.

Run the installer

If you browse to your testing installation (i.e. http://testing.yoursite.com) you should be redirected to the magento web installer, which should allow you to “install” magento. When it asks you for a security / encryption key make sure you give the same key that your production install is using.

If you can’t remember what key your production install is using then have a look in app/etc/local.xml in your production installation. You should see something like:

In this example the key is fihfw9393rjW3493jwfwfj93jfww.

Chillax!

At this point you should hopefully have a fully functioning version of 1.4.1, sans custom theme / installed modules / product images. To migrate the product images remove the media dir and copy the one from your production installation over.

If something broke during the upgrade then you’ll need to find the cause of the problem and then re-attempt the upgrade afresh.

Config cache problems with Magento

Matt — Sun, 01 Aug 2010 19:18:00 +0000

After having numerous problems upgrading a Magento site 1.4.1.1 on a test server I decided to try and get it working locally before applying the fix(es) to the live server.

This is a fairly simple process and there’s lots of information on how to do it. The key steps in the process are emptying magento’s cache directory and updating the base urls in the core_config_data table so that magento will generate correct urls.

When I setup my copy of the site locally I changed local.xml & deleted the cache before modifying the db, just to make sure that magento was connecting ok. Once that was done I went off to delete the new cache files from siteroot/var/cache. Only, there weren’t any cache files. I took no note of it figuring magento had just decided not to cache the files and so proceeded to load the site, only for it to redirect me to the live site.

I spent the next few hours trying in vain to work out where magento was getting the idea that it should redirect to the main site. After wiping the db / files and re-extracting them several times I noticed that it was still redirecting even if the database was empty and the cache dir (var/cache) didn’t exist. Obviously this is one helluva wtf, especially as there weren’t any references to the live site’s address in the files. The opinion on IRC was that somehow my local site was talking to the production site’s db and was using it’s database instead of my local one, however this couldn’t be the case as magento started complaining if I dropped the local database entirely.

In a last ditch attempt I tried grepping for the site’s address across the entire filesystem (using grep -R “sitedomain.com” / ) and came across a load of files in /tmp/magento. After deleting the directory magento started working perfectly again, though it continued to store cache files in /tmp/magento rather than var/cache/ for some reason.

Can’t Install Drupal? Correct DB info yet no error?

Matt — Wed, 15 Jul 2009 21:33:20 +0000

The solution is to make sure that: a) You have a copy of default.settings.php in the sites directory to which you are installing drupal and b) Make sure the default directory still exists with its own copy of default.settings.php / … Continue reading →