Comment partager la bibliothèque principale de WordPress
Nous avons dix blogs fonctionnant sur de petites instances EC2, nous voulons voir si tous les blogs peuvent partager le même code php wordpress afin
- Quand je met à jour le Wordpress, tous les blogs sont mis à jour
- Économisez de la mémoire dans Apache/mod_php en évitant les scripts dupliqués ou le bytecode dans le cache (dans le cas d'APC).
Nous ne pouvons pas utiliser MU car nous avons besoin de tous les blogs dans une base de données distincte. Par conséquent, plus tard, il sera beaucoup plus facile de les déplacer.
Quelqu'un a déjà essayé ça?
En supposant que toutes les installations se trouvent sur la même instance et peuvent donc partager les mêmes fichiers, la principale chose à faire est donc de faire en sorte que tout le contenu personnalisé vive en dehors des dossiers WordPress principaux.
Donc, tout d’abord, vous allez vouloir une nouvelle copie de WordPress quelque part, intacte (et intouchable, l’essentiel est d’avoir une copie unique, non?).
Vous utiliserez ensuite des liens physiques ou des liens symboliques pour reproduire ces fichiers ailleurs. Normalement, dans les environnements de type Unix, vous utilisez ln -s pour créer des liens symboliques. La façon de faire cela est laissée au lecteur, mais si vous avez votre WordPress dans/example/wp, vous ferez quelque chose comme ln -s /example/wp /home/username/public_html/wp ou quelque chose comme ça. Si les liens symboliques causent des problèmes, passez plutôt aux liens durs.
Maintenant, les deux éléments principaux du dossier WordPress principal, mais qui sont personnalisés et ne font pas partie du "noyau", sont votre fichier wp-config.php et le dossier entier wp-content. Nous devons donc les obtenir en dehors du dossier principal/wp de chaque site. Les deux sont possibles.
Le fichier wp-config.php est simple, car WordPress vérifie également un répertoire par lui-même. Si votre dossier wp est à /home/username/public_html/wp, alors WP recherchera /home/username/public_html/wp/wp-config.php, mais à défaut, il recherchera également /home/username/public_html/wp-config.php. Il suffit donc de créer vos fichiers wp-config.php dans le répertoire ci-dessus.
Pour le dossier wp-content, vous pouvez le repositionner en dehors du répertoire principal wp en ajoutant du code à votre fichier wp-config.php comme suit:
define( 'WP_CONTENT_DIR', '/home/username/public_html/custom-content' );
define( 'WP_CONTENT_URL', 'http://example.com/custom-content');
Ensuite, WordPress s’attendra à ce que le contenu et tout ce qu’il contient y vivent. Le dossier wp-content dans le répertoire/wp sera complètement ignoré. Vous devrez donc créer ce dossier et y placer vos thèmes/plugins/uploads.
La dernière étape consiste à utiliser .htaccess (ou certains autres fichiers de configuration si vous n'utilisez pas Apache). Affichez le dossier/wp comme visible à la racine, comme s'il se trouvait là. Ce n'est pas compliqué, cela nécessite juste un peu de réflexion. Vous voyez, les règles .htaccess normales de WordPress (pour les permaliens non-par défaut) indiquent essentiellement à Apache de rediriger toutes les demandes vers le fichier index.php de WordPress principal si la demande ne fait pas référence à un fichier qui existe réellement. Cela permet aux images téléchargées et autres de travailler directement en dehors de WP.
Voici un exemple de jeu de règles que vous pouvez utiliser dans /home/username/public_html/.htaccess pour imiter cela, mais qui vous permet également de prendre en compte le répertoire/wp.
Options -Indexes
RewriteEngine on
RewriteCond %{HTTP_Host} ^(www.)?example.com$
RewriteCond %{REQUEST_URI} !^/wp/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /wp/$1
RewriteCond %{HTTP_Host} ^(www.)?example.com$
RewriteRule ^(/)?$ wp/index.php [L]
Essentiellement, ces règles disent deux choses.
Premièrement: si l’URL demandée n’a pas/wp/dedans et n’est pas un fichier ni un répertoire existant, changez l’URL en utilisant une réécriture interne pour avoir/wp/devant. Cela a pour effet de remapper toutes les URL de http://example.com/w Whatever à http://example.com/wp/w Whatever . En gros, cela fonctionne comme si/wp/était réellement à la racine du site.
La deuxième règle modifie les demandes de l'URL racine (juste le /) dans le fichier /wp/index.php. Cela peut ne pas être strictement nécessaire, mais cela fonctionne pour moi.
Cela permet au répertoire/wp de rester "pur", pour ainsi dire, et vous pouvez donc utiliser des liens symboliques ou des liens durs pour conserver le one-true-WP-install ailleurs, à l'abri de tout élément spécifique à un site.
Notez que de nombreux plugins mal écrits (et même quelques thèmes) peuvent supposer qu'ils se trouvent dans le dossier principal wp-content. Tout ce qui est stupide comme include '../../../wp-load.php'; ou similaire sera cassé par cette approche. Cette erreur est de la part du plugin/thème. Aucun plugin/thème ne devrait inclure jamais wp-load .
Il y a quelques choses qui n'ont pas de sens dans votre postulat de base. Premièrement, si vous avez dix blogs dans des instances distinctes, ils ne peuvent pas partager la même base de code - dix instances EC2 = dix serveurs, donc dix ensembles de fichiers nécessaires. Deuxièmement, vous aurez inévitablement des scripts dupliqués pour la même raison. Pouvez-vous parler entre instances? Je ne le pense pas, mais même si deux sites essaient de fonctionner à partir de la même base de code, il y aura un conflit de wp-config.php avec les paramètres de la base de données au minimum.
Je ne suis pas vraiment sûr que le multisite ne soit pas la solution. Bien que tous les blogs existent dans la même base de données, ils ont tous un préfixe de table spécifique au blog, facilitant les sauvegardes de la base de données (une base de données contre dix) tout en permettant la portabilité (voir ici pour plus d'informations). Il est un peu fastidieux de déplacer un blog d'un site multisite. Ce n'est pas plus fastidieux que de déplacer un site vers un autre domaine.
Vous semblez vouloir créer dix WP environnements différents, mais uniquement la base de code complète pour l'un d'entre eux, et c'est le cœur de WPMS: une base de code, plusieurs sites. Donc, votre exigence de "même base de code mais pas multisite" est mutuellement exclusive, raison pour laquelle cela fait 4 jours et personne n'a répondu à cette question. Il semble que vous deviez repenser un peu vos exigences.
Maintenant, alternativement, si vous voulez juste vous assurer que WP est mis à jour globalement, envisagez peut-être de accrocher vos installations de base WordPress à SVN . Vous pouvez faire la même chose pour des plugins individuels, tant qu'ils sont dans le référentiel. De cette façon, vous pourriez simplement exécuter un script Shell pour toucher les instances et svn up sur les dix en même temps. Cependant, cela semble demander beaucoup de travail pour éviter une installation multisite.