zypher
  • 0
Новичок

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

  • 0

Я пытался настроить сетевую установку 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 ?

Share
  1. Я почти уверен, что вам придется использовать творческие правила перезаписи и ручное вмешательство DNS. Я также почти уверен, что это сделано специально, чтобы вы не могли передать создание всего, кроме DNS, мнекому-то другомусвистит (:

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

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

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

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

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

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

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

    Шаг второй: создайте файл Sunrise.php в каталоге wp-content. Поставьте <?php сверху для начала.

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

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

    Поскольку вы используете здесь тот же слаг, что и «подкаталог», вам не нужна отдельная таблица. Вы можете просто заглянуть в основную таблицу 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, я тоже могу ответить на вопросы об этом, но ответ будет немного более подробным. 🙂

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

    • 0

Оставить ответ

You must login to add an answer.