Il progetto API di WordPress Core Fields sta cercando una nuova leadership

Nel 2014, lo sviluppatore principale di Pods, Scott Kingsley Clark, ha assunto il ruolo principale principale per il progetto Metadata UI. Nel 2015, il progetto Metadata UI è rinato come API Fields.

L'API Fields è stata sviluppata per consentire la registrazione dei campi in diverse schermate nell'area di amministrazione tramite un'unica API. Nuovi meta box e campi al loro interno potrebbero essere aggiunti ai post mentre nuove sezioni e campi potrebbero essere aggiunti alla schermata del profilo.

L'obiettivo dell'API è integrarsi con tutte le varie schermate di amministrazione, inclusi Post, Termini, Utenti, Media e Commenti e fornire la standardizzazione.

Clark ha guidato il progetto per tre anni e, nonostante abbia visto un rinnovato interesse l'anno scorso, ha annunciato nel canale Slack del progetto che si dimetterà.

È con il cuore pesante che devo passare il testimone a questo progetto. Dopo centinaia di ore del mio tempo, non credo più di poter apportare modifiche all'interno del core di WordPress.

La visione dell'API Fields era troppo grande, troppo impegnativa per chiunque. Credo così profondamente che WordPress abbia bisogno di un'API Fields, ma il viaggio verso il punto in cui siamo con l'API Fields è stato lungo e arduo.

La verità è che mi sono esaurito anni fa mentre costruivo il primo e il secondo prototipo. Non tutti erano d'accordo su come architettare il codice, ha subito molte revisioni in base al feedback dei contributori principali. Non riuscivo a convincere abbastanza persone entusiaste di questo, non riuscivo a convincere abbastanza aziende e persone interessate a supportarlo.

Devo lasciare che qualcun altro abbia la sua possibilità, la sto trascinando verso il basso. Se qualcuno si fa avanti per guidare in futuro, sarei felice di assisterlo dove posso. Ma non sono in grado di continuare a guidare la proposta/progetto API Fields. Mi dispiace, per favore accetta le mie scuse e spero che tu possa perdonarmi per non aver portato questo progetto oltre il traguardo. Credo ancora di essere una parte così vitale del successo futuro di WordPress.

Scott Kingsley Clark

Le prove e le tribolazioni di condurre un progetto open source

Nella seguente intervista, Clark spiega perché si sente personalmente responsabile della mancanza di progressi nel progetto, perché l'API è importante per il futuro di WordPress e riflette su cosa avrebbe potuto fare diversamente.

Vuoi passare il testimone a qualcuno in particolare?

No, non sono sicuro di chi avrebbe la spinta e il potere per portare a termine il progetto. È un progetto su larga scala che dovrebbe essere affrontato con una visione a lungo termine, ma con incrementi abbastanza piccoli da diventare il core di WordPress. È molto da chiedere a qualcuno, inoltre non è una priorità per le persone in questo momento poiché sono distratte dal rilascio di Gutenberg nel prossimo futuro.

Perché l'API Fields è una parte vitale del futuro di WordPress?

Le persone guardano WordPress oggi e si chiedono come siano mai sopravvissute senza l'API REST. Beh, almeno so di sì! La stessa cosa si può dire dell'API Fields anche se non è ancora disponibile. Ci sono così tanti casi in cui è frustrante creare soluzioni per WordPress attraverso tutti i diversi hook.

Per coerenza, è il selvaggio west là fuori. Ottieni una meta box registrata e la riempi con quello che vuoi. Hai bisogno del tuo CSS per definire lo stile dei campi del modulo e ognuno ha la propria idea di come dovrebbe apparire questa interfaccia. Sei responsabile dei tuoi layout reattivi che sono ottimizzati per i dispositivi mobili, c'è così tanto che devi gestire da solo. Dovresti essere in grado di personalizzare gli aspetti, ma ogni luogo in cui desideri aggiungere un campo o un modulo dovrebbe davvero avere un'API adeguata.

A lungo termine, immagina di registrare i campi su WordPress come se registri i tipi di post. Immagina che i campi e le relative configurazioni siano disponibili per l'API REST e accessibili tramite l'app WordPress o altre app personalizzate.

Il mondo intero si apre perché hai un'API coerente, il mondo intero ha senso perché hai un'interfaccia coerente per quei campi nelle varie schermate di modifica. Post, termini, commenti, utenti, media, persino il Customizer avrebbero tutti la stessa API sottostante per aggiungere gruppi, pannelli e campi alle loro schermate.

Se Gutenberg fosse stato completato dopo l'attivazione dell'API Fields, la migrazione per le persone non sarebbe stata così difficile. Gutenberg avrebbe potuto mostrare automaticamente tutte le interfacce API Fields come fa per la compatibilità con le versioni precedenti della meta box. Sarebbe stato anche molto più bello.

Prendendoti del tempo per riflettere, cosa avresti potuto fare di diverso per convincere più contributori principali ad accettare il progetto e trasformarlo in una priorità più alta?

