In the last few days several PrestaShop-based stores 1.7.x have started showing errors like:
The problem is not local to the server, nor a PHP configuration error, but is related to an external condition: PrestaShop Addons under maintenance, with Cloudflare response not XML. Let's see how to diagnose it correctly and how to fix it cleanly, without invasive patches to the core.
The first check to do is directly from the server:
curl -I https://addons.prestashop.com/ 2>/dev/null | head
If the response is similar to:
HTTP/2 302
location: https://maintenance.addons.prestashop.com/
server: cloudflare
then the problem is confirmed.
The server is not receiving valid XML but a redirect to a maintenance page.
PrestaShop 1.7.x, in particular versions
In case Addons responds with HTML (maintenance, redirect, Cloudflare page), the flow becomes:
HTML saved as .xml
XML parser attempts to read it
Error invalid element name
In some cases BO redirect loop (ps_accounts module involved)
The files involved, in this case, are located in:
config/xml/
And typically they are:
default_country_modules_list.xml
modules_native_addons.xml
must_have_modules_list.xml
In case of blocking, they may be:
corrupt (HTML inside)
empty (0 bytes)
regenerated at each access
The most correct, temporary and reversible solution is to create an override of the Tools class to intercept calls to Addons and return a minimum valid XML.
Create the file:
/override/classes/Tools.php
With the following content:
class Tools extends ToolsCore
{
public static function addonsRequest($request, $params = array())
{
// Minimum valid XML to avoid empty or corrupt files
$emptyXml = "\n
if ($request == 'native' || $request == 'must-have') {
return $emptyXml;
}
return false;
}
}
After creating the override:
cd /var/www/vhosts/DOMINIUM/httpdocs
rm -rf var/cache/prod/*
rm -rf var/cache/dev/*
Also delete corrupt XML files:
rm -f config/xml/default_country_modules_list.xml
rm -f config/xml/modules_native_addons.xml
rm -f config/xml/must_have_modules_list.xml
If OPcache is active, restart PHP-FPM.
Compared to other solutions circulated (commenting on core files, modifying AdminController, forcing internal flags):
Does not modify system files
Is reversible
Does not compromise future updates
Does not generate 0-byte files
Keeps the core flow consistent
When Addons comes back up and running, it will be sufficient:
Delete the override (optional) *
Clear cache
Allow XML files to regenerate properly
It is important to remember that older versions of PrestaShop (such as 1.7.6.x) are no longer officially supported. In these cases, the connection to Addons services actually loses operational value: since there are no longer any core updates or official patches, the dependency on the marketplace does not provide any real benefits in terms of security or maintenance.
In such contexts, keeping an override like the one illustrated active can be a rational and stable choice, especially in closed environments or controlled infrastructures. Indeed, the absence of official updates makes automatic connection to Addons services nonessential.
Our FAST BACK OFFICE module is designed specifically to exclude the SaaS part from PrestaShop so that these versions are more responsive and more stable.
As long as Addons results in maintenance it is advisable to disable also:
ps_accounts
ps_mbo
ps_eventbus
ps_metrics
to avoid OAuth handshakes, redirect loops, or unnecessary external calls.
Beginning with PrestaShop 1.7.8, the management of the marketplace and Addons integrations has been progressively decoupled from the core and delegated to specific modules (notably ps_mbo, ps_accounts, ps_eventbus, ps_metrics), which constitute what is now called the PrestaShop Integration Framework.
In versions 8.x and 9.x:
the framework is not technically part of the Symfony core,
but it is included by default in the official build distributed by prestashop.com,
while in the "clean" GitHub version such modules are not mandatorily integrated and can be installed or excluded consciously.
The difference then is not so much "in the core," but in the packaging and preinstalled dependencies.
The episode analyzed highlights an important structural aspect of the PrestaShop ecosystem: the dependency on external services (Addons and related components) and the handling of related HTTP calls during backend loading.
In 1.7.x, particularly releases prior to 1.7.8, the handling of invalid responses (redirects, maintenance HTML, Cloudflare responses) is not always robust. This can lead to non-XML content being saved in cache files (config/xml/*), resulting in parsing errors or, in more complex cases, redirect loops in the backend.
Versions 8.x and 9.x significantly improved the resilience of the system. However, with the introduction of the PrestaShop Integration Framework (PIF), the architecture relies even more explicitly on external services for:
addons authentication,
marketplace management,
metrics,
eventbus,
remote synchronizations.
This means that in the presence of:
addons-side maintenance,
cloudflare blockages,
dNS or TLS issues,
outbound firewall restrictions,
versions 8 and 9 can also manifest inefficiencies, albeit in a generally more controlled form than the 1.7.x.
The difference is not in the absence of external dependency, but in the way it is handled.
For professional environments and controlled infrastructures, using the "clean" GitHub version of PrestaShop is often preferable to official distributions pre-configured with the PrestaShop Integration Framework active by default.
Beginning with version 1.7.8, the dependency on Addons is no longer embedded directly in the core, but has been delegated to a set of modules (ps_mbo, ps_accounts, ps_eventbus, ps_metrics) that make up the integration framework. In versions 8 and 9 this approach has been consolidated: the framework is not technically part of the application core, but is automatically included in the official build.
In contrast, the GitHub version allows tighter architectural control, avoiding implicit installation of integration modules and reducing outbound calls to Addons services. This approach is particularly suitable in enterprise environments or in infrastructures with restrictive security policies, where operational stability and system predictability take priority over automatic marketplace integration.
The GitHub version:
does not forcibly include the PrestaShop Integration Framework,
does not enforce Addons authentication on the core side,
reduces automated outbound calls,
offers more architectural control,
minimizes the dependency surface on external SaaS services.
This approach is particularly suitable for:
enterprise environments,
infrastructures with restrictive firewalls,
isolated staging environments,
installations where operational stability is prioritized over marketplace integrations.
Adoption of the GitHub build does not eliminate the possibility of integrating Addons services, but it allows this to be done in an explicit and controlled manner, avoiding implicit dependencies during backend bootstrapping.
Author: Loris Modena
Loris Modena owner of Arte e Informatica, began working in the computer industry in 1989 as a systems engineer involved in the maintenance and installation of computer systems. He starts programming for the web in 1997 dealing with CGI programming in PERL and later switching to PHP and JavaScript programming. During this period he approaches the Open source world and Linux server management.
