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.