Записи с меткой «wordpress»

ЭВМ/ WordPress редкие уроды

03.05.2011

Началось все с того, что я решил проверить PageRank бложика. Оказалось, что он упал до единицы. Я встревожился. Зашел в Google Analytics, действительно, поисковый трафик упал очень сильно. Зашел в Webmaster Tools, а там более 700 страниц 404 not found, отвалились все ссылки на метки.

А вышло вот как. После обновления до WP 3.1 сломались ссылки на метки, так как теперь они стали по умолчанию вида /tag/lala, вместо прежнего /archives/tag/lala. Однако можно было вручную указать префикс, и я указал archives/tag для сохранения обратной совместимости. А недавно я обновился до WP 3.1.1, и в этой версии они видать «починили» обратную совместимость адресов меток, потому что теперь метки стали иметь вид /archives/archives/tag/lala. Поэтому я снова убрал собственный префикс и все заработало.

Уроды, что тут еще сказать. И да, уже вышел WP 3.1.2. Вроде работает.

ЭВМ/ Кавычки в WordPress

16.03.2011

Есть в WP крайне неприятный баг, связанный с набором кавычек. Если взять в кавычки слово, например «так», то все нормально, в соответствии с русской типографикой WP ставит угловые кавычки. Но если это же слово сделать гиперссылкой, например вот «так«, то вместо закрывающей кавычки WP ставит еще одну открывающую. И приходится вручную набирать эти »

Я надеялся, что уж в новой версии 3.1 это поправят, но нет. И вот даже не знаю, то ли надеть резиновые перчатки и залезть в PHPшные кишки WP, то ли терпеть, ждать новую версию и надеяться. А, можно еще отправить баг-репорт, но вот это делать совсем уж лень.

,

ЭВМ/ WordPress 3.1

05.03.2011

Обновился до 3.1. Понравилась новая «быстрая» панель сверху для администрирования.

Не понравилось, что сломали обратную совместимость постоянных ссылок на метки. Раньше было /archives/tag, сейчас просто /tag. Хотя в настройках можно поправить. Остальных новшеств пока не заметил.

,

Administrivia

29.12.2010

Теперь можно оставлять комментарии, пользуясь своим аккаунтом Facebook или Twitter. Как всегда, не обошлось без доработки плагинов напильником.

, , , ,

ЭВМ/ OpenID consumer для WordPress

22.12.2010

Надеюсь, вы уже успели насладиться ими. Расскажу, как непросто было их сделать.

Как вы, наверное, заметили, комментарии тут сделаны на базе аутентификации через OpenID aka OpenID consumer. Эта функциональность входит все в тот же плагин OpenID, о котором я уже писал, нужно только поставить соответствующие галочки в настройках. Однако после этого начинается самое интересное.

Во-первых, стандартная форма для комментариев, предлагаемая этим плагином, страшна, как смертный грех. Кроме того, она предполагает вбивание вручную полностью OpenID идентификаторов, которые у некоторых провайдеров могут быть довольно длинными. Для решения этой проблемы служит другой плагин: Comments with OpenID. У него есть красивые иконки для большинства известных OpenID провайдеров, нажимая на которые, можно получить заготовку идентификатора, в которую остается только вбить имя пользователя. Плагин пришлось форкнуть и поправить из-за LiveJournal. Эти орлы сломали у себя OpenID, хотели запретить OpenID аутентификацию только для переименованных аккаунтов, а в результате поломали для всех. Поэтому я удалил их иконку, пока не починят. Еще я заменил шаблон OpenID идентификатора для Google, чтобы получалась красивая ссылка на профиль.

Далее возникли проблемы с получением имени пользователя. Как известно, протокол OpenID помимо непосредственно аутентификации содержит различные расширения, позволяющие, в частности, запросить имя пользователя, его email, домашнюю страницу и т.д. И если с аутентификацией у всех провайдеров все более или менее хорошо, то дополнительные атрибуты все отдают по-разному.

