Vai al contenuto

Guida completa PrestaShop

Estensioni, temi e compatibilità in PrestaShop

In breve: Componenti aggiuntivi, personalizzazioni e conflitti tra codice e versioni. Questa guida riunisce i casi che prima erano distribuiti in trenta URL molto simili e li organizza in un unico percorso diagnostico verificabile.

Ambito e componenti da controllare

Il sintomo visibile è soltanto il punto di partenza. Prima di modificare PrestaShop, separa applicazione, estensioni, tema, database, cache, web server e servizi esterni. Cambia una variabile per volta e conserva sempre l’evidenza che conferma o esclude un livello.

Sintomi ed evidenze da raccogliere

Sintomo Prima evidenza utile
Problemi di installazione Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.
Caricamento non riuscito Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.
Layout o frontend danneggiato Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.
Conflitto con altri componenti Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.
Aggiornamento del componente non riuscito Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.

Diagnosi per componente

Ogni componente può produrre sintomi simili. Le schede seguenti indicano cosa significa ciascun caso e quale prova raccogliere prima della correzione.

Un modulo

Nel contesto di PrestaShop, un modulo partecipa a un flusso più ampio. Assistenza PrestaShop per front office, back office, checkout, moduli, catalogo, prestazioni, sicurezza e migrazioni. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nel back office di PrestaShop, nei processi pianificati e nei servizi collegati.

Problemi di installazione

Quando un modulo genera un errore dopo l’installazione, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Caricamento non riuscito

Quando un modulo non viene caricato o inizializzato, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Layout o frontend danneggiato

Quando un modulo rompe il layout o il frontend, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Conflitto con altri componenti

Quando un modulo crea un conflitto con altri componenti, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Aggiornamento del componente non riuscito

Quando un modulo non si aggiorna correttamente, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Il tema

Nel contesto di PrestaShop, il tema partecipa a un flusso più ampio. Assistenza PrestaShop per front office, back office, checkout, moduli, catalogo, prestazioni, sicurezza e migrazioni. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nel back office di PrestaShop, nei processi pianificati e nei servizi collegati.

Problemi di installazione

Quando il tema genera un errore dopo l’installazione, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Caricamento non riuscito

Quando il tema non viene caricato o inizializzato, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Layout o frontend danneggiato

Quando il tema rompe il layout o il frontend, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Conflitto con altri componenti

Quando il tema crea un conflitto con altri componenti, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Aggiornamento del componente non riuscito

Quando il tema non si aggiorna correttamente, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Un override

Nel contesto di PrestaShop, un override partecipa a un flusso più ampio. Assistenza PrestaShop per front office, back office, checkout, moduli, catalogo, prestazioni, sicurezza e migrazioni. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nel back office di PrestaShop, nei processi pianificati e nei servizi collegati.

Problemi di installazione

Quando un override genera un errore dopo l’installazione, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Caricamento non riuscito

Quando un override non viene caricato o inizializzato, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Layout o frontend danneggiato

Quando un override rompe il layout o il frontend, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Conflitto con altri componenti

Quando un override crea un conflitto con altri componenti, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Aggiornamento del componente non riuscito

Quando un override non si aggiorna correttamente, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Un hook

Nel contesto di PrestaShop, un hook partecipa a un flusso più ampio. Assistenza PrestaShop per front office, back office, checkout, moduli, catalogo, prestazioni, sicurezza e migrazioni. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nel back office di PrestaShop, nei processi pianificati e nei servizi collegati.

Problemi di installazione

Quando un hook genera un errore dopo l’installazione, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Caricamento non riuscito

Quando un hook non viene caricato o inizializzato, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Layout o frontend danneggiato

Quando un hook rompe il layout o il frontend, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Conflitto con altri componenti

Quando un hook crea un conflitto con altri componenti, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Aggiornamento del componente non riuscito

Quando un hook non si aggiorna correttamente, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Un modulo di pagamento

Nel contesto di PrestaShop, un modulo di pagamento partecipa a un flusso più ampio. Assistenza PrestaShop per front office, back office, checkout, moduli, catalogo, prestazioni, sicurezza e migrazioni. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nel back office di PrestaShop, nei processi pianificati e nei servizi collegati.

Problemi di installazione

Quando un modulo di pagamento genera un errore dopo l’installazione, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Caricamento non riuscito

Quando un modulo di pagamento non viene caricato o inizializzato, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Layout o frontend danneggiato

Quando un modulo di pagamento rompe il layout o il frontend, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Conflitto con altri componenti

Quando un modulo di pagamento crea un conflitto con altri componenti, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Aggiornamento del componente non riuscito

