PhpBB Lab Académie

Adapter config.php dans une copie privée, transférer les fichiers de la bonne sauvegarde et préserver la protection du dossier avant la première visite phpBB.

Relier le programme à la bonne base

La base dédiée contient maintenant S7-publication. Il manque les fichiers correspondants : programme phpBB, styles, extensions, avatars et pièces jointes. Copier seulement le logiciel neuf ferait perdre une partie du forum préparé. Nous transférons donc les fichiers de cette même paire, sans changer de version.

config.php décrit la connexion à la base. Dans S7, il désigne encore la copie locale de publication. Nous allons modifier seulement une copie de travail privée. Le point S7 et les installations de Wamp restent inchangés.

Notre fin de leçon sera « fichiers prêts, première visite interdite tant que la leçon 7 n’est pas terminée ». La présence d’index.php sur le serveur ne constitue pas une invitation à l’ouvrir. Plusieurs réglages de la base et des éléments du cache gardent encore les valeurs locales.

Préparer le ZIP des fichiers sur votre ordinateur

S7-publication conserve un dossier de fichiers et un export SQL séparé. Pour le transfert, créez un ZIP de la seule copie des fichiers du forum. Dans l’Explorateur Windows, sélectionnez ce dossier à l’intérieur de S7-publication. Ouvrez son menu contextuel avec Maj+F10, puis « Envoyer vers » et « Dossier compressé » ; selon Windows, passez d’abord par « Afficher d’autres options », ou utilisez l’action de compression ZIP équivalente. Le nouveau ZIP apparaît à côté du dossier, dans votre espace privé. Donnez-lui un nom contenant la date de S7-publication.

Ouvrez le ZIP en lecture et retrouvez config.php, .htaccess, les sous-dossiers et leurs fichiers de protection. Vérifiez qu’il contient bien les fichiers de cette paire, sans y ajouter le SQL voisin. Le ZIP regroupe des fichiers ; il ne remplace pas la base et n’est pas chiffré par cette opération. Gardez le dossier et le SQL d’origine intacts. Un ZIP déjà préparé convient seulement si ces contrôles sont faits.

Extraire hors de tout dossier public

Dans File Manager, repérez le dossier personnel de votre compte. Créez un emplacement de préparation qui n’est la racine d’aucun site et ne se trouve sous aucune racine web, par exemple /home/compte/preparation-jardins-S7. Ce chemin reste un exemple. Si votre offre n’autorise aucun emplacement privé, demandez sa méthode de préparation à l’hébergeur avant de poursuivre.

Transférez l’archive des fichiers de S7-publication dans cet emplacement privé avec « Upload » et « Select File ». Extrayez-la au même endroit avec « Extract ». Aucun export SQL n’est nécessaire dans cette archive de travail. Vérifiez où se trouve exactement config.php après extraction : entrez dans les dossiers d’emballage jusqu’à retrouver, au même niveau, index.php et les dossiers adm, files, images, ext, styles, store et cache.

Le dossier trouvé est la racine du forum extrait. Nous déplacerons son contenu dans la racine web réelle ; nous n’ajouterons pas un niveau forum-ecole-publication sous le sous-domaine. Sinon l’adresse finale ne correspondrait plus à celle prévue.

Le gestionnaire peut devoir afficher les fichiers cachés pour montrer .htaccess. Activez ce seul affichage dans ses paramètres. Certaines protections de phpBB se trouvent dans les sous-dossiers et doivent accompagner leurs fichiers. En revanche, le .htaccess racine sera traité séparément parce que nous l’avons déjà installé et protégé à la leçon 4.

Modifier une configuration existante

Ouvrez config.php de la préparation privée avec « Edit », l’éditeur de texte du gestionnaire. Vous pouvez également éditer une copie locale de travail en texte brut puis la renvoyer dans ce même dossier privé. Ne créez pas un fichier vide et ne remplacez pas tout son contenu par un exemple.

Repérez ces variables : dbhost pour l’adresse du serveur SQL, dbport pour son port, dbname pour la base, dbuser pour l’utilisateur SQL et dbpasswd pour son secret. Les noms réels de la leçon 4 doivent remplacer ceux du laboratoire. Le port SQL n’est pas le port web HTTPS 443.

Voici seulement la forme des lignes ; les textes en majuscules sont des repères à remplacer, pas des identifiants utilisables :

$dbhost = 'HOTE_SQL_FOURNI_PAR_HEBERGEUR';
$dbport = 'PORT_SQL_FOURNI_PAR_HEBERGEUR';
$dbname = 'NOM_COMPLET_DE_LA_BASE_DISTANTE';
$dbuser = 'NOM_COMPLET_UTILISATEUR_SQL';
$dbpasswd = 'VOTRE_SECRET_SQL_REEL';

Si l’hébergeur indique explicitement que dbport doit rester vide pour son accès par défaut, écrivez une chaîne vide, deux apostrophes consécutives, comme dans le fichier original. N’inventez pas un port. dbhost désigne le serveur de base de données, pas automatiquement le sous-domaine du forum.

