Il team di sviluppo di Gutenberg conferma che l'API Meta Box non sarà formalmente deprecata

La discussione su come Gutenberg gestirà i meta box si è accesa durante il fine settimana dopo che un partecipante ha commentato il problema di GitHub con preoccupazione per la rimozione del supporto dei meta box dal traguardo più recente.

"Vedo che questo problema vitale è stato rimosso da qualsiasi pietra miliare", ha detto @steveangstrom. “È stato nuovamente de-priorizzato mentre campanelli e fischietti per la modifica del blog ottengono molto lavoro e vengono aggiunti alle versioni beta. Questo è molto preoccupante per il futuro di WordPress come CMS”.

James Nylen, uno degli sviluppatori principali del progetto, ha rassicurato i seguaci dell'argomento sul fatto che il team di Gutenberg non ha dimenticato il problema, ma piuttosto che si tratta di "un problema estremamente complicato che stiamo solo iniziando a esaminare, insieme a molti, molte altre priorità per far funzionare bene l'editor". Ha anche chiesto aiuto alla comunità per pianificare e testare le implementazioni per supportare i meta box.

Questa risposta ha lasciato molte cose poco chiare. I partecipanti alla discussione, molti dei quali sono sviluppatori preoccupati per la prospettiva di dover riscrivere tutti i loro meta box come componenti di React, si chiedono perché i meta box non possono funzionare insieme al nuovo editor Gutenberg e perché il team ha scelto di includere i meta box in la portata del progetto.

"È possibile sostituire l'editor di post TinyMCE esistente con Gutenberg lasciando invariato il resto dell'interfaccia, inclusi meta box e hook esistenti?" chiese Kevin Hoffman. Quando Nylen ha chiarito che Gutenberg, come scritto oggi, è destinato a essere un editor di post_content , Hoffman ha riassunto le preoccupazioni espresse da molti sviluppatori:

Se Gutenberg è veramente concepito per essere un editor di post_content , allora i meta box dovrebbero essere lasciati soli in quanto non si occupano di post_content .

Inoltre, la necessità di un'API per tradurre meta box PHP in meta box React è un problema artificiale. Non deve essere un problema, ma è diventato un problema perché da qualche parte lungo la linea è stato deciso che la riscrittura dell'editor post_content dovrebbe anche cambiare completamente il funzionamento dei meta box.

Hai delineato l'enorme sfida di scrivere un'API di questo tipo nel numero 2251. Tradurre meta box PHP in React per una popolare soluzione di campi personalizzati come ACF è abbastanza impegnativo, per non parlare di provare a farlo per ogni implementazione di meta box che esiste oggi, popolare o meno. Non scala.

Poiché i contributori di Gutenberg hanno condiviso di aver appena iniziato a esaminare il problema dei meta box, ora è chiaro perché non esiste una tabella di marcia su come il progetto gestirà i meta box PHP "legacy". A luglio, Nylen ha dichiarato: "Se dovessi indovinare dove andremo a finire qui: i metabox attuali verranno spostati in un'area "legacy" e forniremo API, documentazione ed esempi per la registrazione di metabox-block di 'nuovo stile' -cose."

Gli sviluppatori di plug-in che gestiscono librerie di meta box, agenzie e altre parti interessate stanno seguendo il ticket per scoprire come pianificare WordPress 5.0, che è stato preso di mira come rilascio di Gutenberg. Andrey Savchenko ha chiesto se WordPress prevede di deprecare formalmente l'API meta box, che alla fine ha ottenuto una risposta chiara dal team. Matias Ventura ha risposto:

"WordPress intende deprecare formalmente l'API Metabox?"
No.

La domanda a cui non è stata ancora data una risposta completa è come funzionano i meta-box nel contesto dell'editor di Gutenberg. Dovrebbero rimanere gli stessi o evolversi? Come possiamo muoverci verso gli obiettivi di progettazione con il minor numero possibile di interruzioni?

