PhpBB Lab Académie

Rechercher dans ce cours

Mettre en ligne son forum phpBB : du laboratoire à l’ouverture au public

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

Adapter les paramètres avant la première visite du forum hébergé

Objectif de la leçon

Modifier uniquement la configuration de la base hébergée, renouveler les fichiers de cache générés, puis vérifier la première connexion administrative sous la protection de l’hébergement.

Explications

Les fichiers sont transférés, mais le forum connaît encore son adresse locale

Votre copie possède maintenant ses fichiers et sa base sur l’hébergement. config.php contient les coordonnées de cette nouvelle base ; cela ne remplace pas les paramètres du forum stockés dans les tables. Certains désignent encore localhost et le dossier forum-ecole-publication. Nous devons les adapter avant la première requête adressée à phpBB.

Le nom de domaine public de l’exercice, forum.votre-domaine.tld, reste un exemple à remplacer. Utilisez partout le seul sous-domaine réellement créé à la leçon 4. Dans notre scénario, le forum occupe sa racine : https://forum.votre-domaine.tld/. Le chemin du script est donc vide et le chemin des cookies vaut /. Si votre destination ajoute un sous-dossier, cette procédure doit être adaptée avant exécution ; ne gardez pas les valeurs racine pour un autre emplacement.

La protection du dossier filtre l’accès avant phpBB. Fermer phpBB bloque ses usages ordinaires mais permet aux comptes privilégiés d’intervenir. La protection du dossier reste active jusqu’à la leçon 14.

Relire avant de modifier

1. Vérifiez dans votre carnet le domaine, la racine documentaire, la base hébergée et le préfixe exact des tables. La leçon 6 s’est arrêtée avant la première visite phpBB. Le certificat HTTPS doit déjà être valide. Ne lancez pas l’installateur pour tester le transfert.

2. Gardez votre sauvegarde S7-publication privée disponible. Dans phpMyAdmin de l’hébergement, sélectionnez la base de destination et sa table de configuration. Si le préfixe de config.php est phpbb_, elle s’appelle phpbb_config ; sinon, adaptez ce nom. Aucune requête de cette leçon ne concerne les copies Windows.

3. Dans l’onglet « SQL », adaptez le nom de table ci-dessous si nécessaire, puis exécutez cette lecture. SELECT lit les lignes demandées ; il ne les modifie pas.

SELECT DATABASE();
SELECT config_name, config_value
FROM phpbb_config
WHERE config_name IN (
 'board_disable', 'email_enable', 'smtp_delivery', 'jab_enable',
 'cookie_name', 'cookie_domain', 'cookie_path', 'cookie_secure',
 'server_name', 'server_protocol', 'server_port', 'script_path',
 'force_server_vars'
)
ORDER BY config_name;



Le premier résultat doit être le nom exact de la base hébergée ; DATABASE() indique la base sélectionnée. Le second présente treize paramètres, certains encore locaux. Si la base est incorrecte, si des lignes manquent ou si l’import ne correspond pas à votre copie, arrêtez avant toute écriture.

Comprendre les valeurs de destination

board_disable reste à 1 : forum fermé. email_enable, smtp_delivery et jab_enable restent à 0 : les canaux d’envoi natifs demeurent désactivés. Les comptes d’exercice désactivés au chapitre 1 ne sont pas réactivés par cette opération. Le chapitre suivant préparera les courriels sur cette seule destination.

Le nouveau nom des cookies, phpbbjardinspub, distingue cette copie. Leur domaine devient le nom d’hôte réel, sans https:// ni barre oblique. Leur chemin / correspond à notre forum placé à la racine. cookie_secure vaut 1 parce que HTTPS est déjà disponible ; cette valeur ne crée pas de certificat.

server_name reçoit le même nom d’hôte, server_protocol reçoit https:// et server_port reçoit 443, le port HTTPS usuel de ce scénario. script_path devient une chaîne vide. force_server_vars reste à 0 : phpBB conserve sa détection normale. Nous ne forçons pas des paramètres pour masquer un défaut d’hébergement.

