• #vanilla 2 #prestashop Integration | Site News | eCartService.net http://bit.ly/4V55MS #
• #prestashop Display module output anywhere | Development Resources | eCartService.net http://bit.ly/7945RN #
• #Paypal Website Payment Pro Module (UK & US) – Free #Prestashop Payment Module | Hung Bui http://bit.ly/5OobF5 #
• Some news on my rework of #prestashop and #paypal http://bit.ly/5lbpz6 #

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
Configuration::updateValue($this->name.'_options', serialize($newoptions));

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 finishing touches

Introduction

In this part of our basic module writing tutorial series we’ll look at the final steps to transform our Tutorialthird module class into a base template that we can use to kick start the writing of new modules. Rather than republish the same old code again we’ll only discuss the changes, but I’ve added a download link at the end of this part so you can grab the final code and use it as the basis for your own projects. We’re going to call this module “Skeleton” – a name that we’ll replace with our own when it comes to producing new modules based on it.

Updated for Prestashop version 1.4 onwards.

Continue reading "Writing your own Prestashop Module – Part 5"

Form Validation and Security

Introduction

While being sufficiently functional for what it does, the module we created in Part 2 does present us with some issues to consider when implementing “real world” modules to extend Prestashop. In particular the user input we captured with our form was written directly to the configuration entry without any checking to determine whether it was valid, nor did we take account of the type of data being entered.

In this tutorial we will look at the general issue of form input checking and security, both for Back Office and Front Office forms and user input as well as looking at improving our code both functionally and aesthetically.

Updated for Prestashop version 1.4 onwards.

Continue reading "Writing your own Prestashop Module – Part 4"

Storing Module Configuration

Introduction

In the third part of this series we’ll look at how we can store configuration data for our modules in the Prestashop database, and how we can allow users to interact with this data to control the module’s behaviour. We will also briefly touch on how we can generate output from our module to provide visual feedback of the configuration changes.

Updated for Prestashop version 1.4 onwards.

Continue reading "Writing your own Prestashop Module – Part 3"

Creating a basic module

Introduction

In this second part of the series we will look at creating our first basic Prestashop module that can be controlled from the Back Office.

The Module class

Similar to the ObjectModel base class, all Prestashop modules are extended from a common base class used to define their basic functionality. The “Module” class provides the interface between the administration screens and your module as well as providing internationalisation and “hook” management functionality.

Updated for Prestashop version 1.4 onwards.

Continue reading "Writing your own Prestashop Module – Part 2"