Preparations

First of all, backup your production site and create a staging environment. After setting the new database connection in app/etc/local.xml, manually change the website urls in the database:

UPDATE
   `core_config_data`
SET
   `value` = REPLACE(`value`, "//www.yourwebsite.com", "//staging.yourwebsite.com");

Now login to the new staging Admin panel and disable all cache under Cache Management and delete the var/cache and var/session folders in your root directory. It is important to clean up and reduce the size of the database before we start the upgrade process, since large databases take forever to upgrade and corrupt databases can cause headaches when debugging.

If you have the Magento Compiler enabled, run the following commands to remove all compiled files and to disable the include path.

$ php shell/compiler.php disable
$ php shell/compiler.php clear

Make sure that the staging website maintains all proper file and folder permissions. If this is not the case you can reset them by following this guide.

Cleanup the database

Since Magento logs alot, let’s clean up a bit first.  Enter the following command to view how much data Magento has been logging until now.

$ shell/log.php status

This displays the size of the `log_` and `report_` tables. If you haven’t enabled Log Cleaning in the Magento Admin (System > Configuration > System > Log Cleaning), this can quickly grow to a couple of hundred MB or maybe some GB’s!
You can manually cleanup these tables by running this command:

$ shell/log.php clean

However there are more tables that can be emptied. You can safely run this query:

TRUNCATE `catalog_compare_item`;
TRUNCATE `dataflow_batch_export`;
TRUNCATE `dataflow_batch_import`;
TRUNCATE `log_customer`;
TRUNCATE `log_quote`;
TRUNCATE `log_summary`;
TRUNCATE `log_summary_type`;
TRUNCATE `log_url`;
TRUNCATE `log_url_info`;
TRUNCATE `log_visitor`;
TRUNCATE `log_visitor_info`;
TRUNCATE `log_visitor_online`;
TRUNCATE `report_viewed_product_index`;
TRUNCATE `report_compared_product_index`;
TRUNCATE `report_event`;
TRUNCATE `sales_flat_quote_item`;

You could also truncate the `core_url_rewrite` table, which can grow pretty large too if you have alot of products and websites/stores-views. Attention: When emptying this you will lose all old url redirects for products, categories, cms pages, etc, but it greatly increases the speed of the upgrade process. Of course it is safe to do this when the website is not yet in production in the first place.

This should leave us with a pretty slimmed down version of the database.

Now reindex the database to be sure

$ php shell/indexer.php reindexall

Clear cache again if Magento somehow managed to create some (you can’t do this enough! )

$ rm -rf var/cache var/session

Important reminder: do not access the staging website in your browser! As this will initiate the upgrade process too early

Fix corrupt database (don’t skip this step!!)

Check for corrupt structure

It’s possible that the database structure has been changed after the moment is was installed, due to plugins or custom code. Magento has released a tool that can fix corrupted databases: The Magento Database repair tool. It adds missing table columns, foreign keys and indexes. Download the php script and upload it to the root of your staging website. Now create a fresh install of Magento of the same version as your current shop, so we can compare it’s database-structure with our staging database.

Run the tool and see if it makes some changes. If an error occurs, just run the tool again until it says there is nothing more to change.

Check for corrupt data

Besides the structure of tables, it’s also possible that some data is corrupted. I’ve had cases that duplicate order records existed that messed up the upgrade process. Run this query to find out whether there are duplicate records and delete them.

SELECT `increment_id` FROM `sales_flat_order` GROUP BY `increment_id` HAVING COUNT(*)>1;
SELECT `increment_id` FROM `sales_flat_order_grid` GROUP BY `increment_id` HAVING COUNT(*)>1;

More info on this can be found in this thread.

Personally I’ve never had other tables that contained duplicate records.

Upgrade the Magento core files

As mentioned earlier, if you are running Magento 1.4.1.x or lower you need to upgrade to 1.4.2 first.

$ chmod -R 777 lib/PEAR
$ ./pear mage-setup
$ ./pear upgrade -f magento-core/Mage_All_latest-stable
$ chmod 550 ./mage
$ ./mage mage-setup
$ ./mage sync

If pear displays errors, if may have to be upgraded.

$ ./pear channel-update pear.php.net
$ ./pear upgrade --force PEAR

Repeat this step if it shows any errors