4. Préparez maintenant la requête suivante. UPDATE modifie des lignes. CASE associe une valeur à chaque nom de paramètre ; WHERE limite l’opération aux treize lignes indiquées. Remplacez les deux occurrences de forum.votre-domaine.tld par votre nom d’hôte réel et phpbb_config par la table exacte. Les guillemets simples encadrent des valeurs SQL ; ne les retirez pas. Il n’y a aucun mot de passe à placer dans ce bloc.

UPDATE phpbb_config
SET config_value = CASE config_name
 WHEN 'board_disable' THEN '1'
 WHEN 'email_enable' THEN '0'
 WHEN 'smtp_delivery' THEN '0'
 WHEN 'jab_enable' THEN '0'
 WHEN 'cookie_name' THEN 'phpbbjardinspub'
 WHEN 'cookie_domain' THEN 'forum.votre-domaine.tld'
 WHEN 'cookie_path' THEN '/'
 WHEN 'cookie_secure' THEN '1'
 WHEN 'server_name' THEN 'forum.votre-domaine.tld'
 WHEN 'server_protocol' THEN 'https://'
 WHEN 'server_port' THEN '443'
 WHEN 'script_path' THEN ''
 WHEN 'force_server_vars' THEN '0'
 ELSE config_value
END
WHERE config_name IN (
 'board_disable', 'email_enable', 'smtp_delivery', 'jab_enable',
 'cookie_name', 'cookie_domain', 'cookie_path', 'cookie_secure',
 'server_name', 'server_protocol', 'server_port', 'script_path',
 'force_server_vars'
);



5. Vérifiez le nom de base affiché, relisez votre bloc adapté puis exécutez-le une fois. Relancez ensuite le SELECT précédent. La preuve attendue est la relecture des treize bonnes valeurs. Un message « zéro ligne modifiée » peut simplement signifier que ces valeurs étaient déjà présentes ; le nombre de modifications ne remplace pas leur contrôle.

Ne pas importer les anciennes connexions

6. Une session représente une connexion ; les clés persistantes servent aux connexions mémorisées. Leurs tables copiées peuvent conserver des autorisations issues du laboratoire. Changer le nom des cookies ne les efface pas. Nous invalidons aussi les liens de récupération de mot de passe hérités, grâce aux champs reset_token et reset_token_expiration de phpBB 3.3.17.

Confirmez encore la base hébergée et l’existence des trois tables ci-dessous avec leur préfixe réel. Adaptez les noms puis exécutez ce bloc uniquement sur cette destination fraîchement importée, avant toute visite :

DELETE FROM phpbb_sessions;
DELETE FROM phpbb_sessions_keys;
UPDATE phpbb_users SET reset_token = '', reset_token_expiration = 0;



L’absence de WHERE est volontaire pour tous les comptes de cette copie neuve. DELETE retire les lignes de connexion, pas les tables ; l’UPDATE vide les liens de récupération. Aucun mot de passe, statut de compte ou message n’est changé ; les copies locales restent intactes.

7. Vérifiez ensuite avec ces lectures adaptées. COUNT(*) compte les lignes ; chaque résultat doit être zéro, avant la première visite qui créera une nouvelle session :

SELECT COUNT(*) FROM phpbb_sessions;
SELECT COUNT(*) FROM phpbb_sessions_keys;
SELECT COUNT(*) FROM phpbb_users
WHERE reset_token <> '' OR reset_token_expiration <> 0;



Retirer les anciens calculs, pas les données du forum

Le cache conserve des résultats calculés pour accélérer phpBB. Un ancien cache transféré peut encore contenir la configuration locale malgré votre modification SQL. Nous allons retirer seulement les fichiers générés concernés, avant la première visite. Ne supprimez jamais le dossier files contenant les pièces jointes.

8. Dans le gestionnaire de fichiers de l’hébergement, contrôlez la racine du forum de destination puis ouvrez cache/production. Dans cette installation native, ce dossier contient le cache utilisé. S’il n’existe pas parce que les fichiers générés ont déjà été exclus du transfert, notez ce cas et ne créez pas de faux fichiers. Si une configuration personnalisée désigne un autre cache, faites vérifier son emplacement avant de poursuivre.

