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

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

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

благодаря

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

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

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

  1. Потому что я так сказал.
  2. Плагины должны быть совместимы с ядром, потому что, если все играют с правилами, ничего не сработает. Если один плагин не играет с правилами, значит у него есть ошибка . И эта ошибка требует исправления, а не что-то еще, а не другого плагина или темы.
  3. Пользователи, не обновляющие WordPress, являются результатом использования багги-плагинов, которые не могут быть оставлены в системах без большой работы. Как написано в (2), это ошибки, о которых вам не нужно заботиться. Ошибки нуждаются в исправлении, а не в вашем плагине, рассматривая сломанный сторонний код.
  4. Устаревший код не нуждается в поддержке. Он нуждается в замене. Не твоя проблема.
  5. Вещи меняются в больших масштабах по сравнению с основными версиями XX. Когда вы пытаетесь поддерживать предыдущие версии, вам часто требуются разные способы обхода и много проверки версий. То есть (а) кошмар обслуживания (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, включенную в ядро. У меня нет желания выпускать новый плагин для старой версии ядра.