Wie kann ich eine WordPress-Datenbank portabel und URL-unabhängig machen?

Problem

Ich bin dabei, eine WordPress-Entwicklung in einer Teamumgebung für mehrere Personen zu beginnen. (3 oder mehr Personen, die gleichzeitig an derselben Codebasis arbeiten und sich jeweils lokal entwickeln)

Bei anderen CMS, mit denen wir gearbeitet haben, hat jeder seine Installationen auf dieselbe Datenbank gerichtet. Aufgrund der Funktionsweise dieses CMS / dieser Datenbank bedeutet dies, dass wir alle denselben Inhalt in unsere Installationen (mit unterschiedlichen URLs) einspeisen können Dieselbe Datenbank ohne große Probleme (außer gelegentlich Upload-Ordner synchronisieren zu müssen)

Meine Frage ist, was uns bei WordPress daran hindert, denselben Ansatz zu verwenden, und wie können wir diese Probleme lösen?

z.B. Drei Kopien von WordPress laufen alle aus derselben Datenbank.

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

usw

Ich hoffe, es versteht sich von selbst, dass dies nur in einer Entwicklungsumgebung vor dem Start sein wird.

Hauptprobleme

1. Verweise auf bestimmte URLs in der Datenbank ( wp_postsund wp_optionsTabellen, wie es scheint)
2. Wenn eine Person ein Plugin installiert, wird es von der anderen Person nicht installiert und es treten Parallelitätsprobleme in der Datenbank auf
3. Upload-Ordner synchron halten

Aktuelle Lösung

Derzeit habe ich die Anfänge einer Lösung für das erste Problem. Ich lege folgendes in eine Datei in meinem mu-plugins Ordner.

Der Code filtert im Wesentlichen den Post-Inhalt beim Ein- und Aussteigen in die Datenbank, indem er eine beliebige Instanz der URL durch ein eindeutiges Token ersetzt.

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

Ich habe die Home- und Siteurl-Optionen über PHP in der Umgebung festgelegt, in der WordPress installiert ist, um sie auszuarbeiten. (Auch dies ist nur für die Entwicklung vorgesehen.) Dies bedeutet, dass bei jeder einzelnen Installation der Post-Inhalt von WordPress so aussieht, als würde er auf dieser URL ausgeführt, wenn er beim Client ankommt.

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

Das zweite und dritte Problem scheinen mit den entsprechenden Symlinks lösbar zu sein (alle entwickeln sich auf demselben Computer).

Aktuelle Fragen

1. Kann ich trotzdem besser mit den unterschiedlichen URLs umgehen? Gibt es etwas, das ich verpasst habe und bei dem die URL fest in die Datenbank codiert ist?

2. Irgendwelche Fallstricke, die ich beim Symlinking beachten sollte?

3. Gibt es noch andere Probleme, an die jemand denken kann?

Mir ist klar, dass diese Fragen sehr spezifisch sind. Wenn etwas unklar ist, kommentieren Sie dies und ich werde es ändern / klären.

Vielen Dank.

Ich werde Frage 2 beantworten. Beachten Sie, dass einige Werte in der Datenbank in serialisierten Arrays gespeichert sind. Wenn sich beispielsweise die Länge Ihrer URL-Zeichenfolge ändert und sie sich in einem serialisierten Array befindet, müssen Sie den Index dafür aktualisieren.

Mit diesem PHP-Skript können Sie alle Werte in serialisierten Arrays aktualisieren oder über die Befehlszeile in Ihrem eigenen Skript ausführen

Frage 1: Sie haben URLs, die an mehr Stellen als nur im Inhalt des Beitrags in die Datenbank ein- und ausgehen. Ich habe URLs in *_postmeta, *_commentsund *_options(zusätzlich zu den von Ihnen definierten) gefunden. Dies gilt nicht für Plugin-Aktivitäten und benutzerdefinierte Meta-Feld- Aktivitäten.

Frage 2: Ich werde auch manchmal Symlink-Plugins verwenden, um die Arbeit zu vereinfachen, und meistens funktioniert es. Manchmal nicht. Ich kann Ihnen die genauen Bedingungen, die ein Problem verursachen, nicht sagen, aber Javascript scheint ein Faktor zu sein.

Frage 3: Ich würde Probleme mit dem *_optionsTisch erwarten, wenn überhaupt. Dinge wie aktivierte Plugins und das aktive Thema bleiben dort erhalten, neben vielen anderen Informationen sind sie ziemlich ortsspezifisch.