We’re pleased to announce that the initial changes we proposed for the Paypal Payment module for PrestaShop have been incorporated into the official 1.1 release which is due in autumn 2008.

We appreciate the PrestaShop’s team recognition of our efforts and look forward to working with them even more in the future. We are committed to making PrestaShop an even better eCommerce platform for forward-thinking companies, and wish their up-coming release every success.

When I first came across PrestaShop I was utterly astonished at how it looked and operated. Having spent years working with the likes of osCommerce, ZenCart et al. PrestaShop was a breath of fresh air, which reminded me greatly of another Open Source favourite of mine – Vanilla.

Having now spent some time working with PrestaShop and it’s underlying code, some of the shine has dulled a little, but there’s nothing that I can find that can’t be buffed back up to the stunning product that it surely will be.

The first challenge was getting simple custom design elements on the page like ssl cert images with java/html links etc. without requiring users to modify the template. PrestaShop’s intuitive module system is great for this, but these are trivial bits of code that don’t really justify the overhead of full modules of their own. AddStuff was born. Well that was easy!

Next it was the Paypal Payment Module which seemed to have issues. Initially the main problems were orders being “lost” due to lack of fsockopen support on their hosting platforms (the only connection method supported in the default module), but others were reporting issues with being unable to run multiple shop installations from a single PayPal account. The latter issue impacted my customers and to be honest would be a major deficiency.

A few weeks ago I posted a stop-gap solution which corrected a bug in the PayPal payment module which enabled multiple shop support, and yet another a little later to improve connectivity for IPN validation by adding support for fsockopen over https (the standard version surprisingly used only an insecure http connection) plus support for cURL as an alternative should the fsockopen method fail.

Over the past week work has progressed on a major overhaul of the module, to hopefully start addressing some of the more underlying problems with poor integration, and failure to capture carts abandoned at the payment stage.

The new version is nearing completion, and I’m currently looking for some volunteers to provide language translations, assuming I’ve got the internationalisation correct, plus some brave souls willing to BETA test on their sites. Anyone interested can post on here, or contact me at the PrestaShop forum: user Paul C.

After discussions with our friends at prestashop.com we are pleased to announce that eCartservice.net are hosting the UK users club forum on our servers. This will be a great resource to compliment the main PrestaShop forum and is intended to facilitate discussions on local UK issues with using the software.

Please feel free to support this new forum by using the forum image and link:

While working on a Paypal test with a customer we noticed that the module appears to have an error which requires users to enter the IPN return url in their paypal account settings. This obviously means that it isn’t possible to set up multiple stores using PrestaShop if you have a single paypal account.

The offending line (42) in paypal.tpl contains the form variable return_url. The post variable return_url doesn’t exist in the Paypal documentation, but the value being passed is correct for the IPN url. This line should likely be notify_url instead.

We’ll continue our testing to confirm that this solves the problem with IPN configuration for multiple stores using PrestaShop.

Update: Patched paypal.tpl file to address the above issue: Paypal.tpl updated

I was browsing the prestashop forum and ended up on a thread concerning an issue with people stealing a site design by downloading the template files from the theme directory. It struck me that this is probably something that those of you who use other template systems with your sites may also face, so thought I’d post the solution here too.

The problem is that although php files cannot be viewed directly on your browser, other source files can be e.g. files ending in .tpl

For example take a look at the following file that has the default permissions:

Unprotected template file

The best way to protect your site is to change the permissions on these files to 600. This will make them accessible only by your own code on the server and present anyone nosey enough to try and look at them with a 403 (forbidden) error. The same is true for php files (although these shouldn’t display the source unless your server configuration is broken).

Have a look at this file with the permissions set to 600:

Protected template file

Simple.

The countdown begins

We’ve been busy working away at the final coding and implementation of our customer service infrastructure and expect to set an official go-live date shortly. Many thanks to all our loyal followers for your patience, we’re sure it’s going to be worth the wait!

In the meantime we’ve been busy writing a few new modules in anticipation of a full stable release of Prestashop you’ll find the goodies filed under Prestashop in our information repository.