Например, Google не отдает свойство namePerson, а отдает два отдельных поля namePerson/first и namePerson/last. А mail.ru так вообще нарушает спецификацию и не передает необходимый параметр openid.ns.sreg. По этому поводу я, кстати, написал им в техподдержку; на результат, правда, особо не надеюсь. В общем, все эти мелочи я поправил опять-таки в своем форке плагина openid. Самые приличные комиты послал автору, надеюсь, включит в очередную версию, а остальной трэш типа заплатки для mail.ru поместил в отдельную ветку wip (work in progress).

Кроме того, я добавил в плагин возможность требовать обязательного наличия OpenID. Нужно поставить новую галочку в настройках «Require OpenID authentication».

Ну и вставил немного русского перевода. Русский перевод хорошо бы сделать полностью и отослать автору, там работы-то на пару часов.

В общем, как это обычно бывает, объединение якобы открытых систем на базе якобы открытых протоколов оказалось делом хлопотным.

, , ,

ЭВМ/ WP LaTeX

02.11.2010

Поставил плагин, чтобы использовать в записях \LaTeX нотацию. Пригодится для рассказывания всяческой околонаучной фигни.

,

ЭВМ/ Google Sitemap

08.06.2010

Google Sitemap оказалась полезной штукой. Это XML файл, описывающий структуру сайта. Как и любой другой XML документ не предназначен для редактирования вручную, поэтому для WordPress есть специальный плагин. Я использую эту штуку, чтобы объяснить гуглу (и другим поисковикам, поддерживающим этот формат), что при индексации предпочтение нужно отдавать в первую очередь отдельным записям, затем меткам и категориям. Главная страница имеет наименьший приоритет, так как информация на ней быстро устаревает и, кроме того, продублирована в архиве.

,

ЭВМ/ IT-хозяйство: веб-хостинг

31.03.2010

Осталось рассказать, какой софт я развернул на своей VPS. Как я уже говорил, Linode делает свои виртуалки на базе Xen, причем в режиме паравиртуализации. А это, в свою очередь, означает, что выбор ОС сильно ограничен: или Linux, или какой-то другой Linux. Нет, конечно есть вполне рабочий порт NetBSD на Xen, есть порт FreeBSD, были даже попытки запустить OpenBSD на этой архитектуре. Но, во-первых, я не слышал, чтобы кто-то делал веб-хостинг на NetBSD, а FreeBSD на мой взгляд ничем не лучше Linux.

Вообще я не очень люблю Linux, но и какой-то патологической ненависти к нему не испытываю. Поэтому к идее развернуть свое хозяйство на этой ОС отношусь спокойно. Кроме того, все последние годы деньги мне платили именно за работу с Linux. Так что опыт кое-какой имеется. Сам я слабо разбираюсь в тонкостях современных дистрибутивов Linux и в том, как устроен веб-хостинг. Но многие коллеги на нынешней работе имеют в этой области хороший опыт, поэтому я все делал, основываясь на их рекомендациях.

После выбора тарифного плана на Linode необходимо решить, какую операционную систему развернуть. Из всего списка я остановился на (точнее мне посоветовали) Debian 5.0 Lenny. Забегая наперед скажу, что система мне понравилась: удобный менеджер пакетов, сами пакеты сделаны хорошо, избавляют от большого количества рутиной работы по первичной настройке. Через несколько секунд новая виртуальная машина готова к работе. Зайти на нее можно либо через AJAX консоль, либо по ssh. Консоль также доступна через ssh-интерфейс (что-то вроде serial console по сети), они ее называют красивым именем Lish — Linode Shell, хотя на самом деле это обычная Xen console. Итак, залогинившись можно приступать к настройке.

В качестве веб-платформы я решил (опять-таки послушав умных людей) использовать связку nginxPHP-FPM + MySQL. nginx — потому что монстр Apache мне не нужен, PHP-FPM — толковая реализация FastCGI для PHP, которая кушает мало памяти (а память на моем VPS сильно ограничена), а MySQL — он и в Африке MySQL, не PostgreSQL же ставить в самом деле.

