PrestaShop Best Practices – The Right Way to Modify v1.4.x

by Adrian Nethercott on July 19, 2011


Adrian NethercottPrestaShop Best Practices is an ongoing series of articles that are meant to demonstrate the best ways to work with PrestaShop.  In this article, Adrian Nethercott of Nethercott Constructions discusses the right, and wrong, way to modify your PrestaShop v1.4.x store.

Nethercott Constructions:

Upgrading PrestaShop to new versions has always been a major issue on the Forum.  That’s because in v1.3.7 and earlier, core files couldn’t be overridden like they can in v1.4, so they had to be modified instead.  There’s also a wealth of information on the PrestaShop forums that was written for v1.3.7 and earlier, so it instructs users to modify their core files.

There are a lot of stores out there with core modifications, and often no log of these modifications was kept, so it is hard to find the modifications.  In this case, the only option is to compare each file to the default file to find the modifications, which is a lot of work.

PrestaShop v1.4 addressed this issue by adding the option to override classes and controllers, so modifying core files is no longer necessary.  Ideally, this should make all stores built using v1.4 and later easy to upgrade.

Unfortunately, that doesn’t help those who have already made modifications, since turning all these modifications into overrides in v1.4 is a lot of work.  Worse, it seems many developers are unaware of the new PrestaShop v1.4 best practices that make it easier to upgrade.

I recently had a client who had a PrestaShop v1.4 website created for them.  The developers had done the best they could, but there were many little issues that they couldn’t resolve, so the client hired me to fix them.  After looking at the code, it became clear that although the developers did know HTML and CSS, they didn’t understand PrestaShop or the proper way to modify it.

They had modified the default theme, many of the modules, and some of the classes and controllers too.  This made it difficult to find what was modified and will make upgrading the store in the future very difficult.

They had also put all of the new CSS code in global.css and embedded a lot of CSS in the HTML using style tags.

What the developers should have done is copy the themes/prestashop directory to a separate directory with a shortened name of the website.  That way, when you need to upgrade PrestaShop in the future, you can overwrite the themes directory without having to worry about losing the changes to your theme.

You will end up with the latest default PrestaShop theme in one directory and your older theme in the other, allowing you to compare the themes and copy over the latest changes.  If you’ve already done it the wrong way, you will need to rename your theme before you overwrite the themes directory with the latest version.

Instead of modifying the modules directly, the developers should have copied the original module TPL files into their modified theme and then modified the files there.  For example, instead of modifying modules/homefeatured/homefeatured.tpl directly, they should have copied it to themes/<theme_name>/modules/homefeatured/homefeatured.tpl.

Actually, since the PHP file modules/homefeatured/homefeatured.php was also modified, it would have been better to copy the modules/homefeatured directory to modules/homefeatured2 and change all instances of homefeatured to homefeatured2.

That way, when you need to upgrade PrestaShop in the future, you can overwrite the modules directory without having to worry about losing the modifications to modules/homefeatured/homefeatured.php.  You can then copy over the latest code from the homefeatured directory to the homefeatured2 directory.  Of course, doing this is unnecessary if you are only modifying the TPL file, and you should avoid editing the PHP files whenever possible.

The developers also shouldn’t have modified the default classes and controllers.  Instead, they should have used overrides.  The best way to write an override is to add code before or after the default code.  That way, you won’t have to worry about upgrading PrestaShop in the future, since the override will run the latest code, then your own code.

Unfortunately, if the code you want to add relies on local variables or code within a core function, you will need to copy the entire function into your override and then modify it as needed.  That makes it slightly harder to upgrade, since you need to copy over the latest changes to your modified function.

You can read more about overriding classes and controllers and see examples in my PrestaShop Development Guide.

The developers also made the mistake of putting all the new CSS code in global.css, including CSS that was used only on the product page.  This caused the product page CSS to be loaded on all pages of the website instead of just the product page, which caused unnecessary CSS to be downloaded and loaded.

If you need to apply CSS to a single page only, you should put it in the appropriate CSS file for that page.  You should only add CSS to global.css if it applies to multiple pages, or if there is no specific CSS file for the page, though creating a CSS for the page would be better.

You should also avoid using the style tag to add CSS and instead move the CSS into the appropriate CSS file.  This enables the CSS to be combined, compressed and cached with the rest of the CSS.

Remember, don’t be lazy, or you’ll create more work for yourself in the future, and we all hate that.

BONUS TIP:

The developers had also created an image-heavy PrestaShop theme.  Usually, this isn’t a problem, but since many of the images weren’t optimised, these images slowed down the website considerably, causing the client to complain that the website was too slow to load.

I always save images that are around 256 colours or less in PNG-8 format using Photoshop, since they are usually smaller than GIF images and have lossless compression, unless there are more than 256 colours.

Lastly, I use Google Page Speed for Firefox to compress GIF and PNG images even further.  The “Optimize Images” option is somehow able to compress these images even more than image editors can, and gives you the option to download the optimised images.

Be aware that the optimised images may not open correctly in image editors anymore, so keep a copy of the original in case you need to edit it.

For images that are much more than 256 colours, I save them in JPEG format with a quality setting of about 60-70, depending on the image.  I try to reduce it as much as possible without a noticeable loss in quality.

Nethercott Constructions Logo

Nethercott Constructions provides custom themes and modules and advice on all things PrestaShop.  You can check them out at http://www.nethercottconstructions.com/.

Adrian Nethercott is a web developer with more than three years of experience working with PrestaShop. His website Nethercott Constructions has free PrestaShop guides and sells PrestaShop modules.

Facebook 

If you enjoyed this article, get email updates (it's free).