Мультивордпрессинг

Условия задачи:

• Создать несколько однотипных блогов.
• Блоги должны поддерживать удалённую публикацию.

Решение:

От весьма заманчивой идеи расплодить на площадке MaxSite CMS пришлось отказаться сразу, из за отсутствия пока что в нём возможностей удалённой публикации. Точнее, она уже присутствует, но разработанная по стандартам автора и с его же собственным клиентом под Windows.

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

Таким образом я пришёл к Movable Type. Платформа написана на perl и является законодателем моды: именно в ней впервые появиласись технологии OpenID, Trackback и многие другие. Одно из главных преимуществ Movable Type — статическая публикация контента. То есть, страницы не генерируются для пользователя скриптами в момент обращения к серверу, а создаются как старые добрые html-файлы. Одна установка системы теоретически способна обслуживать тысячи блогов на разных доменах, поддоменах, подкаталогах — везде в пределах файловой системы сервера. Так как страницы будут статическими — Digg эффект сервер переживёт.

Из главного достоинства вытекают и главные недостатки. При публикации блога или полной перепубликации в случае смены дизайна вы будете обречены часами смотреть на сообщения вроде: «Публикация записи 2 из 7890».

Админка работает медленно. Крайне медленно. На виртуальном хостинге пользоваться оказалось крайне затруднительно. Сложности возникли и с комментариями – так как хостер не давал доступ к  httpd.conf, алиасы для скриптов прописать не удалось.

Стал экспериментировать с WordPress MU — многопользовательской редакцией. Проблем при установке возникло не меньше, чем с Movable Type. Дело в том, что MU расчитан на блоги либо в подкаталогах, либо в субдоменах. А вот с работой на отдельных доменах опять же возникает проблема. Найденные пути решения при помощи плагинов оказались не без проблем. Другое решение тоже предполагало правку httpd.conf…Финальное решение, как всегда, было простым и изящным.

Установить один раз обычный WordPress на один из доменов, а остальные домены сделать его алиасами. В конфиге изменить жёсткий префикс имён таблиц MySql c ‘wp_’ на динамический, создаваемый на основе $_SERVER[‘HTTP_HOST’]. Найденный кусок кода выглядел так:

$prefix = $_SERVER[«HTTP_HOST»];
$prefix = str_replace(«www.», «», $prefix);
$prefix = str_replace(«-«, «», $prefix);
$prefix = str_replace(«.», «», $prefix);
$table_prefix = $prefix.»_» ; //»wp_»;

Я только заменил str_replace на ereg_replace(“www.|-|.”,””,$prefix).

В паранояльном варианте можно задавать префиксы вида md5($_SERVER[‘HTTP_HOST’].$salt) или вовсе по условиям.

Ещё одна подсказка. При интеграции существующего блога в эту сборку обязательно возникнут проблемы с доступом в админку. В этом случае переименуйте в таблице prefix_options название опции “wp_user_roles” на “prefix_user_roles”, и в таблице “prefix_usermeta” аналогичным образом переименуйте все опции, начинающиеся со старого префикса “wp_”.

Условия задачи:

Имеем один домен, на который установлен WordPress и несколько доменов-алиасов(синонимов) к нему. Ну например, domain.ru как основной домен и alias.ru как его алиас. Так вот, пройдя по ссылке http://domain.ru/wp-admin попадаем в админку первого блога. Соответственно, пройдя по ссылке http://alias.ru/wp-admin попадаем в админку второго блога? Ничего подобного, почему то мы вновь оказываемся в админке первого блога. Разобраться, в чём дело.

Решение:

Проблема вытекает из особенностей работы модуля mod_dir апача. Выдержка из документации:

The index of a directory can come from one of two sources:

• A file written by the user, typically called index.html. The DirectoryIndex directive sets the name of this file. This is controlled by mod_dir.
• Otherwise, a listing generated by the server. This is provided by mod_autoindex.

The two functions are separated so that you can completely remove (or replace) automatic index generation should you want to.

