web-dev-qa-db-fra.com

Wordpress continue de rediriger vers install-php après la migration

Voici ma situation. J'ai suivi les instructions exactes sur wordpress codex page sur le déplacement d'un site vers un autre serveur. Voici l'étape que j'ai franchie.

  1. Exporter une copie de ma base de données
  2. Créer une nouvelle base de données sur le nouveau serveur
  3. Importer la base de données que j'ai exportée précédemment
  4. Téléchargez une copie de mes Wordpress via FTP
  5. Utilisez ceci script pour changer toutes mes URL locales en nouvelles
  6. Apporter des modifications à mon fichier wp-config.php en fonction du nouveau serveur (je n’ai pas oublié le préfixe de la table. Bien qu’il comporte des caractères majuscules)

Et puis, lorsque j'essaie d'ouvrir mon site sur le nouvel emplacement, il me dirige simplement vers wp-admin/install.php. Maintenant, pour que le scénario soit plus clair: le dossier de destination (sur le serveur live) est un sous directori dans un dossier public_html qui a déjà un autre wordpress installer à l’intérieur de celui-ci (je dis cela au cas où cela aurait de l’importance))

Mon .htaccess ressemble à ceci

    # BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /subDirectoryName/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /subDirectoryName/index.php [L]
</IfModule>

# END WordPress

J'ai essayé de vérifier et de réparer mes tables via phpMyadmin mais tout semble aller pour le mieux et n'a aucun effet sur le problème.

J'ai également essayé de vider la base de données sur le serveur live et de procéder à l'installation. Et cela s’installe sans problème et tout fonctionne bien, mais bon, je n’ai aucune utilisation pour une autre installation propre. Mais je pense que cela exclut au moins tout problème avec le fichier wp-config. J'utilise Wordpress Version 3.3.1

Donc, je suppose que la grande question qui me reste est la suivante: Pourquoi wordpress ne reconnaît-il pas mon installation après la migration?

Toute aide très appréciée!

55
Hiilo

Enfin, j'ai résolu le problème. Et surprise, surprise C’était la foutue lettre UPPERCASE dans mon préfixe de table. Je l'ai eu de cette façon dans mon fichier wp-config wp_C5n mais pour une raison quelconque, la plupart des tables ont reçu le préfixe wp_c5n. Mais pas tout. Donc, quel est mon identifiant, c’est que j’ai changé mon préfixe de table dans le fichier wp_config en minuscules, puis j’ai parcouru toutes les tables à la main via phpMyadmin pour voir s’il restait des tables de majuscules. Là où environ 3. Ils étaient à l'intérieur de la table d'usermeta et à l'intérieur de la table d'options. Maintenant finalement tout fonctionne. A fait une recherche rapide dans wordpress codex mais ne trouve rien qui mentionne de ne pas utiliser de caractères majuscules.

100
Hiilo

Résolu: wp-config.php setting

J'avais un problème similaire. J'ai reçu le fichier install.php après avoir déplacé des fichiers et créé une nouvelle base de données. Il semble que l'écran d'installation indique qu'il y a un problème pour trouver les tables de base de données correctes.

J'ai résolu le problème en modifiant les paramètres suivants pour qu'ils soient corrects:

// ** MySQL settings - You can get this info from your web Host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'HikeforLife_dev11');

/** MySQL database username */
define('DB_USER', 'HikeforLife_dev11');

$table_prefix  = 'wphk_';
13
WebPro

Je vérifierais deux choses:

  • Tout d'abord, je vérifierais l'URL configurée dans la base de données. Vérifiez la table wp_options et les valeurs des options "siteurl" et "home", il est possible que vous deviez les mettre à jour si votre domaine a changé.

  • Une autre option est que votre serveur Apache ne puisse pas obtenir le .htaccess. Vérifiez si l'option "AllowOverride" est "all" dans le fichier httpd.conf.

J'espère que ça aide.

10
Beltran

J'ai connu un problème similaire. Aucune des suggestions ci-dessus ne m'a aidé, cependant.

Finalement, j'ai réalisé que Wordpress l'utilisateur MySQL de mon environnement de production n'avait pas reçu de privilèges suffisants.

