PHP e l’area dati

Con il modulo «PHP» sul tuo sito gira codice lato server. Vede due cartelle: i tuoi file pubblicati sotto /var/www/html – in sola lettura e sostituiti a ogni pubblicazione – e l’area dati sotto /var/www/storage, dove il tuo codice scrive e che nessuna pubblicazione tocca. Il percorso lo leggi con getenv('PUBLISHING_STORAGE'). File come una configurazione con una chiave API vanno caricati nel portale, nella scheda «Dati» – mai nella chat.

In sintesi

Posizione	Cosa contiene	Il tuo codice può
/var/www/html	I tuoi file pubblicati	solo leggere
/var/www/storage	L’area dati: configurazione, ordini, caricamenti	leggere e scrivere
/var/www/storage/sessions	Le sessioni dei tuoi visitatori – PHP le gestisce da sé	non toccarle
/var/www/tmp	I caricamenti finché la richiesta è in corso	non metterci nulla di proprio
/tmp	Spazio temporaneo, 64 MB, svuotato a ogni pausa	solo cose di breve durata

Un percorso fuori da questi quattro si interrompe con un messaggio su open_basedir. Non è un errore del tuo codice, è il confine.

Nell’anteprima PHP funziona per tutti. Per pubblicarlo serve il modulo.

Due cartelle – e perché

I tuoi file – tutto ciò che costruisce il tuo assistente – sono lo stato pubblicato. Vengono sostituiti integralmente a ogni pubblicazione e, mentre il sito è in funzione, non può modificarli. È voluto: ciò che viene servito non deve potersi riscrivere da sé. È esattamente quello che blocca la forma più comune di insediamento dopo una falla – chi trova una falla non può lasciare un file che giri insieme al prossimo visitatore.

L’area dati sta accanto. È lì che scrive il tuo PHP, e una pubblicazione non la tocca mai. Non è raggiungibile dal web: quello che vi si trova lo consegna il tuo sito stesso – con il proprio controllo su chi può vederlo. Un .php caricato lì non viene mai eseguito.

Raggiungere l’area dati in PHP

Il percorso sta nella variabile d’ambiente PUBLISHING_STORAGE. Prendilo da lì invece di scriverlo fisso:

<?php
$dati = getenv('PUBLISHING_STORAGE') ?: '/var/www/storage';

file_put_contents($dati . '/ordini.csv', $riga, FILE_APPEND | LOCK_EX);

getenv() e non $_ENV: qui $_ENV è vuoto, PHP non lo riempie in questa installazione.

Altre due variabili ti aiutano:

• PUBLISHING_VORSCHAU vale 1 quando il codice gira nell’anteprima, altrimenti manca. Così nell’anteprima il tuo sito può usare, per esempio, una chiave di prova di un’API di pagamento.
• PUBLISHING_HOSTING vale sempre 1 – il tuo codice capisce così che gira da noi e non sul tuo computer.

Metterci dei file: la scheda «Dati»

L’area di lavoro del tuo sito ha la scheda «Dati». Lì carichi, crei cartelle, scarichi ed elimini – per esempio il file di configurazione da cui il tuo codice legge la sua chiave API. Non ce n’è uno prestabilito: l’area dati all’inizio è vuota, e come si chiama il file e cosa contiene lo decide il tuo codice.

Come procedere:

1. Chiedi al tuo assistente quale file si aspetta il codice e cosa ci va dentro – con segnaposto al posto dei valori veri.
2. Crea il file sul tuo computer e inserisci lì i valori veri.
3. Apri la scheda «Dati», scegli in alto Live o Anteprima e carica il file.
4. Apri la pagina che ha bisogno del file. Controlla prima nell’anteprima – è lì che vedi i messaggi di errore.

E lo fai lì, non nella chat. In quei file ci sono chiavi e password, e non devono passare attraverso un modello linguistico. Il tuo assistente non ha volutamente nessuno strumento per l’area dati; può dirti cosa ci va, ma devi metterlo tu. L’FTP da noi non c’è.

Cosa può fare la scheda e cosa no:

• Un singolo file può pesare fino a 100 MB.
• Una cartella si può eliminare solo se è vuota – un clic sbagliato non deve portarsi via un intero albero.
• Non ci sono versioni. Quello che elimini o sovrascrivi qui è perso. A differenza dei file del sito, il tuo assistente non può recuperare nulla.
• La cartella sessions appartiene a PHP e non viene mostrata.
• Un nome non può finire con un punto o uno spazio, può essere lungo al massimo 120 caratteri e non può trovarsi oltre dieci livelli di cartelle. .. non è permesso.
• Un punto iniziale resta: .env dopo il caricamento si chiama ancora .env.

