That Matt

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.

Puppet: Retrieved certificate does not match private key

Matt — Sat, 07 Aug 2010 22:08:52 +0000

I’ve been playing around with puppet recently and while trying to start up a client and get it to talk to the server I ran into this error:

err: Could not request certificate: Retrieved certificate does not match private key; please remove certificate from server and regenerate it with the current key

Apparently the root cause of this error is that the client’s ssl certificates have been messed up.

To fix it you have to remove all of the client’s ssl stuff – cd into the directory containing all the ssl info – /etc/puppet/ssl for me running a manual install of puppet 2.6 – and remove all files, in all sub-directories, apart from ‘ca/serial’, which should contain 0000.

Then on the server revoke the client’s ssl certificate using:

sudo pupetca --clean {client hostname}

Then restart the client, resign it on the server and you’re good to go!

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 connect to remote mysql server with php/apache but can through php/cli

Matt — Wed, 07 Jul 2010 21:00:50 +0000

Today at work we were migrating some sites to a new server infrastructure with the different services (i.e. php, mysql, mail) spread over different servers.

One problem we ran into whilst setting this up was that php scripts running through apache were having trouble connecting to the mysql server.

What was even stranger though, was the fact that this problem only appeared when the php script(s) were run through apache – running them through the command line / shell worked absolutely fine.

After a couple of hours of debugging, head bashing and confusion we found the solution at the bottom of one of those very very long experts exchange threads.

It turns out that some linux distros has a neat little access control system called SELinux which was blocking communication by apache to remote database servers.

The aforementioned exchange thread suggests disabling SELinux entirely by executing

sudo setenforce 0

but this isn’t a permanent solution and won’t persist through a reboot without changing a config file.

This can be accomplished by changing a line in /etc/selinux/config. Change the line that says:
SELINUX=enforcing
to
SELINUX=disabled

However, if you’re willing to do a bit of digging there are SEL options you can change to grant apache access to remote database servers, and if you have a few hours to kill, there’s also the fedora documentation.

Hopefully this’ll save someone else the headache we had!

OSCommerce / Paypoint redirects to payment information after paying

Matt — Wed, 30 Jun 2010 19:52:05 +0000

I was asked to do some work on an oscommerce site which was accepting payments from paypoint (formally secpay) yet instead of redirecting the user to the “Thank you for your order” page it was sending them to the payment information page, and wasn’t classing the order as being paid for.

After a bit of debugging it turns out the problem stems from the paypoint-secpay merger and the fact that OSCommerce is a poorly supported hunk of junk.

During a typical transaction paypoint will ask the user for their card details, and if the details check out it sends a request back to OSCommerce telling it that the transaction was a success. It will then display to the user whatever your server outputs. Thus your customers should see the “Thank you for your order” page appear under a url of “https://www.secpay.com/java-bin/ValCard”.

When oscommerce receives the “the transaction succeeded” message from secpay it looks at the ip address the message came from, and tries to resolve it to a hostname to see if it came from secpay.com.

Since the merger the ip address that paypoint are using (in this case it was 81.93.226.30) doesn’t resolve to secpay.com, in fact it doesn’t resolve to anything. If php can’t resolve an ip address to a hostname then it gives up and returns the ip, thus oscommerce was trying to check that ‘secpay.com’ was the same as ’81.93.226.30′, which it isn’t.

To fix this I changed the before_process() method in the secpay payment module to look like so:

function before_process() {

      if ($_POST['valid'] == 'true') {
          if ($remote_addr = $_SERVER['REMOTE_ADDR']) {
	      // Check that the request came from one of the secpay / paypoint servers
    	      if (strpos($remote_addr, '81.93.226') !== 0) {
        	    tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, tep_session_name() . '=' . $HTTP_POST_VARS[tep_session_name()] . '&payment_error=' . $this->code, 'SSL', false, false));
          }
        } else {
          tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, tep_session_name() . '=' . $HTTP_POST_VARS[tep_session_name()] . '&payment_error=' . $this->code, 'SSL', false, false));
        }
      }
    }

Ignoring for a second the horrible use of php3/php4 conventions, the method now checks to see if the sender’s ip address begins with 81.93.226, as paypoint seem to own that range.

Hopefully this will save someone else the headache

Updated textarea maxlength with Jquery plugin

Matt — Thu, 08 Apr 2010 15:08:19 +0000

When I first wrote the “Textarea maxlength with jQuery” plugin last year I had no idea how popular it would be – over 70% of the visits to my site since then have been people reading that one post. The problem is, the code there is basically an ugly hack – you copy and paste and you’re done. But if you need to implement the same functionality across a site with slight differences to the functionality, you’d end up with a lot of copy and paste garbage. So what with it being time for some spring cleaning I thought I’d begin by refactoring the original code into a jquery plugin:

jQuery.fn.limitMaxlength = function(options){

	var settings = jQuery.extend({
		attribute: "maxlength",
		onLimit: function(){},
		onEdit: function(){}
	}, options);

	// Event handler to limit the textarea
	var onEdit = function(){
		var textarea = jQuery(this);
		var maxlength = parseInt(textarea.attr(settings.attribute));

		if(textarea.val().length > maxlength){
			textarea.val(textarea.val().substr(0, maxlength));

			// Call the onlimit handler within the scope of the textarea
			jQuery.proxy(settings.onLimit, this)();
		}

		// Call the onEdit handler within the scope of the textarea
		jQuery.proxy(settings.onEdit, this)(maxlength - textarea.val().length);
	}

	this.each(onEdit);

	return this.keyup(onEdit)
				.keydown(onEdit)
				.focus(onEdit)
				.live('input paste', onEdit);
}

And here’s an example of it in use, limiting all textareas in the document and updating a p element with the id of charsRemaining with… the number of characters remaining. It also sets the textarea bg color to red when the user tries to exceed the maxlength.

$(document).ready(function(){

	var onEditCallback = function(remaining){
		$(this).siblings('.charsRemaining').text("Characters remaining: " + remaining);

		if(remaining > 0){
			$(this).css('background-color', 'white');
		}
	}

	var onLimitCallback = function(){
		$(this).css('background-color', 'red');
	}

	$('textarea[maxlength]').limitMaxlength({
		onEdit: onEditCallback,
		onLimit: onLimitCallback
	});
});

And here’s a jsbin paste with a quick demo. Although there is a lot more code in this version it’s a lot more flexible as it allows you to decide how to inform the user of how many characters there’re remaining. It also means that it’ll take any characters already in the textbox into account when the document loads.

Update 2010/04/09: Fixed a few bugs & typos
Update 2010/08/01: Removed problematic comma & added live(‘input paste’) – thanks Surya and Len!

Testing Kohana3 with PHPUnit

Matt — Wed, 02 Dec 2009 21:39:51 +0000

Unit testing is great, period. It allows you to test different parts of your application independently of the rest of the system. Any changes that will cause problems elsewhere can be identified almost instantly (if you’re doing it right!).

Up until recently Kohana3 was using a home-grown module for unit testing – It was ok, but lacked some of the more advanced features of independent testing suites – however now the project has now adopted PHPUnit as its official test framework! PHPUnit is one of the more popular testing suites for PHP, it has full support for Fixtures, Mock Objects, Code Coverage and a lot of other cool stuff.

The module only requires a few changes to the bootstrap in order to integrate Kohana with PHPUnit, and afterwards you can run tests from the cli, IDE or our custom web runner. All available tests are loaded from Kohana’s cascading filesystem and can be filtered using PHPUnit’s –group switch.

Go and git it while it’s hot!

How to get Ubuntu to ping a Windows hostname (and vice-versa)

Matt — Wed, 02 Dec 2009 20:00:28 +0000

I’m currently running ubuntu server in a virtual machine on my pc, and one of the annoying problems I’ve always had with ubuntu is that it never seems to be able to resolve the hostnames of machines running windows.

After a little bit of digging I found a really simple solution in this forum topic

All you have to do is:
sudo nano /etc/nsswitch.conf
change the line that says
hosts: files dns
to this:
hosts: files wins dns
(order does matter)

finally, you need to install winbind
sudo apt-get install winbind

To enable windows to ping ubuntu you then need to install samba:

sudo apt-get install samba

Virtualbox – 1 differencing child hard disks

Matt — Sat, 07 Nov 2009 00:00:06 +0000

If you’re getting an error along the lines of “{hard disk} cannot be directly attached to the virtual machine because it has 1 differencing child hard disks”

Then the solution is to delete the virtual machine (but not the hard disk!) and then recreate the machine using the hard disk.

Stretch wallpaper across multiple monitors on Windows

Matt — Sun, 06 Sep 2009 17:35:12 +0000

When I first got a second monitor I looked around for quite a while to try and find a solution for stretching a wallpaper across dual monitors – Windows was repeating the first half of the wallpaper on both the monitors.

I eventually came across DisplayFusion which seemed to satisfy the bill – The free version allows you to stretch wallpapers across your monitors as well as drag maximised windows between screens (an incredibly useful feature).

If you buy the full version it can automatically cycle between pictures from a folder, flickr or VladStudio.com and it’ll also extend the start menu bar onto your other monitor(s).

I was fairly happy with using DisplayFusion to solve the problem, however it seemed odd to me that Microsoft didn’t include some kind of option in Windows to do this by default. It actually turns out they did – When you choose your wallpaper you have to set the “Position” option to “Tile”.

It’s kind of annoying seeing how simple a solution it is having spent quite a while looking for it!