Have you ever had to debug your shop while it is live? Maybe you installed a module that is not working, or a bad update and you need to figure out what is wrong with the shop with out your customers seeing all of the printed out debugging messages and hurting your sales. Or maybe you are like me and you are trying to optimize a site, but you do not want everyone seeing the debug profiling messages at the bottom of the screen. The other day I was talking to Tomer at Presto-Changeo about it mentioned that during his speech at Prestashops’s most recent Barcamp he went over what he does. He use’s a little piece of code in the defines.inc.php that checks his IP address. Awesome idea I thought, but I have expounded upon it a little.

What You Do

You are going to need to ftp into your site and edit your /config/defines.inc.php file. Basically what I have done is added code so that when you use a query string, you can see the debugging errors and the profiling print outs. This is a pretty simple modification, if you look at the image below, the highlited lines are what I have added to the file.

Also, instead of typing the lines out, you can use the gist below and just replace the whole defines.inc.php file. As a note, this file is written for Prestashop 1.6, but it should work with all 1.5 and 1.6 versions.

Once you have this in your defines file, you can access the debug profiling and the error reporting simply by adding ?error or ?profile to the end of your sites url. Like site.com?profile will show you the debug profiling of your site. Site.com?error will show you any error messages. If you have any problems implementing this modification, drop us a line and we will give you a hand.

by Lesley Paone is an expert in Prestashop and SEO related to e-commerce sites. He is the owner of Nashville based Designhaus42, a leader in Prestashop development with clients all over the world. In his free time he is a global moderator on the Prestashop forums and is very active in the SEO moz forums.

I receive a number of emails every week about speed optimization for Prestashop. People ask what I do, how it works, what can be expected, and other questions about the optimization process. I figured there is no better way to illustrate what is done and how it works then to show exactly how I have optimized one client’s site.

Patrik from Sweden contacted me about his Prestashop 1.6 site needing to be optimized. He just had a Template Monster theme installed and the site was not performing like he wanted. The first thing I do when figuring out how a site needs to be optimized is run it through the tools that I use. I use 3 main tools to check a site for optimization; Pingdom, GT Metrix, and Kraken.io. Each tool I use has a different purpose for me.

Kraken.io

With Kraken I look at the images on the site and see how much optimization can be made. By optimizing the images, I can speed up the site, because less information is being downloaded. Sites vary wildly with image optimization, some hardly need any, while others have several megabytes that can be removed by optimizing the images.

Looking at the results from Kraken, optimizing the images will only save 22kb. That is not too much, but it is still worth it.

Pingdom

Next I run the site through Pingdom to see if I can see where any bottle necks are. Pingdom is great for trying to diagnose whether an issue is server related, network related, or database related. You can see in the image below that the wait time is about 2.5 seconds. That means when the file is requested from the server, it takes the server 2.5 seconds to start sending any information. Since Prestashop is database driven, to me this means the site is more than likely stressing the database out.

GT Metrix

Next I run the site through GT Metrix, this give me the most complete overview of what I will need to do on the site and the gains that can be expected. Looking at the image below I can see the main things that need to be worked on are enabling Gzip on the server, using Prestashop’s CCC, and a several other small adjustments.

Getting Started

The first thing I am going to do with the site is turn on CCC and the Apache optimizations in the backend. Once that is done, I am going to start going down the list and looking at what can be optimized from the GT Metrix list.

Optimizing Image Sizes

In the two pictures below, both image area’s use the home_default image, but they are both scaling them to two different sizes in the theme. The natural image size is 270 x 270, but it is being scaled to 208 and 228 by the theme. So what I am going to do here is actually make two separate image sizes in the backend for each of those modules, this is so the images are created the size they need to be and are not scaled in the HTML.

Upon further inspection, I can see the theme is configuring the images wrong. The theme set the wrong size for the images because the theme actually created that image type. Also it is using that image type in two places with different sizes. So what I did was change the tm_home_default to be generated at 208 x 208 for use in the Home Featured module. Then I created another image called tm_specials to be used with the Specials Block. After I did this, I need to regenerate the images and also edit the Specials Block template file to use the new image name.

Next you can see where GT Metrix notices that images dimensions are not specified in the template. From the looks of the image sizes that are not specified it is the Specials Block and the Home Featured modules that need to be edited. To fix this I edit the template files and add the image dimensions in.

Then I install the Smushit module from PrestaTeamShop and optimize all of the images on the site. The Smushit module is a pretty neat module, it will optimize images as you upload them on to the server. The way that I use it during an optimization is that I install it and optimize the images, then I uninstall and remove it. This keeps me in the licensing agreement. But I would highly recommend buying a license and keeping the module installed so it will optimize the images that you add after the optimization.

Once the images are optimized, I can see that the Font Awesome file is loading with a query string attached to tell the version number. In this theme, it is in the global.css file, so I edit the file to take off the version number. Appending a querystring to a resource like that will cause the resource to not cache, and you do not want that.

Since the site is hosted on Cpanel, the next thing I do is set up a pseudo CDN for the site. This basically uses a Cname to tell a directory to load from the site root. I use this to set up media servers without actually having a CDN site powering them. This will provide more download channels for the site and the site will download quicker.

Finishing Up

To complete the optimization process I use a the Express Cache module from Xtendify. This module has helped every site I have installed it on by leaps and bounds over not using it. What the module does is cache the whole pages in the database instead of having to make hundreds of database calls like Prestashop does on a page load.

Results

I left a few steps out in the optimization because they were repetitive, but I imagine you have an idea of what goes into the optimization of a Prestashop website. The important part now is the tests to see how much the site has been optimized. First let’s start with GT Metrix.

You can compare these test results to the one before, the site has decreased the requests by about 66%, decreased the file size by about 75%, and cut the loading time to less than one fourth of what it was before. One thing you have to take with a grain of salt in using GT Metrix is that they do not have as good of a network connection as Pingdom has.

Now I am going to look at the site with Pingdom, they have a testing server in Amsterdam, so the results will be more accurate on load time.

The results of the optimization really stand out in this test, the site went from loading in a little over 4 seconds to loading in almost one second. The requests and the site size is still down about the same as with the GT Metrix test, but by using a testing server in the same region as the site, you can really tell how well the optimization worked. Since this site targets that region, users to the site will have the best possible user experience because the site loads very quickly.

Cost Involved

It is impossible to price a site optimization without seeing the site that needs to be optimized. Every version of Prestashop has version specific tweaks that can be applied, every theme needs different optimization techniques, and every server operates differently. As a general rule our optimizations start out at $200 and go up from there. If you would like a price to optimize your site please contact us and we can give you a firm quote.

by Lesley Paone is an expert in Prestashop and SEO related to e-commerce sites. He is the owner of Nashville based Designhaus42, a leader in Prestashop development with clients all over the world. In his free time he is a global moderator on the Prestashop forums and is very active in the SEO moz forums.

If you are not using Prestashop 1.6 yet, you really should check it out. It has a redesigned back office, template, and a lot of speed enhancements as well. One thing you can do to further optimize the loading performance of Prestashop is to use Media Servers, otherwise know as a CDN with your site.

Setting up the Media Servers

I chose to go with MetaCDN with this article, because I have heard a lot of good things about them lately, but I haven’t had a chance to check them out yet. One of the great things about MetaCDN is they have a 14 day free trial that does not require a credit card to test out.