С nginx и MySQL никаких проблем не возникло, оба пакета нашлись в стандартном репозитории Debian. А вот с PHP-FPM не все просто. PHP-FPM — суть сторонний патч для PHP, и только совсем недавно было принято решение включить его в следующую версию PHP. А до сих все прикладывали его вручную, а самые продвинутые делали собственный пакет. Оба этих варианта мне не годились, потому что у меня совсем нет времени делать и поддерживать наколенные поделки, свои или чужие. Легкое гугление показало, что есть добрые люди, которые не только собрали нужный мне пакет, но и создали для него репозиторий и готовы пакет поддерживать. Но на практике оказалось, что их пакеты уже остали от обновлений Debian Security, поэтому эту затею пришлось оставить.

Дальнейшее гугление привело меня на сайт Dotdeb. И там наконец обнаружился добротный пакет PHP-FPM, но только для PHP 5.3, тогда как в Lenny по умолчанию идет 5.2. Но так как мне было все равно, какую версию PHP ставить, я его и взял. Впоследствии правда оказалось, что есть небольшие проблемы этой версии с некоторыми плагинами для WordPress, но в остальном все отлично.

Теперь осталось только выбрать движок для блога. Так как я этой темой никогда особо не интересовался, то взял самый популярный — WordPress. И, надо сказать, не жалею. Интерфейс приятный, удобный, работает быстро. За пол дня подточил стандартную тему — и новый непорядок готов!

, , , , , , , , , , ,

ЭВМ/ StatCounter plugin 1.4

26.03.2010

В течение пары дней вышли подряд две новые версии WordPress плагина для интеграции с сервисом StatCounter.com. StatCounter — это типа нашего SpyLog, позволяет вести статистику посещений сайта. Сервис бесплатный, но есть дополнительные услуги за деньги. Сначала вышла версия 1.3, и тут же 1.4. Из видимых изменений — статистика теперь отображается прямо в консоли WP:

, ,

ЭВМ/ OpenID

18.03.2010

Задумал я на базе этого блога сделать себе OpenID. OpenID — это способ идентифицировать и аутентифицировать себя на многих web-сервисах с помощью одной учетной записи. Фактически это означает, что получив один раз OpenID, можно больше не регистрироваться на сотне сайтов только ради того, чтобы читать приватные записи или писать комментарии. Конечно, эти сотни сайтов должны поддерживать OpenID. Получить OpenID можно во многих местах абсолютно бесплатно, например в том же LJ. Или настроить OpenID provider у себя в standalone блоге.

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

В целом задача выглядела очень простой. Для WordPress (а этот блог работает именно на нем, если вдруг кто не понял) есть специальный плагин, который так и называется — OpenID, он предоставляет функционал как потребителя OpenID (для тех же комментариев), так и провайдера. Однако после установки плагин не заработал, так что пришлось засучить рукава и выяснять почему. Для тестирования в качестве потребителя OpenID использовался все тот же LJ.

Первое, что нагуглилось сразу — текущая версия OpenID 3.3.2 не работает с PHP 5.3, а именно его я использую по ряду причин. Патчик, исправляющий проблему, очень простой и действительно рабочий. Кроме того автор патча утверждает, что обратная совместимость не ломается, так что есть надежда, что в новой версии плагина эта проблема будет исправлена. Однако в Subversion репозитории проекта этого патча почему-то нет. На всякий случай я напомнил автору OpenID об этой проблеме.

Вторая проблема была связана с тем, что при авторизации возникал переход по адресу вида http://blog.name/index.php/openid/server…, который заканчивался ошибкой 404. Эта проблема также известна, и даже есть кривая заплатка. Чтобы понять ее причину и, главное, найти правильное решение, нужно сделать шаг в сторону и выяснить, как устроены постоянные ссылки в WP.