7
funkylaundry

N'oubliez pas également les préfixes de la table si votre installation n'utilise pas le préfixe par défaut.

2
Martin Tonev

Cela m'est arrivé après avoir copié un site Web déjà migré vers WP Moteur et j'ai oublié de faire une chose requise par WP Moteur:

Mettez à jour le WordPress installation principale du site en cours de copie dans la dernière version.

Alors voici le problème alors:

Mon ancien site que je copiais d'un autre serveur vers WP Le moteur possédait la version 4.0. Toutefois, lorsque vous copiez un site existant vers WP Moteur, vous ne t copier les WordPress, vous ne faites que copier le contenu de wp-content et l'état (ou l'instantané) de la base de données existante. Ainsi, l'état de la base de données de mon site existant correspondait à une installation exécutée WP 4.0. Néanmoins, lorsque vous créez un nouveau WordPress installez le WP Engine, cette installation est créée avec la dernière version de WordPress, qui à l’époque était la version 4.0.1, cela signifie que les fichiers de base sur la destination (WP Engine) ont été pour une installation 4.0.1 mais l’instantané de la base de données que j’allais importer dans WP Le moteur était pour la version 4.. Donc, lorsque j’ai écrasé la valeur par défaut WP Base de données du moteur avec l'importation de la copie de la base de données de mon ancien site, j'ai eu l'erreur de redirection vers le script d'installation.

Donc, pour résoudre ce problème, je viens de me connecter au WordPress site admin du site sur WP Engine, assurez-vous de réinitialiser les autorisations du fichier (en cliquant sur le bouton bleu). bouton), ce que vous devez parfois faire sur WP Moteur, puis réinstallez le WordPress noyau, qui met fondamentalement à jour votre base de données afin qu'elle soit en interne l'état de la base de données correspondait à une installation WordPress 4.0.1) et les fichiers de base correspondent également à la version.

Il m'a fallu un certain temps pour comprendre ce qui se passait.

2
racl101

Alors que j'essayais d'installer le programme d'installation du serveur sur localhost, j'ai configuré le fichier de configuration ainsi que la base de données dans l'hôte local. J'ai été redirigé vers le fichier install.php.

wp

Vérifiez: 1 Accédez à yourTableName_options Déplacez-vous sur 'option_id' - '1' Modifiez 'url yousite' sur 'localhost/youLocalSiteFolderName'

Déplacer vers 'option_id' - '37' Changer la valeur de homw en 'localhost/youLocalSiteFolderName'

Vérification: 2 Déplacer vers le fichier 'wp_config' vérification: $ table_prefix = 'yourNew_Prefix _';

J'espère que ça va aider

2
Ran

J'ai eu le même problème et je l'ai corrigé en modifiant les privilèges de l'utilisateur de la base de données en lecture et écriture complètes.

1
Spacer

J'ai essayé toutes ces solutions avant de réaliser que j'avais activé opcache dans PHP sur mon environnement réel. Wordpress ne lisait pas de version en cache de wp-config.). .

1
Andy

J'ai rencontré ce problème aujourd'hui et j'ai commencé à chercher sur Internet. Dans mon cas, il n'y avait pas de table dans ma base de données. J'ai oublié d'importer les tables sur le serveur en ligne. Je l'ai fait et tout fonctionne bien.

1
Alexandre le Grand

J'ai rencontré le même problème que l'OP - Wordpress continue à rediriger vers install-php après la migration.

Le problème était que mes tables de base de données sont nommées comme prefix_tablename et j'ai raté le trait de soulignement de $table_prefix dans wp-config.

$table_prefix = 'myprefix';

aurait du être

$table_prefix = 'myprefix_';

1
chris.dempsey

J'ai eu ce problème quand j'ai utilisé la balise br dans la page produit de woocommerce. J'essayais de modifier le modèle qui soudainement tout .... c'était un cauchemar. Mon client pourrait me tuer. essayez de ne pas utiliser cette balise br n'importe où.

0
Mohsen35

Ce problème peut avoir de nombreuses causes.

Ma suggestion est d'activer WP_DEBUG dans wp-config.php

define('WP_DEBUG', true);
0
Paul Verschoor