To make a Prestashop migration of local surroundings to real surroundings of production (online) is something relatively simple but in no tutorial they explain to you what to do if all fault, something that usually happens to relative frequency.

After reading many tutorial ones on this process I decided to write this article that concentrates in how to detect, to monitor and to solve the most common problems that usually they appear once we finish the migration process.

This tutorial has been created on a store Prestashop installed in local, Mac using MAMP Server and a servant of production of quality but quite restrictive surroundings as usually it offers the company of Hostspain lodging.

This process that I am going to explain is valid for a migration in both felt: local->online and online->local

Migration of Prestashop from localhost to a servant online

It is necessary to begin by the principle and for it we are going to explain step by step that we must follow to realise the migration. The scene is the following one:

  • Local servant: Our developing store is installed in the /localhost/tienda route, where localhost would be the local domain and lies down a subdirectory.
  • Servant online: Our store online will be in

We begin with the migration:

  1. We accede to back office of our local store, go to Preferences, Maintenance and we put the store in way maintenance, selecting option no. We kept.
  2. We export the local data base acceding to phpMyAdmin. We will choose a complete export towards a file.
  3. Now we go to the servant online and we created a new data base acceding to the Control Panel of our lodging. Soon we concerned the data base of the previous point in our servant online using phpMyAdmin.
  4. We connect by FTP to our servant online with a client FTP as it can be FileZilla and copied (upload) all the archives and folders from our local store towards the root directory of the servant online.
    [alert type=€ warning€ close=€ true€] EYE! Perhaps when archives by FTP are copied sometimes do not copy the totality of the archives and folders, it agrees to review this by far well-taken care of. This it warning because in an occasion I had to make the inverse process (to migrate a Prestashop online to local surroundings) and when unloading the archives and folders I verified that they were not all, especially the product images stored in the /img/p directory. The problem was that FileZilla did not detect the complete structure of folders yes/archives but PHP, I solved it creating script PHP that packed all the archives/folders of Prestashop in an only file that was the one that unloaded to me. Normally from PHP yes the complete structure of archives of a directory can be read correctly, without it lacks nothing. [/alert]
  5. In the servant online it is necessary to publish the /config/ file to assign the constants related to the data base:
    it defines (€˜_DB_SERVER_€™, €˜** my servant of YOU, usually is localhost €˜);
    it defines (€˜_DB_NAME_€™, €˜** name of YOU ** €˜);
    it defines (€˜usuary _DB_USER_€™, €˜** of YOU **€™);
    it defines (€˜_DB_PASSWD_€™, €˜** password of YOU **€™);
  6. Arrived at this point our store still it does not work because the file .htaccess located in the root continues aiming at the old routes (localhost/lies down), nevertheless yes that we will be able to enter the zone of administration.
  7. We enter back office of the servant online, go to Preferences, SEO & URLs, we looked for the three fields related to the domain, put following the values and we punctured To keep:
    Domain of the store:
    Domain SSL:
    Root directory: /
  8. More down we punctured the button To generate the robots.txt file, that will be in charge to generate the file .htaccess and robots.txt.
  9. According to what it says the official documents of Prestashop (in my case it was not necessary) is necessary to take the following step: We connect by FTP the servant online and erased all the files except for index.php of the directories:
  10. We go to Preferences, Maintenance and we activated the store leaving the way maintenance.
  11. Arrived at this point the store it would have to work, tries to accede to to see what it happens. In my case it did not work and if the same happens to you it happens to the following section.

Problems that can appear finalized the migration once

The servers online usually have important restrictions in everything what he talks about to security, privileges, shown of errors, volume of information. This often leaves us in a dark room in which there is to find the exit. The production surroundings usually do not show the errors that can throw PHP, Apache or MySQL, which lets very complicated know what and where it is failing. Some companies of lodging form their servers to keep the PHP/MySQL/Apache errors in some .log file to which not always we can accede.

We return to the example from before: in my case the Prestashop migration did not work. What we can do if it fails the store and it appears to us a page in target or a message internal Error€¦ that does not give any type us of information? We are going to do the following thing:

  1. We are going to activate the way debug or development in our store online. We publish the /config/ file and we put the value true in constant _PS_MODE_DEV_. With this we are saying to Prestashop that shows all the errors of PHP, which is going to be decisive to detect the origin of the problem. We must remember to put this value in false once we have finished everything and the store is working!
  2. We return to prove the store and if it continues appearing the page in target is because they are continued hiding errors PHP although they are taking place, for which we will take the following steps.
  3. We publish the file .htaccess by the root of our servant online and add the following lines at the outset:
    php_flag log_errors on
    php_value error_log /home/mitienda/public_html/log/errores_php.log
    This route must be the appropriate one according to our case, if we do not know which is we can find out creating it a file info.php in the root of our servant online who contains the following thing:
    <? php I throw getcwd (); >
    Soon we executed this script putting in navigator and it will show to the complete physical route of our directory Web root to us. Once we know the route we must eliminate this script.
  4. Now we proved our store and will continue appearing the page in target because it continues failing, but everything has gone well will be being been generating an error PHP that is being stored in the /log/errores_php.log file of the servant online. If we opened that file from FileZilla we will see what module or what script is generating the error. S.A. to accede to the /log/ directory we see that the errores_php.log file does not exist probably is because the lodging company does not allow that we include the directives php_flag and php_value within our file .htaccess. In this case we cannot do nothing concerning configuration and we will have to speak with the lodging company to tell them that they activate log and they place them in a route to which we can accede to consult them.
  5. Finally you must have obtained, of one or the other form, to consult happy the .log of PHP to know what errors are taking place in your store. In my case I verified that the problem was that four modules were not working correctly, were using the routes of the local store instead of the routes of the store online. This I solved it very easily deactivating those four modules and returning them to activate. Of that form they were reshaped, already you know, this is as Windows, if something fails€¦. it reinitiates!

Some possible problems€¦

  • In one of the occasions that I have put in practice this method took place a failure by the cache system. In the origin servant XCache was using and the destiny servant did not support it. In order to solve I published it the /config/ file and I deactivated the cache putting constant _PS_CACHE_ENABLED_ with a value of €˜0 €˜