Non ne sono sicuro, è un delicato equilibrio tra prendere input ed essere fiduciosi nel risultato finale. All'inizio, il feedback riguardava il modo in cui l'API era estranea per WordPress, hanno chiesto se potesse essere simile nella struttura ad altre API come Customizer.

Abbiamo scartato il codice e ricostruito da zero come un fork del Customizer, supportava anche il fatto che il Customizer utilizzasse anche l'API Fields. Al culmine dello sviluppo, abbiamo implementato tutte le aree dell'API Fields.

Le versioni principali si stavano muovendo abbastanza velocemente, c'erano molte modifiche al codice da una versione all'altra di WordPress con cui dovevamo tenere il passo perché avevamo essenzialmente creato un progetto che era una patch gigante per WordPress.

Non c'erano abbastanza hook in atto per fare ciò che dovevamo fare e molte sezioni non erano estensibili a causa di decisioni di codice che si contrassegnavano come "finali", il che significa che non è possibile estendere una classe specifica per personalizzarne il funzionamento.

Avrei voluto partecipare a tutti i grandi WordCamp negli Stati Uniti e in Europa, essenzialmente facendo pressioni per questa funzione. Raccogliere sostenitori e cose del genere, in un certo senso sembra politica. Sono rimasto in giro nelle riunioni degli sviluppatori Core, cercando di tirarlo fuori. Ho cercato di legittimare la funzionalità avendo un canale dedicato nello Slack ufficiale di WordPress, pubblicando aggiornamenti su https://make.wordpress.org/core/ e tenendo riunioni settimanali.

Alla fine, ho dato la priorità al mio tempo per lo sviluppo nel tempo per raccogliere le truppe. Questa è stata la rovina, ho iniziato a esaurirmi rapidamente dopo le prime riscritture poiché avevo molte altre responsabilità altrove oltre all'API Fields.

Non è che le aziende vogliano facilmente pagarti per lavorare a un progetto come questo a tempo indeterminato, anche se sia WebDevStudios che 10up mi hanno dato il tempo di portarlo avanti. Non era un assegno in bianco, a un certo punto dovevo tornare al lavoro fatturabile. Da quel momento in poi, è stato tutto nel mio tempo libero ed è stato difficile da gestire durante i periodi di stress finanziario e di vendita/acquisto di case.

C'è richiesta di un'API Fields nel core ma non abbastanza mani per costruirla. Perché pensi che lo sia?

Tutti sono concentrati altrove. Ci sono molte aree di WordPress che richiedono l'attenzione delle persone. Ci sono cose come l'accessibilità che meritano molta più attenzione di quanta ne ottenga. Ma l'attenzione per me sembra essere su Gutenberg e sull'API REST.

Gutenberg in particolare è stato un enorme dispendio di tempo per le persone che contribuiscono e le persone che implementano. È una caratteristica davvero grande. È decisamente più grande dell'API Fields, è come un'app completamente nuova che vive in WordPress. L'integrazione con esso ha richiesto molta istruzione e tentativi/errori. L'attenzione delle persone è dove deve essere in questo momento. È solo un peccato che Gutenberg sia arrivato prima dell'API Fields in termini di priorità e livello di interesse.

Che consiglio daresti al prossimo project leader di Fields API?

Questo è un grande progetto, tutti vorranno dire che dovrebbe essere in un certo modo. Devi valutare le opzioni e proporre qualcosa delle dimensioni di un morso per iniziare con il core. Costruisci su questo, ma non perdere mai di vista l'obiettivo a lungo termine dell'integrazione su tutti gli schermi di WordPress. Anche i moduli di commento front-end potrebbero prosperare con l'API Fields.

Perché ti senti personalmente responsabile del fatto che il progetto non sia una priorità fondamentale?

Ad un certo punto, abbiamo avuto slancio. Avevamo almeno tre o quattro persone che erano attive. È andato in pezzi perché ho esaurito il tempo. È la mia miopia, è colpa mia. Ho passato centinaia di ore a sviluppare il progetto in un paio d'anni. Avrei dovuto lasciare a me stesso molto più tempo per organizzare il testo della proposta di funzionalità e mantenere il fuoco acceso nei cuori dei nostri contributori.

Considerando il tempo e gli sforzi che hai dedicato al progetto negli ultimi anni, senti un senso di sollievo nel passare il testimone?

Se la torcia viene superata o raccolta, mi sentirò molto meglio. Il sollievo principale è che ufficialmente non è più un peso che devo portare da solo. Va bene provare e fallire, è comunque triste.

Spero che qualcuno o qualche azienda si faccia avanti e dedichi tempo a questo. Potrebbero persino riaccendere il fuoco nel mio cuore che si è spento da solo. Per ora, ho una cosa da fare in meno. Ho ancora un piatto pesante ma non è più un peso così pesante.

Sebbene l'immediato futuro del progetto non sia chiaro, coloro che sono interessati a prenderne il controllo sono incoraggiati a leggere i post contrassegnati con il tag API Fields su Make.WordPress.Core per conoscere la sua storia. Puoi anche controllare la pagina Github del progetto.

Se sei interessato a rilevare il progetto, puoi contattare Clark su Twitter, Slack o tramite il suo sito web.