Ха! Я изначально написал, что поддерживать WordPress 3.1 и особенно PHP4 не стоит, на что вы ответили:
> ну, изредка появляются товарищи на php4. Были просьбы сделать плагин совместимым, потому как хостинг такой
Поэтому если вы собираетесь делать поддержку PHP4 и WordPress 3.1, то нужно делать её правильно, а не тяп-ляп, что некогда даже интерпретатор установить =)
WP_Cron запускается в отдельном HTTP запросе, даже если выставлен ALTERNATE_WP_CRON, то происходит всего лишь редирект. Никакой магии нет. И admin-ajax.php в этом плане ничем не отличается, wp-load.php он и в африке wp-load.php :)
А вот ваш «простой случай» всё объясняет, но WordPress тут, извините, абсолютно не причём. И не важно, версия 2.9 или 3.2 :)
Если писать для php4, то нужен весь цикл, нужно установить те версии WordPress, которые работают под php4 и нужно установить сам интерпрератор и всё протестировать от начала и до конца. Только после этого, можно будет говорить о совместимости.
А если вы поставили пару амперсандов и думаете, что оно всё заработает на php4 и WordPress 3.1, то вы ошибаетесь :)
Не нужно обвинять WordPress, если вы воспользовались криво-написанным плагином или темой :) Ещё в версии 1.5 плагины загружались с include_once(). Вряд ли «где-то между версиями 2.9 и 3.2» это изменилось на include() а потом обратно.
С svn-ом тоже проще, можно делать коммиты в ветку (branches), без синхронизации ;) а когда наберётся достаточно комитов, можно мерджить. Только вот мерджи в svn плохо работают когда более 1 человека на проекте, git лучше справляется с конфликтами :)
Если вдруг ваш плагин подгрузился два раза за один запрос, значит что-то работает не правильно, где-то допустили ошибку, и нужно в этом разобраться, а не просто class_exists поставить. :)
Функция class_exists здесь будет полезена в том случае, если у вашего класса не совсем уникальное имя, как например «socialusers» или же, если ваш плагин является частью темы или другого, более крупного плагина, как например Jetpack и Polldaddy, Grunion Contact Form, WP-Stats, и т.д.
Таким товарищам нужно помогать. Помогать выбирать хороший и безопасный хостинг. Ровно так же, как и помогать заказчикам переходить на более свежие версии IE, нежели писать поддержку IE6 в своих работах.
> Это проверяется. См. строчку:
> if (!function_exists ('add_shortcode') ) return;
Прочитайте внимательно ещё раз: «Если вы не собираетесь поддерживать WordPress 2.4, вам не нужно проверять её наличие с function_exists.» :)
> Не знаю динамики, но возможно где-то ещё остались пользователи старых версий (3.2 вышла год назад).
Статистику можете посмотреть здесь: wordpress.org/about/stats/ и обратите внимание на версии PHP — 99.5% версии 5 и выше. Поддерживать всё, что ниже двух последних версий не стоит, ровно так же как и IE6 ;) А если всё же вас кто-нибудь спросит насчёт поддержки 3.1, вы можете смело попросить их обновиться.
> Надо будет поставить. Хотя есть элемент свободы — плагины всё равно можно ставить только на standalone, и если блоггеру угодно ломать свой standalone через XSS — это его право :).
Защита в данном случае от пользователей которые не имеют доступ к FTP или админ-права на сайте. Если бы все standalone сайты имели только одного пользователя админ, то проблем бы не возникало, но у нас ведь есть ещё и авторы, и редакторы, и контрибюторы, и за счёт плагинов может быть ещё масса ролей без права на unfiltered_html, как в оригинальном WordPress, так и в сетевом варианте WordPress Multisite.
Короче говоря, это не «элемент свободы» а дырка :) и как только пользователи на неё пожалуются на WordPress.org, ваш плагин оттуда исчезнет, так что поторопитесь :)
> Но опасаюсь конфликта с CSS-настройками текущей theme. Мало ли, что у них на уме.
Да, вы правы, нужен снова префикс, rikki-twitter :)
Здорово, спасибо за статью! Есть немного замечаний :)
* Класс «socialusers» и шорткод «userid» могут вызвать конфликт с другими плагианами, которые решили свои классы и шорткоды так же назвать. Берите более уникальные называния, например с префиксом: Rikki_Social_Users и [rikki_userid]. Было много примеров где знаменитые плагины были вынуждены менять свои шорткоды.
* Функция add_shortcode появилась в WordPress 2.5. Если вы не собираетесь поддерживать WordPress 2.4, вам не нужно проверять её наличие с function_exists.
* Callback функции в объекте класса нужно было передавать по ссылке в php 4, а в php 5 все объекты по умолчанию будут передаваться по ссылке, поэтому можно писать array( $this, 'mce_buttons' ); без &.
* Не стоит забывать о безопасности. Пользователь может ввести что-нибудь вроде: foo.com' onclick='...' в вместо URL, и ваш код подставит его XSS в вашу ссылку, даже если он не имеет право публиковать unfiltered_html. В данном случае нужно esc_url(). Подробнее: codex.wordpress.org/Data_Validation
Вообще идея клёвая, но я бы не стал её реализовывать таким образом. Я бы лучше добавил 10 своих иконок (а скорее даже один спрайт) + 10 правил в CSS, и в постах добавлял бы класс:
И если вдруг плагин сломался, перестал поддерживаться автором, не совместим с WordPress версией 3.6, или же просто надоел, то все мои существующие посты будут всё равно отображаться, пусть без иконок, но всё же не придётся бегать по базе и искать все [userid.
Ещё раз спасибо за статью!
P.S. WordPress правильнее писать с заглавной буквы P: capitalp.org/
В директорию WordPress.org возьмут любой недоработанный код, главное readme.txt правильно оформлять. На то и даётся вам репозиторий с директорией trunk :)
Поправочка, «они» являются создателями WordPress.com, а сам WordPress создал Matt Mullenweg вместе с Mike Little за несколько лет до появления Automattic ;)
Это конечно всё здорово, WordPress тут не причём, с таким же упехом может работать любое другое php приложение, но самый очевидный вопрос не в этом, а вот в чём: трафик-то у нас что, бесплатный? ;)
> ну, изредка появляются товарищи на php4. Были просьбы сделать плагин совместимым, потому как хостинг такой
Поэтому если вы собираетесь делать поддержку PHP4 и WordPress 3.1, то нужно делать её правильно, а не тяп-ляп, что некогда даже интерпретатор установить =)
> Может приведете хоть один резон за php4?
В отличии от вас, нет. :)
Вот это всё и объясняет :)
core.trac.wordpress.org/browser/tags/3.4.1/wp-admin/includes/plugin.php#L533
WP_Cron запускается в отдельном HTTP запросе, даже если выставлен ALTERNATE_WP_CRON, то происходит всего лишь редирект. Никакой магии нет. И admin-ajax.php в этом плане ничем не отличается, wp-load.php он и в африке wp-load.php :)
А вот ваш «простой случай» всё объясняет, но WordPress тут, извините, абсолютно не причём. И не важно, версия 2.9 или 3.2 :)
Если писать для php4, то нужен весь цикл, нужно установить те версии WordPress, которые работают под php4 и нужно установить сам интерпрератор и всё протестировать от начала и до конца. Только после этого, можно будет говорить о совместимости.
А если вы поставили пару амперсандов и думаете, что оно всё заработает на php4 и WordPress 3.1, то вы ошибаетесь :)
core.trac.wordpress.org/browser/tags/1.5/wp-settings.php#L111
Поправьте меня, если я не прав :)
Если вдруг ваш плагин подгрузился два раза за один запрос, значит что-то работает не правильно, где-то допустили ошибку, и нужно в этом разобраться, а не просто class_exists поставить. :)
Функция class_exists здесь будет полезена в том случае, если у вашего класса не совсем уникальное имя, как например «socialusers» или же, если ваш плагин является частью темы или другого, более крупного плагина, как например Jetpack и Polldaddy, Grunion Contact Form, WP-Stats, и т.д.
> Это проверяется. См. строчку:
> if (!function_exists ('add_shortcode') ) return;
Прочитайте внимательно ещё раз: «Если вы не собираетесь поддерживать WordPress 2.4, вам не нужно проверять её наличие с function_exists.» :)
> Не знаю динамики, но возможно где-то ещё остались пользователи старых версий (3.2 вышла год назад).
Статистику можете посмотреть здесь: wordpress.org/about/stats/ и обратите внимание на версии PHP — 99.5% версии 5 и выше. Поддерживать всё, что ниже двух последних версий не стоит, ровно так же как и IE6 ;) А если всё же вас кто-нибудь спросит насчёт поддержки 3.1, вы можете смело попросить их обновиться.
> Надо будет поставить. Хотя есть элемент свободы — плагины всё равно можно ставить только на standalone, и если блоггеру угодно ломать свой standalone через XSS — это его право :).
Защита в данном случае от пользователей которые не имеют доступ к FTP или админ-права на сайте. Если бы все standalone сайты имели только одного пользователя админ, то проблем бы не возникало, но у нас ведь есть ещё и авторы, и редакторы, и контрибюторы, и за счёт плагинов может быть ещё масса ролей без права на unfiltered_html, как в оригинальном WordPress, так и в сетевом варианте WordPress Multisite.
Короче говоря, это не «элемент свободы» а дырка :) и как только пользователи на неё пожалуются на WordPress.org, ваш плагин оттуда исчезнет, так что поторопитесь :)
> Но опасаюсь конфликта с CSS-настройками текущей theme. Мало ли, что у них на уме.
Да, вы правы, нужен снова префикс, rikki-twitter :)
* Класс «socialusers» и шорткод «userid» могут вызвать конфликт с другими плагианами, которые решили свои классы и шорткоды так же назвать. Берите более уникальные называния, например с префиксом: Rikki_Social_Users и [rikki_userid]. Было много примеров где знаменитые плагины были вынуждены менять свои шорткоды.
* Функция add_shortcode появилась в WordPress 2.5. Если вы не собираетесь поддерживать WordPress 2.4, вам не нужно проверять её наличие с function_exists.
* Callback функции в объекте класса нужно было передавать по ссылке в php 4, а в php 5 все объекты по умолчанию будут передаваться по ссылке, поэтому можно писать array( $this, 'mce_buttons' ); без &.
* Не стоит забывать о безопасности. Пользователь может ввести что-нибудь вроде: foo.com' onclick='...' в вместо URL, и ваш код подставит его XSS в вашу ссылку, даже если он не имеет право публиковать unfiltered_html. В данном случае нужно esc_url(). Подробнее: codex.wordpress.org/Data_Validation
Вообще идея клёвая, но я бы не стал её реализовывать таким образом. Я бы лучше добавил 10 своих иконок (а скорее даже один спрайт) + 10 правил в CSS, и в постах добавлял бы класс:
И если вдруг плагин сломался, перестал поддерживаться автором, не совместим с WordPress версией 3.6, или же просто надоел, то все мои существующие посты будут всё равно отображаться, пусть без иконок, но всё же не придётся бегать по базе и искать все [userid.
Ещё раз спасибо за статью!
P.S. WordPress правильнее писать с заглавной буквы P: capitalp.org/