Once you sign up for an account with them and validate it, you will be taken to a page that looks like the image below.

If you click on the lightning bolt it will take you to the area where you can add your website information. If you look at the image below you can see the information I added for the website I am optimizing. If you notice I have added 3 different CDN addresses, because Prestashop supports having 3 media servers. Also notice how I have small selected for the site. This actually refers to the files sizes, not the size of your site. If you have a lot of files over 10mb, use the large option, which no e-commerce site should really have.

Once you have the information entered you will be directed to another page. On the next page you will need to copy the accelerated domain address. You will need this address in just a minute to set up your cname’s in your cpanel.

Setting up the Cname in Cpanel

Next you are going to want to log into your cpanel account so that you can set up the Cname aliases so that your media servers will work off of your site’s domain name. Once you get logged in you are going to need to click on the “Simple DNS Zone Editor” like in the image below. If your Cpanel does not have this for some reason, you will need to contact your host and tell them what to add.

Once you are in the editor, you will need to enter the subdomain that you want to use in the top box of the Cname Record and then you will need to enter the information you copied from MetaCDN in the bottom section, like in the image below.

Once you have that information entered it might take 10 minutes to an hour until the subdomains work correctly, so you might have to wait a little while. Make sure you make an entry for each subdomain that you created in MetaCDN as well. All of the subdomains will point back to that same address that MetaCDN gave you, no matter how many subdomains you use.

Setting the Media Servers up in Prestashop

Once you have confirmed the media servers are working, you can do this by going to the subdomains and your site should load or redirect you to your site, you can add them to Prestashop. You will need to go to Advanced Parameters then Performance to add them, you simply add them like in the image below. Notice how you do not need to add http:// to them to make them work.

After you have added them, that is all you need to do. I would test your site to make sure everything works correctly, some lower quality themes that were not professionally written might have problems with them, but for the most part all themes should be compatible.

by Lesley Paone is an expert in Prestashop and SEO related to e-commerce sites. He is the owner of Nashville based Designhaus42, a leader in Prestashop development with clients all over the world. In his free time he is a global moderator on the Prestashop forums and is very active in the SEO moz forums.

You might not know what a cron job is, but it would make your life easier if Prestashop had one. So many wonderful and amazing features could be unlocked if Prestashop took advantage of this technology that has been around for decades. If you are unfamiliar with what a cron is, it is a schedule task on its simplest sense.

Things you could do if Prestashop had built in cron functionality

• Schedule Products. You could schedule products to be active and in active based on the times with a cron job. An example would be if you were selling a product that could not be sold before midnight on a certain date.
• Schedule Slides. You could easily schedule slides to be active / deactivated at certain times based on dates. Like in the example above, you were selling a product that has to be released at midnight, you could have a slide appear at midnight to advertise the product.
• Currency Rates. Currency rates could automatically be updated without having to put a manual job together.
• Clearing the Cache. The cron configuration could automatically be set to clear the Prestashop cache to keep file on disk size down.
• Schedule Shop Maintenance. With a built in cron, you could schedule things such as deleting old abandoned carts, deleting products that are older than a certain date, or even changing shipping rates on a specific date.
• Schedule Better Sales.  It would be easy to schedule sales that involved multiple items like say for one day only you want to offer an xbox with a game on sale, or for even one hour, you could.
• Search indexes and Layered Navigation indexes could be automatically rebuilt. This would be especially useful if you were running a product feed that updated automatically.

How it could extend modules

• Shipping rate caches could be deleted.
• Abandoned cart emails could be sent automatically.
• Modules could be enabled or disabled depending on the date.
• Modules that generate feeds such as Google Merchant of Amazon modules could automatically update and sync with the services.
• Things I haven’t even thought of yet. (No seriously, special modules could be designed around it)

In my mind the best way to handle the cron would be to have a hook dedicated to it that modules could hook into. That way modules that were compatible would be able to use the cron feature and modules that were not compatible would not be able to use it. Also I think a setting in the back office to adjust the cron settings would be needed. Something where you can set how often you want the cron to work. Also, at the same time I purpose that their be two types of cron’s, the poor mans cron (or pseudo cron) and a fully functional cron that has to be set on the server. This would give flexibility to people that do not know how to set a cron job on their server.

Update

It looks like we were heard by PrestaShop. They responded to my feature request and said they just started working on one. Also I noticed that there is now a cron module on the github for PrestaShop as well. This is a great feature that I think will help keep PrestaShop as the best e-commerce platform in the world.

by Lesley Paone is an expert in Prestashop and SEO related to e-commerce sites. He is the owner of Nashville based Designhaus42, a leader in Prestashop development with clients all over the world. In his free time he is a global moderator on the Prestashop forums and is very active in the SEO moz forums.

Support with PrestaShop is one of the main issues my clients bring up to me, not knowing where to get it or how much to pay for it. I would like to announce that we are now offering support for PrestaShop to everyone. In the past we just offered support for our existing clients, but we have felt it is time to make the move to start offering support packages to everyone.

Why?

This is something that I have asked myself too, why would we want to deal with the absolute worst aspect of programming. But I always come back to the same thought, we are problem solvers and love to solve problems. Having worked with PrestaShop so long, we know all of the ins-and-outs of development with it. We know version specific bugs, we are basically know it all’s about PrestaShop. We have been providing support on the PrestaShop forum for years, so more than likely anything you experience, we have seen before and know how to correct.

Certified

I almost forgot to mention that we are a PrestaShop certified agency as well. That means we uphold the highest standards of customer support and the highest standards of quality in our coding as well. We are actually one of the only certified agencies that offers end merchant support.

Why Chose Us?

We think the choice should be pretty simple, but that is us. The main reasons are that we offer the lowest cost support plans and we have the best customer service. Some of our competitors only offer support for a few hours a day. We offer support for 24 hours a day 7 days a week. We understand the implications if your payment gateway goes down on Black Friday and what that can mean to your sales. At the same time our plans are all inclusive. What that means is some company just offer “support” that does not include any development or any custom coding. We look at it all the same. You are our client and you have bought time from us. If you want something custom coded and it can be accomplished in the time of your support package we will do it. If you want us to upload products, sure. If you are lonely and just want to talk on the phone, we can do that as well.

Take a look at our support plans, if you see one that might fit your needs feel free to contact us and ask us questions about it. Or if you do not see anything that fits your needs, contact us, let us know what you need. We have several clients with custom support plans that include everything from server monitoring to server deployment. You can view our support plans here.

by Lesley Paone is an expert in Prestashop and SEO related to e-commerce sites. He is the owner of Nashville based Designhaus42, a leader in Prestashop development with clients all over the world. In his free time he is a global moderator on the Prestashop forums and is very active in the SEO moz forums.

Lately I have had a few clients inquire as to how scalable PrestaShop is and what kind of set up would be needed to scale PrestaShop to a site that receives a lot of traffic. By a lot of traffic we are talking thousands or tens of thousands of concurrent users on the site at once browsing around or making purchases. Configuring a site like this is a whole different ball game than configuring a PrestaShop site that gets a moderate amount of traffic and sales.

The Basics

