Ce qui ne va pas lorsque vous déplacez un site WordPress du local vers le direct

Le site est parfait sur votre ordinateur portable. Chaque page se charge, chaque image est nette et le processus de paiement fonctionne. Ensuite, vous le poussez sur le serveur en ligne, l'ouvrez dans un navigateur, et quelque chose ne va pas.

Les environnements local et en ligne sont plus différents qu'ils n'y paraissent. Cet écart est la source de la plupart des problèmes.

Duplicator est un plugin de sauvegarde et de migration WordPress utilisé sur plus de 1,5 million de sites. Une part significative des sites utilisant Duplicator Pro sont des environnements locaux ou de développement, près de 1 sur 10. Cela représente beaucoup de personnes construisant sur un ordinateur portable et déployant sur un serveur en production.

Nous avons examiné les tickets de support des personnes qui déploient des sites de serveurs locaux vers des serveurs en production. Les échecs sont constants, et l'un d'eux apparaît beaucoup plus ici que partout ailleurs dans nos données.

Ces chiffres reflètent le volume des tickets de support et les données d'installation anonymisées, pas le nombre de clients ou de ventes.

Table des matières

Principales conclusions

Voici ce que disent les tickets sur le déplacement d'un site WordPress d'un environnement de développement local vers un serveur en production. Chaque chiffre provient des propres enregistrements de Duplicator.

• Près de 1 site sur 10 utilisant Duplicator Pro sont des environnements locaux ou de développement. Construire localement d'abord est une pratique courante, pas un cas extrême.
• Les problèmes de local vers production représentent environ 1 ticket sur 8 de tous les tickets de support de migration. Pour un scénario unique, c'est une part importante.
• Le SSL est la défaillance signature de ce transfert. Il apparaît dans environ 1 ticket sur 5 des tickets local vers production, environ quinze fois plus souvent que dans les tickets de migration en général.
• Les incompatibilités de version PHP sont environ trois fois plus fréquentes ici que dans les autres migrations car les outils locaux utilisent des versions PHP modernes, et de nombreux hébergeurs en production sont en retard.
• Le problème unique le plus courant est une limite de l'hébergeur qui bloque l'installation, pas une faute dans le transfert lui-même.
• Presque tous les échecs remontent à une différence entre les deux environnements, pas au transfert.

En bref : Votre ordinateur portable et votre serveur en production divergent généralement sur quatre points : la version PHP, le SSL, les permissions de fichiers et le nom de domaine du site. Réglez ces points avant de déplacer, et le transfert se déroulera sans problème.

Une mise en garde qui façonne la lecture de ceci. Ce sont des tickets de support, donc ils montrent où le transfert de local vers production échoue, pas à quelle fréquence il échoue.

Beaucoup de ces transferts se passent bien et ne génèrent jamais de ticket. Et le chiffre de 1 sur 10 décrit les sites utilisant Duplicator Pro, pas WordPress dans son ensemble.

Pourquoi Local et En ligne sont plus éloignés qu'ils n'y paraissent

Un environnement WordPress local est conçu pour les tests privés. Un serveur en production est conçu pour l'internet public. Ce sont des tâches différentes, et les configurations le reflètent.

Quatre différences causent presque tout dans ce rapport :

• Version PHP. Les outils locaux et les hébergeurs web en production peuvent fonctionner avec différentes versions PHP par défaut.
• SSL. Le local fonctionne avec http:// simple ou un certificat auto-signé. La production attend un certificat valide.
• Permissions de fichiers. Le local est permissif car vous êtes le seul utilisateur. La production est plus verrouillée.
• Le nom de domaine. Votre site se connaît sous un nom comme monsite.local. Après le transfert, ce nom n'existe plus.

Que vous utilisiez Local, MAMP, XAMPP, Docker, ou une configuration localhost simple, les modes d'échec sont les mêmes car l'écart se situe entre les environnements plutôt qu'entre les outils.

Le problème SSL dont personne ne vous parle

Le site apparaît sur le serveur de production, et le cadenas est manquant. Ou la mise en page est cassée car la moitié des feuilles de style ont refusé de se charger. Ou le navigateur affiche un avertissement de contenu mixte, et vous n'avez aucune idée de ce à quoi il fait référence.

C'est l'échec le plus distinctif de tout le jeu de données. Les problèmes SSL apparaissent dans environ 1 ticket sur 5 des migrations local-vers-production, comparé à environ 1 sur 70 pour les tickets de migration en général. C'est environ quinze fois le taux normal, et la raison tient au timing plutôt qu'au déménagement lui-même.

