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

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

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

Файл application/maxsite/plugins/wpconvert/admin.php, заменил все встреченные
$slug_new = mso_slug($slug);
на
$slug_new = mso_slug($slug);
                           
$cdate = explode(' ', $item['wp']['post_date']);
$slug_new = $cdate[0].'-'.$slug_new;
Таким образом, при конвертации спереди дописывается дата опубликования поста, что и требуется.

Далее, мне хотелось, чтобы поисковики нашли ссылки в ленте постов в таком же виде, как они и были в WordPress, то есть без указания контроллера 'page' (считайте это моим капризом; если уверюсь в отсутствии штрафа за дубль контента, откажусь). Тут тоже несложно: если у слага впереди есть 200 (первые цифры года), то из ссылки на него убирается сегмент контроллера.
Файл application/maxsite/common/page.php, функция mso_page_title(), заменил 
$out = '<a href="' . $MSO->config['site_url'] . $type . '/' . $page_slug . '" title="' . mso_strip($page_title) . '">' . $page_title . '</a>';
на
if($type == 'page'){
        if((strpos($page_slug,'200') === false) OR (strpos($page_slug,'200') > 0)){
            $out = '<a href="' . $MSO->config['site_url'] . $type . '/' . $page_slug . '" title="' . mso_strip($page_title) . '">' . $page_title . '</a>';
        } else {
            $out = '<a href="' . $MSO->config['site_url'] . $page_slug . '" title="' . mso_strip($page_title) . '">' . $page_title . '</a>';
        }
    }
}

Это же нужно сделать при формировании sitemap.xml.
Файл application/maxsite/plugins/xml_sitemap/index.php, заменил второе встреченное вхождение
$out .= $t . $t . '<loc>' . $url . 'page/' . $row['page_slug'] . '</loc>' . NR;
на
if((strpos($row['page_slug'],'200') === false) OR (strpos($row['page_slug'],'200') > 0)){
    $out .= $t . $t . '<loc>' . $url . 'page/' . $row['page_slug'] . '</loc>' . NR;
} else {
    $out .= $t . $t . '<loc>' . $url . $row['page_slug'] . '</loc>' . NR;
}
Все!

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

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

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

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