A «trailing slash» redirect is issued when the server receives a request for a URL http://servername/foo/dirname where dirname is a directory. Directories require a trailing slash, so mod_dir issues a redirect to http://servername/foo/dirname/

Суть в том, что если происходит запрос директории, а не файла на сервере и запрос не оканчивается слэшем, то модуль автоматически переадресует запрос на тот-же адрес, но добавив слэш в конце. Это не баг, это весьма неудобная фича. Называется она trailing slash redirect.

А в случае домена — алиаса он заодно и заменяет имя алиаса на имя основного домена. Поэтому если мы ко второму запросу добавим в конце слэш, то попадём в админку второго блога, а если нет — то нас перебросит в админку первого.

Для окончательного решения вопроса необходимо внести некоторые правки во всеми нами любимый файл .htaccess. В моём случае он сгенерирован WordPress при включении опций показа ЧПУ (человеком понятных URL) и выглядит так:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Синтаксис .htaccess достаточно прост. Директива RewriteEngine On означает, что мы включили обработку механизма преобразований. RewriteBase — это базовый URL для преобразований относительно данной директории.

RewriteCond — это условия преобразований, логика работы. Первый параметр — сравниваемая строка, второй — условие. В качестве сравнивaемых строк используются обычно переменные сервера. Например — REQUEST_FILENAME путь к запрошенному файлу в файловой системе сервера. Условие !-f означает, что запрос файлом не является, а !-d — что не является директорией. Соответственно, две строки RewriteCond говорят модулю, что последующие действия должны быть выполнены, если запрошены не реально существующие файл или директория.

RewriteRule — это непосредственно правило преобразования. Именно оно выполнится в нашем случае, если два условия RewriteCond будут истинны. Синтаксис прост — первый параметр — шаблон, второй — подстановка. В шаблоне нам доступна вся мощь регулярных выражений языка Perl, о которых я упоминал в прошлый раз, и без знания которых в веб-разработку лучше не соваться. Тем более больше дня их изучение в необходимом объёме не займёт.

Итак, добавляем ещё два условия:

RewriteCond %{REQUEST_FILENAME} -d 
RewriteCond %{REQUEST_URI} !^%{HTTP_HOST}$

Первое, как уже понятно, истинно в случае если запрос ведёт к директории. Во втором используются ещё две переменные сервера — REQUEST_URI — сам запрос и HTTP_HOST — имя сервера. Второе условие истинно, если запрос не равен имени сервера. То есть если запрос ведёт к подкаталогу сервера, то условие тоже истинно.

Теперь добавим правило редиректа.

RewriteRule ^(.+[^/])$ http://%{HTTP_HOST}/$1/ [R]

В шаблоне используется простое регулярное выражение. ^ и $ означают проверки на начало и конец строки, . — проверка на любой символ, квантор + в отличие от квантора * (звезды Клина) выражает один или более экземпляр предыдущего выражения, таким образом .+ означает любую сколь угодно длинную последовательность символов, числом более единицы. Квадратные скобки [] — определяют символьный класс, а ^ объявляет исключающий класс. Таким образом [^/] — исключающий символьный класс литерала /.

Всё выражение означает: строка начинается любым символ числом от единицы до бесконечности и оканчивается любым символом не являющимся литералом /. То есть просто строка, не заканчивающаяся слэшем. Шаблон замены правила создан. Теперь рассмотрим, на что заменяем эту строку.

Префикс http:// понятен, переменная имени сервера тоже. / здесь означают сами себя, а вот с $1 интереснее.

$X это обратная связь директивы RewriteRule, предоставляющая доступ к сгруппированным частям шаблона RewriteRule с порядковым номером X. Группируются они круглыми скобками, в нашем случае первой и единственной группой является (.+[^/]).

В итоге правило перебрасывает любой запрос, являющийся запросом к существующей директории, но не ограниченный бэкслэшем на http://имя.сервера/этотзапрос/. закрывающийся как раз / — mod_dir доволен, и мы можем попасть в админки.