kernel panic in userspace

Як я ўжо пасьпеў паабяцаць у твіттэры, сзрабіў патч для WordPress і закамьміціў у тамашні trac. Напэўна, гэта нават ня баг, гэта фіча.

Справа ў тым, што ў вэрсіі 2.7 з trunk у Dashboard у віджэце апошніх каментароў няма спасылкі на сам каментар. Паней такой спасылкай была “#” і магчыма было перайсьці да каментара на старонцы паста, каб адказаць. Цяпер форма адказу убудавана ў Dashboard і спасылка зьнікла. Выглядае цяпер усё прыкладна наступным чынам

Мяне, як чалавека, які можа забыць, што было напісана ў пасьце з такой-та назовай, такая сітуацыя не задавальняе, таму я дадаў пасьля спасылкі рэдагаваньня паста ту самую “#”. Да таго ж закамьміціў у trac запыт на вяртаньне такой патрэбнай функцыі. Тым больш, што адрас атрымліваецца з базы ў любым выпадку, нават калі пераменная не выкарыстоўваецца. Патч магчыма спампаваць адсюль. Прымяняецца наступнай камандай у корані інтсаляцыі WordPress

patch -p0 < comment_link_dashboard-27112008.diff

Дарэчы, распрацоўшчыкі WordPress таксама не губляюць адчуваньне гумару, вось такую прыкольную штуку заўважыў пры даданьні тыкета:

Как я уже успел пообещать в твиттере, сделал патч для WordPress и закоммитил в тамошний trac. Наверное, это даже не баг, это фича.

Суть в том, что в версии 2.7 из trunk в Dashboard в виджете последних комментариев нету ссылки на сам комментарий. Раньше такой ссылкой служила решётка и можно было перейти к коментарию на странице поста, чтобы ответить. Теперь форма ответа встроена в Dashboard и ссылка пропала. Выглядит теперь всё примерно таким образом

Меня, как человека, способного забыть что было написано в посте с таким-то названием, такая ситуация не устраивает, посему я добавил после ссылки редактирования поста ту самую “#”. К тому же закоммитил в trac запрос на возвращение такой нужной функии. Тем более, адрес получается из базы данных в любом случае, хоть даже переменная не используется. Патч можно скачать здесь. Применятеся следующей командой в корне интсалляции WordPress

patch -p0 < comment_link_dashboard-27112008.diff

Кстати, разработчики WordPress тоже не лишены юмора, такую забавную вещь заметил при добавлении тикета:

WordPress – вельмі добрая і харошая сістэма, і дакумэнтацыя ў яе добра арганізавана. Толькі вось сёньня апошняя мяне падвяла і агарчыла. І прымусіла бляць доўга мацюкацца.
А ўсё справа ў функцыі для падгрузкі лякалізацый плягіна load_plugin_textdomain. У дакумэнтацыі напісана

If your plugin isn’t in its own subdirectory, you can leave out the second argument of load_plugin_textdomain.

Тут, як аказваецца, маецца на ўвазе не падтэчка тэчкі плягіна. Падтэчкай называецца сама тэчка. А ўлічваючы тое, што нельга трымаць плягіны па-за межамі гэтай тэчкі, то такое з плягінам у базе дадзеных WordPress немагчыма.
Але я ж гэтага адразу ня ведаў. Апусьціў другі аргумэнт. Доўга ўчытваўся, я апошнія пару дзён часта прапускаю важныя моманты. Выпрабаваў усё, што толькі магчыма было выпрабаваць. Нават да танцаў з бубнам вакол самога файла лякалізацыі. Выратавала апошняе – калупаньне кода самаго WordPress (што апошнім часам становіцца маім любімым мэтадам). Аказваецца, што ў функцыі ўвогуле 3 аргумэнты. Для таго, каб атрымаць неабходны мне рэзультат, патрэбна вызваць у выглядзе load_plugin_textdomain($domain, false, $dir), дзе $dir – адносны шлях да дырэкторыі з лякалізацыямі, калі глядзець з wp-content/plugins.
Мараль прыдумайце самі.

WordPress – очень хорошая и удобная система, и документация у неё отлично организована. Только вот сегодня последняя меня подвела и огорчила. И заставила блять долго ругаться матом.
А всё дело в функции для подгрузки локализаций плагина load_plugin_textdomain. В документации написано

If your plugin isn’t in its own subdirectory, you can leave out the second argument of load_plugin_textdomain.

