PrestaShop Delivery Slip Table

This is basically a note to myself: I want a bit crazy searching for where the "delivery slips" were stored in the PrestaShop database. It turns out that there is no "delivery slip" table, rather the delivery slip ID is actually part of the ps_order_invoice table (field delivery_number). The value is filled out whenever an order is set to "Shipped" or "Processing in progress".

Which basically means that PrestaShop is not set up for making multiple shipments on the same order. Not very handy, especially for B2B orders.

Composer Packages in PrestaShop (pre-1.7.x)

Yesterday, I needed a Composer component for use in my PrestaShop application (I could have used sFTP in PHP in a number of different ways, but after reading the excellent book Modern PHP, I of course wanted a Composer solution to my problem). From reading the PrestaShop Developer's Blog, I knew that version 1.7.x will have Composer integrated into the program, so I needed to set it up in such a way as to avoid future problems.

To do this, I created a "composer" folder deep within my shop (but available from everywhere in case I needed future components), along with a "composer/vendor" folder. I created a composer/composer.json file that looked like this...

{
    "require": {
    }
}

I then set up Composer support in PHPStorm, chose Tools->Composer->Add Composer Dependency, and installed the phpseclib/phpseclib 2.0.0 package. PHPStorm think of everything ;->

My code was then able to use the phpseclib by requiring {full path}/composer/vendor/autoload.php, and creating a new \phpseclib\Net\SFTP class. From there, things just worked.

I then added the composer/vendor folder to .gitignore (as recommended by getcomposer.org), and added, committed, and pushed composer.json and composer.lock (whether to add composer.lock or not is a controversial issue... YMMV).

After reading these two excellent articles, it's clear that composer.lock SHOULD be added to git for my circumstances.

On my Linux server, I pulled the latest code. I found that Composer was already installed, so I navigated to the new /composer directory, and ran sudo composer update install (update when you have not checked in composer.lock, install when you have. Install obeys composer.lock). My new package was added to the Linux server, and the code worked out of the box.

For efficiency, I may decide to adapt this in PrestaShop 1.7.x, but I believe I will be able to use this as-is in future PrestaShop versions if needed.

Tired of using an old SwiftMailer version in PrestaShop? Want to get better logging?  What easier date time handling? With Composer and it's packages, you've got it, plus a lot more.

PayPal Auto Return with PrestaShop

Kim from Colillas Branding (whose English was so good that I was surprised to see he was Spanish) asked today how to get PayPal to return directly to the website instead of first showing a "confirm payment" page. Returning to the site insures that you have a chance to show your tracking code, as the extra step that PayPal puts in can keep that from happening.

I googled and found the PayPal Auto Return feature, which looked like exactly what I needed. However, the location described in the above link does not exist in my PayPal account (I needed to look under Profile -> Account Settings -> Selling Options -> Website Preferences).

There I could turn on Auto Return, but I couldn't find what the return URL should be set to. There are questions on the PrestaShop forum asking what the return URL needs to be, but no useful replies.

So, time to "use the force.... read the source". In the PayPal module (the official PrestaShop one from 1.6.1.2), they set PAYPAL_RETURN_LINK to /modules/paypal/paypal_login/paypal_login_token.php. I added my domain to the front of that (i.e. I set "Return URL" in PayPal to http://www.mysite.com/modules/paypal/paypal_login/paypal_login_token.php), and it works... I was immediately sent to my shop on payment, the order confirmation page was shown (I'll need to look for that template in the PayPal module and customize it... another item for my to do list), the Google Tag Manager code got called, and the order is marked as paid PrestaShop. Bingo.

Now if I only knew how to do the same with RedSys for my ING payments... Kim! Help! 

Contributing to PrestaShop

Ever since I started using open source software, I've gotten a lot of help in the various support forums, and try to help others in the forums whenever possible in return.

However, when I posted my "forgotten password" change for PrestaShop, and someone from Bellini Services suggest that I submit it as a pull request to the PrestaShop team, I thought "Yea, well, actually, why is it that I've never contributed to an open source project?" Maybe now is the time to start.

After reading the PrestaShop guide for making pull requests, I decided to wait until after work some day when I wasn't expected home for dinner. However, late yesterday I found a quick one line bug fix in the core PrestaShop code that looked like a good place to get my feet wet.

Following the guide was quicker and easier than I thought, and I had my pull request up in no time. First thing this morning, Maxime from the PrestaShop core code team pointed out that I had actually used the wrong branch for my pull request (I used 1.6 instead of 1.6.1.x), which was simple to fix. Maxime also indicated they would update the documentation to avoid future problems like this. Actually, if I had read this article, I could have saved myself some time.

He also indicated that a new forgotten password feature was already checked into the development branch. This one appears to be pretty much the same as what I coded, so I will skip sending it as a pull request.

All in all, I was surprised at how easy contributing is (thanks to the miracle of git), and how quickly PrestaShop (or at least Maxime) responded. Bottom line: contributing to PrestaShop is easy. I would encourage anyone with the talent to take it up as a hobby 

htaccess Tester - Way Cool

This is cool... a great htaccess tester from a company called "Made With Love". Looks like the Belgians are not as dumb and clunky as all my Dutch friends say they are ;->

When I lived in Holland, the Dutch busting on the Belgians always reminded me of my favorite Philly DJ's comment (heating up the Philadelphia - Pittsburgh rivalry): "Pittsburgh--where the sky is yellow and brown and the plants are as smart as the people".

PrestaShop: Improved Customer Password Recovery

Ever since I started using PrestaShop, I hated the password recovery method: send email with link, clicking on link sends you a new password via email.

For me, this method has various problems:

• Two emails to the client are needed. Not all emails arrive instantly, so this can slow down a customer that wants to do business with you.
• A password is being sent as plain text to the user.
• The password auto-generated by PrestaShop is hard for the user to remember.
• The customer's secure key is sent out as plain text (it's the "token" parameter in the URL of the first email).

