PhpBB Lab Académie

Classer un problème selon ce qui échoue réellement, recueillir des indices utiles sans modifier plusieurs réglages à la fois, puis décider entre correction ciblée, arrêt de l’intervention et retour à une sauvegarde cohérente.

Commencer par une observation exacte

Une page d’accueil visible ne prouve pas que tout fonctionne. Inversement, un refus de connexion n’indique pas toujours une base endommagée. Avant d’agir, notez l’heure, l’adresse exacte, le compte utilisé, l’action tentée et le texte de l’erreur. Précisez aussi l’installation concernée : source, clone restauration ou clone retour. Ces quelques éléments permettent de rattacher un symptôme à une opération et à un environnement.

Reprenez votre carnet : quel est le dernier contrôle réussi ? Quelle modification a été faite juste avant l’échec ? Une erreur apparue après modification du config.php invite d’abord à relire cette copie. Une erreur apparue après import ne justifie pas de changer le mot de passe de tous les comptes. Le but n’est pas de trouver une manipulation qui fait disparaître l’erreur à tout prix, mais d’en expliquer la cause.

Distinguer adresse, connexion SQL et application

Si le navigateur ne trouve pas localhost ou refuse la connexion, vérifiez que Wamp et le service web attendu fonctionnent, puis le port web utilisé. Si une page « introuvable » apparaît pour un clone, contrôlez son chemin et son dossier final. Ne confondez pas le port web de l’adresse avec le port MySQL ou MariaDB indiqué dans config.php.

Si phpBB signale un échec de connexion à la base, vérifiez dans le config.php de cette installation le moteur, l’hôte, le port SQL, le nom de base et l’utilisateur. Le compte SQL doit exister pour l’hôte prévu et posséder des droits sur cette seule base. Son mot de passe est distinct du mot de passe du compte forum CamilleAdmin. Une erreur d’accès SQL n’est pas une invitation à utiliser le compte SQL de gestion dans phpBB.

Si le site charge mais semble vide, vérifiez d’abord que le compte connecté peut voir les espaces attendus. Dans notre cours, les visiteurs ne lisent pas les espaces des adhérents. Vérifiez ensuite le nom de base et le préfixe : une connexion réussie à une autre base n’est pas une restauration réussie. Ne recréez pas immédiatement des forums ou des utilisateurs qui semblent manquer ; vous risqueriez d’ajouter du contenu au mauvais endroit.

Lire les journaux utiles

Une erreur de serveur ou une page blanche demande de consulter les journaux autour de l’heure notée. Dans Wamp, les entrées relatives à Apache et à PHP permettent habituellement d’ouvrir leurs journaux ; leurs intitulés et chemins dépendent de la version installée. Utilisez leur texte dans le menu et le journal réellement associé au service en cours, sans chercher une couleur d’icône ou recopier le chemin d’une autre machine.

Un journal d’erreurs PHP peut préciser un fichier manquant, une erreur de syntaxe ou une incompatibilité. Le journal Apache peut aider à comprendre un chemin introuvable ou une erreur au niveau du serveur. Une ligne ancienne n’explique pas automatiquement l’incident actuel : comparez l’heure et le chemin. Si aucun événement pertinent n’apparaît, vérifiez d’abord que vous consultez le bon service et le bon journal.

Dans phpBB, le PCA propose aussi les journaux d’administration et d’erreurs. Ils renseignent certaines opérations applicatives, mais ne remplacent pas les journaux du serveur. phpBB ne peut pas toujours écrire son propre journal s’il ne démarre plus ou ne se connecte plus à la base. Ne concluez donc pas « aucune erreur » parce que le journal du forum est vide.

Conserver les preuves avant une correction

Recopiez seulement les lignes utiles dans un document privé, avec leur date et l’action correspondante. Les logs et les fichiers de configuration peuvent contenir des informations personnelles ou techniques sensibles. Pour demander de l’aide, préparez un extrait où les secrets sont retirés ; n’envoyez jamais un config.php complet avec son mot de passe. Gardez localement la version originale des preuves, sans les publier dans le bac public.

Corrigez une seule cause identifiée, puis reproduisez le contrôle qui échouait. Si vous avez rectifié le nom d’une base dans le config.php du clone, testez sa connexion et ses témoins avant d’examiner autre chose. Si vous remplacez un fichier réellement manquant, utilisez le paquet exact choisi pour cette intervention, pas une autre version trouvée au hasard.

Savoir arrêter et revenir

Une alerte de mise à jour incomplète demande de revoir le déroulement de la migration et la correspondance des fichiers. La valeur « Version du forum » vient de la base ; ne la modifiez pas manuellement pour effacer une alerte. Relisez la procédure officielle correspondant à la version cible et vos preuves du chapitre précédent. Une migration interrompue ne se résout pas forcément en relançant les mêmes étapes à l’aveugle.

Décidez de poursuivre seulement si vous comprenez la correction, disposez toujours de S2 et pouvez refaire les contrôles. Si la cause reste inconnue, si la compatibilité n’est pas établie ou si vos critères essentiels échouent, gardez le clone fermé et conservez son état pour le diagnostic. Le retour S2 vérifié dans le second clone fournit une solution de comparaison ; il ne faut pas confondre sa validation locale avec une autorisation de remplacer un site réel en activité.

Exemple commenté

Après préparation du retour, Camille obtient une erreur SQL. Elle relève l’heure et relit le config.php du retour. Le nom d’utilisateur appartient encore au premier clone, alors que la base est phpbb_ecole_retour. Elle corrige uniquement l’utilisateur et le secret du retour, puis vérifie le nom du site, les témoins et les accès ordinaires. Elle ne donne aucun droit global au compte du premier clone.

Autre situation : le site affiche sa page d’accueil après une mise à jour, mais une fonction importante provoque une erreur PHP dont la cause reste indéterminée. Camille ne déclare pas l’intervention réussie. Elle conserve le clone fermé, relève l’erreur et utilise le clone revenu à S2 pour comparer le comportement antérieur. L’existence d’une page d’accueil rassurante ne remplace pas la recette.

Exercice de décision

Vous ne devez pas provoquer ces pannes. Analysez les trois cas dans votre carnet, en distinguant observation, premier contrôle, action éventuelle et résultat attendu.

1. Dans le clone de retour, un visiteur lit « Clone de retour local - controles en cours » après la fin de la leçon précédente. CamilleAdmin peut toujours accéder au PCA. Faut-il réimporter la base ? Indiquez le réglage à vérifier et la conduite attendue.

2. Le premier clone affiche une erreur de connexion SQL juste après une modification locale de config.php. Son compte de forum CamilleAdmin était utilisable auparavant. Listez les paramètres SQL à relire et expliquez pourquoi changer le mot de passe de CamilleAdmin ne constitue pas le premier remède.

3. Après une vraie montée de version, les fichiers indiquent la cible choisie, mais « Version du forum » reste au niveau de S2 et la migration n’a pas fourni de résultat final confirmé. Écrivez pourquoi le test est incomplet, quelles preuves conserver et quand arrêter pour envisager le retour.

4. Pour votre laboratoire réel, choisissez le dernier contrôle exécuté et rédigez une fiche courte : installation, heure, acteur, action, résultat, décision. S’il n’y a aucune panne, écrivez-le explicitement. Il n’est pas nécessaire d’inventer une erreur ni de modifier le forum pour remplir le document.

Un diagnostic commence par l’adresse, l’heure, le compte et le message exact. Distinguez problème web, connexion SQL, session, permissions et cohérence de version. Lisez les journaux pertinents, protégez les secrets, puis corrigez une cause à la fois. Une fermeture volontaire n’est pas une panne ; une page d’accueil visible n’est pas une validation complète.