Quando un modulo di pagamento non si aggiorna correttamente, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Un modulo corriere

Nel contesto di PrestaShop, un modulo corriere partecipa a un flusso più ampio. Assistenza PrestaShop per front office, back office, checkout, moduli, catalogo, prestazioni, sicurezza e migrazioni. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nel back office di PrestaShop, nei processi pianificati e nei servizi collegati.

Problemi di installazione

Quando un modulo corriere genera un errore dopo l’installazione, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Caricamento non riuscito

Quando un modulo corriere non viene caricato o inizializzato, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Layout o frontend danneggiato

Quando un modulo corriere rompe il layout o il frontend, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Conflitto con altri componenti

Quando un modulo corriere crea un conflitto con altri componenti, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Aggiornamento del componente non riuscito

Quando un modulo corriere non si aggiorna correttamente, il sintomo non basta per scegliere la correzione. Su PrestaShop conviene prima capire se il problema dipende dal componente, dalla sua configurazione, da un override, da una dipendenza o da un conflitto con il resto del progetto. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Percorso diagnostico in ordine

Esegui i controlli dal meno invasivo al più profondo. Un tentativo è utile solo se ha un risultato atteso, produce un’evidenza e può essere annullato.

  1. Registrare versione del CMS, PHP e componente

    Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.

  2. Leggere changelog, requisiti e dipendenze dichiarate

    Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.

  3. Riprodurre il problema con configurazione minima in staging

    Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.

  4. Controllare override, hook, eventi e file personalizzati

    Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.

  5. Svuotare cache e rigenerare asset previsti dalla piattaforma

    Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.

  6. Confrontare l’installazione con il pacchetto originale

    Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.

Strumenti e percorsi utili in PrestaShop

  • Controlla i log applicativi in var/logs/ e i log PHP/web server nello stesso intervallo del problema.
  • Esegui php bin/console list dalla root del progetto per verificare i comandi disponibili nella versione installata.
  • Prima di intervenire su moduli, override o tema, documenta modalità debug, cache, versione PHP e ultimo deploy.
Attenzione: comandi, percorsi e nomi dei menu cambiano tra versioni e ambienti. Verifica sempre la documentazione della versione installata e non eseguire comandi distruttivi senza backup.

Verifica finale e rollback

Il ritorno della pagina non basta a chiudere l’intervento. Ripeti il caso iniziale, un caso di controllo e i flussi collegati; poi verifica che non siano comparsi nuovi errori.

  • un modulo nel caso che generava il problema e in un secondo caso di controllo
  • frontend e area amministrativa con utenti e permessi differenti
  • salvataggio dei dati e assenza di nuovi errori nei log
  • email, attività pianificate, API, code o callback coinvolte
  • cache e CDN dopo la riattivazione
  • prestazioni, consumo risorse e stabilità per un intervallo adeguato
  • backup aggiornato e documentazione della modifica

Riferimenti ufficiali

I percorsi e i comandi possono cambiare tra versioni. Prima di intervenire, confronta la procedura con la documentazione della versione installata e conserva un rollback verificato.

Domande frequenti

Da quale controllo partire per estensioni, temi e compatibilità in PrestaShop?

Parti da un caso riproducibile e dal log registrato nello stesso orario. Versioni, ultima modifica, URL, utente e risultato atteso permettono di distinguere un errore applicativo da cache, infrastruttura o servizi esterni.

È sufficiente svuotare la cache?

No. La cache è un livello da verificare, ma non corregge file mancanti, dipendenze incompatibili, dati incoerenti o configurazioni errate. Usala come test e annota quale livello ha restituito la risposta.

Quando serve un ambiente di staging?

Quando la correzione può influire su utenti, ordini, contenuti, permessi o configurazioni. Lo staging deve rappresentare il caso reale senza esporre dati personali e deve avere un piano di riallineamento con la produzione.

Quali informazioni preparare prima di chiedere assistenza?

Prepara URL, messaggio, orario, versione di PrestaShop, versione PHP e database, modifiche recenti, accessi disponibili e un estratto pertinente dei log. Non inviare password nel primo messaggio.

Quando è preferibile un rollback?

Quando il ripristino del servizio è prioritario e la modifica può essere annullata senza perdere dati recenti. Prima confronta file e database del backup con lo stato corrente e conserva separatamente ordini, utenti o contenuti creati dopo la copia.

Serve una diagnosi sul tuo sito?

Se il problema riguarda un’installazione reale, prepara versione, URL, orario, modifiche recenti e log pertinenti.

Assistenza PrestaShop Invia i dettagli del problema