Tag Archives: php

Fixing a download link downloading the same file when it should be dynamic

One of my clients, the Database of Pollinator Interactions allows researchers to easily search on which insects and mammals pollinate which plants. To make it simple for researchers to gather the references to papers they need to look up, their website allows downloading of search results as a CSV file.

This is powered by a little bit of AJAX, when a searcher clicks the download button, Javascript calls on a PHP script which reads the search filters out of a cookie, compiles the results into a comma separated file, and lets you download it.

However, the site had a bug (no pun intended). If you ran a search and downloaded the results, then ran a different search and downloaded the results, you got the same file of results, even if the search was completely different and the results shown on the page were correct for the search.

This turned out to be because the live server was set up to cache pages where possible, whereas my development server was not. The call to the script that made the file was on a URL that did not change, as it read what it required from a cookie. So the browser thought it was hitting the same URL each time the download button was pressed, so to help speed things up served up the file for download from its cache, rather than requesting a new one from the website.

The fix for this was quite straightforward. In the PHP script that received the call from Javascript, I added these headers at the top of the code:

header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");

Having them all is probably overkill and I should go back and find which one really does the job for them.

This makes the script send headers when the browser requests the URL saying not to cache what is sent back. So the browser will request it fresh each time the URL is called.

Now, when the button is pressed, a new CSV is always requested rather than the browser providing the one it has already received. Problem solved.

My first Stripe integration, using PHP

Recently I carried out my first integration to the new (to the UK) payment processing provider Stripe. My client Jasper Goodall was looking at moving to Paypal for taking payments and having integrated with Paypal in the past, I suggested Stripe as a more developer and client friendly alternative. He liked the look of Stripe and signed up.

I was moving the site from using Sagepay over to Stripe and as all the basket and post-payment logic was written, dropping in Stripe was very straightforward. Their documentation is very clear, testing is simple, and taking a payment is a doddle. I hit a few minor issues, which were:

PHP needs ‘mbstring’ turned on

My local PHP 5.2.4 install didn’t have mbstring on by default, so I had to install it. This was on my Windows PC so I had to move the mbstring DLL in to the main ‘php’ directory and edit the httpd.conf file to include the DLL as one that needed to be loaded. I then restarted Apache and it was working fine.

My host did have mbstring turned on, so I didn’t need to change anything there.

Secure certificate required

My client didn’t have a certificate to allow his to use SSL. However his host, Claranet, had a shared secure area that all of their customers could use without requiring their own certificate. This was good, but I had to re-code parts of his site so things like the stylesheets would load properly when using this area.

If you or your client are on shared hosting with one of the larger providers, it’s worth checking to see if they have a secure area you can use before investing in your own certificate. This can save you some money, but has the disadvantage that the URL of your secure pages won’t show your domain in that part of the website address, which may make some customers suspicious. It will be worth adding some text to your pages explaining how they are secured if you think that is going to be a problem.

Coding up receipts

Previously, we were using Sagepay which takes various information about the products in the customer’s basket and builds an e-mail notification of the sale for you. Stripe just take the amount of money you are charging, so I had to update the website to create a notification for the customer, and one to tell the client a sale had been made. These were very simple additions to the post-sale process.

Overall, Stripe was a delight to integrate with. I’ve set up shops using several payment gateways – Sagepay (was Protx), Worldpay, Secure Trading, Paypal, and Paypoint. Stripe was by far the easiest, taking only a few hours to integrate with including the bug fixing of my setup and the re-coding of the existing shop to send the right information through and use the extra secure area of their hosting. If you were starting from a cleaner base, you’d probably be looking at an hour or two including reading the documentation. Really nice.