Тут, как оказывается, имеется в виду не поддиректория директории плагина. Поддиректорией называется сама директория. А учитывая то, что невозможно держать плагины за границами этой директории, то такое с плагином в базе данных WordPress невозможно.
Но я ведь этого не знал. Опустил второй аргумент. Не заработало. Долго вчитывался, я последние пару дней часто упускаю важные моменты. Испробовал всё, что только можно было использовать. Вплоть до танцев с бубном вокруг самого файла локализации. Спасло последнее – ковыряние кода самого WordPress (что уже становится моим любимым методом). Оказывается, у функции вообще 3 аргумента. Для того, чтобы получить необходимый мне результат, требуется вызывать в виде load_plugin_textdomain($domain, false, $dir), где $dir – относительный путь к директории с локализациями, если смотреть из wp-content/plugins.
Мораль придумайте сами.

From WordPress documentation:

If your plugin isn’t in its own subdirectory, you can leave out the second argument of load_plugin_textdomain.

They mean plugin subdirectory as its directory in wp-content/plugins, so you need to use function like load_plugin_textdomain($domain, false, $dir), where $dir – relative path to plugin directory from wp-content/plugins.

Працягваючы тэму папярэдняга паста.
Баг за паяданьнем працэсару пряўляецца, як выявілася, не адразу. Такім чынам, новыя, некалькі больш лібэральныя, CFLAGS дапамагаюць у вырашэньні гэтай праблемы.
Цяпер застаецца спадзявацца, што будзе выпраўлены і іншы баг, які праяўляецца ў выпадзеньні mpd на заіканьні пасьля доўгага праслухваньня. Ад фармата і часу працы, па маіх назіраньнях, паводзіны не залежаць. Паводзіны аднолькавыя і ў вэрсіі 0.13.1, і ў апошняй з git. Будзем чакаць, пакуль што палёт нармалёвы.

Продолжая тему предыдущего поста.
Баг с поеданием процессора проявляется, как оказалось, не сразу. Таким образом, новые, несколько более либеральные, CFLAGS избавлют от этой проблемы.
Теперь остаётся надеяться, что будет побеждён и другой баг, проявляющийся в выпадании mpd на заикания после долгого прослушивания. От формата и времени работы, по моим наблюдениям, поведение не зависит. Поведение одинаковое и в версии 0.13.1, и в последней из git. Будем ждать, пока что полёт нормальный.

У дагонку папярэдняму пасту.
Паставіў плягін Lightbox 2, каб пры кліку на малюнак адчыняўся прыгожы прагляд, як у папярэднем пасьце. Думаю, што ня ўсе мае чытачы, ды і тыя, хто па пашуковых запытах прыходзіць, такія ўжо ацкія кодэры і вярстальнікі, таму могуць сутыкнуцца з праблемай неперакрываньня некаторых элементаў блёгу пры праглядзе малюнкаў.
Вось толькі сёньня раніцай мне на вочы папала апісаньне элементу css z-index. Дакладна як па замове. Параметр гэты адказвае за “слаі” ў старонцы. Т.б. калі ў элемента выстаўлены большы z-index, чым у другога на той жа пазыцыі, то ён будзе знаходзіцца вышэй і перакрываць элемент зь меншым z-index. Такая вось вулічная магія :)
Асабіста кажучы, вылечваньне праблемы з элементамі, якія не перакрываюцца пры праглядзе графікі, вырашаецца пошукам у css файле шаблёну (звычайна style.css, але могуць быць укладзены і іншыя) апісаньня гэтых самых элементаў і выпаўленьнем z-index на больш дэмакратычны. Мажна ўвогуле выдаліць параметр, калі візуальна нічога ад гэтага ня зьменіцца. У мяне для шапкі z-index быў выстаўлены ў 150 (!). Адкуль аўтар знайшоў столькі слаёў мне незразумела, магчыма ў гэтым ёсьць нейкі глыбінны сэнс, які мне з маіх мяшчанскіх пазыцый не пабачыць. Я выдаліў азначэньне z-index увогуле і ўсё стала на сваі мейсцы. І дызайн не пакутаваў, ну можа я проста пакуль што гэтага ня бачу :-)
p.s.: “правільны” стыль – мінусавыя паказчыкі z-index

