PhpBB Lab Académie

Distinguer la fin d’une répétition de la fin d’une vraie mise à jour, effectuer la migration de base uniquement lorsque nécessaire, puis contrôler versions, données, accès et fonctions avant de conclure.

Les fichiers et la base doivent correspondre

Une vraie nouvelle version peut apporter des modifications de structure ou de contenu dans la base. Copier de nouveaux fichiers ne réalise pas à lui seul ces transformations. Une migration est l’opération qui applique les changements attendus par le logiciel, dans l’ordre prévu par ses auteurs. Elle ne doit pas être remplacée par une modification manuelle du numéro de version.

Nous avons choisi une méthode qui remplace les fichiers à partir du paquet complet. L’assistant doit donc actualiser la base, sans entreprendre une autre méthode de transfert ou de comparaison des fichiers. C’est le sens de « Mettre à jour uniquement la base de données ». Ce choix ne signifie pas que l’on peut laisser de vieux fichiers en place : le remplacement de la leçon précédente est son préalable.

Si votre fiche indique une répétition 3.3.17 vers 3.3.17, aucune migration nouvelle n’est nécessaire. Vous retirerez install/ et passerez aux contrôles. L’assistant peut indiquer que la version est déjà à jour ; cela ne prouve pas qu’une montée de version vient de réussir. La bonne conclusion reste « répétition terminée et vérifiée ».

Ne pas confondre assistant d’installation et de mise à jour

Une nouvelle installation crée un autre forum. Notre clone possède déjà sa configuration et sa base. Son adresse de maintenance est celle du clone suivie de install/app.php/update. Si l’assistant vous demande de créer un nouveau compte fondateur ou de renseigner une nouvelle base comme lors de l’installation initiale, interrompez cette voie : vérifiez l’adresse et la conservation de config.php.

Avec le paquet complet, l’assistant peut annoncer qu’aucun répertoire de mise à jour n’a été trouvé. La documentation officielle décrit ce message lorsque le dossier spécifique d’un paquet de mise à jour avancée n’est pas présent. Le choix de mise à jour de la base reste alors celui attendu. Ce message précis ne doit pas être confondu avec une erreur SQL, une incompatibilité ou un échec d’écriture.

Une erreur réelle doit être relevée exactement. Conservez le texte, l’étape, les versions et le moment ; gardez le clone fermé. Ne cliquez pas en boucle et ne lancez pas d’autres méthodes de mise à jour pour voir si l’une d’elles finit par marcher. S2 reste disponible pour la restauration indépendante du prochain chapitre.

La fin de l’assistant n’est pas la fin des vérifications

Après une migration réussie, install/ doit être retiré de la racine du clone. Renommer simplement ce dossier n’est pas notre méthode : il doit être absent du site installé. Le paquet original peut conserver son install/ dans son emplacement privé de travail. Vérifiez bien de quel emplacement vous retirez ce dossier.

Le cache généré aide le fonctionnement courant, mais peut contenir d’anciens résultats. La purge prévue dans le PCA permet de le reconstruire. Elle n’est pas une sauvegarde et ne corrige pas une migration ratée. Les protections de cache, notamment .htaccess et index.htm, ne doivent pas être supprimées au prétexte de purger.

Les extensions, styles et langues suivent leur propre compatibilité. Le remplacement du cœur n’actualise pas automatiquement toutes les extensions tierces. Pour la répétition, vous retrouvez les versions compatibles inventoriées. Pour une vraie mise à jour, terminez les étapes documentées des ajouts et rétablissez progressivement les éléments temporairement désactivés. Si un ajout nécessaire ne peut pas fonctionner, la recette n’est pas terminée.

Comparer les numéros puis les comportements

La valeur PHPBB_VERSION dans includes/constants.php indique la version des fichiers. La version présentée par le PCA reflète la version enregistrée pour l’installation. Leur cohérence est nécessaire, mais ne suffit pas : un numéro identique n’atteste ni la présence de toutes les pièces jointes ni le bon fonctionnement des permissions.

Nous contrôlerons donc aussi les témoins, les publications, les comptes ordinaires et l’isolement du clone. Un administrateur peut lire des pages alors que des membres rencontrent un refus ; l’écran d’accueil seul est une preuve trop faible. Chaque contrôle reçoit un résultat écrit, avec le compte et l’adresse utilisés.

Une preuve créée après la sauvegarde

Le sujet « Maintenance — témoin du clone » existe dans S2 puisqu’il a été créé avant elle. À la fin de cette leçon, nous créerons un autre sujet, « Maintenance — après intervention », avec le texte : « Message fictif créé après la sauvegarde S2. »