To make the PrestaShop scalable the first thing you need to do is optimize it. Which is also the last thing you need to do as well. Weird right? I will talk more about the final optimization at the end of the article, lets talk about the first optimization now. I use the general optimization best practices when optimizing a site for scalability. Here is a brief list of things that I do.

• Unhook modules that are not being used
• Set the server up in a thread safe php interpreter like fcgi
• Install mod_spdy
• Optimize the css/js/and html content of the site
• Optimize the images
• Install an Opcode cache, I like APC still
• Install a caching module, I like the one from Xtendify
• Make sure all of PrestaShop’s caching is enabled, even the APC cache, because I run APC

Once those things are out of the way the site should run fairly quick with no load on it. If set up properly you should be looking at under 1 second page load times. But they will grow as more users hit the site.

The Platform

I generally choose AWS for the platform of high traffic sites. The reason being is that it has a lot of built in features that will handle the load well. The best instance for loading PrestaShop sites is the M3 instance, it does load the fastest from the tests I have run. At the same time though, the M3 instance is expensive for the performance gains that you get. That being the case I usually recommend C3 instance types. They are the best all around instance for PrestaShop when price is a factor.

The Setup for High Traffic

From the testing I have done a C3 Xlarge instance will handle around 600 concurrent users, just depending on how well the site is optimized, how many products are displayed on a page, and what modules are running. If you have a resource intensive site you will need something bigger. But 600 concurrent users is not a lot in the grand scheme of things if you run a high traffic site. How to you do it? Do you run a load balancer in front of your instance and spawn more? No, you will wreck your PrestaShop installation if you do that.

The first thing you need to do when considering high traffic with PrestaShop is to break your database away from your actual php files. Set up a RDS instance and run your database from there. Generally RDS instances are slow I have found, but a good mix that can return fast results is using a large RDS instance with 2000 PIOPS. That should handle around 3000-5000 concurrent users and start dropping rapidly when more users join the site.

Load Balancing

So currently the database can handle around 5000 concurrent users, but the instance that the main site files are on cannot. What do you do? You can try growing the instance vertically, but it will not scale in the manner you think it will. Doubling the instance size will only add about 25% more users concurrently. The best practice to do in this situation is to move an Elastic Load Balancer in front of the instance. That way you can spawn multiple instances the same size to deal with the load. When you set a load balancer up in Amazon, one thing you have to take into account is that PrestaShop uses session cookies. If you transfer one user to another node during their session, the cart will be lost. Elastic Load Balancers have an option called sticky sessions, you will need to enable this so that users are kept on the same node and cart data is not lost. Normally you can run about 5 -8 C3 XL instances  off of one properly configured RDS XL M3 instance.

When you start spawning instances with a load balancer there are several major considerations to keep into account. The absolute best practice in operating a site like this is doing it this way. Keep the site files in a repo like github or something similar. That way you can push changes live. But another consideration you have to take into account is the spawned instances and their dependencies. What I recommend as the best practice is when you have your deployment code, build an Amazon Machine Instance off of it that can be spawned. This is essential in making a deployment with an Elastic Load Balancer in front od AWS instances. The reason being is that everything needs to be in sync. The way that you keep the instances in sync is to use a S3 bucket for a few directories. Since we have sticky sessions turned and are using one database, if someone uploads a new product, the image will land on an instance. But at the same time the product will be added globally and no one off of that instance will be able to access the product image. So you have to create an S3 bucket for the following directories.

• /img
• /cache
• /themes/theme-name/cache
• /overrides

When you build your AMI you will want to dynamically link in the S3 bucket so when the instance loads it will load your buckets that have the files needed for the bucket to link properly.

More Users

So we have covered how to handle 3-5k users at once, but what if you need more? If you need more, the weak link is going to be your database instance. You can grow it and it will handle more, but AWS is set up to scale horizontally, not vertically. So what you will need to do is to start spawning read replicas. RDS instance can have what are called read replicas or slaves. These database instances are only used for reading information, all of the storage is sent to the main database and replicated across the network of databases to be read. These are the backbone in scaling up from the base of 3-5k users. Using read replicas you can scale a site to around 20k concurrent users before any major code changes need to take place. Just to give an idea of what 20k concurrent users is in normal traffic, that would equal about 12 million users a week or close to 50 million users a month.

The Last Optimization

When I started this article I mentioned that their was a final optimization. The final optimization does not become apparent until you are load testing the site, so it varies greatly with each site. One site we have worked on for instance did not need to respect any stock, everything was custom made. So instead of using PrestaShop’s smarty cache, we wrote a custom system that actually wrote every page to disk in its path as a html file. That way pages were loaded as static html pages and it really increased the throughput of requests by almost doubling them per instance. Other times we have modified the default queries that PrestaShop uses. If you exclude a table here or there, you will never notice it on a site that does not have a lot of traffic. But when things are scaled up, everything is scaled up. If an extra table was adding 1 millisecond to a query with 1 person on a site, when it has 5000 people it adds 5000 milliseconds over the span of the queries. It becomes more noticeable.

The fact of the matter is that every site is different and the approach to developing a high capacity site varies greatly from site to site depending on the sites needs. One thing that I left out, because their was no place to really insert it is that I run CDN’s in front of these sites. PrestaShop calls them media servers, but they are the same thing. The reason I run them is that the latency for external requests to a S3 bucket are too high. They could be run natively off of Amazon, but I have found that it does not deliver the best performance plus you are hitting the bucket through several round robins and they are not meant to serve that much data up that quickly.

Are you looking to run a high capacity PrestaShop site? Are you wondering if PrestaShop is the best solution for your high traffic site? Contact us, we will give you a free assessment and let you know what we think.

by Lesley Paone is an expert in Prestashop and SEO related to e-commerce sites. He is the owner of Nashville based Designhaus42, a leader in Prestashop development with clients all over the world. In his free time he is a global moderator on the Prestashop forums and is very active in the SEO moz forums.

Have you heard that on December 3rd that most installations of PrestaShop that use Paypal will break? It is true, while there has been no official announcement from PrestaShop about the matter, Paypal has tried to keep everyone in the loop. The sent out a mailing a couple of weeks ago. 

Who is affected?

Every version of PrestaShop is affected, especially older versions that have not been updated or modules that have not been updated in a while. It looks like the latest versions of the PrestaShop Paypal modules have been fixed to take care of the issue, but some shops cannot update to the latest versions.

Why is this happening?

Paypal has decided to stop supporting SSL version 3, in doing that they are making all payment connections use TLS instead. The reason they are stopping support for SSL version 3 is that several bugs have been found in to recently and it is no longer considered secure. TLS is the current replacement for SSL in sever connections. So it is considered more secure than SSL version 3, no bugs have been found in it.

Some More Information

If you would like further reading on the matter there is a great thread on the PrestaShop forum by one of the moderators and also the owner of Presto-Changeo (my favorite PrestaShop module development house).

Forum Link

Also a good friend of mine and the owner of NemoPS has released some patches for the Paypal modules too. You can get them here:

Paypal Module Patch

If you require further assistance with these fixes or you do not feel comfortable doing them yourself we can always fix them for you. Don’t hesitate to contact us and we can get you fixed before the deadline.

