Comment puis-je rendre une base de données WordPress portable et indépendante de l'URL?

Problème

Je suis sur le point de me lancer dans un développement WordPress dans un environnement d'équipe multi-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 pointé leurs installations vers la même base de données et en raison de la façon dont ce CMS / base de données a fonctionné, cela signifie que nous pouvons tous avoir le même contenu alimentant nos installations (situées à des URL différentes) à partir de la même base de données sans trop de problème (autre que d'avoir à synchroniser occasionnellement des dossiers de téléchargement)

Ma question est, avec WordPress, qu'est-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 cela ne se fera que dans un environnement de développement avant le lancement.

Problèmes principaux

1. Références à des URL spécifiques dans la base de données ( wp_postset aux wp_optionstables, semble-t-il)
2. Si une personne installe un plugin, les autres installations ne l'auront pas et entraîneront des problèmes de simultanéité dans la base de données
3. Synchronisation des dossiers de téléchargement

Solution actuelle

Actuellement, j'ai les débuts d'une solution pour le premier problème en place. Je place ce qui suit dans un fichier dans mon dossier mu-plugins.

Le code filtre essentiellement le contenu de la publication lors de son entrée et de sa sortie 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 où WordPress est installé pour les travailler. (encore une fois, c'est uniquement pour le développement) Cela signifie que pour chaque installation individuelle, le contenu de la publication WordPresses ressemblera à ce qu'il s'exécute 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 résolubles avec les liens symboliques appropriés (tous se développant sur la même machine)

Questions réelles

1. Puis-je améliorer ma gestion des différentes URL de toute façon? Y a-t-il quelque chose que j'ai manqué qui aura l'url codé en dur dans la base de données?

2. Y a-t-il des problèmes que je devrais connaître avec le lien symbolique?

3. D'autres questions auxquelles tout le monde peut penser?

Je me rends compte que ces questions sont très spécifiques, si quelque chose n'est pas clair, commentez-le et je modifierai / clarifierai.

Merci.

Je répondrai à 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 URL change et qu'elle se trouve dans un tableau sérialisé, vous devez mettre à jour l'index pour cela.

Vous pouvez utiliser ce script PHP 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é dans les URL *_postmeta, *_commentset *_options(en plus de ceux que vous avez définis). Cela ne compte pas l'activité du plugin et l'activité du méta-champ personnalisé .

Question 2: Je vais aussi parfois créer des liens symboliques pour des raisons de commodité, et la plupart du temps cela fonctionne. Parfois non. 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 *_optionstable, si quelque chose. Des choses comme les plugins activés et le thème actif y sont conservés, parmi beaucoup d'autres informations est assez spécifique au site.