Magento, Poodle and Paypal – Disable SSL v3 Before December 3rd


The so called Poodle security vulnerability was announced by Google last Month (October 14 2014).

The vulnerability effects SSL v3.0 a transport protocol which has been around for over 18 years and is used to secure various TCP/IP protocols the most common of which being HTTPS so it is present in a lot of client and server software.

The workaround fix to mitigate this vulnerability is to simply disable SSL v3 support and fallback (or upgrade) to using the newer TLS 1.x protocol.

The vulnerability seems to be a real cause for concern for a lot of companies especially Paypal who announced recently that the will disable SSL v3 support on the 3rd of December 2014.

How does this affect Magento

In respect to Paypal payments from your Magento store using either the Standard or the Express payment model Magento behaves like a client communicating with the Paypal API over SSL to complete the Payment / Checkout transaction.

When Paypal removes support for SSL v3 your Magento store will no longer be able to communicate with Paypal unless you disable the support for SSL v3.0

Simply put this means you will not be able to process any orders with the Paypal payment system. Not the best news at this time of year when many businesses are in the middle of their busiest time of year on the run up to Christmas.

HOW TO Fix Poodle for MAgento

Fortunately the fix is pretty straight forward and actually doesn’t really have anything to do with Magento at all but rather the configuration of your web server software on your Magento host.

First you need to determine if the host your Magento shop is running on is using the SSL v3 protocol.

If you have command line access to your host, login and run nmap with the following command :

nmap –script ssl-enum-ciphers -p 443 localhost

If your host is NOT vulnerable you will see

SSLv3: No supported ciphers found
If you don’t have command line access run an external scan from a reputable  site such as Symantec, The scan should clearly show you if your server supports SSL v3 or not.

How to Disable SSL v3 on Ubuntu Server

To upgrade to TLS 1.x and disable SSL v3 support on Ubuntu server, and many other servers running Apache locate the configuration file responsible for defining the SSL protocols supported by Apache. On Ubuntu it is
You can search for it with this grep command:
grep -i -r “SSLProtocol” /etc/apache2
Edit the file, find the SSLProtocol line and change it to
SSLProtocol all -SSLv2 -SSLv3
Restart Apache (service apache2 restart) and SSL v3 will be disabled.
Confirm this by running the scans again.

How to test Paypal

The best way to prepare for Paypal disabling SSL v3 is to test your Dev Magento install against the Paypal Sandbox site –

For peace of mind you should do this before December 3rd 2014.

Another simple test is to just do a simple PHP curl request to the Paypal sandbox servers. You can try this with a simple PHP script. Create a file paypal-tls-test.php in the root folder of your Magento shop and paste the following script into it.

