Как обещал, продолжаю свой рассказ про процесс перехода на MaxSite CMS. Сегодня про исправление слагов, а также пожелание по совершенствованию движка.

Жил, значит, я на Вордпрессе. Поначалу он как блоговый движок мне полне понравился. Простота установки, настройки, большое количество плагинов и все такое. Тем не менее, со временем кое-что перестало меня устраивать. Главным образом, нагрузка на базу данных и скорость работы, но и помимо этого волновала запутанность системы плагинов, соответственно, потенциальная неустойчивость. В это же время я открыд для себя CodeIgniter, поэтому когда автор русской сборки WordPress заявил о начале создания новой CI-based CMS, я сразу заинтересовался. (Сейчас я являюсь приверженцем Kohana framework, но это все-таки родственные вещи со схожей идеологией.) Сначала следил за развитием системы, когда версия перевалила за 0.20, стал подумывать о переходе.

Первое, что сдерживало -- трудность миграции. В моем блоге к тому времени было немного записей, тем не менее, не хотелось все перебивать вручную. Автоматическую миграцию осложняло то, что мои короткие ссылки имели нестандартный вид: %year%-%month%-%day%-%slug%, а по умолчанию корректно конвертировались только типа %slug%. То есть при автоматической конвертации мои ссылки бы потерялись.
Что ж, когда охота стала пуще неволи, пришлось лезть в код и переделывать его.

Файл application/maxsite/plugins/wpconvert/admin.php, заменил все встреченные

на

Таким образом, при конвертации спереди дописывается дата опубликования поста, что и требуется.

Далее, мне хотелось, чтобы поисковики нашли ссылки в ленте постов в таком же виде, как они и были в WordPress, то есть без указания контроллера 'page' (считайте это моим капризом; если уверюсь в отсутствии штрафа за дубль контента, откажусь). Тут тоже несложно: если у слага впереди есть 200 (первые цифры года), то из ссылки на него убирается сегмент контроллера.
Файл application/maxsite/common/page.php, функция mso_page_title(), заменил 

на


Это же нужно сделать при формировании sitemap.xml.
Файл application/maxsite/plugins/xml_sitemap/index.php, заменил второе встреченное вхождение

на

Все!

Тут же попутно хочу высказать пожелание по движку. Насколько я понял, система позиционируется как предназначенная для пользователя уровнем не ниже "продвинутого". В таком случае, как мне кажется уместно было бы добавить возможность устанавливать патчи. Здесь вижу два немного разных случая.

1. Патч плагина. Иногда оказывается, что человеку нужно чуть-чуть изменить имеющийся плагин, подогнать его под собственные нужды. Самое простое -- ввести исправления непосредственно в код плагина. В таком случае, если автор плагина усовершенствует его, то пользователю нужно будет опять руками перебивать свой кастомный код. Конечно, это страхует от несовместимостей данного кода с новой версией, но все же... Выходом могли бы стать патчи плагинов, реализуемые, например, подобно расширениям библиотек в CodeIgniter. Скажем, пользовательский патч patch_index.php с кастомной реализацией функции patch_plugin_func(), лежащий в папке плагина, перезаписывал бы исходную функцию plugin_func(), ну или как-то в этом роде. Тогда обновление плагина не затронет сам патч.

2. Более сложный вопрос, это патч собственно движка блога. Такая проблема возникает гораздо реже, однако все же случается. В данном случае мне сложно предложить возможный вариант реализации, поскольку движок блога весьма разнороден. Возможно (хотя не обязательно), это было бы тоже полезно для разработчиков, как, впрочем, и для создателя движка.

Продолжение предполгается.