Welche Bedeutung hat es heutzutage, ein <WP 3.x-kompatibles Plugin zu schreiben?

Ich schreibe derzeit ein einfaches Plugin mit benutzerdefinierten Posts und einigen Funktionen, verwende Post-Metadaten und füge der Tabelle "options" in der Datenbank einige Variablen hinzu. Während meiner Recherche habe ich im WP-Codex einige Hinweise darauf gesehen, wie das Plugin mit Versionen vor WP 3.x abwärtskompatibel gemacht werden kann, und ich habe mich nur gefragt, wie wichtig es jetzt ist, diese Kompatibilität zu integrieren.

Zum Beispiel war die älteste Version von WP, die ich jemals (von einem Client) installiert gesehen habe, 3.2 oder irgendwo in der Nähe. Ich kann mir nicht vorstellen, dass viele Menschen etwas älter als 3.x haben, aber ich könnte mich irren. Ich weiß, dass Sie theoretisch immer versuchen sollten, es perfekt kompatibel zu machen, aber weiß realistisch gesehen jemand, wie wichtig es ist, diese Fähigkeit einzubeziehen?

Vielen Dank

Schreiben Sie immer Plugins für die aktuelle Version und berücksichtigen Sie die nächtlichen Builds der kommenden Versionen. Alles andere spielt keine Rolle.

Bearbeiten Wie @toscho in einem Kommentar betonte:

Möglicherweise ist eine Erklärung erforderlich, warum dies so ist .

1. Weil ich das sage.
2. Plugins müssen nur mit dem Core kompatibel sein, denn wenn alle mit den Regeln spielen, schlägt nichts fehl. Wenn ein Plugin nicht mit den Regeln spielt, hat es einen Fehler . Und dieser Fehler muss behoben werden und nichts anderes und kein anderes Plugin oder Thema.
3. Benutzer, die WordPress nicht aktualisieren, sind das Ergebnis fehlerhafter Plugins, die verwendet werden und in Systemen nicht ohne viel Arbeit aufgegeben werden können. Wie in (2) geschrieben, sind das Fehler, um die Sie sich nicht kümmern müssen. Die Fehler müssen behoben werden, nicht Ihr Plugin, wenn Sie den Code eines Drittanbieters berücksichtigen.
4. Legacy Code benötigt keine Unterstützung. Es muss ersetzt werden. Nicht dein Problem.
5. Die Dinge ändern sich im großen Maßstab gegenüber den wichtigsten XX-Versionen. Wenn Sie versuchen, frühere Versionen zu unterstützen, benötigen Sie häufig unterschiedliche Problemumgehungen und viele Versionsprüfungen. Das heißt, (a) ein Wartungs-Albtraum (b) erhöht die Codebasis (c) macht Unit-Tests unmöglich, da sie auf einer Version ausgeführt werden müssen - nicht weniger, nicht mehr und schließlich (d) den Speicherplatz und die Leistung des Servers verringern (in meiste Fälle).
6. WordPress hat bereits eine sehr alte Codebasis, die an vielen Kanten und Ecken keine Verbesserungen aufweist. Kurz gesagt: WordPress ist alt, verwendet mindestens eine nicht mehr unterstützte PHP-Version und unterstützt daher bereits frühere Versionen auf viel niedrigeren Ebenen als in der öffentlichen API Ihrer Anwendung.

Fragen Sie sich jetzt:

Wenn Sie bereits eine nicht mehr unterstützte PHP-Version unterstützen, warum sollten Sie eine Anwendung unterstützen, die nicht einmal von ihren Erstellern unterstützt wird?

Denken Sie daran, dass für die Veröffentlichung von WordPress 3.0 PHP5 erforderlich ist. Zu dieser Zeit hatten viele Hosting-Unternehmen noch kein PHP5 auf ihren Servern. Es gab also eine Zeitspanne, in der einige WordPress-Sites NICHT auf WordPress 3.0 aktualisiert werden konnten, weil ihre Hosting-Unternehmen ihre Server nicht auf dem neuesten Stand hielten.

Viele Jahre sind seit der Veröffentlichung von WordPress 3.0 vergangen (3+), daher ist es nicht sehr üblich, mit WordPress <3.x abwärtskompatibel zu sein.

Die meisten WordPress-Installationen sind veraltet . Derzeit werden nur 5,2% aller Installationen mit der neuesten Version 3.6 ausgeführt.
27,3% sind noch auf Version 3.0.

Möglicherweise müssen Sie diese alten Versionen mit kompatiblem Code unterstützen. Aber denken Sie über die Auswirkungen nach:

• Sie müssen alle offiziell unterstützten Versionen testen .
• Sie müssen mit inkompatiblen APIs wie dem Medien-Uploader umgehen, der sich in 3.5 drastisch geändert hat.
• Sie lassen Ihre Benutzer denken, dass es in Ordnung ist, WordPress nicht zu aktualisieren, da es immer noch funktioniert.
• Sie benötigen mehr Code, mehr Tests und mehr Zeit für den Support, um dieselben Aufgaben auszuführen.

Und die Benutzer dieser Plugins werden wahrscheinlich nicht einmal Ihr Plugin installieren, da sie wissen, dass bereits neue Plugins ihre Site beschädigen. In Bezug auf die Marktreichweite könnten Sie mit abwärtskompatiblem Code ein wenig gewinnen. In Sachen Effizienz verlieren Sie.

Meine Faustregel für Plugins, die ich schreibe, ist die Unterstützung der aktuellen Version minus 1, sodass alle Plugins, die ich schreiben würde, mit 3.6.x und 3.5.x kompatibel wären. Während ein bestimmtes Plugin möglicherweise auf früheren Versionen funktioniert, kann ich es weder garantieren noch unterstützen, wenn Sie auf Probleme stoßen.

Vor vier Monaten habe ich die Wartung eines beliebten Plugins übernommen. Bevor ich anfing daran zu arbeiten, hatte das Plugin seit 2 Jahren kein Update mehr. Ich habe eine Reihe von Fehlerkorrekturen vorgenommen, die neue Version veröffentlicht und 2 Tage später von einem Mann gehört, der sagte, die neue Version habe den White-Screen-of-Death auf seiner Website verursacht. Nachdem ich es mir angesehen hatte, führte er immer noch WordPress 2.9.2 aus, und mein Update verwendete die in 3.0 eingeführte Funktion home_url. Ich habe keine Ahnung, warum der Typ beschlossen hat, dieses Plugin sofort zu aktualisieren, obwohl er seine WordPress-Installation seit 3 ​​Jahren nicht mehr aktualisiert hat. Als ich die neue Version gemacht habe, hätte ich nie gedacht, WordPress 2.9.2 zu testen.

Hier ist die Moral der Geschichte: In der readme.txt- Datei Ihres Plugins befindet sich im Header die Versionsnummer "Benötigt mindestens". Benutze es. Wenn Sie beim Aktualisieren alte Versionen nicht testen möchten, erhöhen Sie sie. Dies wird Benutzer davon abhalten, die Aktualisierung Ihres Plugins zu verweigern, wenn sie sich weigern, ihre WordPress-Installationen zu aktualisieren.

Ich schreibe gerade ein neues, verwandtes Plugin und plane, es nur in WordPress 3.6 zu erstellen, da ich die im Kern enthaltene getid3-Bibliothek verwenden möchte. Ich habe keine Lust, ein neues Plugin für eine alte Kernversion zu veröffentlichen.