Un outil de migration réécrit le domaine de votre site lors de l'installation. monsite.local devient votresite.com dans toute la base de données, y compris à l'intérieur des données sérialisées. Cette partie est gérée.

Le protocole est une question distincte. Si le SSL n'est pas actif sur votre hôte de production au moment de la migration, alors http://votresite.com est l'adresse correcte du site à ce moment-là. C'est donc ce qui est écrit dans la base de données.

Activez le certificat par la suite, et votre site est maintenant servi via HTTPS alors que sa propre base de données indique toujours http://. Chaque ressource enregistrée pendant le développement local hérite du même problème, car aucune d'entre elles n'a jamais eu besoin de HTTPS.

Rien n'a échoué. Le site a été déplacé à l'adresse qu'il avait à ce moment-là.

La correction consiste principalement à faire les choses dans le bon ordre :

• Activez le SSL sur l'hôte de production avant de migrer. La plupart des hôtes fournissent un certificat gratuit, généralement sous une section appelée SSL, SSL/TLS ou Sécurité dans le panneau de contrôle d'hébergement. Faites cela d'abord, et l'installation écrira https:// dès le départ.
• Si vous avez déjà migré, mettez à jour les URL du site. Vous les trouverez sous Réglages » Général dans le tableau de bord WordPress, dans les champs Adresse WordPress et Adresse du site.
• Effectuez une recherche et un remplacement des références http:// laissées par le développement local afin que les anciens liens de ressources correspondent au nouveau protocole.
• Vérifiez le contenu mixte. Chargez le site de production, ouvrez la console développeur de votre navigateur et recherchez les avertissements concernant les ressources non sécurisées. Ils indiqueront les fichiers exacts qui chargent encore via http://.

Gérez le SSL avant le déménagement, et un nombre surprenant de problèmes n'arrivent jamais.

Ce qui casse lors des migrations de Local à En ligne

Le SSL est la raison principale pour laquelle les migrations local-vers-production échouent, mais il n'est pas seul. Voici les autres erreurs qui apparaissent, leurs causes et comment les résoudre.

Ce qui tourne mal	Environ à quelle fréquence	Ce qui se cache derrière	Comment cela est résolu
Une limite de l'hôte empêche l'installation	Le plus courant	Le délai d'expiration PHP ou la limite de mémoire du serveur de production coupant l'extraction, que votre ordinateur portable n'a jamais imposée	Augmentez max_execution_time et memory_limit sur l'hôte
Le site n'est pas sécurisé après le déménagement	Environ 1 sur 5	Le SSL n'était pas actif sur l'hôte au moment du déménagement, donc l'adresse enregistrée est toujours http://	Activez le SSL sur l'hôte avant de migrer, puis confirmez que les URL du site utilisent https://
L'importation de la base de données échoue	Environ 1 sur 7	Les identifiants de la base de données de production ne correspondent pas à ceux créés par l'hôte	Entrez le nom de la base de données, l'utilisateur et le mot de passe corrects pendant l'installation
Les permissions de fichier bloquent l'écriture	Environ 1 sur 8	Le local est permissif, le live ne l'est pas, donc la propriété et les droits d'écriture deviennent soudainement importants	Définissez les dossiers sur 755 et les fichiers sur 644 sur la destination
Vous ne pourrez pas vous connecter une fois en ligne	Environ 1 sur 9	L'URL du site enregistrée ne correspond pas à l'adresse en ligne, provoquant une boucle de redirection	Corrigez l'adresse WordPress et l'adresse du site, puis effacez les cookies
Des erreurs PHP apparaissent sur le site en ligne	Environ 1 sur 11	L'outil local utilise une version de PHP plus récente que celle de l'hôte, donc des fonctions sont obsolètes ou manquantes	Faites correspondre les versions de PHP des deux côtés avant de déplacer
Quelques références locales subsistent	Environ 1 sur 16	URL codées en dur dans les fichiers de thème, le code personnalisé, les caches ou les services tiers, en dehors de la base de données	Recherchez le domaine local dans le thème et le code personnalisé, puis videz tous les caches

Lisez la troisième colonne, et le schéma est difficile à manquer. Presque rien ici n'est causé par le transfert. C'est causé par le fait que le serveur en ligne est configuré différemment de votre ordinateur portable.

Quand une limite d'hébergement bloque l'installation

Vous démarrez l'installation sur le serveur en ligne, elle s'exécute pendant un certain temps, puis elle s'arrête.

