Where to Start to Become a PrestaShop Developer – Debugging – Part 3

by Adrian Nethercott on April 16, 2012

In this third article, I will talk about how to debug the different programming languages used by PrestaShop.

HTML, CSS and JavaScript

PrestaShop DebuggingMost browsers have developer tools available that allow you to debug HTML, CSS and JavaScript.  For example, Internet Explorer 8 and above come with developer tools built-in (see screenshot below).  Just click the “F12 developer tools” item on the Tools menu or press F12 to open the developer tools at the bottom of the window.  You can then click on the “Select element by click” menu item on the Find menu, then click on an element on the website to inspect that element.

On the left side, you can see the HTML code with the current element highlighted.  You can click on an attribute of an element to temporarily edit it to see what difference it makes to the website.  You can also right-click on any element and click on the “Add attribute” menu item to add a new attribute.  It can be useful to add a “style” attribute to temporarily add CSS to an element to see how it looks.

On the right side, you can see all the CSS that applies to the current element.  You can use the checkboxes to temporarily remove CSS rules to see what difference it makes to the website.  Also, when one CSS rule overrides another rule, the overridden rule has a line through it.  If you have a CSS style that isn’t taking effect, you can use this information to figure out what rule is overriding it.  Using the “Trace Styles” tab makes it even easier to figure out which rule to overriding your rule.

At the end of the menu at the top, you can see the browser mode and document mode that is currently being used.  The browser mode is the version of IE that is sent to the website.  For example, if you select “Internet Explorer 7” as the browser mode, any code that checks the IE version will think you are using IE7.  The document mode is the engine that is used to render the website.  For example, if you select “Internet Explorer 7 standards” as the document mode, then the website will be rendered as it would if you were using IE7.

You can use these modes to change the browser engine and debug earlier versions of IE such as 6, 7 and 8.  It is best to change both modes to match each other unless you are specifically testing whether there is version-specific code you need to change.  You can choose “Quirks mode” as the document mode to debug IE6, though there is no IE6 browser mode, so if your website is sending different code to IE6 and IE7, then it may look different to actually using IE6.

Lastly, you can use the “Console” tab to view information about JavaScript errors including the error message, line number and file, and the “JavaScript” tab can be used for further debugging and profiling.  Read the IE Developer Tool Tutorials to learn more about JavaScript debugging and other features such as code validation.

IE Developer Tools

Firefox 10 and later comes with built-in HTML and CSS debugging tools (see screenshot below) that you can open by right-clicking on an element on the webpage and choosing the “Inspect Element” menu item, but it doesn’t come with JavaScript debugging tools.

Firefox Developer Tools

I recommend that you install Firebug to add developer tools with JavaScript debugging to Firefox (see screenshot below).  The Firebug developer tools and the IE developer tools are very similar.  You can press F12 to display them just like with the IE developer tools.  There are only small differences such as a “Computed” tab instead of “Trace Styles” tab and styles are applied as you type instead of after you’ve finished entering them.  One useful feature Firebug has is that AJAX calls are logged on the “Console” tab, which allows you to debug by seeing the code that is sent and received.  You can read more about Firebug on the Firebug Wiki.


Google Chrome comes with built-in HTML, CSS and JavaScript debugging tools.  Press Ctrl+Shift+I to open them.  You can read more in the Chrome Development Tools documentation.

Chrome Developer Tools


PrestaShop hides all PHP and MySQL error messages by default for security reasons, since they display the full path of the file, which will reveal your website’s username to you and any customers viewing your website.  This reduces the security of your website, since a hacker could now know your control panel address and username.  They just need to brute force your password.

For this reason, when a PHP error occurs, you will see just a blank page or an incomplete page, which makes debugging difficult, since you don’t know which line of code caused the error, so you can only undo your recent changes and try again.  To enable PHP error messages that tell you exactly what has gone wrong, you will need to edit config/config.inc.php and change the following code near the top of the file:

/* Debug only */
@ini_set('display_errors', 'off');
define('_PS_DEBUG_SQL_', false);

You can change 'off' to 'on' to enable PHP error messages and change false to true if you need to debug a MySQL query.  You can use this information to fix syntax errors in PHP code and MySQL queries.  Remember to turn off error messages when you’ve finished debugging.

These error messages won’t help you debug semantic errors though.  A syntax error is an error in the code that prevents it being compiled.  A semantic error is an error where the code compiles, but it’s not doing what you intended it to do.

To fix a semantic error, you can use an echo or print statement to see the value of the variables on a particular line.  For example, you could add the following to see the value of the variable $variable:

echo 'variable is '.$variable;

This won’t work for arrays or objects though.  To view the value of them, you can use the var_dump function.  For example, you could add the following to view the value of the array $array:


You may sometimes encounter a fatal error in PrestaShop, often when using an old module with a new version of PrestaShop.  These error messages don’t provide any information you can use to debug.  In that case, you can get a stack trace to help you locate the error by changing '_PS_MODE_DEV_' near the top of config/defines.inc.php to true.

define('_PS_MODE_DEV_', false);


When you enable PHP errors by changing 'display_errors' to 'on', you will also see Smarty error messages that tell you which template caused the error and on what line.  You can use these error messages to fix syntax errors in your Smarty templates.

To fix semantic errors, you can use the Smarty console to view a list of the available variables and their values.  In PrestaShop v1.5 and later, you can turn on the Smarty console on the Preferences > Performance tab (see screenshot below):

Smarty settings

By default, the Smarty console is not displayed.  You can change the setting to “Always open console” to have the console always open, but then your customers will see it too, so if your website is online, it is better to choose the “Open console with URL parameter (SMARTY_DEBUG)” option.  The Smarty console will then only be displayed when you add ?SMARTY_DEBUG to the end of the URL, so you can view the Smarty console when needed without your customers seeing it.  Note that the console displays in a new window (see screenshot below), so it may be blocked by your browser’s popup blocker.  In that case, you will need to make an exception for your website so that the popup is displayed.  Once you’ve finished debugging, you should change the “Debug console” setting back to “Not open console”.

In PrestaShop v1.4.7 and earlier, you will need to manually edit config/smarty.config.inc.php to enable the Smarty debug console and change false to true on the following lines near the top of the file:

$smarty->debugging = false;
$smarty->debugging_ctrl = 'URL'; // 'NONE' on production

This will enable the equivalent of the “Open console with URL parameter (SMARTY_DEBUG)” setting.  Remember to change the debugging setting back to false when you have finished debugging.

Lastly, you can temporarily remove Smarty code from TPL files by adding {* before the code and *} after it.  This can be useful when debugging.  Just remember to change “Force compile” to “Yes” so the TPL file recompiles, then change it back to “No” when you’ve finished debugging.

Now you know how to debug the programming languages used by PrestaShop.  Please let us know your experiences with the tools in this article in the comments below, or tell us about the tools that you’ve used to debug.

If you enjoyed this article and you haven’t read the first two parts to this series, you can check them out here:

Where to Start to Become a PrestaShop Developer – Software Every Developer Needs – Part 1

Where to Start to Become a PrestaShop Developer – Languages to Know – Part 2

This is just one of the many tutorials to help you get your PrestaShop store up and running the easy way.  Along with this tutorial, you’ll find over 36 other tutorials on the installation, setup, and configuration of a PrestaShop store.  Check out PrestaShop 1.4 tutorials.

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.


Fernando Novoa May 4, 2012 at 9:54 am

thanks for these articles. Theay help me a lot. I am very new with all of this but I think I´m on good way. Thanks again for your help

Curt Donohue May 4, 2012 at 4:14 pm

You’re very welcome Fernando.

Previous post:

Next post: