PhpBB Lab Académie

Organiser un suivi réaliste du forum ouvert et savoir préparer une intervention sans perdre les messages reçus depuis la mise en ligne.

Après l'ouverture, la référence change

Avant l'ouverture, vous aviez surtout des contenus pédagogiques figés. Après l'ouverture, un visiteur peut s'inscrire, un membre publier et un modérateur approuver un message. La copie publique devient donc un état vivant. Vos laboratoires locaux restent utiles pour apprendre ; ils ne contiennent pas automatiquement les nouveaux événements du site hébergé.

Un retour arrière consiste à revenir à un état antérieur pour résoudre une difficulté. Il n'est pas forcément une restauration de toute la base : corriger un réglage précis, remettre une version de fichier compatible ou restaurer une sauvegarde complète sont des interventions différentes. Avant de choisir, il faut comprendre ce qui a changé et ce qu'une opération pourrait remplacer.

Construire un suivi court et concret

1. Ajoutez dans le carnet une partie « Premiers jours ». Notez la date d'ouverture réelle, ou « non ouvert » si la leçon précédente s'est arrêtée. Pour un forum ouvert, choisissez une première vérification le lendemain et une seconde quelques jours après, puis un rythme adapté à l'activité. Une alerte ou un signalement sérieux se traite dès sa découverte, sans attendre la prochaine date.

2. Depuis un contexte visiteur, ouvrez l'adresse HTTPS, puis un sujet public connu. Vérifiez l'adresse finale, l'absence de message de certificat et le fonctionnement des liens utiles. Connectez ensuite recette_public et assurez-vous qu'il retrouve son contexte de membre. Ce passage ne nécessite pas de créer un nouveau sujet chaque jour. Vérifiez aussi l'accès à l'administration séparément avec CamilleAdmin.

3. Dans « Maintenance », consultez le « Journal d’administration » et le « Journal des erreurs ». Le premier aide à retrouver les changements administratifs enregistrés ; le second certains événements système de phpBB. Comparez les dates à votre carnet. Un journal vide n'est pas la preuve que tous les services fonctionnent. L'IP ou le nom du compte affiché ne désigne pas avec certitude une personne : gardez la prudence apprise au cours 6.

4. Regardez les messages en attente et les signalements par le panneau de modération. Une demande d'approbation prévue pour un nouveau membre n'est pas une panne. En revanche, plusieurs membres légitimes rencontrant le même refus inattendu justifient un examen du parcours et des permissions. Ne retirez pas toutes les restrictions avant d'avoir identifié celle qui pose problème.

Surveiller les services que vous avez ouverts

Les courriels publics restent activés puisqu'ils servent à l'inscription et à la récupération de compte. Les laboratoires locaux restent désactivés. Si un utilisateur signale qu'un message n'arrive pas, distinguez l'action effectuée dans phpBB, les traces disponibles chez l'hébergeur et la réception réelle. Le chapitre 4 vous donne déjà la méthode d'essai avec une adresse contrôlée.

Ne téléchargez pas une ancienne file d'attente locale dans le site public et ne forcez pas son envoi pour « débloquer les messages ». Des messages en attente peuvent contenir des destinataires, des liens privés ou des demandes périmées. Ne les publiez pas dans votre carnet ou sur le forum de support. Notez le symptôme sans secret et reprenez la procédure de diagnostic adaptée avec l'hébergeur si nécessaire.

5. Dans le panneau de l'hébergement, vérifiez l'état du certificat du sous-domaine. Dans cPanel, la fonction « SSL/TLS Status » donne les informations de certificat ; selon la version, elle peut apparaître dans l'interface des certificats SSL/TLS. Relevez sa date d'expiration et la méthode de renouvellement prévue par l'hébergeur. Un certificat valide aujourd'hui ne garantit pas que le renouvellement aboutira : demandez où consulter les alertes et qui intervient en cas d'échec.

6. Fixez un rythme de sauvegarde selon les contributions que vous accepteriez de devoir reconstituer. Conservez plusieurs points privés datés. Préparez une restauration d'essai séparée, sans écraser vos laboratoires. Pour une destination hébergée, établissez et vérifiez la protection du dossier avant transfert selon le chapitre 2 ; préservez son .htaccess protégé comme expliqué à la leçon 14. Adaptez les connexions et l'adresse, puis désactivez les envois avant toute première visite de la copie. Pour des sauvegardes automatiques, vérifiez contenu, fréquence, durée de conservation et procédure de récupération. « Sauvegarde activée » ne suffit pas.

Ce cours ne demande pas de créer une tâche planifiée avec une commande trouvée au hasard. Une tâche planifiée exécute une action à une heure ou une fréquence définie. Si vous en utilisez une proposée par l'hébergeur, faites confirmer son rôle et évitez les doublons ; ne changez pas simultanément la planification de phpBB et les réglages de courriel pour essayer de comprendre un retard.

Intervenir sans effacer la journée des membres

7. Lorsqu'un problème apparaît, commencez par noter l'heure, la page concernée, le symptôme et le dernier changement connu. Un lien local oublié dans une description n'appelle pas la même intervention qu'une suspicion d'accès administrateur détourné. Pour une suspicion sérieuse, appliquez la méthode du cours 6 : préserver les traces, protéger les accès et faire traiter la cause avant une reprise.

8. Avant toute opération susceptible de remplacer des fichiers ou des données, protégez l'état actuel. Si l'intervention exige une fermeture, refermez phpBB et, selon la situation, rétablissez la restriction du dossier avec l'hébergeur. Faites cesser les interventions administratives et demandez un instantané coordonné si nécessaire. Sauvegardez la base et les fichiers actuels dans un nouveau dossier privé daté, sans écraser S7-ouverture. Conservez aussi les traces utiles de l'incident.

9. Comparez la portée du correctif. Un lien erroné dans un champ identifié peut être corrigé dans ce champ, puis retesté. Une erreur de version ou de migration peut nécessiter des fichiers et une base compatibles : ne mélangez pas arbitrairement les époques. Si vous ne pouvez pas déterminer une reprise qui conserve les contributions récentes, demandez de l'aide avant d'importer une ancienne base. Réinsérer des messages à la main dans les tables n'est pas une procédure de récupération enseignée ici.

10. Après la correction, rejouez les contrôles touchés et la recette essentielle de la leçon 13 avant réouverture. Notez le résultat et la sauvegarde conservée. Ne changez pas le DNS du sous-domaine pour renvoyer vers un laboratoire : localhost désignerait l'appareil du visiteur et une copie ancienne ignorerait les nouvelles contributions.

Terminer le projet avec un état explicite

Votre bilan final distingue « publié et vérifié » de « préparé, ouverture non effectuée ». En réussite, la copie hébergée reste ouverte sous HTTPS, les courriels fonctionnent, l'activation et le Q&A publics restent en place, les comptes anciens restent inactifs et les permissions privées sont conservées. Les données pédagogiques restent clairement présentées comme démonstration.

Les laboratoires forum-ecole, forum-ecole-retour et forum-ecole-restauration sont conservés ; la copie locale forum-ecole-publication reste également fermée et sans envois. Ils ne sont pas resynchronisés en écrasant la base publique. Vous avez maintenant une méthode pour publier, observer et corriger un forum sans confondre votre espace d'apprentissage et le service utilisé par les visiteurs.

Cas fictif : S7-ouverture date de lundi. Mardi, deux membres ont écrit douze messages. Mercredi, un lien de la description renvoie vers localhost. Restaurer la base de lundi ferait disparaître ces messages, alors que le défaut est limité à un champ.

La réponse adaptée consiste à relever le lien concerné, conserver l'état actuel selon la portée de l'intervention, corriger ce champ identifié puis le retester depuis le public. Si l'origine du problème est inconnue ou plus large, on protège l'état récent et on demande un diagnostic avant toute restauration complète. S7-ouverture reste une référence historique, pas une copie contenant les événements de mardi.

Écrivez une fiche de suivi avec une prochaine date, trois parcours à vérifier, l'emplacement privé des sauvegardes et le moyen de joindre l'hébergeur. Ajoutez une réponse au cas des douze messages : que préserver, que corriger et que ne pas remplacer ? Enfin, rédigez votre état final réel en précisant les contrôles encore non effectués. N'exécutez aucune restauration pour cet exercice écrit.

Après ouverture, les nouveaux messages font partie de la référence à protéger. Surveillez les parcours, les journaux, les courriels, le certificat et les sauvegardes. Choisissez une correction proportionnée ; préservez l'état récent avant une restauration et vérifiez la reprise avant de rouvrir.