Настройка сети WordPress с доменами третьего уровня

Я пытался настроить сетевую установку WordPress. Все шло довольно гладко, пока я не дошел до того, что желаемая структура домена не подходит.

Я хотел бы иметь макет следующим образом:

блог. *. stackexchange.com

так, например, я хотел бы иметь несколько сайтов в сети, которые выглядят так:

blog.wordpress.stackexchange.com
blog.apple.stackexchange.com
blog. $ site.stackexchange.com

Я думаю, я мог бы заставить это работать с некоторыми творческими правилами переписывания и ручным вмешательством DNS, но я бы предпочел настройку, где я могу передать создание всего, кроме DNS, кому-то еще (у нас уже есть процесс для автоматического создание всех поддоменов, необходимых в DNS)

Из моей игры и чтения WP действительно хочет, чтобы сайты были доменом следующего уровня, поэтому в моем приведенном выше примере он хочет, чтобы основной блог WP был на stackexchange.com, а сетевые блоги - на wordpress.stackexchange.com.

Есть ли способ достичь желаемого эффекта или я должен просто пойти по пути ведения blog.stackexchange.com/$site?

Вы можете использовать плагин Domain Mapper для этого. Недостатком является то, что вы должны вручную настроить каждый подблог.

Вы можете сделать это с помощью настроенного файла sunrise.php. По сути, это то, как работает плагин для сопоставления доменов, однако он делает его довольно привлекательным. Для чего-то особенного, вы можете написать простой PHP, чтобы сделать в основном то же самое.

Суть мультисайта заключается в том, чтобы выяснить, какой сайт обслуживать. Плагин «Сопоставление доменов» делает это, создавая таблицу wp_domain_mapping и сохраняя там информацию. Таким образом, когда он получает запрос на xxx.com, он просматривает эту таблицу и видит, что это соответствует blog_id 123.

Сначала настройте WordPress и сделайте его мультисайтовым. Неважно, где он действительно живет, потому что мы собираемся все это изменить. Для простоты я разместил бы его на blog.stackexchange.com и сделал бы его сайтом типа подкаталога (это проще). Созданные подкаталоги, скорее всего, будут слизнями. / WordPress, / Apple, / что угодно.

Так что, да, для начала, вы действительно делаете это на blog.stackexchange.com/wordpress. Считайте, что это ваша постановочная среда. Когда вы создаете каждый сайт, вы можете что-то делать с ним, пока не решите включить отображение.

Чтобы сделать сопоставление доменов самостоятельно, без плагина, вы должны сделать что-то вроде этого:

Шаг первый: добавьте define( 'SUNRISE', 'on' );в начало вашего файла wp-config.php.

Шаг второй: создайте файл sunrise.php в каталоге wp-content. Положите <?phpсверху, чтобы начать с.

Шаг третий: в файле sunrise.php будет ваша логика для определения, какой сайт загрузить.

Вы собираетесь основывать это на $_SERVER[ 'HTTP_HOST' ]переменной. Как именно вы это делаете, легко: как бы вы этого не хотели. Если вы хотите просто написать регулярное выражение для поиска, '/blog\.(.*)\.stackexchange\.com/'а затем найти этот бит в базе данных, вы можете сделать это.

Поскольку вы используете тот же самый slug здесь, что и «подкаталог», вам не нужна отдельная таблица. Вы можете просто заглянуть в основную таблицу wp_blogs и найти нужный вам сайт. Что-то похожее на это:

$current_blog = $wpdb->get_var( "SELECT blog_id FROM {$wpdb->blogs} WHERE path = '/wordpress/' LIMIT 1" );

Если у вас есть $ current_blog, вам понадобится следующий код:

$current_blog->domain = $_SERVER[ 'HTTP_HOST' ];
$current_blog->path = '/';
$blog_id = $current_blog->blog_id;
$site_id = $current_blog->site_id;
$current_site = $wpdb->get_row( "SELECT * from {$wpdb->site} WHERE id = '{$current_blog->site_id}' LIMIT 0,1" );
$current_site->blog_id = $current_blog->blog_id;

Это предварительно определяет глобальные переменные $ current_blog и $ current_site вместо того, чтобы позволить функциям MU WordPress делать это.

Этого будет достаточно, чтобы сайт заработал и заработал (после того, как ваш DNS указал на него и разбирался с материалами виртуального хостинга), однако большинство статических URL-адресов, используемых в коде HTML, все равно будут указывать на blog.stackexchange.com / WordPress, так как это то место, где действительно будет сайт. Кроме того, функция канонического URL, вероятно, не понравится URL и перенаправит вас тоже.

Чтобы устранить эти проблемы, вы также можете заранее определить несколько URL-адресов, связанных с сайтом. Такие вещи, как WP_SITEURL и WP_HOME. Также WP_CONTENT_URL, WP_PLUGIN_URL и WPMU_PLUGIN_URL. Это должно охватывать большинство случаев корректировки URL-адресов.

Наконец, вы хотите установить 'COOKIE_DOMAIN'. Поскольку вы, вероятно, хотите, чтобы логины были общими для всего этого, вы можете установить его на stackexchange.com или даже выше, если не хотите, чтобы они были общими логинами.

Если вы хотите поговорить об интеграции обычной системы входа в систему stackexchange в WordPress, я тоже могу ответить на вопросы, но это будет более подробный ответ. :)

Не стесняйтесь, напишите мне, если вам нужна дополнительная помощь с этим. Рад помочь: отто на wordpress.org.