Questo problema persiste non per mancanza di desiderio, ma per mancanza di risorse. L'obiettivo principale di questo progetto è offrire una ricca interfaccia di editing dei contenuti che ottimizzi la manipolazione diretta del contenuto dell'utente attraverso la nozione di blocchi. (Avendo utilizzato ampiamente i meta-box per vari progetti, credo che i blocchi possano offrire un passo avanti migliore per molte di queste esigenze fornendo al contempo una migliore esperienza utente.)"

Ventura ha elencato diverse opzioni che il team ha preso in considerazione per la gestione dei meta box e ha chiesto aiuto alla community per creare la soluzione migliore:

• Se rileviamo che una meta-box è registrata, possiamo eseguire il fallback alla vecchia interfaccia, non cambia nulla.
• Potremmo dividere la modifica del contenuto e la modifica delle meta informazioni in due schermate o fasi.
• Possiamo provare a vedere quanto sia fattibile renderli così come sono (PHP) sotto il contenuto: #2251.
• Un tema/plugin/CPT potrebbe annullare la registrazione della nuova interfaccia secondo necessità.
• Vari elementi che si basavano su meta box potevano essere convertiti in blocchi per l'interfaccia utente (conservando ancora i dati separatamente).
• Potremmo implementare l'estendibilità delle meta box basata su API come l'API Fields.

Quando è stato chiesto di rispondere alla domanda sul motivo per cui i meta box vengono inclusi nel contesto del nuovo editor, il responsabile del design di Gutenberg Joen Asmussen ha chiarito come il team abbia deciso di includere i meta box nell'ambito del progetto:

Gutenberg ha iniziato solo con la casella dell'editor. L'obiettivo iniziale era unificare più interfacce disparate in un'unica interfaccia a blocchi unificata. È diventato subito evidente che per creare un'esperienza avvincente che ruotasse attorno a questa interfaccia a blocchi unificata, dovevamo considerare l'intero flusso di scrittura, incluse le impostazioni e la pubblicazione.

Se il punto di forza di WordPress è rendere facile per chiunque creare post ricchi, allora non possiamo progettare solo per quelli di noi che sanno già come usare l'editor. Dobbiamo considerare gli utenti che non hanno mai utilizzato WordPress prima e cosa si aspettano da una moderna interfaccia di pubblicazione. Altrimenti aggiungeremmo solo carico cognitivo a un'interfaccia già pesante.

La questione di come i meta box si inseriranno nel contesto dell'editor di Gutenberg è ancora aperta. I partecipanti alla discussione sono ansiosi di avere una risposta a questa domanda per motivi di compatibilità con le versioni precedenti e anche perché influisce sulle decisioni in corso relative allo sviluppo di Gutenberg e al design dello schermo.

"Ho completamente capito quanto lavoro è stato fatto per l'approccio di sostituzione dello 'schermo'", ha commentato Xavi Ivars in merito al problema. "Ma un progetto iniziato con l'obiettivo di sostituire un 'editor di contenuti di post' non dovrebbe tornare alla community prima di decidere unilateralmente che avrebbe sostituito l'intero schermo dell'editor?"

L'API meta box non è stata deprecata, ma non c'è nemmeno un percorso chiaro su come Gutenberg supporterà meta box PHP "legacy". Il team di Gutenberg ha affermato che il problema non è stato risolto per mancanza di risorse. Il progetto ha bisogno del contributo della comunità e di una migliore comunicazione se il team intende trovare una soluzione che introdurrà senza problemi la maggior parte dei siti WordPress nell'era di Gutenberg con il minor numero di interruzioni.

Attualmente, la fattibilità del rendering di meta box PHP legacy sotto il contenuto è piena di sfide e ancora in discussione. Se non c'è abbastanza tempo o risorse client per gli sviluppatori per riscrivere il loro lavoro in meta box basati su JS, potrebbe essere necessario un percorso chiaro per la disattivazione dell'interfaccia Gutenberg per i siti che devono preservare i meta box "PHP" legacy .