Liste de contrôle de préparation à l'hébergement

Utilisez cette liste de contrôle avant d'acheter un hébergement, avant le premier déploiement de production et après une modification de la configuration du serveur matériel ou du PHP. Enregistrez les preuves et le propriétaire de chaque article ; un message verbal « Laravel est pris en charge » n'est pas suffisant.

Les exigences normatives de plateforme et de fonctionnalités figurent dans Exigences d'hébergement. Les valeurs des ressources doivent provenir d'enregistrements Résultats de capacité d’hébergement produit avec Validation de la capacité d'hébergement, et non d’une estimation sans mesure. Un résultat provisoire constitue uniquement une preuve comparative ; qualifiez le profil réel de production avant de considérer ses valeurs comme des exigences certifiées.

• PHP 8.3 ou une version ultérieure est disponible pour les requêtes web et la CLI, et le fournisseur précise la maintenance des versions correctives.
• Composer 2 peut s'exécuter dans le répertoire de l'application sans délai d'attente artificiel pour l'installation des dépendances.
• mbstring, sodium, zipet pdo_mysql est activé à la fois dans le Web et dans la CLI PHP.
• MySQL 8.0 avec InnoDB est disponible, y compris l'autorisation de créer et de modifier des tables, des index et des clés étrangères.
• La racine du document de domaine peut pointer directement vers le fichier de l'application Laravel. public/ annuaire.
• et un renouvellement automatique sont disponibles.
• Le fournisseur indique la mémoire PHP, le téléchargement, le corps du POST, le délai d'expiration de la demande, le processus, l'inode et les quotas de disque.
• Le fournisseur explique si proc_open, PHP CLI, Composer et les fichiers binaires du client de base de données sont disponibles pour le runtime PHP.
• Le fournisseur explique si les liens symboliques sont autorisés pour public/storage.
• Cron est disponible si le ménage planifié est activé.
• Le HTTPS sortant est autorisé pour Composer, les mises à jour du CMS ou l'importation de médias à distance, le cas échéant.
• La conservation des sauvegardes, la procédure de restauration, la surveillance et l'escalade du support sont documentées.
• Les profils de base, de média, d'opérations et de trafic sélectionnés sont identifiés comme étant applicables ou non applicables.

Toute réponse « non » doit être associée à une fonctionnalité délibérément désactivée ou à une procédure de déploiement/d'exploitation externe avant approbation.

• La version de production est installée dans une application Laravel 12.55+ ou Laravel 13 et n’est pas servie directement depuis le dépôt source du paquet.
• Rapports Web et CLI compatibles avec les versions PHP et les jeux d'extensions.
• composer check-platform-reqs est transmis à l'application hôte déployée.
• La connexion à la base de données réussit et utilise la base de données de production prévue.
• APP_KEY est défini, APP_DEBUG=falseet APP_URL est l’URL HTTPS canonique.
• La racine Web est public/; /.env et /.git/config Le comportement de réécriture/contrôleur frontal 404.
• Laravel fonctionne pour une route non-fichier.
• /webadmin achemine via Laravel tandis que /cms sert les actifs statiques appartenant au package.
• storage/, bootstrap/cache, le disque de sauvegarde et requis public/site sont accessibles en écriture par le runtime PHP sans 777.
• public/storage fonctionne lorsque le disque public standard est utilisé.
• Des sauvegardes de bases de données et de fichiers existent en dehors de l'application, et un test de restauration a un propriétaire et une date.
• Les hypothèses relatives à la mémoire, au délai d'attente, au téléchargement, au disque et aux fonctionnalités du profil de capacité sélectionné correspondent à ce serveur.

Marquer les fonctionnalités inutilisées comme non applicables et enregistrer pourquoi.

• Média : un téléchargement peut être stocké et servi ; lorsque des variantes d'image sont requises, GD et le codec au format source sont disponibles.
• Mail: La réinitialisation du mot de passe et l'envoi des notifications de contact atteignent la boîte aux lettres de test prévue via un transport réel.
• Notifications du panneau : Lorsque les courriels sont désactivés et qu’aucun planificateur ne fonctionne, un responsable des opérations du site peut voir les nombres enregistrés de messages non lus ou en attente de réponse et ouvrir la boîte filtrée sur le bon site. Les autres sites restent exclus ; l’ouverture du panneau ne modifie ni l’état des messages ni celui de la livraison.
• : lorsque les notifications par lots/quotidiennes, les résumés quotidiens ou le nettoyage programmé sont sélectionnés, l'administrateur/fournisseur du serveur a configuré Laravel schedule:run chaque minute sous l’utilisateur de l’application avec le bon binaire PHP CLI. Enregistrez le responsable et le chemin réel de l’application ; un planificateur existant qui fonctionne n’a pas besoin d’une deuxième entrée cron.
• Dépendances des notifications : un véritable transport de courrier sortant, canonique APP_URLet un cache partagé avec des verrous atomiques pour plusieurs travailleurs sont configurés. Les nouveaux sites utilisent par défaut des notifications groupées et des résumés quotidiens.
• Preuve du planificateur : sur CMS 1.95.1+, Paramètres du tableau de bord/site ou php artisan webblocks:scheduler:status --json affichent un signal de présence planifié récent et une exécution des notifications terminée. Vérifiez que les preuves passent à l’état retardé après cinq minutes sans exécution. L’exécution manuelle de la commande d’envoi ou la liste des tâches ne prouve pas l’exécution du planificateur.
• : , son contrôle en amont de l'administrateur réussit les vérifications de base de données, d'extension, de processus, d'accès en écriture, de verrouillage et d'espace libre.
• Sauvegarde/restauration MySQL : sont disponibles lorsque des sauvegardes de base de données natives au niveau de l'application sont utilisées.
• Médias distants : fonctionnent uniquement si une importation à distance est requise.

• La page d'accueil publique renvoie la réponse sécurisée attendue.
• /webadmin/login se charge via HTTPS et un administrateur autorisé peut se connecter.
• CMS CSS, JavaScript et les actifs de marque sous /cms renvoient des réponses positives.
• Un brouillon peut être créé et prévisualisé sans devenir publiquement visible.
• Un élément multimédia peut être téléchargé, affiché et supprimé conformément à la stratégie.
• Les journaux ne contiennent aucune erreur d’autorisation, de base de données, de contenu mixte ou d’extension manquante provenant du test de fumée.
• Les sauvegardes, la propriété du déploiement/mise à jour, la surveillance et les contacts d'urgence sont enregistrés lors du transfert.

Conservez les éléments suivants avec l'enregistrement de déploiement sans inclure de secrets :

• plan d'hébergement ou profil de serveur et région ;
• Versions PHP et base de données ;
• noms d'extension activés ;
• Résultat composer check-platform-reqs ;
• limites de ressources configurées et disque disponible au moment de l'acceptation ;
• version du dispositif/profil de capacité, emplacement des résultats bruts, date de qualification et pire cas de cinq analyses ;
• modèle de propriété de la racine du document et du système de fichiers ;
• fonctionnalités facultatives activées et leurs dépendances ;
• date et opérateur du test de fumée ; et
• date du test de sauvegarde/restauration, conservation et partie responsable.

Répétez les sections pertinentes après avoir modifié la version de PHP, le moteur de base de données, la racine du document, la propriété du système de fichiers, la méthode de déploiement ou le fournisseur d'hébergement.