18 Jun

Magento deployment checklist

Just deployed a new Magento site? Or migrated to a new host?

Here are some things you should before you launch…

Secure it

  • Magento base code may not include the latest security patches!  Check the download page for the latest and apply them. For example, Community is still vulnerable to Shoplift out of the box.
  • Change your Admin path – anything other than the default /admin, to make your Magento backend harder to find or brute-force.  This is usually configured in your app/etc/local.xml.
  • Admin password: if you were using “admin123” while in development, now is a good time to change it.
  • File permissions: tend to get overlooked in development. Here’s a handy guide on what they should be.

Enable caches

Magento caches are often disabled during development, but in production it’s essential that they’re all ON.  In the Dashboard, go to System > Cache Management and enable them. Related article: Magento Full Page Cache

Log cleaning

This relates to the four log_* tables in the database. They’re a bit like access logs which are not rotated by default – this is bad because it bloats your database, wastes your InnoDB buffer, and makes database backups more cumbersome.

Go to System > Configuration > System > Log Cleaning and enable  it. The default 30-day retention should be fine.

Cron job

The Magento cron job should be run every five minutes. Top tip: run cron.sh instead of cron.php. The shell script first checks it’s not already running, then runs the PHP, preventing overlaps.

*/5 * * * *  /bin/sh /path/to/docroot/cron.sh

As of Magento 1.9.1, the cron job is responsible for sending customer email so it’s more important than ever.


If you are using Community Edition, indexing may not be a problem to start with, but one day it’s going to cause issues. Here’s my advice on how to configure Magento indexing.

Error pages

Death, taxes, and Magento 503s. Even a well tuned Magento application infrastructure can be complex and one day something will break. Or maybe we’re talking planned maintenance; installing a new extension for example.  Here’s a great tutorial on customising your Magento error pages.  It’s best to get this done early on, so you’re ready for the unexpected.

Top tip: Other reverse proxies like Load Balancers and Varnish (if using) will probably show their own 503 page when something is broken. Talk to your hosting provider about modifying these – default error pages don’t inspire confidence in your brand.

The goal here is a nice customer experience even when something is broken. Make sure there’s a phone number or email address at the very least. Including a discount code will encourage customers to come back and buy later.

Load test

If time allows, the last thing to do before launch is a load or performance test to get insight into what your new solution can really do.  It’s best to do that before you have real world traffic, otherwise load testing is basically DOS’ing yourself. Load testing is also likely to show up areas for config optimisation/performance, which is always a good thing.

Don’t: rely on tools like siege, or services like loader.io and blitz.io. They can be extremely useful of course, but only if you are able to interpret the results properly. Unless you have a deep understanding of HTTP protocol headers, cookies, unique session IDs, these tools probably won’t help you all that much.

Do: get it done professionally. You need a test that can mimic actual human user journeys, and repeat them on a massive scale. jMeter is great, but doing it right can be complicated and very time consuming. I would argue this is best left to professionals who do just that. Not cheap, but a necessary investment for your website’s future. Your hosting provider might offer professional load testing services, or refer you to someone who can. Soasta are excellent.

20 Apr

Foolproof Magento Indexing

This is for Community Edition and Enterprise Editions before 1.13.

Once you have established whether Magento indexing is breaking your site, here is the simple 1-2-3 solution.

Generally, reindexing in the daytime on a busy site can cause problems, and by default Magento will fully reindex after any product/catalogue changes. The gist of this is that you probably don’t want that to happen in peak business hours.

1. Manual indexes.

Two of the indexes are more likely to cause you problems than any of the others – the URL rewrites and the Fulltext search. Set them to manual – the others should be OK.

Magento manual indexing

System > Index Management

Alternatively you can set this directly in the database:

mysql> UPDATE index_process SET mode="manual" WHERE indexer_code="catalog_url";
mysql> UPDATE index_process SET mode="manual" WHERE indexer_code="catalogsearch_fulltext";

2. Configure a cron job to do that manual reindex, every day.

crontab -e -u username

username is the user which runs your PHP-FPM, or just apache for mod_php.  I try to avoid having root run these jobs; it creates lock files in ~/var/ which the application user will not be able to work with.

Your added cron job should look something line this:

@daily /usr/bin/php /path/to/magento/documentroot/shell/indexer.php reindexall >/dev/null 2>&1

I’ve used @daily as a cron shortcut, which is usually midnight (server timezone). You could be more specific if you like, for example if you need to avoid other jobs like database backups. This is in addition to the normal Magento cron running every 5 minutes.
Obviously you need to replace /path/to/magento/documentroot with whatever’s relevant in your hosting environment.

If you don’t have access or confidence to do this via SSH, your hosting provider should be able to help.

3. Ignore the banner.

Might seem like a silly thing to mention, but  I’ve often seen cases where a diligent member of staff was following the advice and doing the reindex, unaware that it was causing problems and will be done by the cron job anyway. If you have a large team of admin staff, just be sure to let them all know.



Business critical updates?

When I suggest this, I’m often greeted with something like, “..but it’s absolutely essential that new products are searchable and available via their URLs IMMEDIATELY!

You have a few choices here:

  1. Think about your business requirements vs. impact vs. cost. Do you really need that? All the time? If it’s just occasionally, then continue as above and deal with the occasional manual reindex in the daytime.

  2. Third party code. This extension claims to do the job. There are probably others, too. I can’t vouch for it because I’m not really a developer. As with all third party extensions, the fewer the better and, of course, YMMV.

  3. Buy the Enterprise Edition. Or upgrade if you’re on EE < 1.13. There are plenty of other reasons for this, but index management is a major factor. If you have enough products for indexing to be an issue, and it really is business critical that your indexes are up-to-the-minute fresh, and you need vendor escalation with your software, then it’s a no-brainer. Talk to your finance director, bite the bullet, and invest in software that does the job out of the box.