Можем ли мы использовать одну установку WordPress для нескольких баз данных, доменов и каталогов контента

10

Я видел несколько вопросов, которые выглядят одинаково, но все они заканчиваются мультисайтом . Для удобства обслуживания, производительности и безопасности я не хочу использовать мультисайты. Поэтому, пожалуйста, потерпите меня.

Вот о чем я думаю:

.
|_____branch1 // for branch1.domain.com
|  |_____themes
|  |_____plugins
|
|_____branch2 // for branch2.domain.com
|  |_____themes
|  |_____plugins
|
|_____branch3 // for branch3.domain.com
|  |_____themes
|  |_____plugins
|
|_____index.php
|_____WordPress
|_____wp-config.php

Как видите, каждый домен имеет свою собственную базу данных и каталог контента, но только один экземпляр WordPress. Теперь темы, плагины и базы данных становятся меньше и независимее. Тогда было бы гораздо проще поддерживать масштабирование ...

Но возможно ли это? Если вы уже сталкивались с такой же проблемой, пожалуйста, поделитесь своими мыслями! Я действительно ценю твою помощь.

SarahCoding
источник
1
Почему исключено использование нескольких сайтов? Для этого потребуется создать хрупкую систему, которая будет менее удобна в обслуживании, чем мультисайты, будет иметь более низкую производительность, чем мультисайты, и хуже, чем мультисайты. Некоторые из самых крупных установок WordPress - это многосайтовые установки, и это все тот же код, который выполняется на стандартном одном сайте
Том Дж. Новелл
Я управляю множеством мультисайтов WP, в том числе более 500 под-сайтов. Производительность будет одинаковой независимо от того, используете ли вы один мультисайт или 500 экземпляров WP, если у вас нет 500 экземпляров на отдельных виртуальных машинах и базах данных. Ремонтопригодность отстой с мультисайта? Попробуйте сохранить 500 количество отдельных сайтов.
user42826
@ TomJNowell Я не уверен, что эта самая большая установка использует только одну базу данных, но я думаю, что это и это видео могут привести нас к той же странице. В основном мы используем WordPress для CRM, и конфиденциальность пользователей очень важна.
SarahCoding
@ user42826 В настоящее время в моей компании не так много сайтов. Я также не могу преобразовать текущий сайт в мультисайт и сравнить его. И оборудование и другие вещи могут отличаться от вас. Поэтому я просто хочу спросить об оптимальной архитектуре установки в моем случае. Насколько я знаю, мультисайт работает с поддоменами, но не может работать для разных доменов.
SarahCoding
Мультисайт работает с разными доменами. Мы используем основной домен * .domain.com и несколько других доменов www.domain2.com и www.domain3.com. Мы используем плагин для сопоставления доменов WP для создания мультидоменов, но из того, что я слышал, ядро ​​WP теперь поддерживает многодоменное сопоставление.
user42826

Ответы:

10

Как сказал @ tom-j-nowell в комментарии к OP, мультисайты могут сделать это проще.

Производительность и безопасность на самом деле не являются проблемой для мультисайтов (по крайней мере, не больше, чем для обычных установок), но я согласен, что мультисайты иногда могут быть проблемой, потому что многие плагины (как пользовательские, так и сторонние) могут не правильно работать на мультисайтах, или, может быть, потому, что вы хотите полностью разделить пользователей разных сайтов.

Тем не менее, то, что вы хотите достичь, не так сложно.

Что вам нужно изменить между установкой:

  • папка плагинов
  • папка тем
  • настройки базы данных

Конфигурирование может быть выполнено с использованием констант.wp-config.php Единственная проблема в том, как их переключать на основе URL.

Переменная сервера 'SERVER_NAME'должна работать для вас, по крайней мере, если ваш веб-сервер настроен правильно.

Например, вы можете создать папку с именем /confна том же уровне wp-config.phpфайла и /WordPressпапки.

В эту папку вы можете добавить несколько файлов:

  • branch1.domain.com.conf
  • branch2.domain.com.conf
  • branch3.domain.com.conf

внутри каждого из них вы можете сделать что-то вроде

$branch = 'branch1';
$base_dir = dirname( __DIR__) . "/{$branch}";

defined( 'WP_CONTENT_DIR' ) or define( 'WP_CONTENT_DIR', $base_dir );

// be sure WP understand URLs correctly
defined( 'DB_HOME' ) or define( 'DB_HOME', "{$branch}.example.com" );
defined('WP_SITEURL') or define('WP_SITEURL', "{$branch}.example.com/WordPress");

