Мультисайтинг на Drupal 7 с использованием поддиректорий вместо доменов

В рамках одного из последних проектов потребовалось развернуть независимую англоязычную копию сайта. Многоязычного решения (привет, http://drupal.org/project/i18n) не требовалось, потому что структура сайтов планировалась очень разная (проще говоря, при большом основном сайте нужна временная небольшая английская версия).

Разворачивать две инсталляции Друпала — было бы позором. Ибо поддерживать такой огород в дальнейшем — не реально. Очевидный выход — мультисайтинг. Но нюанс был в том, что заказчик хотел видеть английскую версию не на поддомене, а хотел — в поддиректории (в подпапке).

Примерно так:

  • Адрес основной версии сайта — example.com
  • Адрес дополнительной английской версии — example.com/en/

Оказывается, что Drupal 7 из коробки умеет и такой мультисайтинг.

Все наши заботы ограничились следующим:

1. Переименовываем директорию с настройками основного сайта:

mv sites/default sites/example.com

2. Создаем символическую ссылку с бывшей default на новую директорию:

ln -s sites/example.com sites/default

Симлинк нужен для того, чтобы все файлы, которые лежали у вас прежде в ./sites/default/files продолжили нормально открываться по старым ссылкам (а не превратились в 404-ые ошибки). Как вариант, можно не делать симлинк, а настроить переадресацию в .htaccess с 301-ым кодом. Примерно такой редирект вписывайте в начало .htaccess:

RewriteRule ^sites/default/files/(.*)$ /sites/example.com/files/$1 [R=301,L]

Плюс редиректа перед симлинком на старое хранилище файлов в том, что глядя на 301-ый редирект поисковые системы через какое-то время обновят в своих индексах старые ссылки на новые. Но за вас никто не обновит старые ссылки, которые вы понаставили в контенте.

С основный сайтом — всё готово, займёмся дополнительным.

3. Копируем существующую директорию с настройками сайта:

cp -r sites/example.com/ sites/example.com.en

Обратите внимание: имя для копии задаём example.com.en (т.е. в конец имени мы добавили названия желаемой подпапки).

4. Теперь выставляем права на запись файлу с настройками:

chmod 644 sites/example.com.en/settings.php

Надеюсь, Drupal или вы сами сделали файл доступным только для чтения, как рекомендуется из соображений безопасности.

5. Создаём дамп базы данных основного сайта, заводим новую базу, заливаем в неё дамп. Открываем sites/example.com.en/settings.php в любимом текстовом редакторе и указываем реквизиты доступа к новой базе.

6. Так, теперь создаём ещё одну символическую ссылку, которая и будет выполнять роль поддиректории:

ln -s . en

Обратите внимание, я во всех примерах кода подразумеваю, что команды вы выполняете находясь в корневой директории сайта, соответственно, точка в предыдущей команде — эта текущая директория, т.е. корень сайта. По сути, мы тут сознательно создаём циклическую ссылку.

7. И добавляем, как советуют тут, в .htaccess следующий код сразу после RewriteBase /, чтобы нормально работали ЧПУ:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteCond %{REQUEST_URI} ^/en
RewriteRule ^ en/index.php [L]

Проверяем. Всё работает, включая ЧПУ? Отлично! Радуемся и возвращаем ограниченные права файлу настроек подсайта:

chmod 444 sites/example.com.en/settings.php

Мы теперь имеем два абсолютно независимых сайта: один на основном домене, второй — в поддиректории. У сайтов независимые настройки, независимый контент. А кодовая база — общая. То есть обновив модуль или тему на основной версии, вы «автоматически» получите обновление на дополнительной.

Если вдруг вам потребуется темы и/или модули тоже разделить между сайтами, то раскладывайте их не в sites/all/modules и sites/all/themes, а в директории sites/example.com/modules и sites/example.com.en/modules (sites/example.com/themes и sites/example.com.en/themes). Но даже сделав отдельные темы и модули вы всё равно будете иметь общее ядро, что, как минимум, упрощает процесс его обновления.

Почти всё, что я здесь рассказал, уже написано по-английски в официальной документации.

14 комментариев

  1. Andruxa
    Авг 25, 2012 @ 15:28:17

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

    Добавил бы, что необязательно создавать вторую базу для нового сайта — можно оставить и в одной, с разными префиксами таблиц, причем некоторые можно сделать общими. Прямо в settings.php закомментирован пример, как сделать, чтобы у обоих сайтов были общие пользователи. Но это в зависимости от ситуации, разумеется.

    > То есть обновив модуль или тему на основной версии, вы «автоматически» получите обновление на дополнительной.
    Насчет «автоматически» — только в том случае, если оба сайта используют общие таблицы, иначе — update.php придется запускать на каждом из них.

    Reply

    • kostin
      Сен 01, 2012 @ 01:55:23

      Спасибо за дополнения. Всё по делу. Читателям на заметку.

      Для новичков уточню: вызов update.php актуален только если менялась схема БД.

      Reply

  2. Eugene
    Мар 04, 2013 @ 12:25:31

    Спасибо за статью. Кажется у вас ошибка — вместо «ln -s en .» нужно делать «ln -s . en»

    Reply

    • kostin
      Мар 08, 2013 @ 17:16:06

      Спасибо за замечание. Исправил в статье.

      Reply

  3. finik
    Янв 21, 2014 @ 15:34:35

    в моём случае перестали работать все страницы сайта кроме главной.
    в .htaccess надо писать
    RewriteRule ^ /en/index.php [L]
    вместо
    RewriteRule ^ en/index.php [L]

    Reply

  4. Николай
    Апр 22, 2014 @ 16:06:39

    Здрасти!
    Все делал как вы описали на веб сервере, перенаправление происходило а вот почему то сайт с дубликатом базы не открывался ошибка 500
    Вы могли бы по подробнее описать а то как то не понятно вы описали свои действия, например не понятен пункт 1. 2. и какой то симлинк, куда его ложить и как он должен выглядеть не понятно, с этим все ясно RewriteRule ^sites/default/files/(.*)$ /sites/example.com/files/$1 [R=301,L], 3. опять не понятно какую, куда копируем? 4 и 5 ясно а вот 6. какую символическую ссылку и куда ее пихать? 7. яснее не куда а вот

    Reply

    • kostin
      Апр 22, 2014 @ 16:26:56

      Вам нужно разобраться с тем, что такое символическая ссылка. Грубо говоря, это аналог ярлыка в Windows, но в нашей ситуации по ярлыку будет ходить Apache.

      Во всех командах (и на переименование, и на копирование, и на создание симлинков) пути даны относительные. То есть сначала вы должны зайти в корень сайта (что-то типа cd /var/www/public_html, вы должны оказаться в той директории, где лежит друпаловский index.php), а уж начиная оттуда все команды приобретают смысл.

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

      Для ошибки 500 может быть масса причин. И одна из них в том, что на вашем хостинге могут быть запрещены симлинки. Надо логи смотреть.

      Reply

  5. Николай
    Апр 22, 2014 @ 16:51:35

    Это все хорошо а как быть с продвижением например по анг версии сайта за рубежом, опишу подробнее наша компания имеет представительство в нескольких странах мира — это Сша, Германия, Китай, раньше стояла древняя самописка с языками и переводом, сейчас стоит друпал 7 но только с русской версией, других пока нет, как отнесется google к данному виду мультиязычности?

    Reply

  6. Николай
    Апр 22, 2014 @ 16:55:30

    не лучше ли переносить сайты с конкретным переводом на отдельную площадку, сами домены зарегины, но закрыты от перенаправления, так как нет под них перевода

    Reply

    • kostin
      Апр 22, 2014 @ 17:00:55

      Вы можете использовать вообще отдельные домены для каждого сайта. Можете использовать отдельный поддомен на общем домене для каждого сайта. В перечисленных случаях у Друпала мультисайтинг заработает из коробки.

      Но статья о том, как запустить мультисайтинг на поддиректориях. Такое иногда бывает нужно. Не только для создания иноязычной версии.

      В контексте SEO: если у вас версия под каждый язык огроменная, то лучше действительно разносите на поддомены. Но если на каждом языке по 30-50 страниц, то лучше собирайте в поддиректории. Будет удобнее и аналитику проводить, и в индекс побольше страниц попадёт. Например, Яндекс очень обрадуется.

      Reply

  7. Николай
    Апр 22, 2014 @ 17:04:30

    ну вот например tvema.ru подскажите пожалуйста как быть на лощадки раскидывать и потом маится их обновлять по отдельности или на поддиректории

    Reply

    • kostin
      Апр 23, 2014 @ 10:49:47

      У вас достаточно много страниц в индексе (500+ в Яндексе), поэтому вы можете делать мультисайтинг «из коробки» на поддоменах, типа en.tvema.ru и de.tvema.ru, не заморачиваясь с поддиректориями. При этом кодовая база у вас будет общая (одно ядро, одни модули), обновлять всё сможете централизовано (для того мультисайтинг и придуман).

      Но если у вас сайты будут отличаться только контентом (на разных языках), то я вам вообще рекомендую смотреть в сторону https://drupal.org/project/i18n, о котором в начале поста тоже упоминается.

      Reply

  8. Бурлак
    Июн 05, 2014 @ 23:29:35

    Спасибо за статью, хоть в друпал и не новичок — занес в закладки:)

    Вот сделал я сайт aaportal.ru — у него жесткая спецификация, Архейдж — игра такая, но хочу размещать информацию по другим играм.

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

    Поддиректории — вы пишите что если будет много материала то не супер, а его будет много…

    Отдельные домены — суть теряется…

    Советы есть какие?:)

    Reply

    • kostin
      Июн 06, 2014 @ 09:23:53

      Делайте в поддиректориях.

      Reply

Leave a Reply

*