Negli ultimi giorni diversi store basati su PrestaShop 1.7.x hanno iniziato a mostrare errori del tipo:
Il problema non è locale al server, né un errore di configurazione PHP, ma è legato a una condizione esterna: PrestaShop Addons in manutenzione, con risposta Cloudflare non XML. Vediamo come diagnosticarlo in modo corretto e come risolverlo in maniera pulita, senza patch invasive al core.
Il primo controllo da fare è direttamente dal server:
curl -I https://addons.prestashop.com/ 2>/dev/null | head
Se la risposta è simile a:
HTTP/2 302
location: https://maintenance.addons.prestashop.com/
server: cloudflare
allora il problema è confermato.
Il server non riceve XML valido ma un redirect verso una pagina di maintenance.
PrestaShop 1.7.x, in particolare versioni < 1.7.8, durante l’accesso al backend:
Nel caso in cui Addons risponda con HTML (maintenance, redirect, pagina Cloudflare), il flusso diventa:
HTML salvato come .xml
Parser XML tenta di leggerlo
Errore invalid element name
In alcuni casi loop di redirect BO (modulo ps_accounts coinvolto)
I file coinvolti, nel caso specifico, si trovano in:
config/xml/
E tipicamente sono:
default_country_modules_list.xml
modules_native_addons.xml
must_have_modules_list.xml
In caso di blocco, possono risultare:
corrotti (HTML dentro)
vuoti (0 byte)
rigenerati ad ogni accesso
La soluzione più corretta, temporanea e reversibile consiste nel creare un override della classe Tools per intercettare le chiamate verso Addons e restituire un XML valido minimo.
Creare il file:
/override/classes/Tools.php
Con il seguente contenuto:
<?php
class Tools extends ToolsCore
{
public static function addonsRequest($request, $params = array())
{
// XML minimo valido per evitare file vuoti o corrotti
$emptyXml = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<modules></modules>\n";
if ($request === 'native' || $request === 'must-have') {
return $emptyXml;
}
return false;
}
}
Dopo aver creato l’override:
cd /var/www/vhosts/DOMINIO/httpdocs
rm -rf var/cache/prod/*
rm -rf var/cache/dev/*
Eliminare anche i file XML corrotti:
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
Se attivo OPcache, riavviare PHP-FPM.
Rispetto ad altre soluzioni circolate (commentare file core, modificare AdminController, forzare flag interni):
Non modifica file di sistema
È reversibile
Non compromette aggiornamenti futuri
Non genera file 0 byte
Mantiene il flusso del core coerente
Quando Addons tornerà operativo sarà sufficiente:
Eliminare l’override (opzionale) *
Pulire cache
Lasciare che i file XML si rigenerino correttamente
È importante ricordare che le versioni più datate di PrestaShop (come la 1.7.6.x) non sono più supportate ufficialmente. In questi casi la connessione ai servizi Addons perde di fatto valore operativo: non essendoci più aggiornamenti core né patch ufficiali, la dipendenza dal marketplace non apporta benefici concreti in termini di sicurezza o manutenzione.
In tali contesti, mantenere attivo un override come quello illustrato può rappresentare una scelta razionale e stabile, soprattutto in ambienti chiusi o infrastrutture controllate. L’assenza di aggiornamenti ufficiali rende infatti non essenziale il collegamento automatico ai servizi Addons.
Il nostro modulo FAST BACK OFFICE è pensato appositamente per escludere la parte SaaS da PrestaShop in modo da rendere queste versioni più reattive e più stabili.
Finché Addons risulta in manutenzione è consigliabile disattivare anche:
ps_accounts
ps_mbo
ps_eventbus
ps_metrics
per evitare handshake OAuth, redirect loop o chiamate esterne non necessarie.
A partire da PrestaShop 1.7.8, la gestione del marketplace e delle integrazioni Addons è stata progressivamente disaccoppiata dal core e delegata a moduli specifici (in particolare ps_mbo, ps_accounts, ps_eventbus, ps_metrics), che costituiscono quello che oggi viene definito PrestaShop Integration Framework.
Nelle versioni 8.x e 9.x:
il framework non è tecnicamente parte del core Symfony,
ma viene incluso di default nella build ufficiale distribuita da prestashop.com,
mentre nella versione GitHub “clean” tali moduli non sono obbligatoriamente integrati e possono essere installati o esclusi consapevolmente.
La differenza quindi non è tanto “nel core”, ma nel packaging e nelle dipendenze preinstallate.
L’episodio analizzato evidenzia un aspetto strutturale importante dell’ecosistema PrestaShop: la dipendenza da servizi esterni (Addons e componenti collegati) e la gestione delle relative chiamate HTTP durante il caricamento del backend.
Nelle versioni 1.7.x, in particolare le release antecedenti alla 1.7.8, la gestione delle risposte non valide (redirect, HTML di maintenance, risposte Cloudflare) non è sempre robusta. Questo può portare al salvataggio di contenuti non XML nei file cache (config/xml/*), con conseguenti errori di parsing o, nei casi più complessi, loop di redirect in backend.
Le versioni 8.x e 9.x hanno migliorato sensibilmente la resilienza del sistema. Tuttavia, con l’introduzione del PrestaShop Integration Framework (PIF), l’architettura si basa ancora più esplicitamente su servizi esterni per:
autenticazione Addons,
gestione marketplace,
metrics,
eventbus,
sincronizzazioni remote.
Questo significa che, in presenza di:
manutenzione lato Addons,
blocchi Cloudflare,
problemi DNS o TLS,
restrizioni firewall outbound,
anche le versioni 8 e 9 possono manifestare disservizi, sebbene in forma generalmente più controllata rispetto alla 1.7.x.
La differenza non è nell’assenza di dipendenza esterna, ma nel modo in cui essa viene gestita.
Per ambienti professionali e infrastrutture controllate, l’utilizzo della versione GitHub “clean” di PrestaShop è spesso preferibile rispetto alle distribuzioni ufficiali preconfigurate con il PrestaShop Integration Framework attivo di default.
A partire dalla versione 1.7.8, la dipendenza da Addons non è più incorporata direttamente nel core, ma è stata delegata a un insieme di moduli (ps_mbo, ps_accounts, ps_eventbus, ps_metrics) che costituiscono il framework di integrazione. Nelle versioni 8 e 9 questo approccio è stato consolidato: il framework non è tecnicamente parte del cuore applicativo, ma viene incluso automaticamente nella build ufficiale.
La versione GitHub consente invece un controllo architetturale più rigoroso, evitando l’installazione implicita dei moduli di integrazione e riducendo le chiamate outbound verso servizi Addons. Questo approccio è particolarmente indicato in ambienti enterprise o in infrastrutture con policy di sicurezza restrittive, dove la stabilità operativa e la prevedibilità del sistema hanno priorità rispetto all’integrazione marketplace automatica.
La versione GitHub:
non include forzatamente il PrestaShop Integration Framework,
non impone autenticazione Addons lato core,
riduce le chiamate outbound automatiche,
offre maggiore controllo architetturale,
minimizza la superficie di dipendenza da servizi SaaS esterni.
Questo approccio è particolarmente indicato per:
ambienti enterprise,
infrastrutture con firewall restrittivi,
ambienti staging isolati,
installazioni dove la stabilità operativa è prioritaria rispetto alle integrazioni marketplace.
L’adozione della build GitHub non elimina la possibilità di integrare i servizi Addons, ma consente di farlo in modo esplicito e controllato, evitando dipendenze implicite durante il bootstrap del backend.
Autore: Loris Modena
Per Ind Loris Modena titolare di Arte e Informatica, inizia a lavorare nel settore informatico nel 1989 quale sistemista addetto alla manutenzione e installazione di sistemi informatici. Inizia a programmare per il web nel 1997 occupandosi di programmazione CGI in PERL e successivamente passando alla programmazione in PHP e JavaScript. In questo periodo si avvicina al mondo Open source e alla gestione di server Linux.
