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:

xhr.setRequestHeader(“X_FILENAME”, file.name);

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

xhr.setRequestHeader(“X-FILENAME”, file.name);

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 fdk-aac.zip https://github.com/mstorsjo/fdk-aac/zipball/master
unzip fdk-aac.zip
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
wget http://webm.googlecode.com/files/libvpx-v1.3.0.tar.bz2
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
wget http://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2
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	http://dev.gaiterjones.com/magento/media/catalog/product/m/a/magento-red-furniture-set.jpg	http://dev.gaiterjones.com/magento/magento-red-furniture-set.html	Living Room	Red
52	1112	Chair	http://dev.gaiterjones.com/magento/media/catalog/product/m/a/magento-red-furniture-set.jpg	http://dev.gaiterjones.com/magento/magento-red-furniture-set.html	Living Room	Red
53	1113	Couch	http://dev.gaiterjones.com/magento/media/catalog/product/m/a/magento-red-furniture-set.jpg	http://dev.gaiterjones.com/magento/magento-red-furniture-set.html	Living Room	Red
83	cn	CN Clogs Beach/Garden Clog	http://dev.gaiterjones.com/magento/media/catalog/product/c/n/cn-clogs-beach-garden-clog.jpg	http://dev.gaiterjones.com/magento/cn-clogs-beach-garden-clog.html	Mens	xxx
29	cn_3	CN Clogs Beach/Garden Clog	http://dev.gaiterjones.com/magento/media/catalog/product/c/n/cn-clogs-beach-garden-clog.jpg	http://dev.gaiterjones.com/magento/cn-clogs-beach-garden-clog.html	Mens	Blue
84	cn_4	CN Clogs Beach/Garden Clog	http://dev.gaiterjones.com/magento/media/catalog/product/c/n/cn-clogs-beach-garden-clog.jpg	http://dev.gaiterjones.com/magento/cn-clogs-beach-garden-clog.html	Mens	Blue
85	cn_5	CN Clogs Beach/Garden Clog	http://dev.gaiterjones.com/magento/media/catalog/product/c/n/cn-clogs-beach-garden-clog.jpg	http://dev.gaiterjones.com/magento/cn-clogs-beach-garden-clog.html	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.

Use GEOIP2 for PHP Geo IP data in WordPress, Magento, HTML

The above iFrame makes an ajax request to a PHP class querying GeoLite2 data created by MaxMind, available from http://www.maxmind.com.
This example displays the location of a single visitor i.e. YOU. Click here to see the logging data for this WordPress blog which demonstrates a PHP memcache data logging solution with geo ip visitor data displayed dynamically on a google map.

Magento SEPA Migration Check List

The Single Euro Payments Area (SEPA) is a payment-integration initiative of the European Union for simplification of bank transfers denominated in euro.

If you make or accept payments via direct bank transfers then you will know all about SEPA. As a customer online payment method direct bank transfers are popular in some countries (i.e. Germany) and not so popular in others (i.e the UK).

The deadline for SEPA payments was 1st February 2014 but (as of the time of writing) has been extended 6 months to 1st August 2014.

SEPA standardises bank transfers in Europe, replacing bank specific account and sort code numbers with an IBAN (International Bank Account Number) and BIC (Business Identifier Code).

For most businesses the migration to SEPA involves communicating the new changes to customers and migrating bank account numbers and sort codes to IBAN and BIC.

For Magento stores if you have a payment method that allows customers to pay via a direct bank transfer then you need to ensure that you can capture IBAN and BIC numbers at checkout. Until 1st August 2014 you can decide to give the customer the option of entering either bank account number and sort code or IBAN and BIC. From August 1st you *should* only be accepting IBAN and BIC.

Here is what you need to do to get your Magento Store ready for SEPA payments

  • Make sure you are capturing bank account information in the SEPA format – IBAN and BIC at checkout.
  • Check that your validation rules work for the IBAN and BIC formats.
  • Make a note to remove input fields and validation rules for old account formats, bank account number and sort code.
  • Upgrade your existing debit payment methods to make sure they support SEPA.
  • Implement a validation system for IBAN and BIC

This debit module is perfect for German Magento shops implengint Direc Debit (Lastschrift) payment methods and supports SEPA : https://github.com/therouv/Magento-DebitPayment

To validate IBAN account numbers with PHP take a look at https://code.google.com/p/php-iban/