by Lesley Paone is an expert in Prestashop and SEO related to e-commerce sites. He is the owner of Nashville based Designhaus42, a leader in Prestashop development with clients all over the world. In his free time he is a global moderator on the Prestashop forums and is very active in the SEO moz forums.

I had an interesting experience with a module this week and I think it deserves to be written about. I had a client that was using a gateway called SkyBank, I hadn’t heard of them so I did not think there was a PrestaShop integration for their gateway. In searching there is actually one and it comes from the PrestaShop Addons Store.

Setting it up

Setting it up was fairly straight forward but I noticed a few things that I have not seen before with a PrestaShop payment gateway that piqued my interest. Below is a screen shot of the module configuration screen so you can see what I mean.

Most of the settings are normal payment gateway settings, but there are a few that stand out for me. Mainly it is the autoship, the option to take checks, and the cron setting. I haven’t seen these before in another PrestaShop module so I honestly did not know what they did, but they sounded interesting.

Awesome features

So in looking through the documentation I figured out the ACH was about accepting electronic checks, that is pretty straight forward. But the autoship was actually pretty cool. What it does is allows people to create orders and have them shipped automatically at their choosing, kind of like Amazon. On the front end of the shop it looks like this.

Customers can chose the interval between their orders to have them shipped. This is great for sites that sell consumables that people will need at set intervals, like e-cigarette juice, razor blades, or even dog food. They can also manage their auto-ship order from their account so they can delete or change the interval of the auto-ship.

And here is the order management area.

From the backoffice you get a very similar view since the module installs a new menu item in your order tab. In the new menu item you have the ability to manage the auto-ship orders, the module even marks the orders as auto-shipped in your order view, so you can accurately look over the orders and know where they came from. Here is a view of the back office autos-ship area, before any orders were entered.

The more I read the documentation for this module, the more I was blown away. I have worked with dozens of payment modules for PrestaShop and not seen one that comes close to this feature set, even some of the expensive paid ones. I looked into the code on how the auto-ship works and it is pretty sound. What it does is store the customers credit or debit card number on the gateway, then it uses a token to charge their card back. That way you are not storing credit card information in your shop, the gateway is handling it all.

Another interesting feature I noticed was how it handled refunds. When a payment is made, it only gives the choice to void, not to refund the payment. I thought that was weird, but reading about it made me understand what it was doing. If a payment has not yet batched, you can void a payment and the customer will get the money back to their account immediately. If you refund the payment at that point, it will take them a couple of days to get the money back. That is a pretty awesome customer service feature. So once the payment has batched, the void button changes over to a refund button that will let you refund a whole order, or just a partial refund of any amount you want. That is a feature I have always liked, because sometimes you need to retroactively give an unsatisfied customer a discount.

Bottom Line

I have been developing in PrestaShop for 5 or 6 years now, it is not very often that I am surprised by a module, but this one truly surprised me. It really opens the door to a lot of possibilities of things that used to require expensive custom development. From the testing I did with my clients shop everything seemed to work flawlessly as well. I would highly recommend this module to all of my clients looking for a payment gateway.

by Lesley Paone is an expert in Prestashop and SEO related to e-commerce sites. He is the owner of Nashville based Designhaus42, a leader in Prestashop development with clients all over the world. In his free time he is a global moderator on the Prestashop forums and is very active in the SEO moz forums.

With another great year coming to a close I thought it might be helpful to share the insights and some short comings with PrestaShop I have noticed in the last year. PrestaShop is a great platform, it probably has one of the most powerful feature sets of any ecommerce platforms, but at the same time it has its short comings as well.

Change Password Handling

We are coming into 2015 and passwords are still being sent out in plain text. Granted, they are not stored in plain text, they are stored salted and hashed; but still they are sent out in plain text. This is considered insecure on so many levels. No platform serious about security sends out passwords in plain text anymore. You expose your site and your customers main in the middle type attacks and also risk their payment security. As more payment modules get a deeper integration with PrestaShop, this becomes even more troubling. Several modules support storing tokenized cards now, so this poses an even greater risk as time goes on.

Upgrade Swiftmailer

As far as I know there are not any open attacks on the version of Swift that PrestaShop uses, but I would not bet that one could not be made. The version is about 7 years old and does not properly support TLS the current standard for mail connections. What does that mean for you? PrestaShop has an SMTP feature that you will never be able to use. It will never connect to services like Mandrill or Gmail, because their connection types are not supported. There is a module from Bellini Services that does upgrade the version, you can get it here, but why even have the option present if it will never properly work?

Focus on Speed

To be quite frank, PrestaShop 1.6 is the slowest version of PrestaShop to date. The queries are inefficient, and site load times suffer dearly from them. The image optimization if better than the previous version, Javascript is moved to the end of the document, so that helps as well. But even with all of that, too much time is spent querying the database. You can optimize the front end of a site until your Google Page Speed score is 100%, but if your site takes 5 seconds to start sending out information from the database, it is still taking 5 seconds. This needs to be addressed yesterday.

Stop Adding new Functionality, Fix what is Broken

If you look at the change logs from version to version of PrestaShop you will notice that there are always new features added. I am of the opinion that new features only need to be added in major versions, unless it was a detrimental omission. But still, new features keep popping up and submitted bugs just get closed. It seems no real effort is put into trying to reproduce bugs anymore, and if the bug is a hard fix, it is just labeled a feature request and abandoned until someone’s feet are held to the fire. This is bad practice and it needs to stop.

Easier Upgrades

Upgrades are still a pain to be honest. It should not be this way. One of the main reasons that upgrades are an issue is the ever changing roadmap of PrestaShop. The development flow has taken on an illogical process and continues to be just plain messy. The database schema is not the same from subversion to subversion, new features are added and old ones taken away from subversion to subversion. It is almost like an every man for himself development team. Some one gets a new idea and adds it, someone finds a feature to hard to fix, and takes it out. This madness needs to stop and a roadmap needs to be published.

Restoring Previous Features

When the update to 1.5 from 1.4 happened, several features went missing. Then when the update to 1.6 from 1.5 happened, even more features went MIA. What I imagine happened was during the rewrite, the features were to time consuming to add back in, so they were left out. You can no longer edit the .htaccess file from PrestaShop, there is no way to change the legend on product images, and a host of other basic features that were lost. Some time needs to be spent on bringing the product pack up to what it was, not adding new features that are useless to most shops.

Re-Factor the Default Template

It was nice that PrestaShop adopted bootstrap, but the implementation of it was not friendly at all. The CSS it overly bloated with selectors that are not used, or selectors that could be refactored to use existing selectors. I am all for having each element on a page having a selector, but even so, that does not mean the selectors have to be used. They can be unused but available allowing for modification at a later date. The CSS in 1.6 is so bloat that it will not run on IE without CCC enabled, even with it enabled there are still errors. The the theme needs to be taken back apart and put back together with better CSS usage and less bloat in the CSS files.

Keep People Out of Code

I have tried to stress this one so many times, but it always falls on deaf ears. The reason Shopify has taken hold is that it empowers users to make simple changes without having to be coding experts. The same thing with WordPress as well. PrestaShop needs to quit relying on 3rd party modules to handle what should integrated features. Features like this add no processing overhead to the frontend of the shop, but they add a richness and ease of use to the end user. There needs to be basic modules for editing the .htaccess, robots.txt, css files, and adding code to the header and footer template files. These are no brainers that would make PrestaShop more readily adopted by end users.

