I contributori di Gutenberg discutono degli svantaggi dell'utilizzo di iframe per Meta Box

Pubblicato: 2017-11-04
credito fotografico: Scatola quadrata chiusa, variazione – (licenza)

Su GitHub è in corso una discussione vivace e produttiva sull'uso da parte di Gutenberg degli iframe per i meta box. Ieri, lo sviluppatore di WordPress Kevin Hoffman ha creato un problema intitolato "Gli iframe sono una valida soluzione a lungo termine per i meta box?"

Gutenberg 1.5 ha introdotto il supporto iniziale per i meta box. Hoffman ha identificato diversi problemi con gli iframe che sono emersi quando gli sviluppatori hanno iniziato a testare l'attuale implementazione della meta box. Ha eseguito alcuni test delle prestazioni che hanno rivelato che l'uso degli iframe da parte di Gutenberg triplica il numero di richieste di asset, poiché accoda tutti gli asset CSS e JS nella finestra padre e in tutti gli iframe.

credito immagine: Kevin Hoffman

"In generale, gli iframe sono stati scoraggiati nello sviluppo web per molti anni per ragioni ben documentate", ha affermato Hoffman, prima di citare una litania di problemi che gli sviluppatori di plugin hanno già scoperto testando il supporto meta box di Gutenberg. "È possibile risolvere questi problemi senza richiedere la modifica del tema o del plug-in che genera il meta box? Dobbiamo considerare che il codice di terze parti che ha alimentato meta box per anni potrebbe non avere il lusso di essere aggiornato per essere compatibile all'interno di un iframe".

Tammie Lister, responsabile del design di Gutenberg, ha risposto alle preoccupazioni di Hoffman, indicando che l'attuale implementazione di meta box è semplicemente un esperimento e non necessariamente ciò che atterrerebbe in WordPress 5.0:

È bello pensare un po' che quello che abbiamo oggi per i meta box a Gutenberg è un esperimento, per molti aspetti è un modello di tenuta mentre il progetto elabora la direzione da prendere. Nel dire che è uno che funziona "per ora" ma non è quello con cui spediremmo.

Tutto quanto sopra detto, penso che sia importante guardare a cosa verranno utilizzati in futuro i metabox. Quali sono i casi (se presenti) che non verrebbero convertiti in blocchi? Tutti i metabox devono funzionare su dispositivi mobili? C'è anche un'interfaccia alternativa che non abbiamo esplorato? Scommetto che c'è. In questo momento, si tratta di guardare a quelle possibilità e mettersi su una strada che funzioni per lo stato in questo momento e per lo stato futuro.

La presentazione di questa implementazione come un esperimento che "funziona per ora" (ma non sarebbe stato distribuito) è una sorpresa dopo l'arrivo di Gutenberg 1.5 con l'annuncio che "questa versione include il tanto atteso supporto per le meta-box (necessita di test!)"

Hoffman sostiene che l'approccio iframe non funziona nemmeno "per ora", poiché la questione è stata aperta per citare diversi modi principali in cui è stata interrotta. Se Gutenberg avanza con l'approccio attuale, richiederebbe la modifica di molti plugin per essere compatibili con WordPress 5.0, cosa che secondo Hoffman vanificherebbe l'intero scopo di supportare meta box legacy.

"Finora non ho visto alcuna prova che suggerisca che i meta box continueranno a lavorare con Gutenberg", ha detto Hoffman. "Se la risposta è no, allora dovremmo smettere di fingere che la 5.0 sarà solo un'altra versione di WordPress e iniziare a essere onesti riguardo alla rottura della compatibilità con le versioni precedenti".

Edwin Cromley, un collaboratore del progetto, ha affermato che il team prevede che alcuni temi e plug-in verranno interrotti e che non è possibile soddisfare ogni possibile caso d'uso. Ha ammesso che la soluzione iframe potrebbe non soddisfare gli obiettivi del progetto. Invece, sostiene la creazione della migliore esperienza per la stragrande maggioranza degli utenti.

Tuttavia, l'approccio attuale influenzerebbe negativamente molti siti che utilizzano WordPress principalmente come CMS con meta box. Il committente principale di WordPress Scott Taylor ha espresso preoccupazione per i tipi di post personalizzati, molti dei quali non utilizzano la tradizionale sezione "contenuto" a favore dei soli meta box.

"In questa iterazione attuale, il supporto dei meta box è un componente aggiuntivo, quando nella realtà di molte persone, i meta box SONO l'interfaccia utente, l'API, il meccanismo che usano per comporre il loro CMS", ha affermato Taylor. “Gli iframe sono il gulag.

“E stiamo dimenticando per sempre i valori su cui è stato costruito WP: dovrei essere in grado di aggiornare all'ultima versione di WP e non dover riscrivere nulla. Ho così tanti progetti in libertà su WP che non toccherò mai più. Posso essere sicuro che alcuni di loro non si romperanno selvaggiamente con questo cambiamento?

