PhpBB Lab Académie

Rechercher dans ce cours

Sauvegarder, restaurer et mettre à jour son forum phpBB

Auteur : phpBB-Lab. Date de cette version : jeu. 17 sept. 2026 12:12.

Choisir une version cible et vérifier sa compatibilité

Objectif de la leçon

Décider si une véritable mise à jour est possible et nécessaire, identifier un paquet complet adapté et vérifier les dépendances avant de modifier le clone restauré.

Explications

Notre point de départ est un clone qui fonctionne

Vous avez restauré Forum école sous une autre adresse, avec une base et un compte SQL distincts. Les messages témoins, les fichiers et les accès ont été vérifiés. Cette copie est maintenant notre laboratoire de maintenance. Nous travaillons exclusivement dans forum-ecole-restauration. Le forum source forum-ecole reste à l’écart des manipulations de ce chapitre.

Mettre à jour signifie passer d’une version installée à une version plus récente. Recopier les fichiers de la même version est une réinstallation des fichiers, utile pour répéter une méthode, mais ce n’est pas une montée de version. Cette distinction évite de déclarer une opération réussie alors qu’aucune nouvelle version n’a été installée.

Le parcours précédent utilise phpBB 3.3.17. Lors de la préparation de cette édition, la page officielle de téléchargement présentait encore 3.3.17 comme version stable de la branche 3.3. Nous n’inventons donc pas une version suivante pour l’exercice. Si cette situation est toujours celle que vous constatez, vous ferez une répétition avec le paquet complet 3.3.17. Si une version stable 3.3 plus récente est effectivement disponible lorsque vous étudiez ce cours, suivez la branche de véritable mise à jour, après les vérifications ci-dessous.

La source du paquet fait partie du choix

Consultez la page officielle de téléchargement https://www.phpbb.com/downloads/ et l’annonce correspondant à la version envisagée. Relevez le numéro exact et vérifiez qu’il s’agit d’une version stable. Un paquet de développement, une version candidate ou une autre branche majeure ne remplace pas ce choix. Notre procédure traite la maintenance au sein de la branche 3.3 ; elle ne constitue pas un guide de migration vers une autre branche.

Le paquet complet, nommé « Full Package » sur le site officiel, contient les fichiers du logiciel. Il peut servir à une installation neuve ou au remplacement des fichiers d’une installation existante. La différence dépend de ce que vous conservez et de l’assistant que vous utilisez : nous protégerons la configuration et les données, puis utiliserons uniquement la mise à jour de la base lorsqu’une montée de version le demande.

Le paquet de mise à jour avancée répond à un autre besoin, notamment lorsque des fichiers du cœur ont été modifiés. Notre cursus n’a pas modifié ce cœur. Avoir une extension ou un style supplémentaire ne signifie pas automatiquement avoir modifié le cœur. N’adoptez pas une procédure plus complexe simplement parce que son nom contient « avancée ».

Compatibilité : plusieurs éléments doivent fonctionner ensemble

Une version de phpBB s’exécute avec une version de PHP et un système de base de données. Reprenez les versions réellement relevées dans votre inventaire : ne confondez pas la version de WampServer, celle de PHP et celle de phpBB. Consultez les prérequis de la version cible ; un numéro plus élevé n’est pas, à lui seul, une preuve de compatibilité.

Une extension ajoute du code et peut avoir ses propres limites de compatibilité. Un style fournit l’affichage et doit convenir à la version utilisée. Un paquet de langue contient les textes de l’interface ; conserver un ancien paquet sans contrôle peut laisser manquer de nouveaux libellés. Listez ce qui est réellement installé et actif sur votre clone, puis consultez les indications de chaque fournisseur.

Les cours précédents n’ont pas demandé d’installer les extensions du site PHPBB Lab dans votre Forum école. L’extension School qui présente ce cours sur la plateforme n’est donc pas supposée présente dans votre laboratoire. Inscrivez « aucune extension supplémentaire installée pendant le parcours » si cela correspond à votre inventaire ; ne recopiez pas la liste des extensions d’un autre site.

Pour la répétition 3.3.17, utilisez le même paquet complet français vérifié que celui de l’installation, avec son archive d’origine conservée. Pour une vraie version cible différente, procurez-vous aussi le paquet français compatible, en respectant sa provenance. Le paquet complet officiel peut ne fournir que l’anglais britannique. La disponibilité du cœur ne prouve pas que chaque ajout est prêt.

Une décision écrite avant les fichiers

Votre fiche de décision dira : version installée, version cible, origine du paquet, prérequis vérifiés, extensions actives, styles, langues, méthode retenue et résultat attendu. Une information manquante se note comme telle. Si une extension indispensable n’est pas compatible, l’opération n’est pas prête : on recherche une solution documentée, on adapte le projet sur le clone ou on diffère. On ne teste pas d’abord sur le forum source pour gagner du temps.

Cette fiche est courte, mais elle vous évite de chercher après coup quel paquet a été utilisé. Elle accompagnera la sauvegarde S2 que nous préparerons à la prochaine leçon.

Exemple commenté

Deux décisions possibles pour le même laboratoire

Cas A : votre clone indique 3.3.17 et la version stable proposée est encore 3.3.17. Vous écrivez : « Répétition du remplacement des fichiers en 3.3.17. Aucune montée de version. Migration de base non nécessaire. » Le résultat attendu est un clone toujours en 3.3.17, avec toutes ses données et ses particularités conservées.

