Les règles WordPress ont aussi des exceptions

wordpress apache
Temps de lecture: 2 minutes

wordpress apacheWordPress a fait un grand pas en avant dans l'évolution de la plate-forme de blogs, en la rapprochant d'un système de gestion de contenu à part entière avec suivi des révisions, plus de prise en charge des menus personnalisés et - la fonctionnalité la plus intrigante pour moi - une prise en charge multisite avec mappage de domaine.

Si vous n'êtes pas un drogué du système de gestion de contenu, ça va. Vous pouvez passer directement cet article. Mais pour mes collègues techno-geeks, chefs de code et apache-dabblers, je veux partager quelque chose d'intéressant et de cool.

Le multi-site est une fonctionnalité qui vous permet d'exécuter n'importe quel nombre de sites Web WordPress avec une seule installation WordPress. Si vous administrez plusieurs sites, c'est bien car vous pouvez installer un groupe approuvé de thèmes et de widgets et les activer pour vos sites clients. Il y a quelques obstacles techniques pour mapper vos domaines, mais le processus n'est pas difficile.

L'un des problèmes que j'ai identifiés est la personnalisation des thèmes. Étant donné que les thèmes peuvent être mis à disposition sur plusieurs sites Web, toute personnalisation que vous apportez à un thème affectera également tous les autres sites utilisant ce thème lors de votre installation multi-sites. Ma façon de contourner cela consiste à dupliquer un thème avant de commencer la personnalisation et à nommer clairement le thème du site client pour lequel je le stylise.

Un autre problème intéressant est ce qui se passe dans le fichier .htaccess sur votre serveur Apache. WordPress doit réécrire les chemins sur une base blog par blog et le fait avec une règle de réécriture et un fichier php.

WordPress utilise la règle de réécriture suivante:

RewriteRule ^ ([_ 0-9a-zA-Z -] + /)? Files /(.+) wp-includes / ms-files.php? File = $ 2 [L]

Essentiellement, tout ce qui est dans un sous-répertoire de mysite.com/files/directory est réécrit sur mysite.com/files/wp-includes/myblogfolderpath ... et c'est là que cela devient intéressant. Que se passe-t-il si vous avez réellement besoin d'avoir un fichier sur votre serveur qui est mysite.com/files/myfolder/myimage.jpg? Vous obtenez une erreur 404, c'est ce qui se passe. La règle de réécriture Apache entre en action et change le chemin.

Certes, vous ne rencontrerez peut-être jamais ce problème, mais je l'ai fait. J'avais un site qui devait utiliser un widget javascript d'un autre site Web, et il avait besoin de trouver des graphiques sur mysite.com/files/Images/myfile. Puisqu'il n'y avait aucun moyen de modifier le fichier sur le site hôte, j'avais besoin de trouver un moyen de le faire sur mon serveur. La solution simple consiste à créer une condition de réécriture qui crée une exception pour des fichiers spécifiques.

Voici la solution:

RewriteCond% {REQUEST_URI}! /? Files / Image / file1.jpg $
RewriteCond% {REQUEST_URI}! /? Files / Image / file2.jpg $
RewriteRule ^ ([_ 0-9a-zA-Z -] + /)? Files /(.+) wp-includes / ms-files.php? File = $ 2 [L]

Les conditions de réécriture doivent être placées avant la règle de réécriture, sinon cette astuce ne fonctionnera pas. Il devrait être facile de modifier cette condition pour vos propres besoins, si vous rencontrez un problème similaire. La solution a très bien fonctionné pour moi, me permettant de remplacer des graphiques personnalisés plutôt que le texte alternatif moins souhaitable qui ne convenait pas à ma conception. J'espère que cela fonctionnera pour vous aussi.

Que pensez-vous?

Ce site utilise Akismet pour réduire les spams. Découvrez comment sont traitées les données de vos commentaires..