Arrêter l’assistant et reconnaître le scénario
Vous ouvrez l’administration d’un WordPress qui publiait encore hier. Le navigateur vous envoie vers /wp-admin/install.php et propose une langue ou un nouveau titre de site. Quelques minutes plus tard, la même adresse indique que WordPress est déjà installé. L’assistant ne sait pas quel contenu vous vouliez retrouver. Il ne regarde que ce que l’instance en cours de démarrage peut identifier. Valider le formulaire reviendrait à autoriser une installation, alors que le problème peut se limiter à la base ou au chemin que cette instance regarde.
Fermez l’onglet qui propose de terminer l’installation. Conservez une capture cadrée sur le message et l’adresse, sans paramètres privés. Relevez l’heure et le fuseau. Ouvrez l’adresse normale du site puis celle de connexion, sans cliquer sur le formulaire d’installation. Dans les outils de développement, onglet Réseau, conservez les redirections et regardez quelle réponse a envoyé vers l’assistant. Une redirection de la page d’accueil n’a pas le même point de départ qu’un accès direct à install.php depuis un ancien favori.
Distinguez le site exploité de la copie dont on préparait la première installation. Pour un site avec des contenus, la priorité est de retrouver l’instance qui les contient. Pour un nouvel environnement jetable, un écran « Déjà installé » peut signifier que vous avez simplement rouvert l’assistant après une installation réussie ou qu’il pointe vers un ancien ensemble de tables. Vérifiez l’identité du site avant de choisir. Un écran de connexion qui montre une autre adresse ou un autre titre ne valide pas la création de votre nouveau site.
- Site connu envoyé vers l’assistant : ne validez pas le formulaire et n’effacez aucune table. Conservez l’heure, le chemin et le symptôme.
- Nouvel environnement affichant « Déjà installé » : vérifiez d’abord le dossier, la base et le préfixe ; un autre WordPress peut utiliser la cible.
- Message explicite sur une table inaccessible ou une erreur de connexion : conservez son libellé séparément. Il correspond à un autre point d’arrêt.
Comprendre ce que WordPress vérifie au démarrage
Le cœur WordPress peut reconnaître une installation à partir de son cache, puis de l’option siteurl de la table d’options utilisée par l’instance. Si la valeur manque, il examine aussi les tables attendues. Certaines combinaisons de tables présentes mais illisibles amènent un message de base à réparer, au lieu de l’assistant. Il ne suffit donc pas de dire « l’assistant s’affiche, la base est vide » ou « le message Déjà installé prouve que toutes les tables sont en bon état ». Les deux messages sont des décisions prises pendant une requête donnée.
Pour un site simple, le démarrage peut rediriger vers l’assistant quand il ne reconnaît pas d’installation. L’assistant revérifie ensuite ce point et peut répondre « Déjà installé ». Un résultat différent entre les deux requêtes aide à orienter l’enquête : configuration chargée sur des nœuds différents, lecture intermittente, cache persistant, redirection déjà enregistrée ou environnement de copie confondu. Il ne permet pas de choisir entre ces causes sans autre preuve. Un multisite suit une branche différente ; si vous voyez une erreur d’installation propre à un réseau, gardez le contexte du sous-site et faites vérifier le réseau plutôt que d’appliquer une correction de préfixe pour site simple.
Vérifiez aussi qui a envoyé la redirection. Une réponse qui affiche Location vers l’assistant peut venir d’une règle de serveur, d’un cache ou d’un mécanisme qui n’a jamais démarré WordPress. Une redirection WordPress et une redirection du proxy se ressemblent dans la barre d’adresse. Le premier code HTTP, les en-têtes disponibles, la trace d’origine et l’heure sont plus utiles que l’écran d’arrivée seul. Si la réponse à l’origine est normale mais que la redirection n’existe qu’en bordure, ne modifiez pas les tables.
Parcours 1 : retrouver le dossier et la base que le domaine utilise
Cette méthode convient après une migration, une copie ou l’ajout d’un deuxième site. Dans le panneau d’hébergement, ouvrez la fiche du domaine et repérez la racine documentaire réellement configurée. Comparez-la au dossier où se trouvent les fichiers de votre site. Un nom comme public_html ou une archive récente ne prouve pas qu’un domaine les utilise. Si la configuration de déploiement a changé, comparez avec la fiche de l’instance qui fonctionnait et la sauvegarde correspondante.
Dans le gestionnaire de fichiers ou en SFTP, consultez le wp-config.php effectivement utilisé par cette instance. Il se trouve généralement à la racine WordPress ; WordPress peut aussi le charger depuis le dossier parent dans certaines dispositions. Des configurations lisent des variables d’environnement ou un fichier inclus : la valeur écrite dans un modèle de configuration n’est pas toujours la valeur effective. Relevez pour vos propres vérifications le nom de la base, l’hôte et le préfixe $table_prefix. Ne transmettez pas le fichier ni la valeur de DB_PASSWORD. Sur plusieurs nœuds, comparez leurs références de configuration via le responsable de l’hébergement.
Le préfixe est ajouté devant les noms de tables. Avec wp_, la table d’options s’appelle normalement wp_options. Avec atelier_, WordPress regarde normalement atelier_options. Dans une base partagée, plusieurs ensembles peuvent être valides. Un ensemble qui contient une table d’options et une table de publications n’est pas pour autant celui du domaine. Vérifiez le siteurl, le contexte de la sauvegarde et, sur une copie, un contenu connu avant de modifier la cible.
- Comparez le domaine, le chemin de l’installation et les références de base avec la fiche d’hébergement. Sur la copie, gardez une version datée de la configuration privée et de la racine documentaire actuelle.
- Dans le panneau de base de données, sélectionnez la base relevée, puis utilisez les requêtes en lecture seule des deux sections suivantes. Vérifiez le compte et la connexion qui ont exécuté la lecture ; un compte d’administration peut voir des tables que le compte WordPress ne peut pas lire.
- Si une erreur de dossier, de base ou de préfixe est confirmée, corrigez la seule référence erronée sur une copie. Remettez la valeur attestée par la configuration antérieure ou l’inventaire du site. Ne renommez pas les tables d’un site pour les faire entrer dans une configuration incertaine.
- Rouvrez l’accueil et la connexion habituelle. Vous devez retrouver un contenu connu et l’administration de la bonne instance, sans assistant. Si le résultat ne correspond pas, restaurez la seule référence changée et gardez le relevé de la nouvelle réponse.
Repérer les tables visibles sans les modifier
Dans phpMyAdmin, sélectionnez la base dans la colonne de gauche puis l’onglet SQL. Dans un client MySQL ou MariaDB, sélectionnez explicitement cette base à la connexion. Lancez d’abord le premier SELECT seul : le nom retourné doit correspondre à la cible attendue. Si le résultat est vide ou indique une autre base, arrêtez-vous et resélectionnez la bonne. Ensuite, remplacez les trois noms d’exemple par les noms du site. Gardez les suffixes options, posts et users pour le site simple décrit ici. Si le projet utilise une table d’utilisateurs personnalisée, vérifiez son nom auprès du mainteneur au lieu d’interpréter son absence comme une preuve.
La seconde lecture donne un échantillon de tables visibles. Elle ne modifie ni les lignes ni la structure. L’absence d’une table peut correspondre à un mauvais préfixe, à un compte dont les droits sont différents, ou à une restauration incomplète. Si le compte du panneau voit l’ensemble et que WordPress ne le lit pas, demandez au responsable de tester les mêmes opérations avec l’identité de base du site dans un terminal privé. Évitez de copier un secret dans la ligne de commande. L’erreur obtenue avec le compte exact peut séparer un refus d’accès d’une table réellement absente.
SELECT DATABASE() AS base_active;
SELECT TABLE_NAME
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
AND TABLE_NAME IN ('wp_options', 'wp_posts', 'wp_users')
ORDER BY TABLE_NAME;Confirmer quelle installation possède ces options
Seulement après avoir confirmé la base et le nom de la table, lisez les deux options ci-dessous. Remplacez wp_options par le nom exact repéré et conservez les accents graves qui encadrent l’identifiant SQL. Cette requête ne récupère aucune ligne d’utilisateur ni de configuration complète. Traitez néanmoins les URL d’une préproduction comme des informations internes. Si siteurl est présent et non vide, ce relevé est compatible avec une installation reconnue par le cœur dans le contexte où vous avez lu la table. Il ne démontre pas que tous les nœuds WordPress accèdent à cette table, ni que les autres données sont intactes.
siteurl désigne l’adresse d’installation de WordPress et home celle du site ; elles peuvent légitimement différer quand WordPress vit dans un sous-dossier. Des constantes ou des filtres peuvent aussi modifier les valeurs utilisées à l’exécution. Comparez ce résultat au déploiement prévu et à une sauvegarde connue. Ne remplacez pas les deux URL par une valeur identique au hasard. Si la valeur ressemble à l’ancienne adresse du même site, vérifiez si vous êtes devant le bon contenu migré avant de conclure que la table appartient à un autre projet.
SELECT option_name, option_value
FROM `wp_options`
WHERE option_name IN ('siteurl', 'home')
ORDER BY option_name;Parcours 2 : récupérer une base attendue mais incomplète ou illisible
Si le domaine, le dossier, la base et le préfixe concordent, concentrez-vous sur les tables et leurs droits. Une connexion SQL réussie ne signifie pas que le compte peut lire la table des options. Si la table existe et que la lecture est refusée avec le compte WordPress, faites comparer ses droits actuels à ceux prévus pour cette seule base. En hébergement administré, donnez au support l’heure et le type d’erreur, sans lui transmettre vos secrets par un canal public. N’élargissez pas les droits à toutes les bases du serveur pour faire passer le test.
Si une table manque, si la lecture échoue pour une cause de stockage ou si siteurl manque alors que le site doit avoir des contenus, recherchez une sauvegarde cohérente. Vérifiez sa date et le jeu de tables attendu. Un export partiel peut contenir des publications sans les options ou les relations nécessaires. Ne créez pas une table vide pour faire disparaître l’erreur ; vous ne retrouveriez ni les bons réglages ni la cohérence des contenus. Une fonction de réparation des tables ne recrée pas une sauvegarde absente. Le message suggérant une réparation ne suffit pas à la choisir.
- Sur une copie isolée, importez la sauvegarde validée dans une nouvelle base réservée à l’essai. Ne versez pas l’export dans une base qui sert encore l’ancien site.
- Pointez la copie vers cette base en conservant une version privée de sa configuration initiale. Si l’adresse du site en copie doit différer, appliquez la procédure de migration prévue pour cette copie et notez les changements.
- Relisez les tables et les options, puis ouvrez des contenus connus et l’administration avec un compte prévu pour la copie. Vérifiez une date ou une version de contenu pour ne pas confondre une sauvegarde fonctionnelle avec une sauvegarde assez récente.
- Pour annuler le test, remettez la référence de base initiale de la copie. Gardez les deux bases distinctes et les relevés. Ne supprimez rien tant que la récupération n’est pas validée par la personne responsable des données.
Parcours 3 : isoler une redirection qui revient par intermittence
Ce parcours est utile si l’assistant apparaît puis disparaît sans modification de votre part. Prenez plusieurs observations sur l’accueil et la page de connexion. Notez l’heure, le code de la première réponse, la destination et le contexte navigateur. Si un identifiant de requête existe, gardez-le. Avec l’hébergeur, comparez aux journaux du proxy, du serveur et de la base sur la même plage. Une vérification SQL réalisée plus tard, quand tout fonctionne, ne permet pas d’exclure une panne à l’heure relevée.
Demandez au responsable d’établir si les requêtes en erreur arrivent sur le même nœud et si elles utilisent les mêmes références de base, de préfixe et de cache d’objets. Si une redirection n’arrive pas jusqu’à WordPress, examinez la couche qui la sert : le cache de page, une règle d’hébergement ou un ancien renvoi. Si la réponse vient de WordPress, comparez l’accès aux options, puis le cache d’objets ou les composants chargés tôt, notamment un fichier de connexion de base personnalisé. La vérification d’installation se fait avant le chargement des extensions ordinaires dans le démarrage standard ; désactiver toutes les extensions n’est pas un premier test qui localise cette branche.
- Sur une copie représentative, reproduisez la différence entre les deux chemins ou nœuds. Changez une seule référence ou règle confirmée à la fois.
- Si une règle de redirection ou une réponse enregistrée est en cause, corrigez cette règle puis retirez la réponse en cache pour les chemins concernés. Si les nœuds n’ont pas la même configuration, alignez la configuration attestée avant de répéter les demandes.
- Contrôlez plusieurs fois l’accueil, la connexion et un lien profond, dans la fenêtre privée et dans le parcours normal. Un seul chargement réussi ne suffit pas lorsque le symptôme était intermittent.
- Conservez la règle ou la version précédente pour retour arrière. Si elle reproduit l’assistant sur la copie, ne la rétablissez pas sur le site en service pour obtenir une preuve supplémentaire.
Terminer seulement une installation qui doit être neuve
Si l’environnement est réellement neuf, confirmez qu’il n’héberge rien à récupérer. Préférez lui attribuer une base dédiée vide et la configuration prévue pour cette base, sur le bon domaine de travail. Cette séparation rend le diagnostic plus facile que l’ajout d’un nouveau préfixe dans la base d’un site utilisé par une équipe. Si l’installation a déjà été menée à terme et que les contrôles montrent le bon site, reprenez à la page de connexion : rouvrir l’assistant n’est pas une étape nécessaire.
Le test est terminé quand les requêtes normales ne mènent plus à l’assistant et que vous retrouvez les contenus du bon site, ou, pour une installation réellement neuve, quand la connexion mène à la nouvelle administration attendue. Conservez la relation entre domaine, dossier, base et préfixe avec les heures de contrôle. Cette fiche permet de vérifier le même point après un déplacement ou un changement de serveur sans devoir exposer la configuration complète.
