Условия задачи:
- Создать несколько однотипных блогов.
- Блоги должны поддерживать удалённую публикацию.
Решение:
От весьма заманчивой идеи расплодить на площадке 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 попадаем в админку первого блога. Соответственно, пройдя по ссылке 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 servername/foo/dirname where dirname is a directory. Directories require a trailing slash, so mod_dir issues a redirect to 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. Группируются они круглыми скобками, в нашем случае первой и единственной группой является (.+[^/]).
В итоге правило перебрасывает любой запрос, являющийся запросом к существующей директории, но не ограниченный бэкслэшем на имя.сервера/этотзапрос. закрывающийся как раз / — mod_dir доволен, и мы можем попасть в админки.