Pull to refresh

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

Reading time5 min
Views636

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


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

Решение:


От весьма заманчивой идеи расплодить на площадке 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 доволен, и мы можем попасть в админки.

Tags:
Hubs:
Total votes 9: ↑5 and ↓4+1
Comments1

Articles