In saying all of this, PrestaShop is a great platform, I just want to see it grow into a better platform that is adopted by more businesses. It has the power, and the features that business needs, it just needs some minor tweaks to get back on the right path of delivering what the market wants and needs.

by Lesley Paone is an expert in Prestashop and SEO related to e-commerce sites. He is the owner of Nashville based Designhaus42, a leader in Prestashop development with clients all over the world. In his free time he is a global moderator on the Prestashop forums and is very active in the SEO moz forums.

We are proud to offer a new service to our clients of load testing your website. Load testing is a great way to establish whether you need to upgrade your server or that your current server can handle your site taking an increased load. The load tests that we generate are different from how other companies set them up, we use real world browsing metrics.

Why Load Test?

There are several benefits to load testing your PrestaShop website. Below are some of the mains ones.

• Find out when you need to upgrade servers
• Know if your site will go down during a big sale
• See how your site loads across several regions
• See how quickly your site loads with users on it

How Does it Work?

We will have a short consultation you with to determine what type of server you are hosted on and what kind of load your site needs to be tested against. We will then develop what are called user scenarios for the testing of your site. User scenarios mimic users browsing around your site, we do not just put the users on the home page, we have them browse category pages, cms pages, product pages, and the checkout process. We can also target your website from several regions at once as well giving you a view of how your site is loading for viewers all around the world.

Example Test

This example test was tested on the PrestaShop cloud. If you are not familiar with it, PrestaShop has introduced a free hosted version of PrestaShop that is on their own cloud network. We tested their servers up to 1000 concurrent users on the site in a 60 minute test. The results were pretty impressive, you can view them here.

Conclusion

We believe that expanding our services to also include load testing we can benefit our clients by preemptively diagnosing issues before their site crashes during a major sale or if it is featured by a major media outlet. You can learn more about our PrestaShop load testing services by visiting our site here.

by Lesley Paone is an expert in Prestashop and SEO related to e-commerce sites. He is the owner of Nashville based Designhaus42, a leader in Prestashop development with clients all over the world. In his free time he is a global moderator on the Prestashop forums and is very active in the SEO moz forums.

If you are like most of our clients you might have bugs in your Prestashop installation or things that are not working quite how you want them to. We are giving away a 4 hour support package to help you get your business on the road to becoming successful. Enter below for your chance to win and good luck!

a Rafflecopter giveaway

Recently a couple of our clients wanted to replace their stock PrestaShop search with a third party search called Algolia. I had really never heard of them but I checked out what they offer. Basically they offload your search to their site and present it to your site in area using AJAX. Seemed pretty cool, I tried out a  few of the demo sites they had listed. I got in contact with them and they already had part of the code base for PrestaShop written, which they shared with me. From there we finished the back end and modified the front end display as well. Then we integrated with one of the sites to test things out with it and how it works.

My Thoughts

To be quite honest, I think the service is pretty solid. It is rare in this industry I am amazed by anything thing anymore, but I can say I was truly amazed by the speed in which it returned search results. It is highly optimized for speed. We have two sites that we have integrated it with, one has a catalog of 3,000 products and the other has a catalog of 15,000 products. Each site delivers the search results blazingly fast. I think the general consensus of people that I have showed it to is “Damn, that’s fast”. Below is a graphic from one of the accounts showing how fast the searches are returned.

One of the nicest features of Algolia is that they can replicate to data to several data center locations around the world. Doing this, search results are served from the closest location to the actual user. This helps with the blazing speed of the searches.

Shortcomings

After using Algolia for about a month, the only short coming that I am coming across is the analytics on the searches. I would like to see more targeted analytics with a way to send user account information back to the search and maybe port that data out to other services. It would be helpful to know what users are searching on your site and when. Also it would be nice to know which users on your site are searching for things. Currently I cannot find a way to link an ip address to search results. Just vague general information is shown.

Conclusion

I can say my view on how fast it is till I am blue in the face, I think it would be best for your to make your own conclusion. This site is using the search with a catalog of just over 3,000 products, test it out for yourself, see what you think! American Quality Health Products

by Lesley Paone is an expert in Prestashop and SEO related to e-commerce sites. He is the owner of Nashville based Designhaus42, a leader in Prestashop development with clients all over the world. In his free time he is a global moderator on the Prestashop forums and is very active in the SEO moz forums.

We get asked a lot where we recommend clients to host their PrestaShop sites at. As a development company with clients all around the world we have experience with hundreds of hosts, we know all of the ins and outs of most of the popular hosting companies. One thing that is important about this article is that is does not included shared hosting. All shared hosts are pretty much equal and not really suited to host a PrestaShop website in my eyes. PrestaShop takes a good amount of processing power sometimes to work and we have seen a lot of PrestaShop sites taken down by shared hosts for using too many resources. These recommendations are purely for VPS and dedicated level hosting.

Who we do not recommend

First before we get into who we recommend, I want to tell you who we do not recommend and why. Could your current host be causing you problems and you not even know it.

Inmotion or A2

Generally I cannot recommend any host that chooses to use a type of PHP called DSO with PrestaShop. It just does not play well with PrestaShop. The speed is not there, which is a main reason in getting a VPS or a dedicated server. Also both companies tend to not give you root access or any freedom on the machine set up. From our experiences with both companies, if you try to use a setup that is not their default, they will no longer support your machine.

Godaddy

I don’t think I can say enough bad about Godaddy. They sell consumer grade machines that were never meant to be dedicated servers. They also use a mysql farm for most of their accounts. Which means even though you have a dedicated machine or account, your database is hosting with a bunch of other clients on a separate machine. This is troubling because their resource usage will affect yours. At the same time this adds a latency in the database requests slowing the site. Also, I have not gotten over them supporting SOPA either.

Bluehost

Bluehost used to not be a bad host, but they have fallen into the hands of EIG which is a company that is known for buying hosts and then lowering the quality of the support. I have see over the last several months that the support quality and also the datacenter quality has dramatically gone downhill. They use a main datacenter out of Provo Utah that seems to have massive failures resulting in days of down time. Also, their staff is less than knowledgeable because of the turn over rate at the company.

 AWS, Digital Ocean, and cloud hosting

These seem like a good choice at first and for small site they often work well. But there is no management at all and running cpanel often costs an arm and a leg. But the real issue I have noticed with cloud hosting is the mid level performance is not good at all. If you have a site that is doing more than 100 or so visitors a day, it normally will suffer. It seems the machines might be compute optimized and the storage latency could be the issue. What ever the issue is, they just do not perform without a lot of tweaks and having an expensive setup. Most of our clients that move over to a cloud host after having been on a dedicated machine usually realize a 4 to 8 fold increase in the cost of hosting. For a lot of people that is just not acceptable, so we do not recommend AWS unless we absolutely have to.

So who do we recommend?

We recommend a hosting company called LiquidWeb. They have an outstanding selection of servers and can do some pretty custom setup’s as well. A setup we tend to use a lot with our clients is two SSD drives for the database and 2 spinning drives for the files. With 8gb of ram you can keep a great cache running with all of the executable files stored compiled in memory already. We have several dozen clients with them and everything has always been outstanding. They provide some of the best support in the industry in my opinion. One thing I will note is they are pricier than some of the other hosts. The price comes from the way the servers are set up and the level of support you are paying for. They do support FCGI and APC out of the box, which most hosts these days do not. That is also another major factor that influenced our decision to use them. If you need to upgrade your hosting you should check them out. They are who we use and recommend.