The following steps apply to all versions of Magento (1.4.2 and higher) that want to upgrade to the latest stable version (currently 1.7.0.2). Reminder: unfortunately it’s not possible to upgrade to a version other than the latest release. If you really need this, you need to manually download the specific version of Magento and connect the older database to initiate the upgrade process.

View which packages can be upgraded

$ ./mage list-upgrades

Configure Magento to upgrade to the latest stable version, as we do not want a bèta version. (Bèta state is default!)

$ ./mage config-set preferred_state stable

Upgrade all packages! This will also upgrade any plugin installed via SSH if possible. Magento will replace all php files in the app/code/core and in the app/design/base/default map
Custom theme files and php files from app/code/local remain untouched!

$ ./mage upgrade-all --force

The filesystem has now been fully upgraded.

Upgrade the database

Since all package files on the server have been upgraded. Magento will check for version changes when a page is loaded in the browser. All packages will execute the upgrade php scripts which change the database structure. Now open the staging website in your browser and Magento will start the upgrade. You can monitor this progress via SSH:

$ mysql -h YOUR_DB_HOST -u YOUR_DB_USER -D YOUR_DB_NAME -p

> SHOW FULL PROCESSLIST;

Depending on your database size, this process can be ready in a few minutes or can take up a few hours. I usually like to refresh the processlist every 10 minutes to see what Magento is up to. If anything goes wrong, you’ll at least know where to look . It is important not to open the site in another browser during the process, so be sure that no-one else does too.

When the process is finished (no more activity in the mysql processlist), close the browser and clear cache.

$ rm -rf var/cache var/session

Finishing up

To be sure the database upgrade was succesful, run the Magento Database Repair tool again. Now you’ll need a fresh database of the latest Magento version to compare against, so create this first.
If the upgrade went ok, the tool shouldn’t find any differences.

The last step is to reindex everything again!

$ php shell/indexer.php reindexall

The upgrade is now complete! You can safely open the website in the browser and see if everything still works. Remember: All errors are almost always related to corrupt database structure, custom theme files, incompatible plugins or custom code (app/code/community and app/code/local).

In order for Internet Explorer to open documents in Office (or any out-of-process, ActiveX document server), Internet Explorer must save the file to the local cache directory and ask the associated application to load the file by using IPersistFile::Load. If the file is not stored to disk, this operation fails.

When Internet Explorer communicates with a secure Web site through SSL, Internet Explorer enforces any no-cache request. If the header or headers are present, Internet Explorer does not cache the file. Consequently, Office cannot open the file.

This means that IE should always be forced to cache the file before opening. In PHP this is achieved by sending the following HTTP headers,:

// Do not use header("Pragma: no-cache");
header("Pragma: private");
// Do not use header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
header("Cache-Control: cache");

Not everyone is happy with this new feature. Here is the way to disable it for project:

Open functions.php and add:

// Disable admin-bar from showing on your blog
wp_deregister_script('admin-bar');
wp_deregister_style('admin-bar');
remove_action('wp_footer','wp_admin_bar_render',1000);

Example:

textarea {
	resize: none;
}

I know this can be an usability thing for Chrome and Firefox users, but I think when you make your textarea large enough there should be no problem at all.

Facebook Login (previously Connect)

This method is used by external websites, offering their visitors an easy method of registration and login, using their Facebook account. As shown in the example code provided with the SDK, we first create an instance of the facebook class, which we use to retreive a session.

We will not find a session in two cases:

1. The visitor has not authorised the website in the past
2. The method getSession() cannot find the signed_request or session variable in the $_COOKIE or $_REQUEST variables

To be sure that the visitor has not authorised your application in the past, we transfer the visitor to Facebook using the method getLoginStatusUrl(). This will header the visitor to Facebook, which in turn headers the visitor back to the referring URL including a $_REQUEST['session'] variable, if the visitor has indeed authorised in the past. Be sure to build in a check to only check this once a session, otherwise this will result in a loop if the user is unknown.

Canvas

When using Facebook Canvas (a website iframed within Facebook), the requested page within the iframe is always provided a signed_request which the SDK uses to build a “session”. This means that we always know whether the visitor is an authorised user or not, making the  getLoginStatusUrl() superfluous. If we can’t find a session (getSession()), or we can’t find “/me“, the user has not authorised and we need to present the authorisation button.

The following graphic depicts the flow for both cases:

Of course, the above can also be established with the Javascript SDK, but a little dedudancy won’t do any harm. And the getLoginStatusUrl method is probably a lot quicker than the JS variant.

