Carrello della spesa
- Patryk Marek
- News
- 0 piace
- 131 visualizzazioni
- 0 Commenti
Annota l’indirizzo esatto, l’ora con il fuso orario e l’azione dopo la quale è comparso l’errore. Queste tre informazioni permettono di cercare lo stesso evento nei log. Il solo numero 500 o 522 non indica ancora il modulo da modificare.
Questa guida aiuta a preparare una segnalazione per la diagnosi. Non descrive la riparazione di un negozio specifico né presenta cause di esempio come risultato accertato.
Cosa annotare durante il guasto?
- Indirizzo e azione: ad es. apertura del prodotto, salvataggio di un’impostazione nel pannello oppure passaggio dal carrello alla consegna. Non annotare in una segnalazione pubblica i token presenti nell’indirizzo del pannello.
- Ora: data, ora e fuso, ad es.
2026-09-26 14:32 Europe/Warsaw. Se il problema si ripresenta, annota due o tre occorrenze concrete. - Risposta: codice HTTP, messaggio visibile e identificatore della richiesta, se la pagina di errore lo fornisce. Completa lo screenshot con il testo del messaggio.
- Ambito: un solo indirizzo o l’intero negozio, frontend o pannello, utente autenticato o ospite, una rete o anche un’altra.
- Ultima modifica: aggiornamento, installazione di un modulo, importazione, modifica di un’impostazione dell’hosting. Indica la data; il solo ordine degli eventi non dimostra la causa.
Errore 500 ed errore 522 richiedono punti di partenza diversi
| Risposta | Da dove iniziare | Cosa non si sa ancora |
|---|---|---|
| HTTP 500 | Confronta l’ora e il percorso con il log dell’applicazione e del server che gestisce la richiesta. | Il codice non identifica da solo il modulo, la query o l’impostazione PHP. Guasti diversi possono restituire lo stesso stato. |
| Cloudflare 522 | Verifica la connessione tra Cloudflare e il server di origine. Annota il Ray ID, se è visibile, e comunica l’orario all’hosting. | Il solo codice non conferma un errore di PrestaShop. L’origine può essere, tra l’altro, l’indisponibilità o il sovraccarico del server oppure il blocco delle connessioni. |
| Pagina vuota senza stato registrato | Verifica la risposta del documento principale negli strumenti del browser; conserva l’indirizzo e l’ora. | Non è ancora chiaro se il problema riguardi la risposta del server, uno script nel browser o una risorsa necessaria per visualizzare la pagina. |
Descrizione del 522 e raccomandazioni per la connessione con il server di origine: documentazione Cloudflare. Significato generale dello stato 500: HTTP Semantics, RFC 9110.
Come preparare una semplice prova di riproduzione?
Esempio dimostrativo di segnalazione: “Alle 14:32 apro la scheda prodotto come ospite. Il documento ha stato 500. La home page nello stesso browser funziona. Alle 14:35 lo stesso prodotto funziona da un’altra rete”. Una nota di questo tipo non diagnostica la causa, ma indica richieste concrete da confrontare.
A ogni ripetizione cambia una sola condizione e annota il risultato. Se contemporaneamente svuoti la cache, cambi PHP e disattivi diversi moduli, sarà difficile stabilire quale modifica abbia influito sul comportamento del negozio.
Quali log trasmettere alla persona che effettua la diagnosi?
Chiedi di verificare un breve intervallo di tempo attorno all’evento: il log dell’applicazione, gli errori PHP e del server WWW e, in presenza di un livello intermedio, anche i suoi eventi. La posizione di salvataggio dei log dipende dalla versione del negozio e dalla configurazione dell’hosting. Invece di presumere un percorso, fornisci all’amministratore l’ora esatta, l’indirizzo e il metodo della richiesta, se lo conosci.
I frammenti di log possono contenere indirizzi e-mail, identificatori di sessione e dati degli ordini. Trasmetti l’estratto necessario tramite un canale concordato e rimuovi i segreti. Anche un file HAR completo può contenere tali informazioni; non pubblicarlo come semplice allegato su un forum.
Come confrontare i livelli senza modificare la protezione dell’intero negozio?
Il confronto delle risposte tramite CDN e direttamente dal server dovrebbe essere preparato da un amministratore che conosca la configurazione del dominio, del TLS e dell’accesso all’origin. La differenza tra le risposte è un’indicazione per ulteriori test, non una prova automatica della responsabilità del WAF o di PrestaShop.
Usa la modalità di debug su una copia di lavoro o in un accesso controllato. La disattivazione globale della protezione oppure la visualizzazione di eccezioni dettagliate a tutti i visitatori non è necessaria per redigere una segnalazione utile.
Modello di segnalazione pronto da scaricare
Scarica il modulo di descrizione del guasto — TXT. Compila i campi e contrassegna l’informazione mancante con “non verificato”. Il modulo non richiede password né chiavi API.
Cosa verificare dopo la correzione?
Ripeti i passaggi annotati nelle stesse condizioni, verifica il risultato dell’operazione e le nuove voci nei log. In caso di problema sporadico, una sola apertura corretta della pagina conferma solo quel tentativo. Concorda con l’esecutore il periodo di osservazione, l’ambito dei test e il segnale per una nuova segnalazione.
Se il problema è comparso durante un cambio di versione, utilizza anche la lista di preparazione all’aggiornamento di PrestaShop. Una guida separata spiega il ruolo delle intestazioni di sicurezza HTTP.
Commenti (0)