C'est le problème unique le plus courant dans les tickets local-vers-live, et c'est une limite de l'hôte plutôt qu'un transfert défectueux. Le délai d'expiration PHP ou la limite de mémoire du serveur coupe le processus pendant l'extraction, qui est l'étape la plus lourde. Les machines locales n'ont pas de tels plafonds, donc une construction qui fonctionnait bien sur votre ordinateur portable peut se heurter à un mur sur l'hébergement mutualisé.

Augmentez max_execution_time et memory_limit sur le serveur de destination. Ceux-ci se trouvent dans le panneau de contrôle de votre hôte, souvent sous Options PHP ou Éditeur MultiPHP INI, et le support de votre hôte peut les augmenter rapidement si vous ne les trouvez pas.

C'est aussi là que l'outil que vous utilisez fait une différence.

Une archive zip standard doit être décompressée en une seule exécution continue. Sur un serveur avec une limite d'exécution courte, c'est un problème.

Si la décompression prend plus de temps que ce que l'hôte autorise, le processus est interrompu en cours de route, et vous vous retrouvez avec un site partiellement décompressé et aucune erreur claire.

DupArchive est le format d'archive de sauvegarde personnalisé de Duplicator, conçu pour être décompressé en plus petits morceaux. Il traite le site morceau par morceau, de sorte qu'aucune exécution unique n'a besoin de dépasser la limite de l'hôte.

C'est ce qui permet à Duplicator de gérer de grands sites, y compris des migrations réelles de 400 Go, sur des serveurs qui seraient étouffés par une archive conventionnelle.

L'installateur autonome résout un problème connexe à l'autre extrémité. Il n'a pas besoin que WordPress existe déjà sur la destination, vous pouvez donc déplacer une construction locale sur un serveur complètement vide sans rien configurer au préalable.

PHP est plus récent sur votre ordinateur portable que sur votre hébergeur

Tout fonctionne localement, puis le site en ligne génère des erreurs sur les pages qui utilisent des fonctionnalités spécifiques de plugins ou de thèmes.

Cela apparaît environ trois fois plus souvent lors des migrations de local vers live que lors d'autres migrations, et cela est dû à la façon dont les outils sont empaquetés.

Les environnements de développement locaux sont livrés avec une version PHP actuelle. De nombreux hôtes en ligne utilisent encore par défaut une version plus ancienne, de sorte que les fonctions qui fonctionnaient sur votre ordinateur portable sont obsolètes ou manquantes sur le serveur.

Vérifiez les deux avant de déplacer. Dans votre outil local, la version PHP est généralement affichée dans le panneau des paramètres du site.

Sur l'hôte, regardez sous Version PHP, Sélectionner la version PHP ou Gestionnaire MultiPHP. Faites-les correspondre et compilez en fonction de la version que vous allez réellement déployer.

L'importation de la base de données échoue

Le site en direct charge une erreur concernant l'établissement d'une connexion à la base de données, ou l'installation s'arrête à l'étape de la base de données.

Après un déplacement, il s'agit presque toujours d'un problème d'identifiants plutôt que d'une base de données corrompue. Le nom, l'utilisateur ou le mot de passe ne correspondent pas à ce que l'hôte en direct a créé.

Obtenez le nom de la base de données, le nom d'utilisateur, le mot de passe et la valeur de l'hôte de votre compte d'hébergement en direct, et saisissez-les soigneusement pendant l'étape d'installation. Si le site est déjà en ligne et échoue, ces valeurs se trouvent dans wp-config.php dans le dossier racine de votre site, accessible via le gestionnaire de fichiers de votre hôte ou un client FTP.

Les autorisations de fichiers ne sont pas transférées

L'installation s'arrête avec une erreur indiquant qu'elle ne peut pas écrire un fichier ou créer un dossier.

Les environnements locaux sont permissifs car vous êtes la seule personne à les utiliser. Les serveurs en direct sont plus stricts. La propriété et les droits d'écriture qui n'ont jamais eu d'importance sur votre ordinateur portable commencent à en avoir ici.

Définissez les dossiers sur 755 et les fichiers sur 644 sur la destination. Vous pouvez modifier les autorisations de fichiers via un client FTP ou le gestionnaire de fichiers de votre hôte, qui affichent tous deux une option d'autorisations ou CHMOD lorsque vous cliquez avec le bouton droit sur un dossier. La documentation de votre hôte confirmera l'utilisateur du serveur Web correct si vous n'êtes pas sûr.