by Lesley Paone is an expert in Prestashop and SEO related to e-commerce sites. He is the owner of Nashville based Designhaus42, a leader in Prestashop development with clients all over the world. In his free time he is a global moderator on the Prestashop forums and is very active in the SEO moz forums.

Sometimes getting people to your site is not the problem, it might be getting them to finish the checkout process that is the sticking point. We have found this to be the case with several of our clients that target markets with either an older audience or an audience that is not as technical as other audiences. But what do you do to coax people to complete their order? A couple of months ago we were sent a module that replaces the standard PrestaShop checkout with a newer sleek module. The makers PresTeamShop want us to test the module out. We were actually about to redesign a checkout for one of our clients, so this was a great opportunity to test the module out on a live site, instead of just playing with it in a development environment.

Looking at the module

When you install the module, you have to enter your email and purchase number to get a registration code. With that code you can unlock the module and start using it. This process only takes a few minutes. Out of the box we did not have a single issue with installing and activating the module.

The configuration is pretty straightforward, you can enable a lot of options with the checkout, the first two we used were making the registration form smaller by removing the company name field and the identification field as well. Next we added the name field to the invoice address area. The site we were working with has a lot of people that purchase the items for gifts, or for people that are not tech savy. We had actually been looking for a solution to this issue for a while and this module fit the bill.

The feature list of the module is actually quite extensive, but we would like to highlight a few of the ones we liked best.

• Ability to disable payment methods via selected shipping method
• You are able to remove or add custom fields to the registration
• You can hook Google Address API in for autofilling the registration address
• Removing the terms of service
• Selecting the group customers are added to
• Adding a different name to either the invoice or delivery address
• Moving field locations
• Social login integration
• Show remaining amount for free shipping
• Plus about a dozen more features…

Here are a few shots of the configuration screens.

When we first started testing out the module we did not realize all of the features that it came with, this was a great added bonus. Especially since we provide support and have had a very lackluster experience with some of the other one page checkout modules our clients have used. Not this module though, since we have tested it we have also used it on 4 of our clients live sites and not had a single issue with any or them, even the ones that use custom templates. Below is a screenshot of what the checkout looks like in action.

You can see it totally changes the layout of the checkout and makes everything front and center where no scrolling is required. This is our favorite part of the the module. People can see everything they need to do without having to scroll through a long page like the default one page checkout is in PrestaShop. This makes the checkout process easier to work and more understandable.

We did notice something however

Conversion rates increased. We were measuring checkout drop off on several of the sites, we noticed less people were dropping off during the checkout and more were completing orders. In fact we have noticed a gain of 30% in completed carts on average in the sites that we installed the module on. Most of the sites we installed the module on we have long term relationships with, so we are regularly working on them and hearing the owners concerns. This module solved one of the major issues for everyone we installed it with, getting more people to complete orders. In every shop we have installed this module in so far it has made back the cost of the module with the increase in checkout conversions. That cannot be said about very many PrestaShop modules.

We would highly recommend this module, it works flawlessly and it increases conversion rates of people landing on your checkout page. What more could you ask for from a module?

You can purchase the module here.

If you are a support member you can get 13 Euro off of the price of the module with our support perks program. Simply login to your account and go to the support perks page from the menu and you can get the code from there.

We are happy to announce that we have started offering SEO packages aimed at PrestaShop sites. We feel our experience with PrestaShop and our experience with SEO will make this a great union. During the month of December we are offering a free SEO checkup for your site. You can use the form below to register for the checkup.

What is the SEO Checkup?

The SEO checkup will be a full audit of your site against your competitors site. We will look at your site and also you competitors rankings and see where you currently stand. At the same time will will provide a report on your site with vital information that you should change / fix on your site to ensure better rankings. The reports take about 2-3 days to generate, as soon as the report is ready we will email it to you.

This blog post is a bit different from our normal blog posts. This is a response to a comment, so the techniques used in the article are not really of any value unless you are developing a custom theme from scratch. The comment was based on my previous article on PrestaShop 1.7, specifically I called the way that the CCC is being handled as lazy. Julien Bourdeau responded with this “”This is considered a lazy way and bad programming practice.”: Again, I would love to read your source and know what you mean by lazy.” This article is going to illustrate a better way to handle CSS / js in PrestaShop and how it should be designed, but is not.

How it currently works

There is no big secret how the CSS/JS in PrestaShop 1.6 and earlier works. What happens is the hooks are loaded and if your module is hooked to one of them it is added to the CCC queue. There are also some page specific files added as well such as the cms.css, the product.css or .js. Basically every page type has its own cache file created for it. In my opinion this is a good way. Not the best way but a good way, an acceptable way, a respectable way.

How it will work in 1.7

In 1.7 the previous way has been thrown out the window. The way that the CCC works in this version is that it compiles everything sitewide into one CSS file and one JS file. So in effect when you are on the home page you are loading the product page CSS as well. This is what I disagree with on a number of levels and called lazy.

Why is it bad?

I am glad you asked. There are a couple of reasons why I consider it bad practice. The first being the code overhead. When you deal with a software package such as PrestaShop that has a lot of modules, a half a dozen different page types, and very specific code for each page; the file sizes grow. Soon you will have a huge CSS file powering a site. Why is this bad? CSS files load from the top down, loading is not really the issue, the issue comes in rendering. Have you ever been on a page with a layout that jumps around until the page is loaded? If so, that is a CSS rendering issue. CSS renders client side, so it directly depends on the client side processor. Which, in Google’s stats, is a mobile phone more than 50% of the time. Mobile phones have less ram and smaller processors than their desktop counterparts. They are more susceptible to code overhead issues.

Who else thinks this is bad?

Google thinks it is bad. Which search engine do you want to think you are doing everything right? Google, they have the biggest market share. From what I understand, and I could be wrong on this point; the starter theme is a stripped down theme made to develop off of. Let me explain why Google thinks this approach is bad, and how bad it is. Google has started using their Page Speed metric as a ranking factor. It is not one of the higher signals, but this could change at any time.

With CSS in Google’s page speed tool there are 3 levels of grading. The first is passed, which means you did everything right. The second is “Consider Fixing” which basically means there is room for improvement. The third is “Should Fix” which of course means you should fix this. Below is the results of running the new PrestaShop starter theme through the Page Speed tool.

What this means is not only I, but Google as well thinks this is a problem. So obliviously there is a problem with this new method. I realize what PrestaShop was trying to do with this method, they wanted to rely on cache files to increase the loading speed, but this method is not the best approach for a system like this.

I have a better solution

The solution would change how hooking is handled for modules, but should be a relatively easy change for module developers, and it even would have 100% backwards compatibility so module developers could choose not to use it.  Theme developers could also opt to either use this change or not use it as well.

What I would propose is add new hooks to PrestaShop specifically for CSS and JS. Add a new hook for every page type and two positions for every hook. Some like below.

displayProductCSSMain
displayProductCSSSecondary
displayCMSCSSMain
displayCMSCSsSecondary
ect

