Какова важность написания плагина, совместимого с <WP 3.x?

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

Например, самая старая версия WP, которую я когда-либо видел (установлен клиентом), была 3.2 или где-то там. Я не могу представить, чтобы у многих было что-то старше 3.х, но я могу ошибаться. Я знаю, что в теории вы всегда должны стараться сделать его полностью совместимым, но реально ли кто-нибудь знает, как важно включить эту возможность?

Спасибо

Всегда пишите плагины для текущей версии и помните ночные сборки из будущих версий. Все остальное не имеет значения.

Изменить как @toscho указал в комментарии:

Там может быть какое - то объяснение нужно , почему это является таким образом.

1. Потому что я так сказал.
2. Плагины должны быть совместимы только с ядром, потому что, если все играют по правилам, ничего не получится. Если один плагин не играет с правилами, значит, в нем есть ошибка . И эта ошибка нуждается в исправлении, а не в чем-то еще, и не в другом плагине или теме.
3. Пользователи, которые не обновляют WordPress, являются результатом ошибочных плагинов, которые используются и не могут быть заброшены в системах без большой работы. Как написано в (2), это ошибки, о которых вам не нужно беспокоиться. Ошибки должны быть исправлены, а не ваш плагин, учитывая испорченный сторонний код.
4. Legacy Code не нуждается в поддержке. Требуется замена. Не твоя проблема.
5. Вещи меняются в больших масштабах по сравнению с основными версиями XX. Когда вы пытаетесь поддерживать предыдущие версии, вам часто нужны разные обходные пути и много проверок версий. То есть (a) кошмар обслуживания (b) увеличивает базу кода (c) делает невозможным выполнение модульных тестов, поскольку они должны выполняться на одной версии - не меньше, не больше и, наконец, (d) уменьшают дисковое пространство и производительность сервера (в большинство случаев).
6. WordPress уже имеет очень старую кодовую базу, в которой отсутствуют улучшения по многим краям и углам. Вкратце: WordPress устарел, использует как минимум не поддерживаемую версию PHP, и поэтому вы уже поддерживаете предыдущие версии на гораздо более низких уровнях, чем в общедоступном API вашего приложения.

Теперь иди спроси себя:

Если вы уже поддерживаете более не поддерживаемую версию PHP, зачем вам поддерживать приложение, которое даже не поддерживается его создателями?

Помните, что для выпуска WordPress 3.0 необходим PHP5. В то время многие хостинговые компании еще не использовали PHP5 на своих серверах. Таким образом, был период времени, когда некоторые сайты WordPress НЕ МОГУТ обновляться до WordPress 3.0, потому что их хостинговые компании не поддерживали свои серверы в актуальном состоянии.

Прошло много лет (3+) с момента выпуска WordPress 3.0, поэтому обратная совместимость с WordPress <3.x - не очень распространенные плагины.

Большинство установок WordPress устарели . В настоящее время только 5,2% всех установок работают в последней версии 3.6.
27,3% все еще на версии 3.0.

Вы можете подумать, что должны поддерживать эти старые версии с совместимым кодом. Но подумайте о последствиях:

• Вы должны протестировать все официально поддерживаемые версии.
• Вы должны работать с несовместимыми API, такими как медиа-загрузчик, который сильно изменился в 3.5.
• Вы заставляете своих пользователей думать, что не стоит обновлять WordPress, потому что он все еще работает.
• Вам нужно больше кода, больше тестов и больше времени для поддержки, чтобы сделать то же самое.

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

Мое практическое правило для плагинов, которые я пишу, - поддержка текущей версии минус 1, поэтому все плагины, которые я напишу, будут совместимы с 3.6.x и 3.5.x. Хотя определенный плагин может работать на более ранних версиях, я не гарантирую и не поддерживаю его, если у вас возникнут проблемы.

Четыре месяца назад я взял на себя поддержку популярного плагина. До того, как я начал работать над ним, у плагина не было обновления в течение 2 лет. Я сделал кучу исправлений ошибок, выпустил новую версию и через 2 дня узнал от парня, который сказал, что новая версия вызвала белый экран смерти на его сайте. После того, как я изучил его, он все еще работал на WordPress 2.9.2, а в моем обновлении использовалась функция home_url, представленная в 3.0. Я понятия не имею, почему парень решил обновить этот плагин немедленно, хотя он не обновлял свою установку WordPress в течение 3 лет. Когда я делал новую версию, я никогда не думал тестировать WordPress 2.9.2.

Вот мораль этой истории: В файле readme.txt вашего плагина есть номер версии «Требуется как минимум» в заголовке. Используй это. Когда вы делаете обновления, если вы не хотите тестировать старые версии, увеличивайте их. Это будет препятствовать пользователям, отказывающимся обновлять свои установки WordPress, от обновления вашего плагина.

В настоящее время я пишу новый связанный плагин, и я планирую сделать его только для WordPress 3.6, потому что я хочу использовать библиотеку getid3, включенную в ядро. У меня нет желания выпускать новый плагин для старой версии ядра.