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

Блоги должны поддерживать удаленную публикацию.

Решение: От очень заманчивой идеи создания на сайте CMS MaxSite пришлось сразу отказаться, ввиду отсутствия в ней возможностей удаленной публикации.

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

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

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

Таким образом я пришел к Подвижный тип .

Платформа написана на Perl и является законодателем моды: именно в ней впервые появились технологии.

OpenID , Трекбек и многие другие.

Одним из главных преимуществ Movable Type является статическая публикация контента.

То есть страницы не генерируются для пользователя скриптами в момент обращения к серверу, а создаются как старые добрые html файлы.

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

Поскольку страницы будут статическими, сервер Digg выдержит этот эффект. Основные преимущества также приводят к основным недостаткам.

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

Админ работает медленно .

Чрезвычайно медленно.

Пользоваться виртуальным хостингом оказалось крайне сложно.

С комментариями тоже возникли сложности — поскольку хостер не предоставил доступ к httpd.conf, прописать алиасы для скриптов не удалось.

Я начал экспериментировать с Вордпресс МУ - многопользовательское издание.

Проблем при установке было не меньше, чем с Movable Type. Дело в том, что MU предназначен для блогов либо в подкаталогах, либо в поддоменах.

А вот с работой на отдельных доменах снова возникает проблема.

Решения, найденные с помощью плагинов, оказались не без проблем .

Другое решение также потребовалось редактирование httpd.conf. Окончательное решение, как всегда, было простой и элегантный .

Установите обычный Wordpress один раз на один из доменов, а остальным доменам сделайте псевдонимы.

В конфигурации измените жесткий префикс имен таблиц MySql с «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) или даже по условиям.

Еще одна подсказка.

При интеграции существующего блога в эту сборку обязательно возникнут проблемы с доступом к админ-панели.

В этом случае переименуйте имя опции «wp_user_roles» в таблице prefix_options на «prefix_user_roles», а в таблице «prefix_usermeta» аналогичным образом переименуйте все опции, начинающиеся со старого префикса «wp_».

Условия задачи: У нас есть один домен, на котором установлен Wordpress и несколько доменов-псевдонимов (синонимов) к нему.

Ну, например, domain.ru в качестве основного домена и alias.ru в качестве его псевдонима.

Итак, пройдя по ссылке http://domain.ru/wp-admin Попадаем в админку первого блога.

Соответственно, перейдя по ссылке alias.ru/wp-admin мы попадем в админку второго блога? Ничего подобного, мы почему-то снова попадаем в админку первого блога.

Это не баг, это очень неудобная функция.

Это называется перенаправление с косой чертой в конце .

А в случае домена-псевдонима он также заменяет имя псевдонима именем основного домена.

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

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

htaccess. В моем случае он был создан Wordpress путем включения параметров отображения ЧПУ (удобочитаемые URL-адреса) и выглядит следующим образом:

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

/index.php [L] </IfModule>

Синтаксис .

htaccess довольно прост. Директива Перезаписать двигатель включен означает, что мы включили обработку механизма преобразования.

Переписать базу — это базовый URL для преобразований относительно этого каталога.

RewriteCond — это условия трансформации, логика работы.

Первый параметр — это сравниваемая строка, второй — условие.

Переменные сервера обычно используются в качестве сравниваемых строк.

Например - REQUEST_FILENAME путь к запрошенному файлу в файловой системе сервера.

Состояние !-ф означает, что запрос представляет собой файл Нет есть, и !-д - который не является каталогом.

Соответственно, две строки RewriteCond сообщите модулю, что последующие действия следует выполнять, если запрошенный файл или каталог на самом деле не существует. ПерезаписатьПравило является непосредственно правилом преобразования.

Именно это и будет верно в нашем случае, если два условия RewriteCond будет правдой.

Синтаксис простой — первый параметр — шаблон, второй — подстановка.

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

Причём их изучение в необходимом объёме не займёт больше суток.

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

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

Первое, как уже понятно, справедливо, если запрос ведет в каталог.

Второй использует еще две серверные переменные — REQUEST_URI - сам запрос и HTTP_HOST - имя сервера.

Второе условие истинно, если запрос не равен имени сервера.

То есть, если запрос ведет в подкаталог сервера, то условие также истинно.

Теперь давайте добавим правило перенаправления.

RewriteRule ^(.

+[^/])$ %{HTTP_HOST}/$1/ [R]

В шаблоне используется простое регулярное выражение.

^ И $ означает проверку начала и конца строки, .

— проверить наличие любого символа, квантора + в отличие от квантора * (звездочка-клин) выражает один или несколько экземпляров предыдущего выражения, таким образом .

+ означает любую произвольно длинную последовательность символов с номером больше единицы.

Квадратные скобки [] - определить класс персонажа и ^ объявляет эксклюзивный класс.

Таким образом [^/] - эксклюзивный литерал класса символов / .

Все выражение означает: строка начинается с любого номера символа от единицы до бесконечности и заканчивается любым символом, не являющимся литералом.

/ .

То есть просто строка, не заканчивающаяся косой чертой.

Шаблон правила замены создан.

Теперь давайте посмотрим, на что мы заменим эту строку.

Префикс http:// Я понимаю, переменная имени сервера тоже.

/ здесь они имеют в виду самих себя, но с $1 интереснее.

$X это директивная обратная связь ПерезаписатьПравило , который обеспечивает доступ к сгруппированным частям шаблона ПерезаписатьПравило с серийным номером Икс .

Они сгруппированы круглыми скобками; в нашем случае первая и единственная группа — это (.

+[^/]) .

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

имя_сервера/этот запрос .

закрываюсь только что / — mod_dir рад, и мы можем попасть в админку.