В рамках поддержки проекта VestaCP занялся патчем для phpmyadmin. Основная проблема в том, что дополнительные функции из коробки не работают, также как и contoluser. Многим пользователям функционал по сути не нужен, он избыточен. Правда, не очень приятно видеть при входе сообщение о том, что у тебя часть функций отключено и не работает — «The phpMyAdmin configuration storage is not completely configured, some extended features have been deactivated».

За вечер пятницы удалось изобразить скрипт, который правит конфигурационный файл и добавляет недостающие таблицы. Чтобы не возиться с определением версии операционной системы, сделал 3 разных скрипта для centos/debian/ubuntu. И еще слегка упростил себе жизнь — не стал изобретать генератор паролей, использовал дополнительный пакет.

Интереснее было в процессе отладки. Выянил, что пихать много запросов в mysql из баша — это не очень хорошо, далеко не все отрабатывает. Гораздо правильнее разбить на несколько. Как оказалось, 3 и 4 ветка phpmyadmin имеют некоторые отличия. В четвертой ветке некоторые значения задаются явно и в дампе несколько больше таблиц, нежели в 3 версии. Довольно странное отличии в количестве нижних подчеркиваний в названии таблиц: в третьей — одно, в четвертой — два. Думаю, в следующих версиях увеличат :)

По моим прикидкам скрипт успели протестировать более чем на полусотне серверов, не считая мои и тестовые — все вроде ровненько прошло. На неделе, наверное, закинем на гитхаб прогоним тесты повторно.. возможно мой вроде-код даже появится в релизе VestaCP. Код добавил на Github, никакого терпения не хватило :)

PS: Слегка удивило, что фикс никто не сделал раньше и не сэкономил мне время (специально поискал в интернетах), вроде ничего сложного не было. Подозреваю, что все-таки пользователи тратят на это 5-10 минут и забывают или забивают вовсе :-)

VestaCP Forum — phpmyadmin fixer
Github — Fixes for phpmyadmin (configuration storage and some extended features)

Ubuntu

sudo wget --no-check-certificate 
https://raw.githubusercontent.com/skurudo/phpmyadmin-fixer/master/pma-ubuntu.sh 
&& chmod +x pma-ubuntu.sh && ./pma-ubuntu.sh

Debian

wget --no-check-certificate 
https://raw.githubusercontent.com/skurudo/phpmyadmin-fixer/master/pma-debian.sh 
&& chmod +x pma-debian.sh && ./pma-debian.sh

CentOS

wget --no-check-certificate 
https://raw.githubusercontent.com/skurudo/phpmyadmin-fixer/master/pma-centos.sh 
&& chmod +x pma-centos.sh && ./pma-centos.sh

Пришло при обновлении вот такое вот сообщение. Можно показывать всем подряд и, руководствуясь мерами безопасности, не ставить или ставить, но особо предупреждать об отсутствии ответственности.

php5 (5.4.45-0+deb7u2) wheezy-security; urgency=medium
  * PHP 5.4 has reached end-of-life on 14 Sep 2015 and as a result there
    will be no more new upstream releases.  The security support of PHP
    5.4 in Debian will be best effort only and you are strongly advised
    to upgrade to latest stable Debian release that includes PHP 5.6 that
    will reach end of security support on 28 Aug 2017.
 -- Ondřej Surý <ondrej@debian.org>

Меня больше смущает другой момент — как будет с поддержкой некоторых скриптов. Понимаю, что некоторые и так застряли с версией 5.3 и по-другому не работают никак. Но что будет с новыми версиями еще не ясно, что-нибудь да всплывет. Вспоминается история с libxml в ее реализации с php 5.3 и её работе в php 5.4 — вот уж капкан соблазнов.

Обратились с ошибкой при загрузке фотографий — «Error: missing temporary folder». С правами проблем не было, других ошибок не видно. Решение оказалось на редкость простым. Дело в том, что webasyst весьма придирчив к upload_tmp_dir. Если значение пустое, то получаем ошибку. Поэтому определим значение для пользователя четко в конфигурационном файле apache2:

php_admin_value upload_tmp_dir /home/user/tmp

Перенося блог на базе Wordpress с одного сервера на другой, в который раз задумался над тем, зачем я таскаю уже несколько лет такое чудовище. Записей не сильно больше полутора тысяч, а в их ценности для прогрессивного человечества у меня есть определенные сомнения. Несколько раз пытался привести хозяйство в божеский вид, не всегда поднималась рука удалить то или иное. Редактировать старые записи, кажется, не очень правильным решением.

Дополнительным доводом за переезд на другой движок стал тот факт, что Wordpress меня убивает скоростью работы. Не смотря на оптимизацию, уменьшения количества плагинов и шаманства, скорость работы не устраивает совершенно. Больше всего расстраивает скорость работы админской панели. Нагромождения и торможения убивают весь творческий процесс. Вот думаешь, сейчас напишу статью или заметку. Потом приходит мысль: «опять оно будет еле ворочаться, да ну его». Эдакий закрепленный bad experience в действии.

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

При таких условиях самое время пересмотреть свои взгляды на процесс заполнения блога и понять, а что из всех свистюлек, фишечек, рюшечек действительно нужно? SEO? Ерунда, популярность и продвижение для меня слишком не актуальна. Backup? Его и так делают bash-скрипты. Красивый dashboard? Да нет же! wysiwyg? Возможно, но не то. В сухом остатке получается, от движка нужно не так много — скорость и стабильность работы. На данный момент то, что мне нужно есть на базе Эгея от Ильи Бирмана. На нем и остановился. Старые заметки вряд ли в полном объеме будут перенесены. Некоторые, возможно, появятся здесь после обновления фактических данных.