Installazione e configurazione

Comprendere i Permessi dei File su Linux

Ogni file e directory su un server Linux ha tre set di permessi: uno per il proprietario, uno per il gruppo e uno per gli altri (tutti gli altri utenti). Ogni set controlla tre azioni: lettura (r), scrittura (w) ed esecuzione (x). Questi permessi sono rappresentati numericamente usando la notazione ottale, dove lettura equivale a 4, scrittura a 2 ed esecuzione a 1. I valori vengono sommati per ogni set, producendo un numero a tre cifre come 755 o 644.

Ad esempio, un permesso di 755 significa che il proprietario può leggere, scrivere ed eseguire (7 = 4+2+1), mentre il gruppo e gli altri possono solo leggere ed eseguire (5 = 4+0+1). Un permesso di 644 significa che il proprietario può leggere e scrivere (6 = 4+2+0), mentre il gruppo e gli altri possono solo leggere (4 = 4+0+0). Comprendere questo sistema è fondamentale per gestire un negozio PrestaShop sicuro e funzionale.

Oltre ai permessi numerici, ogni file ha un proprietario e un gruppo associato. Su un server web, il processo del server web (Apache o Nginx) viene eseguito come un utente specifico, tipicamente www-data su Debian/Ubuntu o apache/nobody su CentOS/RHEL. Il server web deve poter leggere i file di PrestaShop per servirli e necessita dell'accesso in scrittura a determinate directory per upload, caching e configurazione.

Permessi Corretti per Directory e File di PrestaShop

La regola generale per PrestaShop è semplice: le directory devono avere permessi 755 e i file devono avere permessi 644. Questo dà al proprietario il pieno controllo, mentre il gruppo e gli altri possono leggere (e eseguire/attraversare nel caso delle directory) ma non possono modificare nulla. L'utente del server web dovrebbe essere il proprietario di tutti i file PrestaShop, o almeno appartenere al gruppo che li possiede.

Per impostare questi permessi su tutta la tua installazione PrestaShop, collegati al server via SSH ed esegui:

find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;

Sostituisci /var/www/html/prestashop con il percorso effettivo della tua installazione PrestaShop. Il primo comando trova tutte le directory e le imposta a 755. Il secondo trova tutti i file e li imposta a 644.

Tuttavia, alcune directory richiedono accesso in scrittura da parte del server web. Queste directory necessitano di attenzione speciale perché PrestaShop scrive in esse durante il normale funzionamento:

/var/cache/ — Template compilati di Smarty e cache Symfony
/var/logs/ — File di log dell'applicazione
/upload/ — Upload dei file dei clienti
/download/ — File dei prodotti virtuali
/img/ — Immagini dei prodotti, delle categorie, dei CMS
/modules/ — Installazione e aggiornamento dei moduli
/themes/ — File di cache dei temi
/translations/ — File di esportazione delle traduzioni
/config/ — File di configurazione (parameters.php)
/app/config/ — Configurazione Symfony
/app/Resources/translations/ — Traduzioni Symfony

Se l'utente del server web è il proprietario di questi file (che è la configurazione raccomandata), allora i permessi 755/644 sono sufficienti. Se il server web viene eseguito come un utente diverso, potrebbe essere necessario modificare i permessi del gruppo o la proprietà.

Impostare la Proprietà Corretta con chown

La proprietà è importante quanto i permessi. Il comando chown modifica il proprietario e il gruppo dei file. Per un tipico server Debian/Ubuntu con Apache o Nginx, l'utente del server web è www-data:

sudo chown -R www-data:www-data /var/www/html/prestashop

Il flag -R applica la modifica ricorsivamente a tutti i file e le sottodirectory. Su sistemi CentOS o RHEL, sostituisci www-data con apache o nginx a seconda del tuo server web.

Un approccio alternativo comune è impostare il proprietario come il tuo utente SSH/FTP e il gruppo come l'utente del server web. Questo ti permette di modificare i file via FTP o SSH consentendo comunque al server web di leggerli:

sudo chown -R tuoutente:www-data /var/www/html/prestashop

In questo caso, le directory che necessitano di accesso in scrittura da parte del server web dovrebbero essere impostate a 775 (scrittura di gruppo) e i file scrivibili a 664:

