Jak mogę uczynić bazę danych WordPress przenośną i niezależną od adresu URL?

Kwestia

Mam zamiar rozpocząć rozwój WordPress w wieloosobowym środowisku zespołowym. (3 lub więcej osób pracuje jednocześnie na tej samej bazie kodu, każda rozwija się lokalnie)

W przypadku innych CMSów, z którymi współpracowaliśmy, wszyscy wskazali swoje instalacje na tę samą bazę danych, a ponieważ działał ten CMS / baza danych, oznaczało to, że wszyscy możemy mieć tę samą zawartość, która jest zasilana w nasze instalacje (znajdujące się pod różnymi adresami URL) od ta sama baza danych bez większego problemu (oprócz sporadycznej synchronizacji przesyłanych folderów)

Moje pytanie dotyczy WordPressa, co uniemożliwia nam stosowanie tego samego podejścia i jak możemy rozwiązać te problemy?

na przykład. Trzy kopie WordPress, wszystkie uruchamiane z tej samej bazy danych.

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

itp

Mam nadzieję, że będzie to oczywiste, że będzie to tylko środowisko programistyczne przed uruchomieniem.

Główne kwestie

1. Odniesienia do konkretnych adresów URL w bazie danych ( wp_postsi wp_optionswydaje się, że tabele)
2. Jeśli jedna osoba zainstaluje wtyczkę, druga nie będzie jej miała i spowoduje problemy z współbieżnością w bazie danych
3. Synchronizacja przesyłanych folderów

Aktualne rozwiązanie

Obecnie mam początki rozwiązania pierwszego problemu. Umieszczam następujące elementy w pliku w folderze wtyczek mu.

Kod zasadniczo filtruje zawartość postu, gdy wchodzi do bazy danych i wychodzi z niej, zastępując dowolne wystąpienie adresu URL unikalnym tokenem.

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

Ustawiłem opcje home i siteurl przez php, używając środowiska, w którym jest zainstalowany WordPress, aby je wypracować. (ponownie, to jest tylko dla programistów) Oznacza to, że do każdej instalacji WordPressa zawartość posta będzie wyglądać, jakby była uruchomiona na tym adresie URL, zanim dotrze do klienta.

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

Wydaje się, że drugi i trzeci problem można rozwiązać za pomocą odpowiednich dowiązań symbolicznych (wszystkie rozwijają się na tej samej maszynie)

Rzeczywiste pytania

1. Czy mimo to mogę poprawić obsługę różnych adresów URL? Czy jest coś, za czym tęskniłem, a który zapisałby adres URL na stałe w bazie danych?

2. Jakieś problemy, o których powinienem wiedzieć dzięki symlinkowaniu?

3. Czy są jeszcze jakieś inne kwestie?

Zdaję sobie sprawę, że te pytania są bardzo szczegółowe, jeśli coś jest niejasne, skomentuj to, a ja poprawię / wyjaśnię.

Dzięki.

Odpowiem na pytanie 2, należy pamiętać, że niektóre wartości w bazie danych są przechowywane w szeregowanych tablicach. Na przykład, jeśli długość ciągu adresu URL zmienia się i znajduje się on w szeregowanej tablicy, należy zaktualizować dla niego indeks.

Możesz użyć tego skryptu PHP, aby zaktualizować wszystkie wartości w szeregowanych tablicach lub uruchomić go z wiersza poleceń we własnym skrypcie

Pytanie 1: Masz adresy URL wchodzące i wychodzące z bazy danych w większej liczbie miejsc niż tylko treść postu. Znalazłem adresy URL w *_postmeta, *_commentsi *_options(oprócz tych, które zdefiniowałeś). To nie liczy aktywności wtyczki i aktywności niestandardowego pola meta .

Pytanie 2: Czasami będę również podłączać wtyczki dla wygody i przez większość czasu to działa. Czasem tak nie jest. Nie mogę powiedzieć dokładnych warunków, które powodują problem, ale JavaScript wydaje się być czynnikiem.

Pytanie 3: Oczekiwałbym problemów ze *_optionsstołem. Są tam takie rzeczy, jak aktywowane wtyczki i aktywny motyw, wśród wielu innych informacji jest dość specyficzne dla strony.