Conservez le dollar, le nom de variable, le signe égal, les apostrophes et le point-virgule. Pour une valeur entre apostrophes, une apostrophe contenue dans le secret doit être précédée d’un antislash ; un antislash doit être doublé. Ce sont les règles d’écriture de PHP déjà expliquées au cours 4. Un secret aléatoire long constitué de lettres et de chiffres évite cette difficulté sans imposer un mot de passe commun. Ne modifiez jamais le secret uniquement dans le fichier s’il ne correspond plus au compte SQL.

Le pilote dbms indique comment phpBB dialogue avec la base. Dans notre parcours MySQL/MariaDB, conservez le pilote mysqli déjà utilisé, avec l’extension PHP correspondante disponible sur l’offre. Ne remplacez pas cette valeur par le nom du sous-domaine. Si votre copie utilise un autre moteur, arrêtez cette procédure : convertir les données entre moteurs serait une autre opération.

Gardez table_prefix strictement égal au début des noms de tables importées. Ce préfixe n’est ni le nom de la base ni le préfixe ajouté par cPanel à votre compte. Conservez les autres lignes, notamment l’indication PHPBB_INSTALLED et le gestionnaire de cache existant.

Enregistrez en texte UTF-8 sans BOM, sans ajouter de texte avant le début PHP. Rouvrez le fichier privé et relisez les valeurs réelles sans les copier dans le carnet. Vérifiez son nom exact config.php, pas config.php.txt. Aucun ancien identifiant local ni repère en majuscules ne doit rester dans les cinq valeurs adaptées.

Préserver la barrière pendant le déplacement

Retrouvez la racine web réellement notée. Elle doit contenir uniquement les éléments de préparation connus : le .htaccess déjà enrichi par Directory Privacy et le petit témoin statique. Recontrôlez la protection avec l’adresse HTTPS du témoin depuis un navigateur sans identifiants mémorisés. Une demande d’authentification est attendue ; n’ouvrez toujours pas index.php.

Dans la racine privée du forum extrait, sélectionnez les fichiers et dossiers à transférer, mais excluez le seul .htaccess de ce niveau. Vérifiez la sélection avant d’utiliser « Move » vers la racine web. Les .htaccess présents à l’intérieur de files, cache ou d’autres sous-dossiers doivent rester dans leurs dossiers. Ne les excluez pas globalement par leur nom.

Validez le chemin de destination exact. Si l’outil demande de remplacer le .htaccess racine, annulez : il n’aurait pas dû être sélectionné. Si des fichiers phpBB existent déjà à destination, arrêtez également pour identifier l’ancien essai. Nous n’effectuons pas une mise à jour par fusion d’une application inconnue.

Après le déplacement, index.php et config.php doivent se trouver directement à la racine du sous-domaine. L’archive, l’export SQL, les sauvegardes et une éventuelle copie config.php.bak restent hors de toute racine web. Ne confondez pas ces copies privées avec les ZIP éventuellement conservés par le forum comme véritables pièces jointes.

Contrôler sans encore exécuter phpBB

Vérifiez la présence de files, images, ext et styles, avec Atelier Jardins et l’extension d’annonce inventoriés. Un dossier install d’installation active ne doit pas accompagner ce forum déjà installé : s’il apparaît, retirez seulement cette copie du paquet de travail et vérifiez pourquoi elle y figurait. Ne lancez pas l’installateur.

Le cache copié reste temporairement en place. À la leçon 7, nous adapterons d’abord les réglages de la base, puis retirerons précisément le cache généré avant toute première visite. Ne videz pas tout au hasard : les fichiers de protection et une éventuelle ancienne file d’envoi seront traités distinctement. Les courriels, SMTP et Jabber restent désactivés ; le forum reste fermé.

Refaites le test HTTPS du témoin statique sans identifiants, puis avec le compte de préparation. La barrière doit toujours fonctionner après le transfert. Si elle a disparu, interrompez les essais et faites la rétablir avant toute page phpBB. Consignez l’import validé, la configuration SQL adaptée, les dossiers présents et la protection observée. Le chapitre suivant prépare enfin la première connexion à l’adresse publique.

Après extraction, config.php se trouve dans preparation-jardins-S7/fichiers/forum-ecole-publication. C’est le contenu de ce dernier dossier qui doit arriver dans la racine du sous-domaine, en excluant son seul .htaccess racine. Déplacer le dossier entier créerait un chemin supplémentaire, tandis qu’inclure son .htaccess écraserait potentiellement la protection déjà ajoutée.

Expliquez trois erreurs possibles : placer le nom de la base dans table_prefix ; entrer 443 dans dbport parce que le site utilise HTTPS ; accepter le remplacement du .htaccess protégé. Donnez pour chacune le contrôle à refaire. Puis notez pourquoi le premier affichage phpBB attend la leçon suivante même si index.php est bien présent.

Travaillez sur une copie privée de la bonne paire S7. Adaptez la connexion SQL et gardez le préfixe des tables. Placez le contenu au bon niveau en conservant le .htaccess racine protégé. Les tests statiques peuvent confirmer la barrière ; la première page phpBB attend la leçon 7.