find /var/www/html/prestashop/var -type d -exec chmod 775 {} \;
find /var/www/html/prestashop/var -type f -exec chmod 664 {} \;
find /var/www/html/prestashop/img -type d -exec chmod 775 {} \;
find /var/www/html/prestashop/img -type f -exec chmod 664 {} \;

Hosting Condiviso vs VPS vs Server Dedicato

L'ambiente di hosting influenza drasticamente il funzionamento dei permessi dei file nella pratica. Comprendere le differenze è fondamentale per configurare correttamente i permessi.

Hosting Condiviso

Su hosting condiviso, generalmente accedi ai file via FTP o tramite un file manager nel pannello di controllo cPanel/Plesk. Il modello di esecuzione PHP varia a seconda dell'hosting, ma la maggior parte degli hosting condivisi moderni utilizza PHP-FPM o suPHP, il che significa che PHP viene eseguito come il tuo account utente piuttosto che come l'utente globale del server web. Questo semplifica notevolmente i permessi: poiché PHP viene eseguito come il tuo utente, può già leggere e scrivere i tuoi file con i permessi standard 755/644. Raramente è necessario modificare la proprietà su hosting condiviso perché tutto appartiene già al tuo account.

Se riscontri errori di permesso su hosting condiviso, verifica con il tuo hosting se utilizzano suPHP o PHP-FPM. Se utilizzano il vecchio modello mod_php, potresti dover impostare alcune directory a 777 temporaneamente (anche se questo non è raccomandato per motivi di sicurezza). La maggior parte degli hosting affidabili ha abbandonato mod_php proprio a causa di queste complicazioni con i permessi.

VPS (Virtual Private Server)

Su un VPS hai il pieno controllo. Questa è la configurazione più comune per negozi PrestaShop seri. Dovresti assicurarti che l'utente del server web sia il proprietario dei file PrestaShop o, come minimo, appartenga a un gruppo che ha accesso in lettura. La configurazione raccomandata prevede:

Impostare il proprietario a www-data:www-data (o il tuo utente del server web)
Usare 755 per le directory e 644 per i file
Usare SSH con sudo per apportare modifiche, oppure aggiungere il tuo utente SSH al gruppo www-data

Per aggiungere il tuo utente SSH al gruppo del server web:

sudo usermod -a -G www-data tuoutente

Poi imposta il bit di scrittura del gruppo sulle directory che devi modificare:

chmod g+w /var/www/html/prestashop/themes/tuo-tema/

Server Dedicato

I server dedicati seguono gli stessi principi delle configurazioni VPS. La differenza principale è nelle prestazioni: hai più risorse, quindi puoi eseguire PHP-FPM con pool dedicati per sito. Ogni pool può essere eseguito come un utente diverso, fornendo un migliore isolamento se ospiti più negozi PrestaShop sullo stesso server.

Modelli di Esecuzione PHP: suPHP vs mod_php vs PHP-FPM

Il modo in cui PHP viene eseguito sul tuo server determina direttamente quale utente scrive i file e quindi quali permessi sono necessari.

mod_php (modulo Apache)

Questo è il modello più vecchio e semplice. PHP viene eseguito come parte del processo Apache, il che significa che tutto il codice PHP viene eseguito come l'utente Apache (tipicamente www-data o apache). Il problema è che i file creati da PHP (cache, upload, ecc.) sono di proprietà dell'utente del server web, non del tuo account. Questo può rendere difficile la gestione via FTP e crea problemi di sicurezza su hosting condivisi perché tutti i siti vengono eseguiti come lo stesso utente.

Con mod_php, i file PrestaShop dovrebbero essere di proprietà dell'utente Apache e i permessi 755/644 funzionano correttamente. Tuttavia, questo modello è in gran parte obsoleto sui server moderni.

suPHP

suPHP esegue PHP come il proprietario del file anziché come l'utente del server web. Questo significa che se i tuoi file sono di proprietà di tuoutente, PHP viene eseguito anche come tuoutente. Questo è più sicuro su hosting condiviso perché ogni account è isolato. I permessi standard 755/644 funzionano perfettamente con suPHP perché il processo PHP e il proprietario del file sono lo stesso utente.

Un'avvertenza importante: suPHP in realtà rifiuta i file con permessi 777 o i file di proprietà di altri utenti. Se imposti 777 su un server suPHP, PHP rifiuterà di eseguire quei file, mostrando un errore 500 Internal Server Error.