9. Retirez les fichiers dont le nom commence par data_, sql_, container_, autoload_, url_matcher ou url_generator, ainsi que le sous-dossier généré twig s’il existe. Vérifiez les noms sélectionnés avant la suppression ; les fichiers annexes de ces mêmes familles peuvent porter .lock ou .meta. Laissez en place les fichiers de protection index.htm et .htaccess. Préservez queue.php et queue.php.lock, s’ils existent : la file d’attente sera traitée séparément avant l’activation des courriels en leçon 10. Ne supprimez pas tout cache sans distinction.

10. Sur l’adresse HTTPS réelle, franchissez la protection du dossier avec ses identifiants propres, puis utilisez « Connexion » pour CamilleAdmin. Employez le nouveau secret de la copie de publication préparé au chapitre 1, pas celui du laboratoire conservé. Un écran de fermeture pour les visiteurs est attendu. Une demande d’installation ne l’est pas : dans ce cas, arrêtez et vérifiez config.php et l’import, sans lancer une installation neuve.

11. Ouvrez le panneau d’administration, en vous réauthentifiant si phpBB le demande. Vérifiez le nom « Jardins Partagés — démonstration pédagogique », les versions phpBB et PHP attendues et les données importées. Le forum reste fermé et les envois désactivés. En cas d’échec, conservez le message sans multiplier les mots de passe ni élargir les droits des fichiers.

Exemple commenté

Le carnet indique les treize paramètres relus, les anciennes connexions et récupérations invalidées, le cache renouvelé, puis la connexion CamilleAdmin réussie en HTTPS sous protection. Aucun secret n’y figure. L’administration accessible prouve un premier démarrage ; elle ne valide pas encore les inscriptions ou les courriels.

Exercice à réaliser

Étude de cas : après import, server_name vaut encore localhost, mais la base contient les bons messages. Expliquez pourquoi changer les identifiants SQL dans config.php n’a pas corrigé cette adresse. Indiquez les deux vérifications nécessaires après l’UPDATE. Si phpBB présente ensuite un écran d’installation, quelle action faut-il éviter ?

Correction et résultat attendu

config.php choisit la base ; les paramètres d’adresse sont des données de cette base. Il faut relire les treize paramètres dans la destination puis retirer le cache généré qui pourrait conserver leur ancien état. Une page d’installation n’autorise pas à recréer le forum : elle impose de vérifier la présence et les valeurs de config.php, la base et l’import. Les messages importés doivent être conservés. Une erreur inexpliquée laisse la première connexion non vérifiée et les deux protections en place.

À retenir

Avant toute visite phpBB, adaptez les paramètres de la seule base hébergée et contrôlez leur relecture. Renouvelez le cache généré sans effacer les données ni la file d’attente. Connectez ensuite CamilleAdmin en HTTPS sous la protection de l’hébergement. Un premier accès réussi n’est pas une ouverture au public.

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

Sommaire du cours

Préparer une copie destinée à la publication

  1. Définir la destination et préparer son carnet de mise en ligne
  2. Construire une copie locale réservée à la publication
  3. Préparer les contenus et les comptes qui seront transférés

Transférer le forum sur l’hébergement

  1. Préparer une destination indépendante et protégée
  2. Restaurer la base préparée dans une destination vide
  3. Préparer et transférer les fichiers sans exposer le chantier

Adapter le forum à son adresse publique

  1. Adapter les paramètres avant la première visite du forum hébergé
  2. Vérifier HTTPS, les redirections et les cookies de la destination
  3. Retrouver les ressources et corriger les anciens liens locaux

Vérifier les courriels et les parcours des membres

  1. Configurer l’envoi des courriels et vérifier une réception réelle
  2. Vérifier une inscription et son activation par courriel
  3. Réinitialiser le mot de passe du compte de recette et vérifier sa session

Ouvrir le forum et suivre les premiers jours

  1. Faire la recette complète depuis un appareil extérieur
  2. Préparer la sauvegarde d'ouverture et accueillir le public
  3. Suivre les premiers jours et préparer un retour maîtrisé