Also there would be new general hooks added as well. Something like this should work displayCSSMain and displayCSSSecondary. Those can handle the site wide CSS files. Of course this solution does not need to be just used with CSS, the JS needs the exact same system as well.

I am sure you noticed there are main and secondary hooks for every CSS hook that was added. But what are they for? Speed, specifically for rendering speed.

Take a look at this screenshot below of the PrestaShop starter theme.

In this view there are only about 6 modules showing, the language block, the block cart, the currency block, the home slider, the top menu, and the home featured. These modules should hook to the displayCSSMain. Other modules that are on the footer of the site and lower than the fold should hook to the displayCSSSecondary. The reason being is you can deliver a more compact faster rendering CSS file if you do this. Google grades you on rendering.

At the same time the global.css needs to be broken up into two files as well. One needs to handle the above the fold styling, so it is called in the displayCSSMain, while the other needs to handle the below the fold styling and it will be called in the secondary hook.

Sure this approach will take more work and will be a little bit harder. But it will also help site owners in the long run and PrestaShop will be delivering a better product as well.

Wait, multiple requests are bad though

They are not the best thing in the world, true. But when playing by someone else’s rules, I am talking about Google, you have to use their techniques. The multiple resource issue quickly becomes a non issue because of two factors. First is what Google suggests doing with multiple resources, you can read about it here. Their idea is pretty simple. It is to load the page, then after the page loads and renders, make a call for the other resource file. Lazy loading, this has been around a while and can be incorporated into the system very easily for both the CSS and JS files. This actually makes the impact of the site smaller and faster loading and quicker rendering as well. The second factor that comes into play is HTTP/2, it is the newest version of the HTTP protocol. It drastically improves the loading time of multiple resources and combines the request. This is a technology that is supported by every major browser already. So all you have to do to benefit from the technology is to upgrade your server or switch to a host that supports it. To see how much quicker it is, check out this demo from Akamai.

About the lazy comment

Specially to address the comment I made in my last post calling the current method lazy. What I meant is the method used is literally the easiest way to create cache files for a programmer. It takes the least amount of work to do it this way. The previous method was more amount of work. What I feel like is the case is that PrestaShop 1.7 is being rushed out of the door. In the rewrite of this area someone made a decision to just rewrite it the easiest way possible and not the best way. I think if one piece of the software is being written this way, multiple ones are going to be written this way too.

Are you excited about the new version of PrestaShop 1.7 that has been announced? It contains a lot of rewritten code, a new theme, and a couple of new features. The down side about it, is there is currently no installer package for it like the previous versions of PrestaShop. So we decided to make a tutorial to show you how to install it on a Digital Ocean droplet so you can test it out.

Installing PrestaShop 1.7

Now remember, these instructions are only for the alpha releases, when 1.7 is released it will b
e released with an installer like all previous versions of PrestaShop. So don’t worry about it being this complicated in the future.

First we go to Digital Ocean, once you sign up for an account you can select which operating system you want your server to run on. I chose Ubuntu 14.04 because I use Ubuntu as my desktop operating system and I am most familiar with it.

After you choose your operating system (this tutorial might not be any good if you do not choose Ubuntu) then click on the “One-click Apps” tab. From there select “PHPMyAdmin on 14.04”. Selecting this image makes it where you do not have to manage your database from the command line. Once you have selected this image, you can select your droplet size. Be sure to use at least a 2gb droplet. Composer will not run with the 1gb droplet, it will run out of memory. After that you can select the region for your server and create the droplet, you do not need to select any of the other options unless you know how to use them.

Connecting to your server

Once you have created your image, you will need to connect to your server via ssh. You can either use Putty if you are on Windows, or you can use your ssh client if you are on Linux or OSX. After your droplet is created it will look like the image below.

Here you can see the ip address of your server, the user name to login will be root. You should get an email shortly with your temporary password to login to your server. If you are using Putty on Windows start it up and it will ask you for the information to log in. If you are using a linux type operating system press control + alt +t and open your terminal. The command to login should look something like the one below.

ssh root@159.203.112.165

Once you login the server will ask you for your password, you can either paste it or type it in. After you enter your password, it will request it again and prompt you to change the default password.

Once you have changed your passwords, the next thing you will need to do is to update the system. Since Digital Ocean servers are built from images, they might not run the latest version with the latest security / bug fixes. You can update your system using the command below.

sudo apt-get update

Once this finishes it is time to get down to business. First we need to locate our MYSQL password. Type the command below to get your password.

cat /etc/motd.tail

You should see a printout like below with your password. I have pixelated mine out for the screenshot.

Once you have the password, write it down, you will need it for this next step. With whatever IP address Digital Ocean assigned you, go to yourserveripaddress/phpmyadmin from there login with the username root and the password you just copied. You are going to want to create your database for PrestaShop in here. Click Databases from the menu when you get logged in, once there name your database and click create. We named ours prestashop to keep things simple.

Once you have created your database you will need to switch back over to the ssh window to complete the rest of the setup. Once in the window enter the command below and it will take you to the root web folder on your server.

cd /var/www/html

After you are there you will need to install Git so you can pull the development files from the PrestaShop repository. To install Git use the command below.

sudo apt-get install git

It will ask you if you want to install after it loads the files, type y and press enter.

Where it gets more complicated

Now it starts to get a little bit more complicated. Once you install git, you need a public key to use with git. You also need a Github account as well. Type the command below into your ssh terminal and you can create a key.

ssh-keygen -t rsa

It will ask you where you want to save the keyfile, use the below address.

/root/.shh/id_rsa

After you enter the location it will ask you for a passphrase, remember this phrase, you will need it later. Once you have entered the phrase, you should see something like below.

Once you have created the key, you will need to run the command below so you can copy the publickey.

vi /root/.ssh/id_rsa.pub

When you run this command a window like below should open up. you can highlight the contents, right click and copy.

Once you copy the key to your clip board press shift + : and a blinking cursor will appear at the bottom of the window. Type q and press enter and it will close the vi editor.

Now you will need to log into your github account to use the key. Once you are logged in got to your account settings page. Then click on SSH Keys.

When you are in the SSH Key page, click “New SSH key” at the top right.   Give the key a title, I name mine PrestaShop. Then in the key area paste what you just copied from the vi editor and press “Add SSH key”. This will add the key to your Github account so you can connect to Github and download the latest build of PrestaShop 1.7. Once you have added the key, go back to your ssh client and type the command below.

git clone git@github.com:PrestaShop/PrestaShop.git

This will take a minute, it will pull PrestaShop’s dev version from the repository to your server. Once this is done you will need to install composer. You can find the command to run from the ssh Window on their site, or use the one below.

php -r "readfile('https://getcomposer.org/installer');" > composer-setup.php
php -r "if (hash('SHA384', file_get_contents('composer-setup.php')) === 'fd26ce67e3b237fffd5e5544b45b0d92c41a4afe3e3f778e942e43ce6be197b9cdc7c251dcde6e2a52297ea269370680') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); }"
php composer-setup.php
php -r "unlink('composer-setup.php');"

You will have to hit enter once after you paste the code above, and once more at the end to run the last command.

Now you will need to install NPM and Nodejs. Run the first command below to install NPM