PHP-FPM (FastCGI Process Manager)

PHP-FPM è lo standard moderno. Esegue PHP come un processo separato dal server web, con utente/gruppo configurabili per pool. Su un VPS, PHP-FPM viene tipicamente eseguito come www-data. Su hosting condiviso con CloudLinux o simili, ogni account ottiene il proprio pool PHP-FPM eseguito come l'utente di quell'account.

PHP-FPM combinato con Nginx è la configurazione raccomandata per le prestazioni di PrestaShop. Lo schema di permessi standard 755/644 funziona bene. Assicurati che l'utente del pool PHP-FPM corrisponda al proprietario del file o abbia un accesso appropriato tramite il gruppo.

Perché i Permessi 777 Sono Pericolosi

Impostare i permessi a 777 significa che chiunque sul sistema può leggere, scrivere ed eseguire il file. Su hosting condiviso, questo significa che altri account sullo stesso server potrebbero potenzialmente leggere le credenziali del database da parameters.php o iniettare codice malevolo nei tuoi file PHP.

Anche su un VPS dove sei l'unico utente, 777 è inutile e indica una configurazione errata. Se il server web non può scrivere in una directory con permessi 755, la soluzione è correggere la proprietà, non aprire i permessi a tutti. Ecco cosa dovresti fare invece di usare 777:

Controlla quale utente esegue il server web: ps aux | grep -E "apache|nginx|httpd"
Controlla la proprietà dei file: ls -la /var/www/html/prestashop/
Correggi la proprietà: sudo chown -R www-data:www-data /percorso/della/directory
Imposta i permessi corretti: chmod 755 /percorso/della/directory

Se trovi un tutorial o un post su un forum che raccomanda 777 per PrestaShop, si tratta di un consiglio obsoleto e pericoloso. L'unico uso legittimo di 777 è per le directory /tmp che hanno il bit sticky impostato (mostrato come 1777), che è una configurazione a livello di sistema, non qualcosa che si applica ai file PrestaShop.

Considerazioni Docker per PrestaShop

Eseguire PrestaShop in Docker introduce ulteriore complessità ai permessi dei file. All'interno del container, il server web viene eseguito come www-data con un UID specifico (spesso 33 sulle immagini basate su Debian). Sul sistema host, il tuo utente ha un UID diverso. Quando usi i bind mount di Docker per montare i file PrestaShop nel container, la proprietà dei file è determinata dall'UID numerico, non dal nome utente.

Questo significa che i file creati sull'host come il tuo utente (ad esempio, UID 1000) appariranno all'interno del container come UID 1000, che non è www-data (UID 33). Il server web all'interno del container potrebbe non essere in grado di scrivere su questi file.

Le soluzioni per i problemi di permessi Docker includono:

Corrispondenza degli UID: Crea un utente all'interno del container con lo stesso UID del tuo utente host, oppure cambia il server web per eseguirlo con il tuo UID.
Usa chown nell'entrypoint: Aggiungi un comando di avvio che esegue chown -R www-data:www-data /var/www/html quando il container parte. Questo è semplice ma può essere lento per installazioni di grandi dimensioni.
Imposta i permessi di gruppo: Aggiungi il tuo utente host e www-data allo stesso gruppo (tramite GID), poi usa i permessi 775/664.
Volumi nominati: Usa volumi nominati Docker invece dei bind mount. Docker gestisce automaticamente i permessi, ma perdi l'accesso diretto al filesystem dall'host.

Per ambienti di sviluppo con bind mount, l'approccio più pratico è eseguire un comando chown dopo la sincronizzazione o il deploy dei file:

docker exec tuo-container chown -R www-data:www-data /var/www/html/modules/tuo-modulo/

Tieni presente che le operazioni all'interno del container (come l'installazione di un modulo) possono creare file come www-data, mentre le operazioni sull'host creano file come il tuo utente host. Questa costante discrepanza di UID è la fonte più comune di problemi di permessi nelle installazioni PrestaShop dockerizzate.

Risoluzione degli Errori di Permesso Più Comuni

"Failed to open stream: Permission denied"

Questo errore significa che PHP non riesce a leggere o scrivere un file. Controlla la proprietà e i permessi del file menzionato nell'errore. La causa più comune è che l'utente del server web non è il proprietario del file o della directory. Risolvilo con:

sudo chown www-data:www-data /percorso/del/file
sudo chmod 644 /percorso/del/file

"Unable to write to cache directory"

Il motore di template Smarty di PrestaShop e il framework Symfony scrivono entrambi file di cache. Se la directory var/cache/ non è scrivibile, vedrai questo errore. La directory della cache deve essere di proprietà dell'utente del server web:

sudo chown -R www-data:www-data /var/www/html/prestashop/var/cache/
sudo chmod -R 755 /var/www/html/prestashop/var/cache/

Dopo aver corretto i permessi, svuota la cache esistente eliminando il contenuto delle directory di cache:

sudo rm -rf /var/www/html/prestashop/var/cache/prod/*
sudo rm -rf /var/www/html/prestashop/var/cache/dev/*

"Cannot upload image" o "Cannot install module"

Gli upload delle immagini vanno nella directory img/ e le installazioni dei moduli scrivono nella directory modules/. Entrambe devono essere scrivibili dall'utente del server web. Inoltre, controlla che le impostazioni PHP upload_max_filesize e post_max_size siano sufficientemente grandi per i tuoi file, poiché queste possono produrre errori dall'aspetto simile.

sudo chown -R www-data:www-data /var/www/html/prestashop/img/
sudo chown -R www-data:www-data /var/www/html/prestashop/modules/

"index.php is not writable" durante gli aggiornamenti

L'auto-updater di PrestaShop necessita di accesso in scrittura a quasi tutti i file dell'installazione. Prima di eseguire un aggiornamento, imposta la proprietà dell'intera installazione all'utente del server web. Dopo il completamento dell'aggiornamento, puoi ripristinare una proprietà più restrittiva se lo desideri.

Pagina bianca dopo la modifica dei permessi

Se vedi una pagina vuota bianca dopo aver modificato i permessi, potresti aver accidentalmente rimosso il permesso di esecuzione dalle directory. Le directory necessitano del bit di esecuzione per essere attraversate. Una directory con permesso 644 (senza esecuzione) è effettivamente inaccessibile. Usa sempre 755 per le directory, mai 644.

Puoi anche controllare il log degli errori PHP per maggiori dettagli:

sudo tail -50 /var/log/apache2/error.log
# oppure per Nginx:
sudo tail -50 /var/log/nginx/error.log

I permessi si resettano dopo l'upload FTP

Alcuni client FTP impostano i propri permessi predefiniti durante l'upload dei file. Controlla le impostazioni del tuo client FTP per un'opzione "permessi predefiniti" o "umask". Impostalo per creare file come 644 e directory come 755. In alternativa, esegui i comandi di correzione dei permessi dopo ogni upload FTP.

Best Practice di Sicurezza Oltre i Permessi

I permessi corretti dei file sono solo un livello di sicurezza. Considera queste misure aggiuntive:

Limita l'accesso ai file di configurazione: Il file app/config/parameters.php contiene le credenziali del database. Assicurati che sia leggibile solo dall'utente del server web (permesso 640), non da tutti.
Disabilita l'elenco delle directory: Aggiungi Options -Indexes alla configurazione di Apache o autoindex off; a Nginx per impedire ai visitatori di sfogliare il contenuto delle directory.
Proteggi i file .htaccess: PrestaShop posiziona file .htaccess nelle directory sensibili. Non eliminarli.
Rimuovi la directory di installazione: Dopo l'installazione, elimina completamente la directory /install/. PrestaShop ti avvisa al riguardo, ma vale la pena sottolinearlo.
Imposta il corretto umask: Configura il tuo server web e PHP-FPM con un umask di 0022 in modo che i nuovi file vengano creati con permessi 644/755 per impostazione predefinita.

Comprendendo i permessi Linux, adattandoli al tuo ambiente di hosting e seguendo le linee guida di questo articolo, eviterai i problemi di permessi PrestaShop più comuni mantenendo una configurazione sicura del server.

Leggi la risposta completa

Quando gli aggiornamenti dei moduli vanno male

Hai aggiornato un modulo PrestaShop e ora qualcosa non funziona. Forse il checkout ha smesso di funzionare, la homepage mostra errori, o il pannello di amministrazione non risponde più. Gli aggiornamenti dei moduli possono fallire per molti motivi - versioni PHP incompatibili, conflitti con altri moduli, errori di migrazione del database, o semplicemente bug nella nuova versione. Qualunque sia la causa, devi ripristinare rapidamente la versione precedente per ristabilire la funzionalità del tuo negozio.

Purtroppo, PrestaShop non include un pulsante "annulla" integrato per gli aggiornamenti dei moduli. Non esiste una cronologia delle versioni nativa né un meccanismo di rollback automatico per i singoli moduli.

Prima di iniziare - Sicurezza prima di tutto

Metti il negozio in modalità manutenzione
Crea un backup del database
Documenta l'errore attuale

Metodo 1 - Reinstallare la versione precedente dal Back Office

Vai a Moduli > Gestione moduli
Trova il modulo problematico e clicca Disinstalla (NON "Elimina")
Clicca Carica un modulo
Carica lo ZIP della versione precedente funzionante
Installa e configura il modulo

Dove trovare la versione precedente

La tua email - La maggior parte dei venditori invia link di download con ogni acquisto
Account marketplace - Su PrestaShop Addons e marketplace di terze parti come mypresta.rocks, puoi scaricare versioni precedenti dalla cronologia ordini
I tuoi backup - Estrai la cartella del modulo da un archivio di backup
Contatta lo sviluppatore - Gli sviluppatori possono generalmente fornire versioni precedenti

Metodo 2 - Sostituzione file via FTP/SFTP

Collegati al server via FTP/SFTP
Naviga fino a /modules/
Trova la cartella del modulo
Rinomina la cartella attuale - es. mymodule in mymodule_rotto
Carica i file della versione precedente
Imposta i permessi corretti - directory a 755, file a 644
Svuota la cache di PrestaShop

Metodo 3 - Da riga di comando

# Connetti via SSH
ssh user@tuoserver.com

# Vai alla root di PrestaShop
cd /var/www/html/prestashop

# Backup del modulo rotto
mv modules/mymodule modules/mymodule_rotto_$(date +%Y%m%d)

# Estrai la versione precedente
unzip /percorso/mymodule_v1.2.3.zip -d modules/

# Imposta i permessi corretti
find modules/mymodule -type d -exec chmod 755 {} \;
find modules/mymodule -type f -exec chmod 644 {} \;
chown -R www-data:www-data modules/mymodule

# Svuota la cache
rm -rf var/cache/prod/* var/cache/dev/*

Metodo 4 - Rollback completo del database

Se l'aggiornamento del modulo includeva migrazioni del database, dovrai ripristinare un backup del database precedente all'aggiornamento.

Quando serve un rollback del database

Il modulo ha creato nuove tabelle
Il modulo ha modificato strutture di tabelle esistenti
Il modulo ha inserito o modificato valori di configurazione

Metodo 5 - Pulizia manuale del database

// Cerca file tipo:
// modules/mymodule/upgrade/upgrade-2.0.0.php

public function upgrade($version)
{
    if (version_compare($version, '2.0.0', '<')) {
        Db::getInstance()->execute('ALTER TABLE `' . _DB_PREFIX_ . 'mymodule` 
            ADD COLUMN `new_field` VARCHAR(255)');
    }
}

Dopo il downgrade - Pulizia essenziale

Cache Smarty
OPcache - Riavvia PHP-FPM o Apache
Cache CDN
Cache browser - Testa in finestra privata

Verifica la versione del modulo

Dopo il downgrade, verifica che PrestaShop riconosca la versione corretta.

Testa accuratamente

La funzionalità specifica del modulo
Il processo di checkout dall'inizio alla fine
Le pagine admin dove il modulo aggiunge contenuto
Viste mobile e desktop
Performance

Prevenire futuri problemi di aggiornamento

Sempre backup prima di aggiornare
Testare gli aggiornamenti in ambiente di staging
Leggere il changelog
Conservare le versioni precedenti
Verificare la compatibilità

Quando contattare lo sviluppatore del modulo

Se nessun metodo sopra risolve il problema, contatta lo sviluppatore con la tua versione PrestaShop, versione PHP, versioni del modulo e messaggi di errore esatti.

Leggi la risposta completa

Come testare un modulo PrestaShop su staging prima dell'installazione in produzione

Installare un modulo non testato su un negozio PrestaShop attivo è una delle cause più comuni di downtime, processi di checkout malfunzionanti e perdita di fatturato. Un ambiente di staging ti fornisce una sandbox sicura per validare ogni modulo prima che tocchi il tuo negozio di produzione. Questa guida ti accompagna attraverso l'intero processo - dalla creazione di una copia staging del tuo negozio ai test approfonditi del modulo e al deployment sicuro in produzione.

Perché hai bisogno di un ambiente di staging

Un ambiente di staging è una copia esatta del tuo negozio online che non è accessibile al pubblico. Rispecchia il tuo database di produzione, i file, il tema, la configurazione e i moduli installati. Testare su staging ti permette di individuare problemi che altrimenti colpirebbero i tuoi clienti.

Ecco cosa può andare storto quando salti lo staging:

Conflitti tra moduli - Il nuovo modulo potrebbe entrare in conflitto con un modulo esistente, causando schermate bianche, errori JavaScript o funzionalità malfunzionanti su pagine specifiche.
Incompatibilità del tema - I template del modulo potrebbero non renderizzare correttamente con il tuo tema, specialmente se usi un tema personalizzato o fortemente modificato.
Degradazione delle prestazioni - Alcuni moduli aggiungono query al database pesanti, file CSS/JS aggiuntivi o chiamate API esterne che rallentano i tempi di caricamento.
Corruzione del database - Moduli mal scritti possono modificare tabelle core, aggiungere colonne senza una corretta gestione delle migrazioni, o creare trigger che interferiscono con i dati esistenti.
Interruzione dei pagamenti - Se un modulo rompe il processo di checkout o interferisce con il tuo gateway di pagamento, perdi vendite dal momento dell'installazione fino alla scoperta e correzione del problema.

Opzione 1 - Configurazione manuale dello staging (sottodominio)

Questo è l'approccio più comune e funziona con qualsiasi provider di hosting. Crei un sottodominio come staging.tuonegozio.com e vi copi i file e il database di produzione.

Passo 1 - Creare il sottodominio

Nel tuo pannello di controllo hosting (cPanel, Plesk o DirectAdmin), crea un nuovo sottodominio. Puntalo a una nuova directory.

Passo 2 - Copiare i file di produzione

# Via SSH (metodo più veloce)
cp -r /home/tuouser/public_html/* /home/tuouser/staging.tuonegozio.com/

# O crea prima un archivio compresso
cd /home/tuouser/public_html
tar czf /tmp/prestashop-backup.tar.gz --exclude='var/cache' --exclude='var/logs' .
cd /home/tuouser/staging.tuonegozio.com
tar xzf /tmp/prestashop-backup.tar.gz

Passo 3 - Esportare e importare il database

# Esportare il database di produzione
mysqldump -u dbuser -p production_db > /tmp/production_dump.sql

# Creare il database staging
mysql -u root -p -e "CREATE DATABASE staging_db;"
mysql -u root -p -e "GRANT ALL ON staging_db.* TO 'dbuser'@'localhost';"

# Importare nello staging
mysql -u dbuser -p staging_db < /tmp/production_dump.sql

Passo 4 - Aggiornare la configurazione PrestaShop

# Editare app/config/parameters.php (PrestaShop 1.7+/8.x)
'database_name' => 'staging_db',

# Aggiornare l'URL del negozio nel database
mysql -u dbuser -p staging_db -e "
  UPDATE ps_shop_url 
  SET domain = 'staging.tuonegozio.com', 
      domain_ssl = 'staging.tuonegozio.com' 
  WHERE id_shop_url = 1;"

mysql -u dbuser -p staging_db -e "
  UPDATE ps_configuration 
  SET value = 'staging.tuonegozio.com' 
  WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SHOP_DOMAIN_SSL');"

Passo 5 - Svuotare le cache

rm -rf var/cache/prod/* var/cache/dev/*
rm -rf var/cache/smarty/compile/* var/cache/smarty/cache/*

Passo 6 - Limitare l'accesso

AuthType Basic
AuthName "Accesso Staging"
AuthUserFile /home/tuouser/.htpasswd
Require valid-user

Header set X-Robots-Tag "noindex, nofollow"

Opzione 2 - Staging basato su Docker (Raccomandato per sviluppatori)

Docker fornisce l'ambiente di staging più affidabile perché puoi replicare esattamente la tua versione PHP di produzione, versione MySQL e configurazione del server.

# docker-compose.yml
version: '3.8'
services:
  prestashop:
    image: prestashop/prestashop:8.1
    ports:
      - "8080:80"
    volumes:
      - ./html:/var/www/html
    environment:
      - DB_SERVER=db
      - DB_NAME=prestashop
      - DB_USER=prestashop
      - DB_PASSWD=tua_password
    depends_on:
      - db
  db:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=password_root
      - MYSQL_DATABASE=prestashop
      - MYSQL_USER=prestashop
      - MYSQL_PASSWORD=tua_password
    volumes:
      - db_data:/var/lib/mysql
volumes:
  db_data:

Checklist dei test per nuovi moduli

Fase 1 - Verifiche pre-installazione

Leggere la documentazione del modulo - Comprendi cosa fa il modulo, quali hooks usa e quali sono i suoi requisiti.
Controllare il contenuto dei file - Prima dell'installazione, decomprimi il modulo e controlla il codice.
Creare un backup del database - Anche su staging, fai un backup prima dell'installazione.

Fase 2 - Test di installazione

Installare il modulo tramite il Back Office (Moduli > Gestione moduli > Carica un modulo).
Verificare errori di installazione - Dopo l'installazione, controlla che il modulo appaia nella lista.
Verificare le modifiche al database - Confronta le tabelle prima e dopo l'installazione.

Fase 3 - Test funzionali

Pagina di configurazione - Puoi accedere e salvare tutte le impostazioni senza errori?
Visualizzazione front office - Il modulo viene visualizzato correttamente su tutte le pagine pertinenti?
Responsività mobile - Testa su viewport mobili.
Supporto multilingue - Se il tuo negozio usa più lingue, verifica la visualizzazione corretta in ciascuna.
Compatibilità multishop - Se usi la funzionalità multishop, testa il comportamento su diversi negozi.

Fase 4 - Test dei conflitti

Controllare la console del browser - Apri gli strumenti di sviluppo (F12) e cerca errori JavaScript.
Testare il processo di checkout - Aggiungi un prodotto al carrello, completa ogni passaggio e finalizza un ordine test.
Testare l'elaborazione dei pagamenti - Effettua ordini test con ogni metodo di pagamento.
Verificare la funzionalità dei moduli esistenti - Assicurati che i moduli critici funzionino ancora.

Fase 5 - Test delle prestazioni

# Prima dell'installazione del modulo, misurare la baseline
curl -o /dev/null -s -w "Tempo: %{time_total}s\n" https://staging.tuonegozio.com/

# Dopo l'installazione, misurare di nuovo e confrontare
curl -o /dev/null -s -w "Tempo: %{time_total}s\n" https://staging.tuonegozio.com/

Un modulo ben scritto dovrebbe aggiungere meno di 100ms ai tempi di caricamento. Se noti un aumento di 500ms o più, investiga le query al database e il caricamento degli asset del modulo.

Fase 6 - Test di disinstallazione

Disinstalla il modulo dal Back Office
Verifica che tutte le tabelle specifiche del modulo siano rimosse
Controlla che non rimangano hook, file CSS o JavaScript orfani
Verifica che il front office torni al suo stato pre-modulo

Spostare un modulo testato in produzione

Passo 1 - Pianificare il deployment

Scegli un periodo di basso traffico. Controlla i tuoi Google Analytics per identificare quando il tuo negozio ha meno visitatori.

Passo 2 - Creare un backup di produzione

mysqldump -u dbuser -p production_db > /tmp/production_backup_$(date +%Y%m%d_%H%M%S).sql

Passo 3 - Installare in produzione

Carica esattamente lo stesso file ZIP del modulo testato su staging. Non scaricare una nuova versione.

Passo 4 - Applicare la stessa configurazione

Configura il modulo con esattamente le stesse impostazioni usate su staging.

Passo 5 - Monitorare per 24-48 ore

Dopo il deployment, monitora attivamente i log degli errori PHP, Google Analytics e il tasso di conversione degli ordini.

Trabocchetti comuni dello staging da evitare

Dimenticare di aggiornare gli URL - Se copi il database ma dimentichi di aggiornare ps_shop_url, il tuo sito staging reindirizza alla produzione.
Gateway di pagamento in modalità live - Passa sempre i gateway di pagamento in modalità sandbox/test su staging.
Notifiche email inviate ai clienti - Disabilita l'invio di email su staging o reindirizza tutte le email a un indirizzo di test.
Indicizzazione dai motori di ricerca - Blocca sempre lo staging per i motori di ricerca.
Cron job in esecuzione su staging - Disabilita tutti i cron job copiati dalla produzione.

Leggi la risposta completa

Cookie	Fornitore	Finalità	Durata
PrestaShop-*	PrestaShop	Gestione della sessione e funzionalità del carrello	Sessione
PHPSESSID	PHP	Identificativo sessione PHP	Sessione
mprcr_consent	MPR Cookies Revolution	Memorizza le preferenze di consenso dei cookie	365 giorno/i
mprcr_version	MPR Cookies Revolution	Traccia la versione della configurazione del consenso	365 giorno/i

Cookie	Fornitore	Finalità	Durata
TawkConnectionTime	Tawk.to	Czas polaczenia sesji czatu	Sessione
__tawkuuid	Tawk.to	Identyfikuje powracajacych uzytkownikow czatu	6 mese/i

Cookie	Fornitore	Finalità	Durata
_ga	Google Analytics	Distingue utenti unici assegnando un numero generato casualmente	2 anno/i
_ga_*	Google Analytics	Utilizzato per mantenere lo stato della sessione tra le richieste di pagina	2 anno/i
_gid	Google Analytics	Distingue utenti unici per 24 ore	24 ora/e

Installazione e configurazione

Comprendere i Permessi dei File su Linux

Permessi Corretti per Directory e File di PrestaShop

Impostare la Proprietà Corretta con chown

Hosting Condiviso vs VPS vs Server Dedicato

Hosting Condiviso

VPS (Virtual Private Server)

Server Dedicato

Modelli di Esecuzione PHP: suPHP vs mod_php vs PHP-FPM

mod_php (modulo Apache)

suPHP

PHP-FPM (FastCGI Process Manager)

Perché i Permessi 777 Sono Pericolosi

Considerazioni Docker per PrestaShop

Risoluzione degli Errori di Permesso Più Comuni

"Failed to open stream: Permission denied"

"Unable to write to cache directory"

"Cannot upload image" o "Cannot install module"

"index.php is not writable" durante gli aggiornamenti

Pagina bianca dopo la modifica dei permessi

I permessi si resettano dopo l'upload FTP

Best Practice di Sicurezza Oltre i Permessi

Quando gli aggiornamenti dei moduli vanno male

Prima di iniziare - Sicurezza prima di tutto

Metodo 1 - Reinstallare la versione precedente dal Back Office

Dove trovare la versione precedente

Metodo 2 - Sostituzione file via FTP/SFTP

Metodo 3 - Da riga di comando

Metodo 4 - Rollback completo del database

Quando serve un rollback del database

Metodo 5 - Pulizia manuale del database

Dopo il downgrade - Pulizia essenziale

Verifica la versione del modulo

Testa accuratamente

Prevenire futuri problemi di aggiornamento

Quando contattare lo sviluppatore del modulo

Come testare un modulo PrestaShop su staging prima dell'installazione in produzione

Perché hai bisogno di un ambiente di staging

Opzione 1 - Configurazione manuale dello staging (sottodominio)

Passo 1 - Creare il sottodominio

Passo 2 - Copiare i file di produzione

Passo 3 - Esportare e importare il database

Passo 4 - Aggiornare la configurazione PrestaShop

Passo 5 - Svuotare le cache

Passo 6 - Limitare l'accesso

Opzione 2 - Staging basato su Docker (Raccomandato per sviluppatori)

Checklist dei test per nuovi moduli

Fase 1 - Verifiche pre-installazione

Fase 2 - Test di installazione

Fase 3 - Test funzionali

Fase 4 - Test dei conflitti

Fase 5 - Test delle prestazioni

Fase 6 - Test di disinstallazione

Spostare un modulo testato in produzione

Passo 1 - Pianificare il deployment

Passo 2 - Creare un backup di produzione

Passo 3 - Installare in produzione

Passo 4 - Applicare la stessa configurazione

Passo 5 - Monitorare per 24-48 ore

Trabocchetti comuni dello staging da evitare

Altre categorie

Hai ancora domande?