Live e anteprima

L’anteprima ha una propria area dati, separata da quella del sito pubblicato. Chi guarda una nuova versione della sua gestione ordini non deve sovrascrivere gli ordini veri. Con il selettore in alto nella scheda «Dati» passi dall’una all’altra.

• L’area dell’anteprima all’inizio è vuota. Se il tuo codice ha bisogno di una configurazione per partire, devi depositarla anche lì. È il motivo più frequente per cui qualcosa funziona live e non nell’anteprima.
• Resta da un’anteprima all’altra e durante le pause. Viene eliminata quando il sito non è più ospitato da MADLAB.
• Le due aree contano insieme sullo spazio del tuo piano.

Cosa funziona

• Le sessioni. Un accesso resta attivo, anche durante una pausa del sito.
• I caricamenti dei tuoi visitatori fino a 100 MB per file e fino a 20 file per richiesta.
• Servizi in Internet via HTTPS: API di pagamento, servizi di mappe, fornitori di newsletter.
• E-mail via SMTP presso un fornitore di posta, sulla porta 587 o 465. Vedi più sotto a proposito di mail().
• SQLite come database, in un file nell’area dati.
• .htaccess vale completamente: reindirizzamenti, header, php_value.
• PHP 8.4 con le estensioni comuni, tra cui curl, mbstring, openssl, sodium, gd, intl, zip, exif, pdo_sqlite e sqlite3.
• Fuso orario Europe/Zurich, set di caratteri UTF-8.

Cosa non funziona

• mail() non invia nulla. Restituisce false, live come nell’anteprima. Per i moduli di contatto usa SMTP presso un fornitore di posta – così i messaggi arrivano anche in modo più affidabile, perché il fornitore si occupa della verifica del mittente (SPF, DKIM).
• Nessun server di database. Da noi non c’è MySQL, e nemmeno un database altrove è raggiungibile: verso l’esterno sono aperte solo le porte 80, 443, 587 e 465, e MySQL ha bisogno della 3306. Usa SQLite, o un servizio che offre un’API via HTTPS.
• Niente da eseguire. exec, shell_exec, system e simili sono disattivati. Sul server non c’è né riga di comando né Composer.
• Niente di pianificato. Non c’è un cron. Ciò che deve avvenire a intervalli regolari va svolto durante una richiesta di pagina.
• Nessun servizio proprio, nessuna porta aperta, nessuna connessione verso reti private.
• Non scrivere nei tuoi file. /var/www/html è in sola lettura.

I file con queste estensioni non vengono mai serviti, anche se volessi permetterlo in un .htaccess: .env, .ini, .log, .sql, .bak, .swp, .git, composer.json, composer.lock, e tutto ciò che inizia con un punto (tranne .well-known). È una seconda protezione – la prima è non avere affatto file simili tra i file del sito.

I limiti in cifre

Cosa	Limite
Area dati, live e anteprima insieme	500 MB nel piano «hosting MADLAB»
Un file nella scheda «Dati»	100 MB
Caricamento di un visitatore	100 MB per file, 20 file, 110 MB per richiesta
Memoria per richiesta	128 MB
Tempo di esecuzione per richiesta	30 secondi
Richieste simultanee	8
Pausa dopo	15 minuti senza visite (anteprima: 10)

Dopo una pausa la prima richiesta dura un po’ di più, perché il sito deve avviarsi. Le sessioni e l’area dati lo superano; ciò che stava in /tmp no.

Messaggi di errore

L’anteprima mostra i messaggi di errore. Sulla pagina pubblicata restano nascosti, così che davanti ai visitatori non finiscano percorsi e query – live vedi una pagina bianca o una pagina di errore generica. Per cercare gli errori usa quindi sempre l’anteprima. Il registro del sito pubblicato non ti è accessibile; se te ne serve uno, scrivilo tu stesso nell’area dati (vedi le buone pratiche).

Backup

L’area dati non viene salvata – né live né per l’anteprima. I file del tuo sito sono versionati e si possono recuperare; quello che il tuo PHP scrive nell’area dati no. Scarica quindi regolarmente i dati importanti, come gli ordini, nella scheda «Dati», oppure dai al tuo sito una funzione di esportazione.

Come costruire un sito PHP sicuro, robusto e facile da mantenere è spiegato nelle buone pratiche per i siti PHP.