Pour les besoins de développement de mon thème, j'ai une installation WordPress locale que je lance à partir d'une machine virtuelle, accessible via, disons, http://local.app
. J'ai également une version distante du site sur un serveur de transfert, http://staging.example.com
.
Le site de transit contient tout le contenu sur lequel je conçois le thème (articles, pages, produits WooCommerce, etc.).
Tout cela se trouve dans la base de données MySQL sur le serveur ainsi que dans les supports (images, fichiers, etc.) dans wp-content/uploads
.
Maintenant, via le guide utile sur le Codex intitulé "Deux WordPresses, une base de données", la plupart du temps, cela fonctionne, avec une copie locale du thème, des plugins et du noyau wordpress sur ma machine virtuelle, récupérant toutes ses données à distance serveur de transfert.
Le seul problème est que tous les médias obtiennent 404, car pour une raison quelconque, toutes les URL de fichiers multimédias sont liées à ma machine virtuelle locale plutôt qu'au serveur de transfert. Par exemple. Si je visite la médiathèque et que je vais à la page "Éditer le média", "l'URL du fichier" se lit comme suit:
http://staging.example.com/wp-content/uploads/2015/04/greigh.jpg
http://local.app/wp-content/uploads/2015/04/greigh.jpg
Lors de l'inspection de la base de données, tous les types d'articles attachment
ont des guid avec des URL complètes et non relatives. Comment WordPress crée-t-il ces URL, et existe-t-il un moyen de résoudre ce problème sans avoir à dupliquer l'intégralité de la médiathèque sur ma machine virtuelle?
Quelque part dans le noyau, les URL sont absolument tracées lorsqu'elles sont insérées dans la base de données.
Pourquoi ne chargez-vous pas simplement toutes vos images à partir de votre serveur de transfert? Demandez au serveur de transfert de conserver les fichiers pendant que votre serveur local les reproduit. Ajoutez les éléments suivants à votre .htaccess
dans votre dossier de téléchargements locaux et le contenu est le suivant:
# Attempt to load files from production if they're not in our local version
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
# Replace http://example.com with your production site's domain name
RewriteRule (.*) http://example.com/wp-content/uploads/$1
</IfModule>
Pour les retardataires, si votre environnement de développement est LEMP, pour votre site nginx (par défaut), cela figurerait dans la déclaration de votre serveur principal pour rediriger la plupart des erreurs d'image 404:
# Directives to send expires headers and turn off 404 error logging. Try images from production server
location ~* \.(png|jpe?g|gif|ico)$ {
expires 24h;
log_not_found off;
try_files $uri $uri/ @production;
}
location @production {
resolver 8.8.8.8;
proxy_pass http://Production-or-StagingServerURL.com/$uri;
}
Ajoutez d'autres extensions de ressources, par exemple: svg, à l'emplacement 'array' pour couvrir d'autres types d'erreurs de ressources 404.
Ou voyez cette réponse pour une autre option: Comment configurer nginx pour rediriger les demandes vers le répertoire de téléchargement sur le serveur de production?