Prevent automatic requests to api.prestashop.com

[danh42]

First, a quick history:

 

I work for a company that hosts a handful of high-traffic sites based on PrestaShop. Shortly after we deployed our first PrestaShop site around a year ago, we started getting intermittent complaints that the admin was being unbearably slow. We did some investigation, and found that each time we got one of these complaints, the site in question was making requests to api.prestashop.com that were taking upwards of 30 seconds to complete, and sometimes timing out entirely. After a while, PrestaShop's API servers would stop being overloaded or whatever the problem was, and they'd go back to returning results quickly and our site's admin would go back to functioning acceptably. These requests were happening on all pages in the admin, and seemed to be related to updating the "must have" module lists and other such files in /config/xml. We ran additional tests and confirmed that it was just api.prestashop.com that was responding slowly, and it was not a problem with our ISP or a firewall issue.

 

To fix this, we implemented a local caching server that would only go out to the real api.prestashop.com once per day, and when the same file was requested later on returned its local copy in a couple milliseconds instead of a couple seconds (or more). This also allows the cache to be shared between all of our PrestaShop installs, and it's been working well enough for the past year without trouble.

 

Today, we got a flurry of complaints that people weren't able to access certain modules in the admin, and were instead seeing errors. 1.6.0.x sites were seeing was the following 3 errors repeated for every module installed:

• [bankwire] Error found in config file: Space required after the Public Identifier
• [bankwire] Error found in config file: SystemLiteral " or ' expected
• [bankwire] Error found in config file: SYSTEM or PUBLIC, the URI is missing

The 1.6.1.x sites only showed 6 errors, and these messages were actually useful:

• Error found : Space required after the Public Identifier in country_module_list.xml file.
• Error found : SystemLiteral " or ' expected in country_module_list.xml file.
• Error found : SYSTEM or PUBLIC, the URI is missing in country_module_list.xml file.

The problem was that api.prestashop.com had briefly been returning some HTML-formatted error messages instead of the XML that PrestaShop expected. The XML parser saw the DOCTYPE tag up at the top and (correctly) refused to continue. As a result, this for some reason prevented installed and fully working modules from appearing in the modules list in the admin, and displayed some contradictory numbers:

 

To fix this, we have now updated all the files from PrestaShop in /config/xml to contain empty tags like this:

<?xml version="1.0" encoding="UTF-8"?>
<tab_modules_list>
</tab_modules_list>

...and updated their permissions to prevent them from being written to in the future. This update now allows our sites to function again.

 

Having "must have" modules show up in the admin mixed in with the modules we actually have installed was always a nuisance, but performance and reliability are the real problems here. It's simply not acceptable to have websites break in production in the middle of the day just because a call to a server we have no control over failed to return a properly-formatted list of modules we don't care about or the latest posts from PrestaShop's blog that we already read elsewhere. In general, making synchronous HTTP requests that aren't directly required to display the current page in the admin is a Bad Thing™, and we need our sites to not do that.

 

For things like module updates, it would be nice to be able to inhibit the automatic checks that are triggered by a user simply clicking around in the admin simply because those people aren't the ones who update the modules anyway; they're managing inventory or lookup up orders, and making them wait even one extra second while we grab the latest module version numbers isn't helping anyone. The manual "Check for update" button works fine for that, and we already run a manual check when we're about to install updates anyway. For everything else, it's simply not necessary for our website to know about the E-commerce success story of "Monsieur Chaussure, shoe care products expert" or whatever's being pushed to the RSS feed today. We already hide that distracting stuff on the dashboard, so the fact that it's still being downloaded is simply a waste of resources.

 

While I think a more general solution would make a great feature request for a future PrestaShop version, right now I'm just concerned with our own sites. I'm a competent developer and Linux sysadmin, so I'm perfectly comfortable diving into PrestaShop's internals or making system changes if I need to, but I don't know as much about its internals as I probably should to start ripping out the things we don't need. Can anyone see any obvious problems with our current solution of just blocking requests for updated XML and forcing the local files to always be empty? Is there a more elegant solution to avoid the constant communication with PrestaShop's servers? We've already made some core modifications to most of these sites, so those are acceptable, but obviously we like to keep those to a minimum.

[bellini13]

This might interest you

http://nemops.com/faster-prestashop-back-office-modules-themes-ads/#.VfXHHZclZzK

 

In Tools.php, there is a function addonsRequest which has a series of case statements.  You could just put a return false at the very top to prevent all calls, or you could comment out only certain statements.  You could also add a new config switch so that the calls would only work when the switch is on.