Vous ne pouvez pas vous connecter une fois en ligne

Le déplacement se termine, vous essayez de vous connecter, et la page de connexion vous renvoie ou boucle.

Cela cause plus de panique qu'il ne le mérite. Cela ne signifie presque jamais que le déplacement a échoué. L'URL du site stockée dans la base de données ne correspond pas à l'endroit où le site se trouve maintenant, donc WordPress continue de vous rediriger vers une adresse qui n'existe plus.

Corrigez les champs Adresse WordPress et Adresse du site sous Réglages » Général, puis effacez vos cookies.

Si vous ne pouvez pas du tout accéder au tableau de bord, vous pouvez définir temporairement les deux valeurs dans wp-config.php.

Quelques références locales survivent au déplacement

La plupart des liens fonctionnent, mais quelque chose pointe toujours vers mysite.local.

Les références de la base de données sont réécrites pendant l'installation. Ce qui survit, c'est tout ce qui se trouve en dehors de la base de données : une URL codée en dur dans un fichier de thème ou de thème enfant, un chemin écrit dans du code personnalisé, une page mise en cache ou un service tiers pointant toujours vers votre adresse de développement.

Recherchez le domaine local dans votre thème et votre code personnalisé, videz le cache de tout plugin de mise en cache et le cache du serveur de votre hôte, puis rechargez. Si un service tel qu'un CDN ou un formulaire externe est impliqué, mettez également à jour l'adresse du site dans ce service.

Une vérification avant le départ avant de pousser le local vers l'en ligne

Vous pouvez éviter la plupart des erreurs de WordPress locales à en direct avec environ cinq minutes de préparation.

• Activez le SSL sur l'hôte en direct. C'est l'élément le plus précieux de la liste, et le faire en premier est ce qui le fait fonctionner.
• Comparez les versions PHP sur votre outil local et votre hôte en direct, et faites-les correspondre.
• Ayez les informations d'identification de votre base de données en direct à portée de main avant de commencer l'installation.
• Connaissez l'URL en direct et attendez-vous à ce que les adresses du site changent avec elle.
• Préparez votre connexion administrateur afin qu'une boucle de redirection ne vous empêche pas d'accéder à votre propre site.

Si vous souhaitez obtenir le guide étape par étape complet pour le transfert lui-même, notre guide sur la migration d'un site WordPress local vers un serveur en direct explique le processus. Ce rapport porte sur les différences entre les deux environnements et comment les combler à l'avance.

Duplicator Pro aide le plus dans les parties qui posent problème ici. L'installateur autonome déplace un site vers un serveur vierge, même un sans WordPress installé, et DupArchive gère les constructions locales volumineuses sans s'étouffer lors de l'étape d'extraction.

Questions fréquemment posées (FAQ)

L'écart entre votre ordinateur portable et votre serveur

Chaque problème de ce rapport provient du même endroit. Votre environnement local et votre serveur en direct divergent concernant PHP, SSL, les autorisations ou le nom du site lui-même. Le transfert est l'endroit où ces divergences apparaissent toutes en même temps.

Cela vaut la peine d'être répété clairement car cela change la façon dont vous vous préparez. La migration n'est pas la partie risquée. La divergence l'est.

Avant de construire le site local, vérifiez la version PHP de l'hébergeur en direct et activez son certificat SSL. Développez en fonction de l'environnement dans lequel vous allez déployer, et la plupart de ce rapport ne s'appliquera jamais à vous.

Avant votre prochain lancement, ayez un moyen de revenir en arrière

Un site qui plante dès son premier jour en ligne est un mauvais après-midi. Un site qui plante sans copie propre pour se rabattre est bien pire.

Duplicator Pro est utilisé par plus de 1,5 million de professionnels WordPress pour sauvegarder, migrer et restaurer leurs sites. Son installeur autonome déplace une création locale sur un serveur vierge, et ses outils de récupération vous permettent de revenir si un lancement tourne mal.

Pendant que vous êtes ici, ces autres ressources WordPress valent le détour :

• Ce que plus de 8 000 tickets de support révèlent sur les raisons pour lesquelles les migrations WordPress échouent
• Ce qui casse les sauvegardes WordPress : leçons tirées de plus de 1 400 tickets de support
• Votre liste de contrôle complète pour la migration WordPress (du début à la fin)
• Comment déplacer un site WordPress vers un nouvel hébergeur
• Comment restaurer un site WordPress à partir d'une sauvegarde