Ces deux repères ne racontent pas la même chose. Le premier doit être retrouvé lors d’un retour à S2. Le second devra être absent de cette restauration, puisqu’il n’existait pas encore au moment sauvegardé. Cette absence future sera un résultat normal, pas une perte inexpliquée.

N’utilisez pas une information réelle importante pour ce test. Le message fictif permet d’observer un point de récupération sans demander à quiconque de sacrifier un vrai échange.

Choisir la branche correspondant à la fiche

1. Vérifiez que vous êtes sur le clone et que son config.php désigne phpbb_ecole_restauration. Relisez les versions de la fiche. Si elles sont égales, n’exécutez aucune migration pour cet exercice : allez directement à l’étape 4. Si une cible réellement plus récente compatible a été installée, continuez à l’étape 2.

2. Dans le navigateur, ouvrez http://localhost/forum-ecole-restauration/install/app.php/update. Si votre port web local est personnalisé, conservez celui de l’adresse du clone ; le port SQL n’a rien à faire dans cette URL. Dans « Type de mise à jour à effectuer », sélectionnez « Mettre à jour uniquement la base de données », puis validez avec « Envoyer ». Le message attendu concernant l’absence de répertoire de mise à jour avancée n’impose pas de changer de méthode.

3. Laissez l’assistant terminer et lisez le compte rendu. Le succès attendu est « La mise à jour de la base de données a été réalisée. » Conservez le résultat dans le journal. En présence d’une erreur réelle ou d’un résultat ambigu, gardez le clone fermé et reportez l’erreur au diagnostic ; ne poursuivez pas comme si le succès était acquis.

4. Dans C:/wamp64/www/forum-ecole-restauration, retirez complètement le dossier install. Vérifiez son absence dans ce dossier précis. Sous CamilleAdmin, ouvrez le PCA du clone, onglet « Général », utilisez « Purger le cache » et confirmez. Conservez « Désactiver le forum » sur Oui pendant les contrôles d’administration.

5. Comparez la version affichée par le PCA avec PHPBB_VERSION dans le fichier installé. Pour la répétition, elles restent toutes deux 3.3.17. Pour la véritable mise à jour, elles doivent correspondre au numéro cible réellement choisi. Vérifiez l’absence d’alerte de mise à jour incomplète, sans considérer cette seule absence comme une validation générale.

6. Terminez les opérations prévues pour les langues, styles et extensions effectivement présents. Vérifiez que l’interface française ne montre pas des identifiants de langue à la place des textes et que le style utilisé fonctionne. Réactivez, une par une selon leurs instructions, les extensions compatibles désactivées pour cette maintenance, puis vérifiez leur fonction réelle. Aucun ajout nouveau n’est nécessaire à notre laboratoire standard.

Ouvrir seulement la fenêtre de contrôles du laboratoire

7. Ouvrez temporairement le clone local aux comptes de test. Le courriel et les sorties désactivées pour l’isolation restent désactivés. Sous inscrit_test, vérifiez le sujet « Maintenance — témoin avant sauvegarde » et sa phrase, puis « Maintenance — témoin du clone ». Ouvrez également http://localhost/forum-ecole-restauration/preuve-maintenance.txt : son texte doit être « Fichier témoin du laboratoire phpBB. »

8. Sous inscrit_test, créez dans le Bac « Maintenance — après intervention » avec le texte de l’exemple, puis ajoutez une réponse fictive. Déconnectez-vous et reconnectez-vous pour vérifier que ce résultat persiste. Sous eleve_test, vérifiez l’accès aux espaces d’adhérents ; en visiteur ou sous inscrit_test, vérifiez qu’ils restent refusés. Sous equipe_test, contrôlez la présence des outils de modération dans Questions publiques et le Bac, ainsi que l’absence d’élargissement volontaire aux autres forums.

9. Reprenez les autres preuves pertinentes de l’inventaire, notamment une pièce jointe ou un avatar si vous en aviez réellement sauvegardé. Vérifiez leur consultation depuis le forum ; la seule présence de fichiers sur le disque ne suffit pas. N’inventez pas un résultat de téléchargement si aucun fichier n’existait dans ce laboratoire.

10. Vérifiez que le forum source ne contient pas « Maintenance — après intervention ». Sous CamilleAdmin, refermez le clone avec « Désactiver le forum » sur Oui. Inscrivez la conclusion exacte : répétition ou véritable mise à jour, versions des fichiers et de la base, témoins retrouvés, fonctions testées, résultats et éventuelles limites. Conservez S2 intacte pour le prochain chapitre.

Une vraie mise à jour combine fichiers cibles, migration nécessaire et recette fonctionnelle. Une répétition à version égale ne nécessite pas de nouvelle migration. Dans les deux cas, install est retiré, les témoins et les accès sont vérifiés, S2 reste intacte et la conclusion décrit uniquement ce qui a été effectivement démontré.