// adjust DB settings  as needed
defined( 'DB_NAME' ) or define( 'DB_NAME', $branch );
defined( 'DB_USER' ) or define( 'DB_USER', $branch );
defined( 'DB_PASSWORD' ) or define( 'DB_PASSWORD', '********' );

unset( $base_dir, $branch );

Это изменится в каждом файле конфигурации в соответствии с «веткой».

После этого в вашем уникальном wp-config.phpможно так что-то вроде:

$defaults_conf = [
  'WP_CONTENT_DIR' => __DIR__ . '/branch1',
  'DB_HOST'        => 'localhost',
  'DB_NAME'        => 'branch1',
  'DB_USER'        => 'branch1',
  'DB_PASSWORD'    => '********',
];

$host = getenv('WORDPRESS_HOST') ?: $_SERVER['SERVER_NAME'];

if ($host && file_exists(__DIR__."/conf/{$host}.conf")) {
  require __DIR__."/conf/{$host}.conf";
}

array_walk($defaults_conf, function($value, $name) {
   defined($name) or define($name, $value);
});

unset($defaults_conf, $host);

Выше происходит то, что на основе имени сервера вы загружаете другой файл конфигурации (если он найден), и если файл конфигурации не определяет какую-либо конфигурацию по умолчанию (или файл не найден), конфигурация устанавливается по умолчанию.

Приятно то, что для добавления новой ветки вам просто нужно создать папку ветки и указать .confимя для нового домена ветки, и все готово, на стороне WP нечего менять.

Линия:

 $host = getenv('WORDPRESS_HOST') ?: $_SERVER['SERVER_NAME'];

где я получаю доменное имя. В качестве первого варианта я использую переменную среды, поскольку есть вероятность, что $_SERVER['SERVER_NAME']она не будет работать в контексте командной строки, например, при использовании WP CLI. В этих ситуациях вы можете установить переменную окружения, чтобы заставить WP использовать настройки из определенной ветви.

Обратите внимание, что в специфичных для ветви файлах конфигурации я изменяю WP_CONTENT_DIRи автоматически устанавливаю папку плагинов и тем в соответствующие подпапки /pluginsи /themesподпапки веток.

Возможная проблема здесь, если вы хотите открыть общий доступ к /uploadsпапке (куда загружаются файлы).

По умолчанию эта папка является подпапкой каталога содержимого, поэтому при использовании рабочего процесса над ней она будет /uploadsподпапкой корневой папки каждой ветви.

Если это не проблема для вас, а просто пойти на это, в противном случае самым простым решением будет сделать /uploadsв каждой папке ветки символическую ссылку на папку реальных загрузок, которой вы хотите поделиться.

Gmazzap
источник
Спасибо! Мне очень нравится твоя идея, хотя $_SERVER['SERVER_NAME']она ненадежна . /uploadsреж не проблема. Я также проверил с WP CLI, если мы передаем --urlпараметр для каждого сайта, он работает нормально :)
SarahCoding
1
@ Я сказал в ответ: «Серверная переменная« SERVER_NAME »должна работать для вас, по крайней мере, если ваш веб-сервер настроен правильно». Это означает, что вам нужно правильно настроить свой сервер :) На самом деле, пока вы настраиваете server_nameв nginx или ServerNameв Apache или что-то еще, что подходит для вашего веб-сервера, это $_SERVER['SERVER_NAME']будет просто работать. Даже если WP CLI может работать с использованием --urlпараметров, другие инструменты командной строки могут иметь проблемы, если вы не используете переменную окружения. WP CLI «макетирует» URL запроса в контексте CLI, другие команды, вероятно, этого не сделают.
gmazzap
1
Конечно, я позабочусь, чтобы SERVER_NAMEвсе было настроено правильно. О env vars, я использовал phpdotenv, чтобы это исправить. В настоящее время, кажется, все работает отлично :)
SarahCoding
0

Это возможно с помощью символической ссылки и небольшого планирования. Я сделал кое-что в сети для того же. Наконец, соберите все вещи, и все заработало.

Я запустил несколько сайтов, все они используют одну и ту же тему и папку плагинов. Одни и те же папки работают для мультисайтовых и одиночных сайтов. Но вы должны быть осторожны с определенными плагинами, которые могут быть только для Multi / Single site и быть странными.

Я сделал каталог как master-tnp / themes и master-tnp / plugins. Затем сделайте символическую ссылку на каталог WordPress с помощью команды ln -s.

Подводные камни также в конфигурациях сервера. Убедитесь, что директива «следовать символическим ссылкам» разрешена.

Если вы хотите использовать одну установку WordPress, я собрал подробное руководство о том, как я это сделал, по адресу https://vaish.co/multiple-sites-single-wordpress-directory

Cpyder
источник