Cas B : l’annonce officielle présente une version stable de la branche 3.3 plus récente, dont vous avez vérifié les prérequis et les ajouts. Vous inscrivez son vrai numéro, la date de consultation et la référence du paquet. Le résultat attendu comprend alors les nouveaux fichiers ET une base migrée vers cette version. Le cours ne fournit aucun numéro futur à copier.

Dans les deux cas, vous travaillez sur le clone, vous créez S2 avant l’intervention et vous testez les mêmes fonctions après celle-ci. Répéter correctement la méthode permet d’apprendre sans fabriquer une fausse mise à jour.

Exercice à réaliser

Rédiger la fiche sans encore remplacer de fichier

1. Dans le navigateur, vérifiez l’adresse du clone : http://localhost/forum-ecole-restauration/. Connectez-vous sous CamilleAdmin et ouvrez le PCA. Relevez la version de phpBB présentée. Si un message indique une mise à jour incomplète, consignez-le et ne prenez pas cet état comme un point de départ valide.

2. Dans le dossier du clone, ouvrez en lecture le fichier includes/constants.php et repérez la ligne contenant PHPBB_VERSION. Notez sa valeur, sans modifier le fichier. La version affichée dans le PCA et celle des fichiers doivent être cohérentes au départ. Un écart mérite un diagnostic avant toute nouvelle intervention.

3. Consultez les prérequis et l’annonce de la version stable 3.3 réellement proposée. Reprenez vos versions de PHP et du serveur SQL, puis l’inventaire des extensions, styles et langues. Consignez les compatibilités établies et ce qui reste inconnu. Si votre installation contient des modifications personnelles du cœur, arrêtez cette méthode de remplacement standard et préparez leur traitement séparément.

4. Téléchargez ou retrouvez le paquet complet retenu dans un dossier privé d’atelier. Décompressez-le séparément du forum. Dans son propre includes/constants.php, vérifiez PHPBB_VERSION. Comparez le numéro à votre fiche et le contenu au type de paquet annoncé. L’archive française d’origine 3.3.17 convient à la répétition à cette même version.

5. Écrivez la fiche dans votre journal de maintenance. Commencez par « répétition à version égale » ou « mise à jour vers [numéro réellement vérifié] ». Ajoutez l’adresse et le dossier du clone, le nom de sa base, l’origine de l’archive, les prérequis et les ajouts examinés. Ne notez aucun mot de passe.

6. Relisez la décision. Le forum source n’a été ni remplacé ni migré. Le clone reste dans l’état restauré validé, fermé hors des fenêtres de contrôle. Conservez le paquet prêt pour la prochaine leçon.

Correction et résultat attendu

Une fiche exploitable, même sans nouvelle version

Pour le laboratoire initial, le résultat normal est la répétition 3.3.17 tant qu’aucune cible plus récente compatible n’a été effectivement vérifiée. Ce choix n’est pas un échec : vous apprendrez le remplacement et la conservation des données, puis le contrôle final. Vous n’exécuterez pas une migration simplement pour faire afficher un message de succès.

Dans le cas d’une vraie mise à jour, votre fiche permet de retrouver le numéro exact, le paquet correspondant et la raison de considérer l’ensemble compatible. La seule mention « dernière version » ne suffit pas, car cette expression change avec le temps. Une capture de la page d’accueil ne remplace pas non plus l’inventaire technique.

Si les versions de départ ne correspondent pas entre le PCA et les fichiers, conservez les valeurs et les messages d’erreur. Ne changez jamais manuellement la valeur de version en base ou dans constants.php pour rendre les numéros identiques : cela ne réalise aucune migration.

À retenir

Choisir une cible vient avant remplacer les fichiers. Le paquet complet doit correspondre à une version stable réellement disponible et compatible avec l’environnement et ses ajouts. À version égale, nous effectuons une répétition, pas une mise à jour. Les numéros de version se vérifient ; ils ne se corrigent pas à la main.

Seuil de réussite, en pourcentage : 100 %. QCM obligatoire pour terminer le cours.

Sommaire du cours

Préparer une maintenance que l’on peut vérifier

  1. Comprendre ce qu’il faut retrouver après une panne
  2. Relever un état technique et préparer son carnet de maintenance
  3. Créer des témoins et organiser une fenêtre sans écritures

Constituer une sauvegarde complète et contrôlée

  1. Exporter toute la base dans un fichier SQL réutilisable
  2. Copier les fichiers du forum sans oublier ses données
  3. Contrôler S1, conserver une seconde copie et rouvrir la source

Restaurer et vérifier une copie indépendante

  1. Restaurer la base dans une destination indépendante
  2. Relier les fichiers au clone et isoler son fonctionnement
  3. Prouver la restauration avec les contenus et les accès

Mettre à jour sur une copie vérifiée

  1. Choisir une version cible et vérifier sa compatibilité
  2. Sauvegarder le clone puis remplacer les fichiers du cœur
  3. Terminer la migration nécessaire et vérifier le résultat

Revenir en arrière et entretenir sa méthode

  1. Revenir à un état sauvegardé dans un second clone isolé
  2. Diagnostiquer un échec et choisir la suite de la maintenance
  3. Valider son projet et construire une routine de sauvegarde