Постоянные ссылки на записи не меняются со временем и могут быть использованы на внешних ресурсах. По умолчанию WP генерирует постоянные ссылки вида http://blog.name/?p=123. Они не очень красиво выглядят, так как содержат в себе CGI параметры. «Красивые» ссылки вида http://blog.name/raznoe/kak-ya-provel-leto возможны при наличии mod_rewrite в Apache или соответствующих правил в конфигах lighttpd или nginx. Есть еще одна возможность, из-за которой собственно все и не работает — так называемые «почти красивые ссылки», или PATHINFO permalinks. Ссылки такого типа выглядят как http://blog.name/index.php/raznoe/kak-ya-provel-leto.

Метод PATHINFO (точнее даже PATH_INFO) работает только в Apache и использует одну его интересную особенность: по умолчанию URI вида /path/script.cgi/another/path, при наличии скрипта path/script.cgi, приводят к вызову обработчика этого скрипта, при этом устанавливается специальная переменная окружения PATH_INFO со значением равным /another/path.

У меня Apache нет, вместо него стоят nginx и php-fpm. В конфиге nginx присутствуют строчки, эмулирующие поведение mod_rewrite:

if (!-e $request_filename) {
        rewrite . /index.php last;
}

Вообще говоря, господин Сысоев всячески порицает (см. самый низ страницы) подобные конфиги, однако рекомендуемая им директива try_files присутствует только в nginx 0.7.x, тогда как у меня в Debian Lenny nginx версии 0.6.x, и менять его пока желания нет.

С nginx и его rewrite отдельная очень интересная история. Если зайти на страницу конфигурирования WP в раздел постоянных ссылок, то можно увидеть такую картинку:

Как видно, в качестве альтернативы «некрасивым» ссылкам WP предлагает использовать PATHINFO, которое не работает в nginx! Происходит это из-за того, что WP проверяет имя сервера, и если оно не Apache, или если Apache, но не загружен модуль mod_rewrite, то для постоянных ссылок по умолчанию включается режим PATHINFO. Справедливости ради надо отметить, что на самом деле правила rewrite для nginx, приведенные выше, все-таки заставляют схему с PATHINFO работать. Видимо, WP внутри себя как-то решает эту проблему. Но вот его плагины, в частности OpenID — нет, из-за чего собственно весь сыр-бор.

Так вот, оказывается, существует специальный плагин nginx Compatibility, который, во-первых, сообщает WP, что mod_rewrite как будто бы присутствует, а во-вторых, чинит какую-то проблему с FastCGI PHP SAPI, которая нас сейчас не интересует.

После активации плагина страница настроек стала выглядеть правильно:

По умолчанию предлагаются красивые mod_rewrite постоянные ссылки.

Но вернемся к OpenID. Проблема с ним заключена в нескольких строчках кода в файле common.php:

        if ($wp_rewrite->using_permalinks()) {
                $url .= 'index.php/openid/' . $service;
        } else {
                $url .= '?openid=' . $service;
        }

Автор неявно полагает, что если включены красивые постоянные ссылки, то механизм PATHINFO точно должен работать. Как было показано выше, это верно только для Apache. Таким образом если у вас не Apache (а у меня не Apache), и вы используете красивые постоянные ссылки (а я их использую), то плагин OpenID у вас работать не будет. Замечу, что без использования красивых постоянных ссылок все работает.

Горячие головы предлагают выкинуть совсем строчки, добавляющие index.php в URI, но не думаю, что автор на это согласится, все же он эти строки не зря добавил.

Чтобы найти правильный путь, нужно поставить еще один плагин — AskApache RewriteRules Viewer. Он показывает всю внутреннюю кухню постоянных ссылок:

Видно, что свойство using_permalinks, на которое опирается OpenID, действительно истинно, но свойство using_index_permalinks, которое на самом деле показывает, что работает PATHINFO, ложно. Таким образом правильным решением будет замена в вышеприведенном куске кода using_permalinks на using_index_permalinks. После того, как это было сделано, плагин успешно заработал, а соответствующий патч был отправлен автору.

, , , ,