How can you safely redirect web site traffic from your old pages to the new pages without losing your high search engine rankings?
You can do this by using a “301 redirect“.

But what do you have to do if there is a space in the old URL:

^about nostylesheets.html$

Normally I would use this to make the URL working:

^about%20nostylesheets.html$

But this doesn’t work.
To make an URL working you just have to use quotes to make this URL working:

"^about nostylesheets.html$"

We the developers  already know about the famous jQuery validator and about all the wonderful things it is capable of. But we also know that this validation is only on the client side.

What about server side validation on form input? Isn’t that important too? Of course it is. And that is exactly why we’ve come up with the following solution for this issue: The php validator. This validator consists of  a class which contains a collection of methods similar to the jQuery validator. This way, we have validation on both client- and server sides using exactly the same rules and error messages.

Our PHP validator is based on the bassistance jQuery validator found at: http://bassistance.de/jquery-plugins/jquery-plugin-validation/

How it works

It’s pretty simple really. All you need is the Validator.class.php file which can be found at the google code project page http://code.google.com/p/jquery-validation-php-plugin/, or it can be downloaded directly from: http://jquery-validation-php-plugin.googlecode.com/files/jquery-validation-php-plugin-0.3.zip. Once you obtain this crucial file, then you can get to work.

First, make an instance by doing the following:

$oValidator = new Validator($aasOption);

The two-way road: PHP and jQuery
The $aasOption variable is an array with our validation rules and messages. This array is built the same way the jQuery is built. The main advantage of creating this array is that we can use it in PHP as well as JavaScript. This is mainly due to the fact that they both use the same atributes: ‘rules’ and ‘messages’. This way, we can implement it both ways.

Here is a simple example requiring the $_POST['name'] field to be set:

$aasOption = array(
‘rules’ => array(
‘name’ => ‘required’
),
‘messages’ => array(
‘name’ => array(
‘required’ => ‘This field is required’
)
)
);

The following javascript shows how we implement the array for use in JavaScript:

The catch is that each field to be validated must be specified in the jQuery options object by it’s name, not by id or class, as these are not acuired by the server.

The Form
Now that we can call upon our source, we can build our soon to be validated form.

<label for=”name”>Name:</label>
<input id=”name” type=”text” name=”name” value=”<?php

?>“/>

Now that we have a form, we can validate it with PHP. We must first check if there’s an empty $_POST.
if(!empty($_POST)){}

It is within this if- statement where validation is triggered using the validate(); method from the Validator.class.php.

The if- statement will eventually look like this:

if(!empty($_POST)){
$oValidator->validate($_POST);
}

Now we have validation. Hey! But wait! I don’t see any messages.
That is absolutely true because we haven’t added them yet.

Next to the input field, we must use the exact same label tag for errors that you would use in the jQuery validator.
We do this by using the showError(); method, found in the Validator class. We then echo the message by typing in the following:

<?php echo $oValidator->showError(‘name’); ?>

Pay attention: The showError(); method creates a label tag by default. You don’t have to create a label in wich you echo the method.

For the the jQuery validation you can go to work the same way you usually do. The only difference is that you will use the $aasOption array. More information about the jQuery validation can be found at: http://bassistance.de/jquery-plugins/jquery-plugin-validation/

Here is how you refer to it in JavaScript: validate(<?php echo json_encode($aasOption);?>);

For your viewing pleasure, we have created a demo so that you can see both the php and the JavaSript validation in action:
http://open-source.yes2web.nl/php-validator/demo1/validator-form.php
Further documentation:
http://bassistance.de/jquery-plugins/jquery-plugin-validation/
http://docs.jquery.com/Plugins/Validation
http://code.google.com/p/jquery-validation-php-plugin/

function sprint_r($sIn){
     return print_r($sIn, true);
}

to conform to choices made for (s)printf. While on the subject, why not include a fprint_r as well (useful perhaps for logging):

function fprint_r($oFP, $sIn){
     return fwrite($oFP, sprint_r($sIn));
}

and perhaps a vprint_r to complete the symmetry, though I have no clue as to what it should do .

PHP

In your PHP, always use the following immediately after you set up your connection.

• mysql_set_charset(‘utf8′, $oDB);
• mysql_query(‘SET NAMES \’utf8\”);

The tricky bit lies in your MySQL configuration file:

my.cnf

Add the following lines:

[client]
default-character-set=utf8
[mysqld]
default-character-set=utf8
default-collation = utf8_general_ci

