Qual è l'importanza di scrivere un plug-in <WP 3.x al giorno d'oggi?

Attualmente sto scrivendo un plug-in semplice con post personalizzati e un paio di funzioni, usando post metadati e aggiungendo un paio di variabili alla tabella "opzioni" nel database. Durante la mia ricerca, ho visto alcuni riferimenti nel WP Codex su come rendere il plug-in retrocompatibile con le versioni precedenti a WP 3.x e mi stavo solo chiedendo quanto sia importante ora integrare tale compatibilità.

Ad esempio, la versione più vecchia di WP che abbia mai visto installato (da un client) era la 3.2, o da qualche parte lì intorno. Non riesco a immaginare molte persone che hanno qualcosa di più vecchio di 3.x ma potrei sbagliarmi. So in teoria che dovresti sempre provare a renderlo perfettamente compatibile ma, realisticamente, qualcuno sa quanto sia importante includere quella capacità?

Grazie

Scrivi sempre plugin per la versione corrente e tieni a mente le build notturne dalle versioni imminenti. Nient'altro non importa.

Modifica Come sottolineato da @toscho in un commento:

Ci potrebbe essere qualche spiegazione necessaria per il motivo per cui è così.

1. Perchè dico così.
2. I plugin devono solo essere conformi al core perché se tutti giocano con le regole, nulla fallirà. Se un plugin non gioca con le regole, allora ha un bug . E quel bug ha bisogno di essere risolto e non altro e non un altro plugin o tema.
3. Gli utenti che non aggiornano WordPress sono il risultato di plugin buggy che vengono utilizzati e che non possono essere abbandonati nei sistemi senza molto lavoro. Come scritto in (2), sono bug di cui non devi preoccuparti. I bug devono essere corretti, non il tuo plugin considerando il codice di terze parti non funzionante.
4. Il codice legacy non ha bisogno di supporto. Deve essere sostituito. Non è un tuo problema.
5. Le cose cambiano su larga scala rispetto alle principali versioni XX. Quando si tenta di supportare le versioni precedenti, spesso sono necessarie diverse soluzioni alternative e numerosi controlli della versione. Cioè (a) un incubo di manutenzione (b) aumenta la base di codice (c) rende impossibili i test unitari poiché devono essere eseguiti su una versione - non meno, non di più e infine (d) ridurre lo spazio su disco e le prestazioni del server (in la maggior parte dei casi).
6. WordPress ha già una base di codice molto vecchia che manca di miglioramenti in molti spigoli e angoli. In breve: WordPress è vecchio, utilizza una versione di PHP non più supportata come minimo e quindi stai già supportando le versioni precedenti a livelli molto inferiori rispetto all'API pubblica della tua applicazione.

Ora vai a chiederti:

Quando stai già supportando una versione PHP non più supportata, perché dovresti voler supportare un'applicazione che non è nemmeno supportata dai suoi creatori?

Ricorda il rilascio di WordPress 3.0 richiesto PHP5. All'epoca, molte società di hosting non eseguivano ancora PHP5 sui propri server. Quindi c'è stato un periodo di tempo in cui alcuni siti di WordPress non potevano aggiornare a WordPress 3.0 perché le loro società di hosting non tenevano aggiornati i loro server.

Sono passati molti anni (3+) dal rilascio di WordPress 3.0, quindi essere retrocompatibili con WordPress <3.x non è un plugin molto comune.

La maggior parte delle installazioni di WordPress sono obsolete . Attualmente, solo il 5,2% di tutte le installazioni è in esecuzione sull'ultima versione 3.6.
Il 27,3% è ancora nella versione 3.0.

Potresti pensare di dover supportare queste vecchie versioni con codice compatibile. Ma pensa alle implicazioni:

• Devi testare tutte le versioni ufficialmente supportate.
• Devi gestire API incompatibili come l'uploader multimediale, che è cambiato drasticamente in 3.5.
• Fai in modo che i tuoi utenti pensino che sia giusto non aggiornare WordPress, perché funziona ancora.
• Hai bisogno di più codice, più test e più tempo per il supporto per fare le stesse cose.

E gli utenti di questi probabilmente non installeranno nemmeno il tuo plugin perché sanno che già nuovi plugin rompono il loro sito. In termini di copertura del mercato potresti vincere un po 'con un codice compatibile con le versioni precedenti. In termini di efficienza, perdi.

La mia regola empirica per i plug-in che scrivo è il supporto per la versione corrente meno 1, quindi tutti i plug-in che scrivo sarebbero compatibili con 3.6.xe 3.5.x. Mentre un particolare plug-in potrebbe funzionare su versioni precedenti, non lo garantisco né lo supporto se si verificano problemi.

Quattro mesi fa, ho assunto la manutenzione di un plugin popolare. Prima di iniziare a lavorarci su, il plugin non aveva avuto un aggiornamento da 2 anni. Ho fatto un sacco di correzioni di bug, ho rilasciato la nuova versione e 2 giorni dopo ho sentito da un ragazzo che ha detto che la nuova versione ha causato lo schermo bianco della morte sul suo sito. Dopo averlo esaminato, stava ancora eseguendo WordPress 2.9.2 e il mio aggiornamento utilizzava la funzione home_url, introdotta in 3.0. Non ho idea del perché il ragazzo abbia deciso di aggiornare immediatamente questo plugin, anche se non ha aggiornato la sua installazione di WordPress da 3 anni. Quando ho realizzato la nuova versione, non ho mai pensato di testare WordPress 2.9.2.

Ecco la morale della storia: nel file readme.txt del tuo plugin , c'è un numero di versione "Richiede almeno" nell'intestazione. Usalo Man mano che effettui gli aggiornamenti, se non hai voglia di provare le versioni precedenti, incrementale. Ciò scoraggerà gli utenti che si rifiutano di aggiornare le proprie installazioni di WordPress dall'aggiornamento del plug-in.

Attualmente sto scrivendo un nuovo plugin correlato e sto pianificando di renderlo solo WordPress 3.6, perché voglio usare la libreria getid3 inclusa nel core. Non desidero rilasciare un nuovo plug-in per una versione precedente.