$url = “ssl://”;
$fp = fsockopen ($url, 443);
if (is_resource ($fp)) {
echo “not affected”;
else {
echo “affected”;

Run the script from your store –

If you receive the not affected response, then your host was able to talk to Paypal using TLS and you should also be able to process Paypal payments from Magento.

If you don’t have a dev server this might be the easiest way to test Paypal access from your Live server unless you are prepared to take the shop offline and configure the Paypal payment modules to use the Sandbox.

If you do not have access to the command line you need to talk to your hosting provider ASAP!

A lot of people (like me) may be reacting to this news a bit late but applying these simple changes should avoid any pre Christmas Poodle related Paypal headaches next week.



Cannot Send PHP Mail after Ubuntu Upgrade

I recently made a list of problems experienced after upgrading from Ubuntu 12.04 LTS to Ubuntu 14.04.1 LTS, an additional problem that finally came to light about a week later was that mail sent from php scripts using the php mail() function stopped working.

php mail() returns FALSE

My Ubuntu mail setup uses sendmail with exim4. After the upgrade I was occasionally seeing the following exim4 error

2014-10-29 08:00:50 unable to set gid=33 or uid=0 (euid=0): forcing real = effective

Normal email was working fine and php mail from the command line, or cron jobs was also working fine. It was only email sent via web sites i.e. with online forms using the php mail command i.e.

$mail=\mail($email, $subject, $message);

$mail would always return FALSE, and an exim4 error would be logged.

The exim error points to a permissions problem with the Apache user group – www-data in Ubuntu. Group ID 33 is www-data.

After googling around for a while and looking at various configuration options in php.ini the resolution lay with the Apache ITK MPM module.

It seems that a default configuration in this module with Apache 2.7 has some kind of influence on the permissions associated with the www-data user/group when communicating with exim4.

The fix is to explicitly define the ITK MPM module LimitGIDRange parameter in the /etc/apache2/mods-available/mpm_prefork.conf module configuration to something like

LimitUIDRange 0 2000

Restart Apache and Exim 4 and PHP mail via Apache works again.


Upgrading Ubuntu Server 12.04 LTS to 14.04.01 LTS

Back in July I was ranting about the new Facebook API that requires PHP 5.4 or later.

My main production server was running Ubuntu 12.04 LTS with PHP 5.3, and although the 14.04 LTS had been released it wasn’t available as a release upgrade until the 14.04.01 release was out, so I was waiting for that before I would even think about upgrading.

So the release upgrade to Ubuntu 14.04.01 LTS has been available for a while and I was putting off the upgrade until I had some time to test it on a development server which I did and everything seemed to go ok. I did however make a major mistake in that I upgraded my dev vmware server and assumed that just because the upgrade worked, everything else worked and went ahead with my production server upgrade.


I love Ubuntu and have been using it since Hardy Heron (8.04) so far my experiences with upgrading Ubuntu Server have been pretty good, as long as I stick with the LTS versions, minor and major upgrades haven’t caused me any major heartaches.

Simply run do-release-upgrade from the console, make a coffee and put your feet up.

UBUNTU 14.04.01 LTS Trusty THAR

As I mentioned my main goal of upgrading was to upgrade PHP, Ubuntu 14.04.01 upgrades my most crucial apps to:

PHP : 5.5.9
MySQL : 5.5.40
Apache : 2.4.7
Memcache : 3.0.8
The main show stopping issues I faced were with the Apache upgrade to 2.4.7. So here are the issues that caused me the most downtime and how to resolve them.

APACHE 2.4.7 Errors


As the upgrade finishes one of the last packages to install in Apache and you will quite possible see that apache fails to start after the upgrade.

This is quite likely to be due to older configurations lurking in your Apache config files, for me there was an error in ports.conf where I had an old virtual hosts statement : NameVirtualHost *:443 which is no longer supported.

I removed the NameVirtualHost statements (ports.conf just requires a Listen statement).

After editing ports.conf apache started ok.

Forbidden You don’t have permission to access / on this server. Apache/2.4.7 (Ubuntu) Server at localhost Port 80

I eagerly tried to load a website on the server and got the above error, in fact all my websites were down.

It took a while to track down the causes of this error but the main cause of the problem I think is that my apache2.conf file was overwritten by the upgrade even though I am sure I was asked to keep my original files by the installer.

My default WWW folder is not in the default /var/www and this was the cause of the first problem. Edit apache.conf and add the directory configuration for your default WWW parent folder. Reload apache and…

No websites work.


Apache 2.4.7 requires all apache site config files to have a .conf extension. As the release notes nicely point out all files without a .conf extension are silently ignored.

I am not sure why my site config files never had a .conf extension, I guess either I picked up a bad habit or thats just the way most people create them. Basically all my site config files were being ignored so I still had no websites.

To resolve this obviously rename the files so they have a .conf extension and then add the sites again with a2ensite config.conf and reload apache.

No websites work.

The final problem I had was that access control commands have changed in apache 2.4.7 instead of

Order allow,deny
Allow from all

You should use

Require all granted

Another thing that might also catch you out is that the options statement cannot be mixed with + or – indicators

Options -Indexes Multiviews FollowSymLinks


Will NOT work. Either all options must have a plus minus enabler or none should have one, so use Options -Indexes +Multiviews +FollowSymLinks  instead.

If you have a lot of sites enabled, be prepared for this to take a while as you rename and edit each site file, save it, re-add the site to apache and reload the apache config.

Eventually after going through all my site configs, my websites slowly came back online.



Unfortunately that wasn’t the end of my troubles, two main issues came out of the PHP upgrade.

PHP.INI overwritten

Like the Apache conf my php.ini files were also (I think) overwritten and I am not entirely sure why. The main issue from this for me was that my error settings had changed so I was now seeing STRICT and DEPRECATED errors that I was safely ignoring before.

My PHP cron jobs were also failing due to a similar configuration error in the PHP-CLI ini file.


Another problem I noted was that php-mcrypt was not enabled and I was seeing fatal error Call to undefined function mcrypt_decrypt() – even though  php5-mcrypt was installed.

To resolve this problem (which is probably also associated with the config problems) re-enable the mcrypt module with php5enmod mcrypt and restart Apache.

HTTP custom headers

Finally another error related to Apache is that custom HTTP headers cannot contain the underscore character any more. Apache will silently ignore them and they will not appear in the PHP SERVER array.

This was affecting all my XHR javascript file uploads due to a filename being set with a custom header using underscores:


Fortunately the work around is to simply replace the underscore with a minus


Interestingly on the server side you still see the header as HTTP_X_FILENAME so your server side PHP code does not need to change, but any client side code creating custom headers cannot use underscores in the header name.


The next day, as system tasks started running I saw this error

error: skipping “/var/log/mysql.log” because parent directory has insecure permissions

This is resolved by editing /etc/logrotate.conf and adding the following to the configuration

# use the syslog group by default, since this is the owning group
# of /var/log/syslog.
su root syslog

Lessons Learned

What can we learn from this, firstly always, always, always have backups. My whole system was backed up so simply restoring back to 12.04 LTS was a last result option.

Don’t try to fix it if it isn’t broken. Did my server really need to be upgraded? Yes I think so, although 12.04 is supported until 2017 I needed PHP 5.4+ and I Would have been faced with these upgrade issues at some point anyway.

Read the release notes. Yeah right. I guess I could have read the Apache release notes but no one really does that in the real world.

Better testing. I thought I had tested the upgrade but my dev server did not properly mirror my production server so I was unable to test everything.

Fresh install instead of upgrade. I would never consider doing this on an older LTS. Build a new server with a fresh install of LTS and migrate your production sites and software over to it.


Magento 1.9.x is running without issues after the upgrade

WordPress is running without issues

SMF is running without issues

MYSQL (apart from the fact that it is deprecated) is running without issues

memcached is running without issues

dropbox is running without issues

exim4 and spam assasin (mail) is running without issues

shoutcast and darwin media server are running without issues


Installing / Compiling FFMPEG for Ubuntu 14.04 LTS

There are currently no official repositories for an APT install of FFMPEG on Ubuntu, but If you are upgrading to or installing Ubuntu 14.04 LTS and want to recompile or install FFMPEG the process is very straight forward and takes about 10 to 20 minutes depending on your setup.

You can find the latest installation instructions here

Here are the steps I took to upgrade an existing ffmpeg installation after upgrading from Ubuntu Server 12.04 LTS to 14.04.01 LTS


sudo apt-get update
sudo apt-get -y install autoconf automake build-essential libass-dev libfreetype6-dev libgpac-dev \
  libsdl1.2-dev libtheora-dev libtool libva-dev libvdpau-dev libvorbis-dev libx11-dev \
  libxext-dev libxfixes-dev pkg-config texi2html zlib1g-dev
mkdir ~/ffmpeg_sources

sudo apt-get install yams

sudo apt-get install libx264-dev

sudo apt-get install unzip
cd ~/ffmpeg_sources
wget -O
cd mstorsjo-fdk-aac*
autoreconf -fiv
./configure --prefix="$HOME/ffmpeg_build" --disable-shared
make install
make distclean

sudo apt-get install libmp3lame-dev

sudo apt-get install libopus-dev

cd ~/ffmpeg_sources
tar xjvf libvpx-v1.3.0.tar.bz2
cd libvpx-v1.3.0
PATH="$PATH:$HOME/bin" ./configure --prefix="$HOME/ffmpeg_build" --disable-examples
PATH="$PATH:$HOME/bin" make
make install
make clean

cd ~/ffmpeg_sources
tar xjvf ffmpeg-snapshot.tar.bz2
cd ffmpeg
PATH="$PATH:$HOME/bin" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure \
  --prefix="$HOME/ffmpeg_build" \
  --extra-cflags="-I$HOME/ffmpeg_build/include" \
  --extra-ldflags="-L$HOME/ffmpeg_build/lib" \
  --bindir="$HOME/bin" \
  --enable-gpl \
  --enable-libass \
  --enable-libfdk-aac \
  --enable-libfreetype \
  --enable-libmp3lame \
  --enable-libopus \
  --enable-libtheora \
  --enable-libvorbis \
  --enable-libvpx \
  --enable-libx264 \
PATH="$PATH:$HOME/bin" make
make install
make distclean
hash -r

cp ~/bin/ffmpeg /usr/bin/

After compilation FFMPEG version is

ffmpeg version git-2014-01-21-91f4394 Copyright (c) 2000-2014 the FFmpeg developers
built on Oct 22 2014 03:13:56 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)

Magento Product Attribute Search and Filter

Magento Product Attribute Advanced Search and FilterThe Magento product database is pretty flexible when it comes to extracting product information. Sometimes however, extracting all the information you want for a product is not so easy.

For example you want to extract the main product info, price, title, SKU etc and all the product attributes names and the product category. This might require multiple product / collection calls and when you multiply this by a search across 1000’s of products can become slow.

Magento Product Attribute Search and Filter

I wanted to provide a quick and easy way to search and filter magento products by attributes, in this case by colour, so customers could quickly narrow product selection down by selecting a colour and a filtering by category.

To extract the data I developed my Magento Product Data and Attribute exporter. This let me initially see how many attributes I had to work with, in this case how many different product colours were already configured.

To make colour selection simpler I created a new Magento attribute product_primary_colour and added a primary colour to each product so that I ended up with about 16 main colours that would provide a match to all the existing product attribute colours.

Once I had all my exported product data in a tab delimited text file I quickly realised that it would be relatively simple to search and filter this data via ajax requests.

I had initially thought it would be more effective to do the search within Magento using product collections but the speed of the search against the delimited txt data file made me think again. When I then added cached search results using Memcache I was happy that this solution would work.

The benefits of using the flat txt file are that it is quick and can run completely external from Magento in another webapp or in WordPress or Facebook.

The Magento attribute search and filter is easily customiseable and can search the data created by the export script filtering results from any of the product data columns in the export file. This could be colour, size, type etc, there are no limits.

If your product data is changing regularly simply export the data regularly via a cron job to keep it up to date.

if you need to filter your data by a completely new attribute simply pull the export data into Excel, create your new attribute data and corresponding Magento attribute and import the data back into Magento. Now you can export this data and easily search and filter it.

Here is an example of the attribute search running in an iframe using the Magento test product data. Here I have exported the color attribute, and am filtering against existing product categories like Womens, Mens and Shirts (note Mens matches Womens, some refinement needed there!). This will also easily run in Magento when setup in a static block containing the iframe data.

You can see how quickly the data is filtered and returned, try a search for Red to see some data. Click around the categories and check the debug footer which shows if the results were cached or not and how long the ajax query took to run.

Data from Magento DEV Store running Magento 1.9.x

Magento Product Data and Attribute Exporter

Export Magento Product and Attribute DataOver the last few years I have developed a few different PHP scripts to export Magento product data in order to manipulate product pricing, generate Magento  EAN barcodes or create product import data.

Recently I had to export Magento product data to be used as import data for Amazon product listings. Specifically the products had a lot of different attributes associated with them and I wanted to export each product with all of its associated attribute data to map to the relevant Amazon product data.

To accomplish this I returned to my previous code and enhanced it to be able to export user defined Magento product and attribute data to a delimited text file (as well as creating product EAN barcodes which was a function of the original script.)

The script can extract the usual global product data e.g. price, description etc. as well as any custom product attributes.

The export data is configured in an array;

‘name’ => true,
‘description’ => false,
‘imageurl’ => true,
‘producturl’ => true,
‘type’ => false,
‘ean’ => false,
‘category’ => true

We set the array key value to true or false for the product data we want to export. The same applies to attribute data:

‘colour1′ => ‘color’,
‘custom’ => ‘my_custom_attribute’

So here we are exporting the color product attribute as well as a custom attribute.

The tab delimited data is easily imported into Excel for manipulation and further import/export, for example adaption to an Excel format compatible with Amazon product imports.

This data can also become really useful if you want to provide fast external access to your product info for example, in an external app, on Facebook or even within Magento. See my product attribute search app for more information.

You can download the source code for this export script from my Github.

To run the script copy the files to your server and edit the configuration php file config/applicationConfig.php. Configure the paths to your Magento installation and the folder to export to.

Configure the product arrays by editing php/Application.php, edit $_getProductData and $_getProductAttributes.

To run the script execute it with php export.php debug from the command line. To run silently from a cron job leave the debug switch out.

You can also run the script from your web browser if you install it in a web accessible folder.

Here is an example of the output from my Magento dev store ::

id	sku	name	imageurl	producturl	category	colour1
51	1111	Ottoman	Living Room	Red
52	1112	Chair	Living Room	Red
53	1113	Couch	Living Room	Red
83	cn	CN Clogs Beach/Garden Clog	Mens	xxx
29	cn_3	CN Clogs Beach/Garden Clog	Mens	Blue
84	cn_4	CN Clogs Beach/Garden Clog	Mens	Blue
85	cn_5	CN Clogs Beach/Garden Clog	Mens	Blue


Facebook API v2.0 Ubuntu PHP 5.4 #fail

Facebook #fail, I do not like thisSo I finally caught on to the fact that Facebook released version 2.0 of their API at the end of April (to coincide with the F8 developer conference.) and will discontinue pre v2.0 API calls in April 2015.

I thought I had better take a look as I support a number of PHP apps that run on Facebook or integrate with Facebook for login/authentication etc.

v2.0 of the Facebook API has been completely rewritten from the fairly basic previous API code that I had been using, there are a lot of changes including new login features and permissions.

‘This is great’, I thought…

Facebook PHP API v2.0 requires PHP v5.4

However there is a problem that will cause a whole lot of people a whole lot of problems. The new PHP SDK for v2.0 of the API requires PHP v5.4.

if (version_compare(PHP_VERSION, '5.4.0', '<')) {
 throw new Exception('The Facebook SDK v4 requires PHP version 5.4 or higher.');

My main production server runs the latest (as of the time of writing) LTS of Ubuntu v12.04, it’s up to date but a quick php -v from the command line reveals

PHP 5.3.10-1ubuntu3.13

The 14.04 LTS is not available to apt until the first point release which I think is any day now. 14.04 LTS will include PHP 5.5, but I’m not really planning on upgrading my live server straight away, 12.04 LTS is supported up to 2018 – that’s what Long Term Support means.

I currently work with live production Ubuntu servers ranging from v8 to 12 that I would not even dream of trying to upgrade.

Bearing in mind that a whole lot of people won’t even be running an Ubuntu version above 12 on their production servers getting to PHP 5.4 is going to present them with a considerable upgrade challenge.

You are going to have to be pretty brave to manually upgrade PHP, and if you do it without proper testing then you are also going to have to be particularly stupid.

Upgrading PHP without testing is going to break applications that are running PHP code that has been deprecated, older versions of Magento spring to mind, not to mention the problem people who are on a virtual or shared hosted systems where they have absolutely no control of the version of PHP running on their server.

Facebook #fail

So it looks like it’s a real #fail from Facebook to implement a PHP SDK totally dependent on a PHP version that a lot of people are not running and possibly cannot run.

What does this mean for your existing Facebook apps?

  • For apps that existed before April 30th 2014, making an API call without specifying a version number (‘unversioned’) is equivalent to making a call to the v1.0 of the API.
  • For apps created on or after April 30th 2014, making an API call without a specifing a version number is equivalent to making a call to v2.0 of the API.
  • Apps that were inactive or have a creation date on or after April 30th, 2014 will not be able to make calls to v1.0 of the API. They must use v2.0.

This means your existing pre April 30th 2014 apps will be allowed to still make pre v2.0 api calls until April 30th 2015 after that they will stop working.

  • If you want to create a new Facebook App you have to use the v2.0 API.
  • Inactive apps will no longer work. (define inactive please Facebook.)
  • if you want to create a new Facebook App you need to upgrade to PHP 5.4 or for Ubuntu admins be running the latest LTS (14.04).
  • if you have code on Envato using the old API it will be removed in August 2014 – goodbye to my Magento Facebook storefront!

Man this sucks

I think this really sucks, especially if you are authenticating users via Facebook login if you don’t do anything your users will not be able to login to your website after April 30th 2015. I am kinda glad I didn’t implement that Facebook login feature on our eCommerce site now…

if your eCommerce site is running on shared hosting, or does not support PHP5.4 (i.e. Magento 1.3x) then you are pretty well stuffed I think.

The new API has a learning curve for devs too and I am already coming to this pretty late so I guess I better look at what options I have and what apps are going to stop working next year if I do nothing, or am unable to get my code and server to PHP 5.4 by then.

Having said all this I would bet my bottom dollar that Facebook change these deadlines and extends the v1.0 API support beyond 2015 – watch this space…

Because I am now depressed I am going to include a funny picture to cheer me up.








How to move the Dropbox cache folder

DropboxHow to move the Dropbox cache folder

Dropbox is extremely useful, it can be used in many different ways to allow distributed sharing of files between various systems, Windows, Mac, Unix, IOS devices. The list of ways to use Dropbox are endless.

I use one dropbox account to backup SQL backups from various systems on a Windows 2003 server however I noticed today the disk dropbox was installed on had ran out of disk space and the problem was the Dropbox cache folder.

Dropbox Cache Folder too large?

The Dropbox cache folder is a hidden folder within the Dropbox folder which caches older versions of Dropbox files. The cache contents are cleaned out every few days by Dropbox but the cache files still seem to have the ability to grow very large, very quickly – my cache folder was 20GB, which on a relatively older 250GB disk was a large percentage of the free disk space.

Whilst this may not be a problem on some desktop PC’s or Laptops if you have Dropbox installed on a server with limited disk capacity you might find yourself running low on disk space. Even worse, if you installed Dropbox on a relatively small system partition, your system will grind to a halt.

You can manually delete the cache folders, but you will see that they very quickly reappear and start to grow in size.

Move Dropbox cache folder to an external drive

The solution is to move the Dropbox cache folder (NOT the data folder) to an external drive.

Unix users will be familiar with symbolic links which allow you to link a virtual file or folder to a target file or folder. This is possible on newer versions of Windows with the Mklink command, and on older versions of Windows Server with the Junction command.

To move my Dropbox cache folder on Windows 2003 to an external usb drive, I used junction with the following command:

junction “d:\DATA\Dropbox\.dropbox.cache” “g:\EXTERNAL\dropbox-cache”

with Mklink on Windows 7/8 the command would be

mklink /d /h  “d:\DATA\Dropbox\.dropbox.cache” “g:\EXTERNAL\dropbox-cache”

The external drive is large so the Dropbox cache folder can grow there without any problems.



Upgrade Magento 1.8 to 1.9

Magento Upgrade

Magento CE 1.9 has been released. It appears to be a relatively small update introducing a new responsive GUI. See the release notes here.

Here are my notes after upgrading my dev store from 1.8.x to 1.9 using the command line.

Backup existing install folder and database

1. Magento source
tar -cvvf /home/backup/magento.tar /home/www/magentoinstallfolder/

2. Magento DB
/usr/bin/mysqldump -h localhost -u USER -pPASS magento | gzip > ~/backup/folder/db-magento.sql.gz

1. Remove cached files and temp files

rm -rf downloader/pearlib/cache/*
rm -rf downloader/pearlib/download/*
rm -rf downloader/var/cache/*
rm -rf downloader/var/report/*
rm -rf downloader/var/tmp/*
rm -rf media/catalog/product/cache/*
rm -rf media/tmp/*
rm -rf var/cache/*
rm -rf var/session/*

2. Restart memcached (if being used)

3. Sync mage

./mage mage-setup

./mage sync

4, Run upgrade

./mage upgrade-all

5. Reset ownership and permissions on all files and folders.

Check Magento is operational, login and refresh caches.

If all is well take a well deserved break and maybe eat a cream cake. If all is not well restore from backup…



Google Universal Analytics Update for Magento Version v.1.3.X Old Versions


Google Universal Analytics went out of BETA recently (May 2014) and is now available for all users. Universal Analytics has “more features, better insights”.

All versions of Magento include the client side analytics code which can be enabled in Magento Admin. When enabled Magento creates the client side html and javascript and appends it to the footer section of each page.

On the checkout completion page additional code is created to track sales.

Google Univeral Analytics Magento

Google Universal Analytics uses new client side javascript code, this means Magento does not yet support Google Universal Analytics by default, however it is relatively easy (if you are using new versions of Magento) to override the base/default Magento code that creates the client side analytics html and javascript.

If you simply turn off the built in Magento analytics feature and add the new Google Universal Analytics code to your page templates (as Google suggests you do) then you will lose all eCommerce tracking.

You can update your Magento core code to support Google Universal Analytics using the information below.

New Versions > 1.4.x

If you are using a newer version of Magento i.e. > 1.4.1.x you can update the core analytics functionality following the guidelines here.

Old Versions < 1.4.x

if you are using an older version of Magento (before 1.4.1) i.e. Magento 1.3.x, I have adapted the Magento v1.3.x google analytics core module code to support Google Universal Analytics. The code can be installed as a local module and will override the core module.

Download the code from my GitHub

To install the module copy the files to your Magento app folder, refresh your Magento configuration and configure the settings under Configuration -> Google API -> Google Analytics.

To view the analytics code look at the source code of any page, scroll to the bottom and look for the code between the Google Universal Analytics Code comment tags. For order tracking information, check the code on the Checkout/Success page.