sudo apt-get install npm

And this command to install Nodejs

sudo apt-get install nodejs

Then this command to install cUrl on the server.

sudo apt-get install php5-curl

Now we are getting close. Run the command below to switch to the directory that PrestaShop has downloaded to.

cd /var/html/www/PrestaShop

Before you run Composer, you will have to adjust the memory limit on your server or Composer will error out. Type the command below to edit your php.ini

vi /etc/php5/apache2/php.ini

Find the line that defines the memory for php, it looks like the image below.

To edit the file press i and you can edit the memory. I would go with 2048 just to make sure there is enough memory. After you have changed the memory to 2048M press the escape key. User the memory add this line.

date.timezone = "America/Chicago"

PrestaShop will not install without a timezone being set in the php.ini.

Now press : and type wq and press enter. This will save your changes. Now you will need to restart Apache for the memory change to take affect. Type the command below.

sudo service apache2 restart

Now we have to load all of the dependencies that PrestaShop uses for the new version. Run the command below.

php composer.phar install

After you run composer you should see a screen like the one below asking for a token.

What it is asking for is a token created in your Github account. To create a token log into your Github account and click “Presonal access tokens” in the left menu, then click generate a new token. 

One the next screen it will ask you what permissions for the token to have. For simplicity sake, click all of the check boxes, because you can delete the token later. After you create the token it will let you copy it to the clipboard. Do that and paste the token in your ssh client. Composer will start to run after you do this. It will take compose a while to download everything that is needed. Have your database password handy at this stage. Close to the end of installing all of the components the installer will ask you some questions about the the server. Most of them are below, with the exception of your passphrase, just use something you will remember for that.

After Composer has run, navigate your browser to the ip address for the server /PrestaShop and you should see this glorious screen.

As you make it through the installation process, your hopes will quickly be dashed though. Two screens later you will see this.

Run the commands below and lets fix these errors.

Install mod_rewrite

sudo a2enmod rewrite

Correct the file ownership issue’s

sudo chown -R www-data:www-data /var/www

Install PHP intl extension

sudo apt-get install php5-intl

Restart Apache

service apache2 restart

Now when you refresh the installation page you should have no more errors and you can install PrestaShop as normal YAY! Your admin url should be located at youripaddress/PrestaShop/admin-dev type it in and you should see the 1.7 login screen.

Awesome, log in and start looking around. Not much has changed in the back office, the product and modules pages have changed, and there have been some design tweaks. If you go to the product page or the module page in the back office, you will notice they are broken. To fix this, type in the command below.

vi /etc/apache2/apache2.conf

Once you are in the file, scroll to the very bottom of the file and press the letter i then paste the lines below in the bottom of the file.

DocumentRoot /var/www

<Directory /var/www/>
    Options Indexes FollowSymLinks MultiViews
    AllowOverride all
    Order allow,deny
    allow from all
</Directory>

Once they are pasted in press escape, then press shift + : Now type wq and press enter. This will save the changes to the http configuration file. Now all you have to do is restart Apache using the command below.

service apache2 restart

Now everything should work perfectly.

1.7 is still evolving, things are expected to change in it frequently through the building process. Let us know your thoughts below, do you feel like it is a big enough change? Too much advertising? Is it any faster than 1.6?

Every few months we have a client coming to us that is recovering from a major disaster. It could be any number of things that happened, their server crashed, the host lost the data, a developer messed their shop up, or even a hacker compromised their server. The first thing we ask them about is their backups. Most of them do not have backups and we have to start planning to rebuild from scratch. Don’t be one of these people, save yourself the worry and hassle; get a backup module for your site.

Your PrestaShop website has tons of data that is crucial to running your business. Hackers would do anything to use this data for their benefit and for your loss — which could potentially ruin your business completely. That’s why your web store’s data should be secured and stored in a safe backup.

As a business owner, nothing would scare you more than losing your precious data or having unauthorized logins. Though your PrestaShop may be secure by following some website security best practices, there’s no such thing as a perfect, unbreakable system — trust us.

But how do you protect your online business from hackers, malicious third-party applications, hardware malfunction, and such? The only solution to safeguard the data on your PrestaShop website is to purchase a module that would automatically back up your website’s data!

Reasons Why You Should Back Up Your PrestaShop Website

Still not convinced that you need a PrestaShop module to automatically back up your data? We couldn’t blame you most people don’t believe in data security until they experience a data breach themselves.

Below are reasons why backing up your PrestaShop website is a good idea:

Your Hosting Provider May Have Vulnerabilities

Even though security updates regularly solve some vulnerabilities, it doesn’t guarantee the safety of your data. Your hosting provider or one of your modules may have vulnerabilities that would make an attack by hackers or malicious third-party applications possible. New exploits for web servers come out daily and we have seen more than one plugin that has vulnerabilities in it.

You Cannot Risk Data That’s Crucial to Your Business

The data on your PrestaShop website might be more valuable than you think. Data that you can potentially lose may include:

• Contact information of clients
• Customer service messages
• Product information
• Sales records
• MySQL databases
• Content that costs time and money

There may also be other data that are at risk and losing any or all of these would definitely put your business in a harsh position.

Hardware Malfunction Can Also Lead to Data Loss

Hackers and malicious third-party applications are not the only reasons for data loss. Hardware malfunction can lead to a data loss too. This would usually be caused by a massive hardware malfunction on servers where your data is held.

Your Employees May Accidentally Delete Your Data

Not everyone’s good at technical operations when accessing your PrestaShop website. Believe it or not, there’s also that possibility that someone from your company may accidentally delete important data from your PrestaShop website.

How You Can Effectively Back Up And Protect Your Data

Lucky for you, there’s a way to protect your online store in case of a server crash, data breach, or human error. There is a solution we recommend to our clients over and over again. It is tested, safe, and secure. It can provide you with emailed backups and off site backup stored in the cloud as well.

So, what’s the solution? A PrestaShop module that automatically backs up your PrestaShop data as frequently as you need it to. Here’s the module that you need to protect your website:

Automatic PrestaShop Backup V1.2.1

The Automatic PrestaShop Backup V1.2.1 module has saved countless online businesses from data loss for over 3 years. Everything is automatic and user-friendly; you can also get your PrestaShop website back online as quickly as possible. This module is made by one of the most popular PrestaShop module development companies Presto-Changeo, so you can rest assured that the module is the highest quality possible.

Here are some of the features of this module:

• Completely backs up your PrestaShop website
• Quick and easy restoration in only a few minutes
• Allows saving backup files on your server, get a copy through email, or store backup on Amazon S3 Cloud server (Free up to 5GB for the first year)
• Options to create a backup for the entire file system or only certain folders
• Options to create a compressed or uncompressed backup
• Easy scheduling of automatic backups

The module has an easy to use interface that will walk you through everything you need to do to get the module setup and running. The scheduling of the backups is easy as well, the module will create the cron for you to paste into your cpanel server or it also gives instructions on how to install the cron via command line.

Don’t trust your host with your backups, you really need a solution to handle them. If you look in the terms of service for most hosting companies they say that they are not responsible for the backups. That is something to consider especially with all of the time and money you have put into your shop. The module is only $70, that is a steal when you compare it to rebuilding your shop from scratch.

View the PrestaShop Automatic Backup Module