вопрос
Я собираюсь начать разработку WordPress в многопользовательской командной среде. (3 или более человек работают над одной и той же кодовой базой одновременно, каждый разрабатывает локально)
С другими CMS, с которыми мы работали, каждый указал свои установки на одну и ту же базу данных, и из-за того, как работала эта CMS / база данных, это означало, что у всех нас может быть одинаковый контент, поступающий в наши установки (расположенные по разным URL-адресам) от та же база данных без особых проблем (за исключением случаев, когда приходится синхронизировать загружаемые папки)
Мой вопрос, с WordPress, что мешает нам использовать этот же подход и как мы можем решить эти проблемы?
например. Три копии WordPress работают на одной базе данных.
http: //dev.local/developer-a/
http: //dev.local/developer-b/
http: //dev.local/developer-c/
так далее
Я надеюсь, что само собой разумеется, что это будет только в среде разработки до запуска.
Главные проблемы
- Ссылки на конкретные URL в базе данных (
wp_posts
иwp_options
таблицы, кажется) - Если один человек устанавливает плагин, другой не будет иметь его и вызовет проблемы параллелизма в базе данных
- Синхронизация загружаемых папок
Текущее решение
В настоящее время у меня есть начало решения для первой проблемы на месте. Я помещаю следующее в файл в моей папке mu-plugins.
Код по существу фильтрует содержимое публикации по мере ее поступления в базу данных и из нее, заменяя любой экземпляр URL уникальным токеном.
<?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');
Я установил параметры home и siteurl через php, используя среду, в которой установлен WordPress, чтобы решить их. (опять же, это только для разработки). Это означает, что для каждой отдельной установки WordPress пост-контент будет выглядеть так, как будто он работает по этому URL-адресу к тому времени, когда он попадает к клиенту.
<?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');
}
Вторая и третья проблемы кажутся решаемыми с помощью соответствующих символических ссылок (все они развиваются на одной машине)
Актуальные вопросы
Могу ли я в любом случае улучшить обработку разных URL? Есть ли что-то, что я пропустил, чтобы URL был жестко закодирован в базу данных?
Любые ошибки, которые я должен знать о символической ссылке?
Любые другие вопросы, которые могут возникнуть
Я понимаю, что эти вопросы являются очень конкретными, если что-то неясно, прокомментируйте это, и я внесу поправки / уточнения.
Спасибо.
источник
Вопрос 1: У вас есть URL-адреса, входящие и выходящие из базы данных в большем количестве мест, чем просто содержание публикации. Я нашел URL-адреса в
*_postmeta
,*_comments
и*_options
(в дополнение к тем, которые вы определили). Это не считая активности плагинов и активности пользовательских мета-полей .Вопрос 2: я также иногда буду плагинов symlink для удобства, и большую часть времени это работает. Иногда это не так. Я не могу сказать вам точные условия, которые вызывают проблему, но Javascript, кажется, является фактором.
Вопрос 3: я бы ожидал проблемы со
*_options
столом, если что-нибудь. Здесь хранятся такие вещи, как активированные плагины и активная тема, а также много другой информации, относящейся к конкретному сайту.источник