Elenco di controllo della preparazione dell'hosting

Utilizzare questo elenco di controllo prima di acquistare l'hosting, prima della prima distribuzione in produzione e dopo una modifica della configurazione del server materiale o PHP. Registrare le prove e il proprietario di ogni articolo; un verbale “Laravel è supportato” non è sufficiente.

I requisiti normativi della piattaforma e delle funzionalità sono riportati in Requisiti di hosting. I valori delle risorse devono provenire da quelli registrati Risultati della capacità di hosting prodotto con Convalida della capacità di hosting, non da una stima priva di misurazioni. Un risultato indicato come provvisorio vale solo come prova comparativa; qualificate il profilo reale di produzione prima di considerare i suoi valori requisiti certificati.

• PHP 8.3 o successivo è disponibile sia per le richieste web sia per la CLI e il fornitore indica come vengono mantenute le versioni correttive.
• Composer 2 può essere eseguito nella directory dell'applicazione senza un timeout artificiale per l'installazione delle dipendenze.
• mbstring, sodium, zipe pdo_mysql sono abilitati sia nel Web che nella CLI PHP.
• È disponibile MySQL 8.0 con InnoDB, inclusa l'autorizzazione per creare e modificare tabelle, indici e chiavi esterne.
• La radice del documento di dominio può puntare direttamente all'applicazione Laravel public/ .
• Sono disponibili certificati HTTPS e rinnovo automatico.
• Il provider indica PHP memoria, caricamento, corpo del POST, timeout della richiesta, processo, inode e quote del disco.
• Il provider spiega se proc_open, PHP CLI, Composer e i file binari del client del database sono disponibili per il runtime PHP.
• Il provider spiega se sono consentiti i collegamenti simbolici per public/storage.
• Cron è disponibile se verrà abilitata la pulizia pianificata.
• HTTPS in uscita è consentito per Composer, aggiornamenti CMS o importazione di supporti remoti, a seconda dei casi.
• La conservazione del backup, la procedura di ripristino, il monitoraggio e l'escalation del supporto sono documentati.
• I profili principali, multimediali, operativi e di traffico selezionati sono identificati come applicabili o non applicabili.

Qualsiasi risposta "no" deve essere abbinata a una funzione deliberatamente disabilitata o a una procedura operativa/di distribuzione esterna prima dell'approvazione.

• La versione di produzione è installata in un’applicazione Laravel 12.55+ o Laravel 13 e non viene servita direttamente dal repository del pacchetto.
• Report Web e CLI versioni e set di estensioni PHP compatibili.
• composer check-platform-reqs passa nell'applicazione host distribuita.
• La connessione al database ha esito positivo e utilizza il database di produzione previsto.
• APP_KEY è impostato, APP_DEBUG=falsee APP_URL è l'URL HTTPS canonico.
• La radice web è public/; /.env e /.git/config ritorno 404.
• Laravel funziona per un instradamento non file.
• /webadmin instrada attraverso Laravel mentre /cms fornisce risorse statiche di proprietà del pacchetto.
• storage/, bootstrap/cache, il disco di backup e obbligatorio public/site sono scrivibili dal runtime PHP senza 777.
• public/storage funziona quando viene utilizzato il disco pubblico standard.
• I backup di database e file esistono all'esterno dell'applicazione e un test di ripristino ha un proprietario e una data.
• I presupposti di memoria, timeout, caricamento, disco e funzionalità del profilo di capacità selezionato corrispondono a questo server.

Contrassegnare le funzioni inutilizzate come non applicabili e registrarne il motivo.

• Supporto: un caricamento può essere archiviato e servito; quando sono richieste varianti di immagine, sono disponibili GD e il codec del formato sorgente.
• Posta: La reimpostazione della password e la consegna della notifica di contatto raggiungono la casella di posta di prova prevista tramite un trasporto reale.
• Notifiche del pannello: Con l’email disabilitata e senza scheduler in esecuzione, un responsabile delle operazioni del sito può vedere i conteggi salvati dei messaggi non letti o in attesa di risposta e aprire la casella filtrata per il sito corretto. Gli altri siti restano esclusi; aprire il pannello non modifica lo stato dei messaggi o della consegna.
• Programmazione: quando vengono selezionate le notifiche batch/giornaliere, i riepiloghi giornalieri o la pulizia pianificata, l'amministratore/provider del server ha configurato Laravel schedule:run ogni minuto con l’utente dell’applicazione e il binario PHP CLI corretto. Registrate il responsabile e il percorso reale dell’applicazione; uno scheduler già funzionante non richiede un’altra voce cron.
• Dipendenze di notifica: un vero e proprio trasporto di posta in uscita, canonico APP_URLe una cache condivisa con blocchi atomici per più nodi di lavoro sono configurati. Per impostazione predefinita, i nuovi siti utilizzano notifiche in batch e riepiloghi giornalieri.
• Prova dello scheduler: su CMS 1.95.1+, Impostazioni dashboard/sito o php artisan webblocks:scheduler:status --json mostrano un heartbeat pianificato recente e un’esecuzione delle notifiche completata. Verificate che le prove risultino in ritardo dopo cinque minuti senza esecuzione. Eseguire manualmente il comando di invio o elencare le attività non dimostra l’esecuzione dello scheduler.
• Aggiornamento del sistema: la verifica preliminare dell'amministratore supera i controlli del database, dell'estensione, del processo, dell'accesso in scrittura, del blocco e dello spazio libero.
• Backup/ripristino MySQL: sono disponibili quando verranno utilizzati i backup del database nativo a livello di applicazione.
• Supporti remoti: funzionano solo se è richiesta l'importazione remota.

• La home page pubblica restituisce la risposta sicura prevista.
• /webadmin/login carica tramite HTTPS e un amministratore autorizzato può accedere.
• CMS CSS, JavaScript e le risorse del marchio in /cms restituiscono risposte corrette.
• Una bozza può essere creata e visualizzata in anteprima senza diventare visibile pubblicamente.
• Un elemento multimediale può essere caricato, visualizzato ed eliminato in base alla policy.
• I registri non contengono errori di autorizzazione, database, contenuti misti o estensioni mancanti dal test del fumo.
• Backup, proprietà di distribuzione/aggiornamento, monitoraggio e contatti di emergenza vengono registrati nel trasferimento.

Conserva quanto segue con il record di distribuzione senza includere i segreti:

• piano hosting o profilo server e regione;
• PHP e versioni del database;
• nomi di estensioni abilitate;
• composer check-platform-reqsrisultato;
• limiti di risorse configurati e disco disponibile al momento dell'accettazione;
• versione del dispositivo/profilo della capacità, posizione del risultato grezzo, data di qualificazione e caso peggiore di cinque esecuzioni;
• modello di proprietà della root dei documenti e del filesystem;
• funzionalità opzionali abilitate e relative dipendenze;
• data e operatore della prova fumi; E
• data del test di backup/ripristino, conservazione e parte responsabile.

Ripeti le sezioni pertinenti dopo aver modificato la versione PHP, il motore del database, la radice del documento, la proprietà del file system, il metodo di distribuzione o il provider di hosting.