Come posso rendere un database WordPress portatile e indipendente dall'URL?

Problema

Sto per intraprendere lo sviluppo di WordPress in un ambiente di squadra multi-persona. (3 o più persone lavorano sulla stessa base di codice alla volta, ognuna in via di sviluppo locale)

Con altri CMS con cui abbiamo lavorato, tutti hanno puntato le loro installazioni sullo stesso database e, a causa del funzionamento di quel CMS / database, ciò significa che possiamo avere tutti lo stesso contenuto che si inserisce nelle nostre installazioni (situato in URL diversi) dal stesso database senza troppi problemi (oltre a dover occasionalmente sincronizzare le cartelle di upload)

La mia domanda è, con WordPress, cosa ci impedisce di utilizzare questo stesso approccio e come possiamo risolvere questi problemi?

per esempio. Tre copie di WordPress tutte in esecuzione sullo stesso database.

http: //dev.local/developer-a/
http: //dev.local/developer-b/
http: //dev.local/developer-c/

eccetera

Spero sia ovvio che questo sarà solo in un ambiente di sviluppo prima del lancio.

Problemi principali

1. Riferimenti a URL specifici all'interno del database ( wp_postse wp_optionstabelle sembra)
2. Se una persona installa un plugin, l'altra installazione non lo avrà e causerà problemi di concorrenza nel database
3. Mantenere sincronizzate le cartelle di upload

Soluzione attuale

Attualmente ho gli inizi di una soluzione per il primo problema in atto. Metto quanto segue in un file nella mia cartella mu-plugins.

Il codice essenzialmente filtra il contenuto del post man mano che entra e esce dal database sostituendo qualsiasi istanza dell'URL con un token univoco.

<?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');

Ho impostato le opzioni home e siteurl tramite php usando l'ambiente in cui WordPress è installato per risolverli. (di nuovo, questo è solo per lo sviluppo) Ciò significa che per ogni singola installazione il contenuto dei post di WordPress sembrerà in esecuzione su quell'URL quando arriva al 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');
}

Il secondo e il terzo problema sembrano risolvibili con i collegamenti simbolici appropriati (tutti in sviluppo sulla stessa macchina)

Domande reali

1. Posso comunque migliorare la mia gestione degli URL diversi? C'è qualcosa che mi è sfuggito che avrà l'URL hardcoded nel database?

2. Qualche gotcha di cui dovrei essere a conoscenza con il collegamento simbolico?

3. Qualche altro problema a cui qualcuno può pensare?

Mi rendo conto che queste domande sono molto specifiche, se qualcosa non è chiaro, commentalo e io modificherò / chiarirò.

Grazie.

Risponderò alla domanda 2, tenere presente che alcuni valori nel database sono memorizzati in array serializzati. Ad esempio, se la lunghezza della stringa dell'URL cambia e si trova in un array serializzato, è necessario aggiornare l'indice per esso.

È possibile utilizzare questo script PHP per aggiornare tutti i valori negli array serializzati o eseguirlo dalla riga di comando nel proprio script

Domanda 1: hai URL che entrano ed escono dal database in più punti rispetto al solo contenuto del post. Ho trovato gli URL in *_postmeta, *_commentse *_options(oltre a quelli che hai definito). Questo non sta contando l'attività del plug-in e l' attività del campo meta personalizzato .

Domanda 2: A volte anche i plug-in symlink per comodità, e il più delle volte funziona. A volte no. Non posso dirti le condizioni esatte che causano un problema, ma Javascript sembra essere un fattore.

Domanda 3: mi sarei aspettato problemi con il *_optionstavolo, se non altro. Cose come i plugin attivati ​​e il tema attivo sono mantenuti lì, tra molte altre informazioni è piuttosto specifico del sito.