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

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

Решение:

От весьма заманчивой идеи расплодить на площадке 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 попадаем в админку второго блога? Ничего подобного, почему то мы вновь оказываемся в админке первого блога. Разобраться, в чём дело.

Решение:

Читать далее →