Nous avons un réseau WP (avec le mappage de domaine) qui a été démarré avant WP 3.5; il utilisait donc ms-files.php
et wp-content/blogs.dir/
pour stocker les fichiers multimédias. Je voulais supprimer la dépendance ms-files.php
et, après quelques recherches, a lancé le processus:
J'ai d'abord essayé de ne pas déplacer aucun fichier de blogs.dir/#/files
à uploads/sites/#
, mais de configurer des liens symboliques pour cela. Ensuite, j'ai eu quelques problèmes d'autorisations, j'ai donc tout copié de blogs.dir/#/files
à uploads/sites/#
.
Ensuite, j'ai effacé les valeurs pour upload_path
, upload_url_path
et fileupload_url
sur chaque site.
Et finalement mis à jour/inséré ms_files_rewriting = 0
dans la table wp_sitemeta
.
Nous avons également ajouté des règles de réécriture au fichier .htaccess
pour ne pas avoir à gérer la mise à jour de toutes les URL de la base de données.
L'ID principal du blog dans notre configuration est 2 et non la valeur par défaut qui est 1: define('BLOG_ID_CURRENT_SITE', 2);
Autant que je sache, et d'après ce que je vois dans wp_upload_dir()
, WP utilise la racine du dossier uploads
pour le contenu du blog principal et uploads/sites/#
pour les autres blogs. J'ai donc copié le contenu de blogs.dir/2/files
à la racine du dossier uploads
et PAS à uploads/sites/2
.
Maintenant, voici le problème des fichiers multimédias sur le BLOG PRINCIPAL: dans le back-end, WP charge les fichiers du dossier uploads
, ce qui est correct, mais sur le front-end, il essaie de charger des fichiers à partir de uploads/sites/2
qui n'existe pas et est bizarre!
PS: Je peux simplement ajouter une autre règle de réécriture pour résoudre ce problème, mais je veux vraiment savoir quelle est la raison de l’ajout de /sites/2
au blog principal.
Le "chemin de téléchargement" de WordPress multisite doit être défini sur un chemin relatif au serveur (par exemple, /home/serveraccountname/public_html/wp-content/uploads
).
Le "chemin d'URL de téléchargement" doit être l'URI (par exemple, http://example.com/wp-content/uploads
).
Ignorer le fragment /sites/1/
pour les sous-sites - WordPress les ajoutera automatiquement.
Auparavant, nous pouvions définir le répertoire dans lequel les fichiers étaient conservés et cette option supprimée, ce qui pouvait avoir quelque chose à voir avec les liens mal dirigés. J'ai eu le même problème, mais je suis allé et re-uploadé les fichiers qui ne fonctionnaient pas correctement. Cela peut ne pas être réaliste si vous avez beaucoup de fichiers, mais c'est une option. Une autre option consiste à utiliser un plugin tel que Broken Link Checker de Janis Elsts. Il recherchera sur votre site les liens qui ne fonctionnent pas et vous offre la possibilité de modifier facilement les URL. Il vous enverra également un courrier électronique vous indiquant si un autre site connecté à un lien ne fonctionne plus. C'est très utile et je l'utilise maintenant sur la plupart de mes sites Web. ^^