Hoffman ha sostenuto di ridimensionare l'ambito del progetto per concentrarsi sulla componente editor, un'opinione popolare condivisa da molti sviluppatori di plugin e illustrata in dettaglio nel post di Yoast che propone un approccio alternativo a Gutenberg. Questo approccio mette in scena le modifiche alla schermata di modifica, dando agli sviluppatori più tempo per aggiornare i loro plugin, oltre a consentire al team di Gutenberg di trovare una soluzione adeguata per i meta box.

"Penso che l'obiettivo sarebbe molto più raggiungibile se Gutenberg si limitasse a rivedere l'editor piuttosto che occupare l'intera pagina", ha detto Hoffman. "Poi potremmo lasciare gli hook esistenti in posizione e i meta box potrebbero continuare a comunicare tra loro come fanno ora. Inoltre, l'accodamento delle risorse non sarebbe un problema poiché funzionerebbe come fa oggi.

"Sono in forte accordo con questo concetto proposto da Yoast, che mi sembra manterrebbe gran parte del lavoro già svolto mentre ridimensionerebbe l'ambito del progetto per concentrarsi sulla componente dell'editor".

L'ingegnere di Gutenberg Riad Benguella ha indicato che il team non è troppo entusiasta di lavorare su questo concetto.

"Riutilizzare pezzi di Gutenberg per costruire questo concetto è relativamente fattibile, ma questa non è l'UX per cui vogliamo ottimizzare, vogliamo prima creare il miglior editor possibile e renderlo disponibile per le persone senza problemi di compatibilità con le versioni precedenti (installazioni nuove, nessun metabox... ),” disse Benguella.

“Quando pensiamo che la visione ideale di Gutenberg sia pronta per la spedizione, avremo tempo per discutere le strategie del percorso di aggiornamento, un concetto come questo è un'opzione per un percorso di aggiornamento, ma sicuramente non come prodotto finale. Sono possibili anche altri percorsi di aggiornamento".

La comunità degli sviluppatori di WordPress, tuttavia, non è favorevole a ritardare ancora una volta questa discussione. Molti sono ansiosi di rispondere finalmente alla domanda su come i meta box si inseriranno nel contesto dell'editor di Gutenberg in modo da sapere come prepararsi. Dati i numerosi problemi con l'approccio iframes, il rendering di meta box PHP legacy con il nuovo editor richiederà più sperimentazione e possibilmente una soluzione alternativa.

"Perché dedicare migliaia di ore allo sviluppo dell'editor ideale se non può essere reso compatibile con i siti esistenti?" ha detto Hoffmann. "Se la prima impressione è che interrompe l'interfaccia utente da cui dipendono, gli utenti non sperimenteranno mai l'editor ideale in primo luogo".

"Penso che potrebbe essere un errore rimandare troppo oltre", ha detto Aaron Jorbin, committente principale di WordPress. "Soprattutto perché molte organizzazioni avranno bisogno di almeno 1-2 trimestri per prepararsi".

Mark Kaplun suggerisce al team di Gutenberg di utilizzare un popolare plug-in come indicatore del successo degli esperimenti di supporto dei meta box attuali e futuri.

"Il mio suggerimento produttivo è di non dichiarare pronte le meta box, a condizione che Yoast SEO non funzioni correttamente", ha affermato Kaplun. “È un po' complesso in termini di interazioni ed è installato su un sacco di siti di merda. Se Gutenberg non può lavorarci, probabilmente nessuno lo userà”.

Greg Schoppe, che ha testato e scritto ampiamente sullo sviluppo in corso di Gutenberg, si è unito alla conversazione per sostenere anche l'approccio alternativo di Yoast al progetto.

"Appoggio fortemente il punto di vista di Yoast su Gutenberg", ha detto Schoppe. "Non mi è chiaro come 'aggiornare l'editor visivo' sia stato reinterpretato per essere 'sostituire l'intera interfaccia di modifica post' dal team di Gutenberg, ma sembra direttamente in contrasto con la cosiddetta 'nave di Teseo.'

“In questo caso, la mancanza di una chiara direzione e supporto per i flussi di lavoro standard esistenti sta danneggiando attivamente gli sviluppatori ora. Come posso andare avanti costruendo un progetto, senza un set affidabile di ganci e strumenti su cui posso fare affidamento? È irragionevole pensare che un progetto software così grande capovolgerebbe completamente il flusso di lavoro standard per gli sviluppatori in un singolo aggiornamento. ed è folle che queste conversazioni avvengano solo ora, a novembre, quando il piano prevede l'approvazione di una fusione all'inizio dell'anno".

La discussione sull'approccio degli iframe alle meta box è stata aperta ieri è ancora relativamente nuova, ma finora le risposte del team di Gutenberg non sono riuscite ad affrontare adeguatamente le preoccupazioni della comunità di sviluppatori in questo thread. Trovare un approccio ai meta box che preservi le potenti capacità CMS di WordPress, senza alienare utenti e sviluppatori, è una delle maggiori sfide del team di Gutenberg. Stanno ancora puntando a produrre una proposta di fusione all'inizio del prossimo anno, ma con i meta box ancora in fase di sperimentazione, il calendario previsto dal team continua a mettere il progetto in contrasto con la comunità degli sviluppatori di WordPress.