В догодку предыдущему посту.
Поставил плагин Lightbox 2, чтобы при клике на картинку появлялся красивый просмотр, как в предыдущем посте. Думаю, что не все мои читатели, да и те, кто по поисковым запросам заходит, такие уж адские кодеры и верстальщики, посему могу столкнуться с проблемой неперекрывания некоторых элементов блога при просмотре картинок.
Вот только сегодня утром мне на глаза попадалось описание параметра css z-index. Прямо как по заказу. Параметр этот отвечает за “слои” в странице. Т.е. если у элемента установлен больший z-index, чем у другого на той же позиции, то он будет находиться выше и перекрывать элемент с меньшим z-index. Такая вот уличная магия :)
Собственно, излечение проблемы с неперекрывающимися элементами при просмотре графиуи решается поиском в css файле шаблона (обычно style.css, но могут быть вложены и другие) описания этих самых элементов и исправлением z-index на более демократичный. Можно вообще удалить параметр, если визуально от этого ничего не изменится. У меня для шапки z-index был выставлен в 150 (!). Откуда автор нашёл столько слоёв мне неясно, возможно в этом некий глубинный смысл не видный с моих мещанских позиций. Я удалил определение z-index вообще и всё стало на свои места. И дизайн не пострадал, по крайней мере, пока что я этого не вижу :-)
p.s.: “правильный” стиль – минусовые значения z-index

Понадобилось мне поставить плагин для интеграции Wordpress и Twitter. Виджет хотелось поставить повыше, но с версии 2.5 WordPress не давал мне возможности двигать виджеты в принципе. Исправлять пришлось отключением всех плагинов и поиском злоумышленника. Им оказался плагин Customize, которым никогда и не пользовался даже :) После активации оставшихся плагинов выявилась проблема.
Если вы используете плагин jLanguage для WordPress, то после его деактивации и повторной активации можете столкнуться с проблемой, что странички блога будут полны ошибками в стиле:

Warning: unserialize() expects parameter 1 to be string, array given in path to jLanguage2.2.php on line 954

Всё можно исправить, вы же знаете, стоит лишь заменить на этой 954-й (хотя у меня это 961-я) строке

$jLanguage = unserialize($tmp);

на

$jLanguage = $tmp;

Теперь и настройки можно будет изменить, и плагин будет раотать как надо.
p.s.: френдите, кто есть на twitter

Спатрэбілася мне паставіць плягін для інтэграцыі Wordpress і Twitter. Віджэт хацелася паставіць вышэй, але зь вэрсіі 2.5 Wordpress не даваў магчымасьці двігаць віджэты ў прынцыпе. Выпраўляць прыйшлося адключэньнем усіх плягінаў і пошукам зламысьленьніка. Ім апынуўся плягін Customize, якім я ніколі і не карыстаўся нават :) Пасьля актывацыі застаўшыхся плягінаў выявілася праблема.
Калі вы выкарыстоўваеце плягін jLanguage для WordPress, то пасьля яго выключэньня і паўторнага ўключэньня можаце сутыкнуцца з праблемай, што старонкі блёгу будуць поўныя памылак у стылі:

Warning: unserialize() expects parameter 1 to be string, array given in path to jLanguage2.2.php on line 954

Усё можна выправіць, вы ж ведаеце, трэба толькі замяніць на гэтым самым 954-м (хаця ў мяне гэта 961-ы) радку

$jLanguage = unserialize($tmp);

на

$jLanguage = $tmp;

Цяпер і наладкі можна будзе зьмяніць, і плягін будзе працаваць як трэба.
p.s.: дадавайце да фрэндаў, хто ёсьць на twitter

Sorry Google’s english not much better than my ;-)
It took me put the plugin for the integration and Wordpress Twitter. I wanted to set widget higher, but from version 2.5 WordPress did not give me the opportunity to move widgets in principle. Had to fix via disconnecting all plug-ins and finding the trouble. It was Customize, which never enjoyed even :) After activating the remaining plug-ins I identifyed problems.
If you use plug jLanguage for WordPress, then after its deactivation and re-activation can face the problem that is pages of the blog will be full of errors style:

Warning: unserialize () expects parameter 1 to be string, array given in path to jLanguage2.2.php on line 954
All can be corrected, you know, is only a substitute on that 954 (in my file it was 961) line

$jLanguage = unserialize($tmp);

with

$jLanguage = $tmp;

Now you can change settings, and will plug raotat as expected.
p.s.: frend me, who is on twitter