Since Prestashop 1.4 has now gone into production, the original Smarty debug module has been updated to support the latest features. Specifically this means that you should be able to debug both Smarty v2 and Smarty v3 Pretashop themes using the tool. You can read more about it and download the module from the Debugging Prestashop Templates page.
Another development module to be released soon is an implementation of a code profiler for use in optimising Prestashop custom builds as well as a new release from our Plugins for Prestashop project. The latter has us fairly excited as it has opened up some really original ways of building stores without the need to resort to major code modifications and overrides.
I’m not a great fan of commercial software, but there are some tools that are probably worth paying for — otherwise the author wouldn’t be able to maintain the code. I know from personal experience that relying on donations doesn’t pay the bills.
I came across PSE Terminator today and I must say I’m quite impressed. I usually have to do all of this by hand and this tool could save a huge amount of time. I’ll need to start saving up so I can afford to buy it!
Debugging can be such a pain sometimes…
I’ve been using FirePHP for some time now on my CodeIgniter projects and recently while I was looking at doing some cool things with the product data returned by the Category::getProducts() function it struck me that it would be nice to be able to easily see what data was returned. Why I’ve never used the FirePHP class in my Prestashop projects before I’ve no idea, as it really is very simple to use, if a little erratic in its behaviour….
Continue reading "Using FirePHP (FireBug) with Prestashop"
While porting the WP-Cumulus plugin to Prestashop I came across an interesting situation. In the original plugin the parameters for the Flash movie are stored in an array that is obtained from the WordPress database using a get_option() call. In Prestashop the parameters can be retrieved in bulk using Configuration::getMultiple(), but in that case you have to specify the key names for all the parameters which is a pain.
What I decided to do was to use the serialize() and unserialize() php functions and store the options as a single configuration item in the database. That way we use:
// Get the options
$newoptions = unserialize(Configuration::get($this->name.'_options'));
// Save the options
The above works great in this situation, as the parameter names aren’t language dependent, but this technique isn’t suitable if your configuration data key needs to be defined in multiple languages.
The PrestaShop Blog has announced (in French only currently) a couple of long awaited developer resources, which look to be a pre-cursor to the official 1.1RC1 release which we expect to be made shortly.
The first is a data model of the PrestaShop database produced from MSQL Workbench, which is available for download from the PrestaShop website. It’s their announced intention to update this for each new version of the software, and will greatly assist in the process of new module creation for this open source eCommerce store.
Continue reading "New PrestaShop 1.1 Developer Resources Announced"