Je suis sur le point de me lancer dans le développement de WordPress dans un environnement d'équipe composé de plusieurs personnes. (3 personnes ou plus travaillant sur la même base de code à la fois, chacune se développant localement)
Avec les autres CMS avec lesquels nous avons travaillé, tout le monde a orienté ses installations vers la même base de données et, en raison de son fonctionnement, cela signifie que nous pouvons tous avoir le même contenu alimentant nos installations (situées à des URL différentes) à partir du même fichier. même base de données sans trop de problème (autre que devoir occasionnellement synchroniser les dossiers de téléchargement)
Ma question est, avec WordPress, ce qui nous empêche d’utiliser cette même approche et comment pouvons-nous résoudre ces problèmes?
par exemple. Trois copies de WordPress fonctionnant toutes à partir de la même base de données.
http: //dev.local/developer-a/
http: //dev.local/developer-b/
http: //dev.local/developer-c/
etc
J'espère qu'il va sans dire que ce ne sera que dans un environnement de développement avant son lancement.
wp_posts
et wp_options
semble-t-il)Actuellement, j'ai le début d'une solution pour le premier numéro en place. Je place le texte suivant dans un fichier de mon dossier mu-plugins.
Le code filtre essentiellement le contenu de la publication au fur et à mesure de son insertion dans la base de données en remplaçant toute instance de l'URL par un jeton unique.
<?php
define('PORTABILITY_TOKEN', '{_portable_}');
function portability_remove_home($content)
{
$content = str_replace(get_option('home'), PORTABILITY_TOKEN, $content);
return $content;
}
add_filter('content_save_pre', 'portability_remove_home');
function portability_add_home($content)
{
$content = str_replace(PORTABILITY_TOKEN, get_option('home'), $content);
return $content;
}
add_filter('the_content', 'portability_add_home');
add_filter('the_editor_content', 'portability_add_home');
J'ai défini les options home et siteurl via php en utilisant l'environnement d'installation de WordPress pour les résoudre. (là encore, il s’agit uniquement de développement) Cela signifie que pour chaque installation individuelle, le contenu de la publication WordPresses ressemblera à une exécution sur cette URL au moment où il parvient au client.
<?php
if (!defined('WP_HOME'))
{
// define WP_HOME (aka url of install) based on environment.
// IF THIS ISN'T WORKING, DEFINE IT EARLIER.
define('WP_HOME', 'http://' . $_SERVER['HTTP_Host'] . str_replace($_SERVER['DOCUMENT_ROOT'], '', dirname(__FILE__) ) );
}
if (!defined('WP_SITEURL'))
{
// Assumes WordPress is in a separate directory called 'wp', relative to WP_HOME.
// IF IT'S DIFFERENT, DEFINE IT EARLIER.
define('WP_SITEURL', WP_HOME . '/wp');
}
Les deuxième et troisième problèmes semblent pouvoir être résolus avec les liens symboliques appropriés (tous se développant sur le même ordinateur).
Puis-je améliorer mon traitement des différentes URL de toute façon? Y at-il quelque chose que j'ai manqué qui aura l'URL codé en dur dans la base de données?
Des pièges dont je devrais être au courant avec les liens symboliques?
Y a-t-il d'autres problèmes auxquels on puisse penser?
Je me rends compte que ces questions sont très spécifiques, si quelque chose n'est pas clair, commentez ceci et je modifierai/clarifierai.
Merci.
Je vais répondre à la question 2, sachez que certaines valeurs de la base de données sont stockées dans des tableaux sérialisés. Par exemple, si la longueur de votre chaîne d'URL change et qu'elle se trouve dans un tableau sérialisé, vous devez mettre à jour l'index correspondant.
Vous pouvez utiliser ce PHP script pour mettre à jour toutes les valeurs des tableaux sérialisés, ou l'exécuter à partir de la ligne de commande dans votre propre script.
Question 1: vous avez des URL qui entrent et sortent de la base de données à plus d’endroits que le contenu du post. J'ai trouvé des URL dans *_postmeta
, *_comments
et *_options
(en plus de celles que vous avez définies). Cela ne compte pas l’activité du plugin et Custom Meta Field activity.
Question 2: Je vais aussi parfois créer des liens symboliques pour des raisons de commodité, et la plupart du temps, cela fonctionne. Parfois ce n'est pas le cas. Je ne peux pas vous dire les conditions exactes qui causent un problème, mais Javascript semble être un facteur.
Question 3: Je m'attendrais à des problèmes avec la table *_options
, le cas échéant. Des éléments tels que les plugins activés et le thème actif y sont conservés. Parmi de nombreuses autres informations, vous trouverez de jolis sites spécifiques.