Therefore, I decided to change the "forgotten password" feature. My goal was to send ONE email to the user, which directs them to a page to change their password.

The link which allows the password must be unique to the user, can only be used once, and additionally will only work if used within some arbitrary amount of time... let's say one hour.

FORGOT YOUR PASSWORD?

Looking at the code, I decided that a complete override of the PasswordController was needed. I did this as an override. I created the file /override/controllers/front/PasswordController.php, with public function postProcess, and deleted the /cache/class_index.php to make sure my overridden controller gets called.

I also extensively changed my theme's password.tpl to handle the new method. In addition, the text of the template, the error message, and the email needed to be changed to reflect the new implementation.

In order to limit the tokens to 1 hour, I needed to add a new MySQL table.

CREATE TABLE `customer_extra_info` (
  `id_customer` int(10) unsigned NOT NULL,
  `datetime_password_request` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `token_password_request` varchar(32) NOT NULL DEFAULT '-1',
  PRIMARY KEY (`id_customer`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

I plan to use this table for more customer specific info, which explains it's "non-specific" name.

Why I switched from Mandrill to Mailgun for PrestaShop

I was working on an override of PrestaShop's "forgotten password" feature (article to arrive here shortly) when I ran into a problem... the "forgotten password" email that I was sending to my Gmail account via Mandrill from my RackSpace Cloud server was taking up to 10 minutes to arrive in my Gmail account! 10 minutes may be fine for sending newsletters, but if a customer is in the middle of the checkout process and has to wait 10 minutes for us to respond to his request for help on a forgotten email, we've lost the client.

I started by checking my Mandrill account. I have the free account (up to 12,000 emails a month for free), since I only use it for transactional emails. DKIM and SPF were working, domain was verified, reputation excellent... I saw nothing there that indicated that there was a problem. Their knowledge base had no info on the problem, and since I have a free account, they don't offer support (and I can't blame them ;->).

When reading about the problem, I saw that other Mandrill users were having the same problem. I also saw that Mailgun (owned by RackSpace) offered 50,000 free emails per month for RackSpace cloud users, and thought I would give it a whirl.

After setting up the DNS records and getting the domain verified, I realized that I had PrestaShop configured to send emails via the PHP mail function, and then had Mandrill set up via Postfix. I would assume that is slower than using SMTP directly (which means that my problem may have been a configuration problem), but since I had come this far (and since Mailgun has more free emails per month), I decided to set up Mailgun as my PrestaShop SMTP server.

My tests with Mailgun were mostly arriving in my Gmail account within a couple of seconds, with one taking almost 30 seconds, but it looked acceptable. Gmail's DKIM and SPF authentication tests all passed.

For the moment, I'll stay with Mailgun. I will keep an eye on delivery times, and switch back to Mandrill if I have problems.

How to Make a Copy of the Prestashop 1.6 Bank wire Module

In order to make a copy of the Bank wire module (making a Bank transfer module, in my case), I did the following.

• Make a copy of the \modules\bankwire\ folder and replace the name "wire" in all the file names to "transfer"
• Search and replace (case sensitive) all instances of "wire" in the \modules\bankwire\ to "transfer"
• Make copies of bankwire files in \mail and switch the names of the files, and the contents, from wire to transfer.
• Make a copy of the bankwire folder in \{your_theme}\modules\, and rename the folder banktransfer
• Search and replace (case sensitive) all instances of "wire" in the files in the \{your_theme}\modules\bankwire\ directory to "transfer"
• Delete all files (EXCEPT index.php) from /{your_theme}/modules/banktransfer/translations/
• Add PS_OS_BANKTRANSFER (I used value 99) to the configuration table, imitating PS_OS_BANKWIRE
• Add values to order_state and order_state_lang imitating bankwire, using the same id_order_state value as PS_OS_BANKWIRE (99 in my case)