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.
L_SEVERITYCODE0 -> Error
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.
🙂
Cheers!