Про wp-hashed-id

Есть такой плагин. Добавляет тег %hashed_id% в настройки постоянных ссылок, после чего они могут выглядеть вот так: atrax.ru/aDfcw. Коротко, удобно и не превращаются в punicode ад при попытки скопировать ссылку в коммуникатор.

Я по наивности своей думал, что это какой-нибудь base62 (отсутствие цифр в ссылках меня не смутило и было списано в случайность) и в код смотреть я не стал. Как оказалось зря…

Время шло, плагин устаревал и наконец перестал работать. «Печаль», вздохнул я, отключил его и попытался все это дело раскодировать. Вот тут-то все и началось.

Блог к тому времени порядочно подрос и внутренних ссылок стало больше, чем могло вместиться в поле моего зрения. Периодически я исправлял бросающиеся в глаза ссылки, иногда начинал планомерно вычитывать всю историю, но очень скоро это гиблое дело бросал. Блог у меня из категории «записная книжка» в жанре «оставлю это здесь, чтобы не забылось», поэтому серьезные усилия по его спасению предпринимать было лень.

Совсем недавно мне что-то стукнуло изнутри (так всегда было, но я только через много лет научился слушать того, кто там, и доверять ему) и я отправился на поиски плагина echoded_id. Долго ли, коротко ли, но правильное название я вспомнил и увидел, что искал его не зря — он обновился. Радостно поставив его, в наивной надежде на мистическую «обратную совместимость» я бросился проверять ссылки. Ничего не вышло. И пришло время смотреть в код.

Первое, что я понял из кода — это тот факт, что «hashed» в названии плагина не просто так. Это действительно не банальный base62, а настоящий хеш с настраиваемым алфавитом и солью. Причем, в первой версии никаких настроек не было.  Откопав первую версию из SVN-репозитария WP.org, я нашел и ту соль, и тот алфавит. Подставил в настройки нового — не работает. Попробовал (снова внутренний голос присоветовал) установить старый — вдруг получится?

И сработало, …ять!
— Руслан Габидуллин, «Студия 420»

Ссылки ожили и стали вести на прежние места. А плагин, тем временем, настоятельно требует обновления. Но больше в зависимость от стороннего разработчика мне не хотелось. И я решил избавиться от этой зависимости.

Поставил вспомогательный плагин Broken Link Checker и собрал все битые ссылки. Все полечил и отключил wp-hashed-idи получил окончательный список битых ссылок. Потом снова включил плагин и в файле single.php добавил вывод post_ID. Дальше немного рутины — переходить по битым (но на этот момент работающим) ссылкам и ID из них вписывал как atrax.ru/?p=. Затем окончательно удалил плагин и убедился, что все ссылки живы.

Больше с ним связываться не буду.

Про миграцию

Я решил перенести свой автономный блог на платформу WPcom. Единственный доступный метод — экспорт с последующим импортом. И все было бы хорошо, если бы ссылки в новом блоге не вели бы на старый. Не все. Медиафайлы перенеслись вместе с другим содержимым, но в записях они ссылки на них менялись с неуловимой закономерностью. Не все распозналось, некоторые изображения показывались с их прежнего местоположения. А уж если записи внутри блока перелинкованы между собой, то все ещё хуже — все ссылки нового сайта вели на прежний и повлиять на это можно было только одним способом, перечитывая все и исправляя все старые ссылки на новые. А в блоге более 1000 записей за 14 лет. Разве только в самом дампе поиском и заменой перебить домены. Опять же, не все — медиафайлы на WPcom распределяются по разным CDN-ам.

В общем, блог остался автономным.

Про WordPress

Когда я впервые с ним познакомился, это была идеальная трехкомпонентная система. Ядро занималось взаимодействием с базой данных, управлением пользователей, предоставляла административный интерфейс и массу «крюков», на которые можно повесить дополнительный функционал из плагинов, а тема представляла собой почти самостоятельное приложение, работающее внутри библиотеки ядра. При желании можно было написать все, что угодно, прямо в файлах темы. Чуть-чуть вникая в устройство — оформить его отдельным подключаемым плагином. При этом обновления ничего не ломали и внушали уверенность в том, что новые уязвимости успешно закрываются и все, что «под капотом», хорошо работает само по себе и не требует специальных знаний. Порог вхождения для человека, пишущего на PHP, был практически нулевой.

А сейчас… плагин нельзя просто взять и «повесить на крюк», если у него есть хоть какие-то настройки, то процесс интеграции в систему занимает чуть ли не больше времени. Темы усложнились и должны содержать в себе интерфейс к штатному конфигуратору, под девизом «сделаем разработку проще» появился механизм «дочерних» тем, виджеты — это такие специально написанные плагины, которые должны соответствовать правилам, платформа стала автоматически обновляемой, структура «записи, страницы и комментарии» превратилась в продвинутую таксономию… В общем, сейчас бы, взглянув на CMS, я бы просто прошел мимо. Особенно, если посмотреть в её код (а там HTML-разметка повсеместно перемежается с выполнимым кодом) и оценить производительность (он требует гораздо больше ресурсов, чем того стоит предоставляемый функционал).

Собственно, поэтому я от него и отошел. Выбирать что-то другое — Joomla и Drupal были опробованы еще тогда, в 2004-м, и не понравились. Писать самому? Тоже пробовал, но пусть уж этим занимаются фанатики вроде обиженного на меня Макса. Все больше блогов встречаю в виде статически генерируемых сайтов с прикрученной внешней системой комментирования. Начинаю и сам подумывать об этом.

Такие дела…