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.



Mongoid and awesome_print, a simple patch!

Just a couple of days ago I had the need to print out some Ruby objects on my terminal in a nice and well formatted way.

The default p wasn’t enough for me and so, with just a couple of keystrokes, I end up on the github page of the well known awesome_print gem.

After adding the gem to my gem .gemspec (yep I need the pretty printing feature for my first gem :)) and requiring it inside the code I stumbled upon a little problem.

Here it is:

uninitialized constant Moped::BSON (NameError)

Continue reading “Mongoid and awesome_print, a simple patch!”

Screensavers, black screens and power management

“Oh nice, for today I’m done! Now lets watch a movie before going to sleep!”

This could be considered a justified desire right? After a day of work why not enjoy a movie?

Unfortunately, if you are running a Linux distro you may encouter some problems depending on the Desktop Environment (DE) and the power management system you are relying on.

Those problems can all be summarized in more or less random screensavers activations and/or consequent screens blanking.



Continue reading “Screensavers, black screens and power management”

Chrome why don’t u default?!

Every distro hopper ends up from time to time on Ubuntu or on its derivatives to check how things goes.

Actually I’m a little bit of a distro hopper, at least in this period, and the distro on which I “hopped” on this time is Xubuntu 14.04 (yep, the LTS).

Now, there are many blog posts and articles that focus on the after installation steps and explain how to setup a productive desktop with all the bells and whistles.

I really like those articles but there are some little things that they don’t (can’t) consider (explain).

One of these things is a strange behavior of XFCE regarding Google Chrome.

Continue reading “Chrome why don’t u default?!”