This tells MySQL that the client (which is either PHP or the system) expects UTF-8. If you don’t tell MySQL this, a mysqldump will produce ANSI and an import from the command line will result in double encodings.

And don’t forget to use utf8_general_ci for all databases, tables and fields!

Many people think it’s hard to make their website suitable for mobile devices, but this isn’t the case at all. In this article I’ll introduce a couple of things you should consider before developing a mobile website. In a future article I’ll give some hands-on advice on where to start.

Know your visitors

When you consider to build a mobile website you should first question who you want to target. This is first step and very important for the rest of the process. There are thousands of different mobile devices and how much you probably want to target them all, that is pretty ambitious since almost every mobile browser reacts different. Why is this so important? If you want to target a group of people using low-end devices such as the Nokia 1100, which is very popular amongst low-budget users, this has consequences for example in the choice for the right mark-up language (more about this in a follow-up article). Another good example is when you have a b2b (business to business) model, most visitors use a ‘Blackberry’, so your website will have to be compatible with the Blackberry browser.

Choose your method

There are a couple of methods you can choose from for setting up your mobile environment. One of these methods is ‘doing nothing’. This is the easiest way, but definitely not the best way of dealing with mobile devices. Why is this one of the methods? After reading this article you could decide not to develop a mobile website any longer. I just want to point out that this “method” causes unpredictable results rendering your website on a mobile device.

The second method is to make a mobile version of your CSS stylesheet using ‘media=”handheld”‘. In many cases this works just fine, but you’ll run into problems very easily when you test your site in different devices. Although the mediatype ‘handheld’ is W3C compliant, it’s not a general standard. Many mobile browsers have their own way of interpretation of ‘media=”handheld”‘ and therefore  this method is not very reliable. Here you can see the differences in interpretation (source from ‘a list apart‘):

A third method you could use is to let your server determine which user agent your visitor is using and showing him the right version of your website. This method gives you the opportunity to build multiple versions, for multiple platforms, without using an alternative url. Your visitor can easily find you on your normal url (www.mybrand.com) instead of an alternative (www.mybrand-mobile.com). The problem with this method is that you can never let your visitor decide which version of your website he wants to see. He can’t switch between your versions if he thinks your pc version is better on his device.

The last method is related to the third method. It is possible to use build your own mobile version of your website with another url without losing your brand name. Examples: www.mybrand.com/mobile or mobile.mybrand.com or even shorter: m.mybrand.com.  In this case you can give your visitor the opportunity to switch from you mobile version to your standard version, so for flexibility reasons this method could be the best way. It is also possible to registrate an .mobi TLD (Top Level Domain), for example your url looks like: www.mybrand.mobi.

In my opinion the last method is the best way to achieve your goals. With a mobile version next to your normal site you can also optimize your mobile content. My preferences is to take the .mobi domain name, which could quickly evolve into the standard, when everyone uses a different way it will be still difficult to find the mobile version.

You can always choose or combine methods to suit your preferences. Keep your focus on your target group of visitors and be aware of the restrictions on many mobile devices.

The importance of testing

Although this is a step you take after realising your mobile website, testing is an important component of the process.  You have to  think about validating/ testing before you can put your site online! Mobile browsers, in contrast to the browser on your pc, are very strict in reading your code. Make sure you validate your xHTML (validate / mobilevalidate) or WML (validate). Another way to check the mobile browser compatibility can be found here or here.

Last but not least you have to test your websites. This can be difficult if you are not in possession of the right equipment. Let me point out a few possibilities to test your mobile website.

Test your mobile website on an emulator. This is the most common way to test your website in the first place. It is also not the easiest one. Finding a good emulator isn’t easy since the most look more like a simulator. Well known emulators are from dotMobi, Openwave and Apple. Problem with the most emulators is that they interpret the user agent like a normal browser (browser on the machine where the emulator is installed). This makes it hard to test and you can’t rely 100% on what you see.

The most expensive way of testing is to buy a small subset or representative phones. This is more an option if you’re considering to develop more mobile websites in the near future. Make sure you select a combination of different browsers on different devices (Windows Mobile Explorer, Safari Mobile, Opera Mini and Nokia’s built in browser).

Another way is to ask your friends or colleagues to test your website on their mobile phones. There is always someone to help you out. Make sure your code is valid first and that you have tested it in an emulator, so that you can do your testing on you friends phone quickly and effective.