PayPal and the broken PrestaShop module [SOLVED] ;)

Perfection doesn’t exist but we can strive for it.

Refactoring activities can be considered as the embodiment of this striving. In the context of these activities code gets modified and revamped to properly respond to new and/or future possible features.

The results of this process are nothing more than software updates. 

But software updates aren’t always the outcome of the refactoring process: they are very often (mainly) released to fix bugs and security flaws that otherwise could lead to serious problems.

Sometimes software updates can also be disruptive and bring changes that can cause themselves breakages inside the applications where they are applied.

This is exactly what happened to us just a few days ago when we updated the PrestaShop (PS) Paypal module to address the SSL v3 protocol vulnerability named POODLE.

As a result we ended up with a broken checkout process and the following error:

Please try to contact the merchant:
PayPal response:
TIMESTAMP -> 2013-04-23T01:25:10Z
L_ERRORCODE0 -> 10472
L_SHORTMESSAGE0 -> Transaction refused because of an invalid argument. See additional error messages for details.
L_LONGMESSAGE0 -> CancelURL is invalid.

Here there is a thread on the official PS forum concerning the problem.

The important thing is that in this case the module wasn’t entirely to blame. 

Indeed the problem was connected to the missing update of the files overriding the module templates.

PS modules templates represents the “V” (i.e. View) in the MVC architectural pattern on which PS modules founds their own roots. These views can be customized by overriding them and put their override files inside the PS theme in use.

This grants a good level of customization but at the same time it also injects some consistent dependencies between the modules and the theme. This can lead to problems like the one over mentioned. 

In our case the breakage was related to the change of a variable name inside one of the module templates. This was in particular one of the views used in the context of the payment hook (i.e. express_checkout_payment.tpl.)

Without any apparent reason the module developers changed the smarty variable used inside the value of the input field express_checkout from $PayPal_current_shop_url to $PayPal_current_page.

In our case the variable we were using wasn’t correctly valued and so we ended up with the over mentioned breakage.

The key takeaways of this post are mainly two.

The first one is that the use of the MVC architectural pattern doesn’t automatically ensures a proper separation from the business logic (i.e. the main functionality) and the view layer. To achieve that the pattern must be correctly implemented.

The second one is directly bound to the first and could be summarized in:

always remember to check which layers gets updated when you release an update or when someone else does.

As always I hope this can help to solve the over mentioned problem.



error_log all the things! (in Prestashop)

William Edwards Deming once said: "You can’t manage what you can’t measure.“

I find this statement pretty similar to: "If I can’t var_dump I can’t fix”.

Actually this statement is just a bit stronger than Deming’s one but I find it true in most of the cases.

It doesn’t matter if code is properly written and TDD and/or BDD are actually used. When a program begins to work unexpectedly, one of the things that is usually done to shed some lights on the problem is to put some “log” directives here and there and look at the results.

This kind of debugging strategy, while being rather primitive, can be very useful in many contexts.

For example if you’re developing something with PrestaShop (PS) (so you’re writing PHP…) you may feel the need to log something inside the apache error log.

This can be easily accomplished by using the PHP function error_log.

But this function  accepts only strings, so in order to log a complex structure like an hash you should first convert it to a string using something like var_dump or print_r.

Sincerely I was expecting some kind of support from PS core functionality but unfortunately this wasn’t the case.

As a result I end up writing a bunch of lines of code to log whatever I need right inside the apache error log.

Here they are:

class Tools extends ToolsCore
  public static function console_log()
    $args = func_get_args();
    $log = '';
    foreach ($args as $arg) {
      $log .= print_r($arg, true);

I simply added a public static function to the Tools class (by properly overriding it) that takes any number of arguments and builds a string by using the print_r function.

The string is eventually logged on the apache error log.

I hope this can be useful to the ones willing to go with the old style debugging 😛


A PrestaShop module helper to display “boxed” success and error notifications

First, a little bit of theory:

PrestaShop (PS) implements the concepts of modularity and extensibility through two different entities:

  1. modules
  2. hooks

The first ones are actually wrappers for the custom functionality you may need on your store while the latter ones are the connection points offered by the PS core.

Continue reading “A PrestaShop module helper to display “boxed” success and error notifications”

Download a CSV in PHP…use ob_clean()!

There are many blog posts, guides, code snippets and stackoverflow answers that describe how to create and download a CSV file in PHP.

Anyway none of them helped me the last time I was asked to do that in the context of the configuration panel of a PrestaShop module.

Continue reading “Download a CSV in PHP…use ob_clean()!”

“How to KISSmetrics” in your e-commerce store

Everyone knows “how to Google Analytics in PrestaShop (i.e. PS)” right?

If the answer is no then here. As always modules to the rescue! 🙂

Yes I know they aren’t free 🙁

Ok now do you know KISSmetrics? If the answer is no then here 🙂

Now if you want to integrate this analytic product in your PS store I can suggest you this free module that I’ve developed.

It is still “young” and it is built for the major release 1.4 of PS.

But if you have the latest major release (i.e. PS 1.5) don’t despair! If there is interest in this module the porting will be done in a couple of days 🙂

PrestaShop is on GitHub! Contribute!

Don’t you know PrestaShop (PS)?
Take a look here 🙂

It’s a modular system that let you create a rich e-commerce platform by supporting a vast number of different features. These features are implemented via modules that hooks right into the core of PS.

There are a lot of modules, free and not, and the community is pretty active. Some of them are released together with PS and are directly developed by the PS group.

However some of them are limited (e.g. Cash On Delivery) and so…developers to the rescue!

There are a lot of custom modules posted in the PS dedicated forum section but actually you can also directly fork PS from GitHub, develop your changes to the core modules, and then ask a pull request.

Here’s an example of the over mentioned Cash On Delivery module enriched with the possibility to add a custom fee.
I’ve added this feature too and published the modified version of the module on GitHub. Actually I didn’t fork the entire PS repo but I’ve just created one with only my module.