Colaboratorii Gutenberg discută despre dezavantajele utilizării iframe-urilor pentru casetele meta

Publicat: 2017-11-04
credit foto: casetă pătrată închisă, variație – (licență)

Pe GitHub are loc o discuție plină de viață și productivă cu privire la utilizarea de către Gutenberg a iframe-urilor pentru metabox-uri. Ieri, dezvoltatorul WordPress Kevin Hoffman a creat o problemă intitulată „Sunt iframe-urile o soluție viabilă pe termen lung pentru casetele meta?”

Gutenberg 1.5 a introdus suport inițial pentru casetele meta. Hoffman a identificat mai multe probleme cu iframe-urile care au apărut pe măsură ce dezvoltatorii au început să testeze implementarea actuală a metabox-urilor. A făcut niște teste de performanță care au dezvăluit că utilizarea de către Gutenberg a iframe-urilor triplează numărul de solicitări de active, deoarece pune în coadă toate activele CSS și JS în fereastra părinte, precum și în toate iframe-urile.

credit imagine: Kevin Hoffman

„În general vorbind, iframe-urile au fost descurajate în dezvoltarea web de mulți ani din motive bine documentate”, a spus Hoffman, înainte de a cita o serie de probleme pe care dezvoltatorii de plugin-uri le-au descoperit deja în testarea suportului metabox al lui Gutenberg. „Pot fi rezolvate aceste probleme fără a necesita modificarea temei sau a pluginului care generează metabox-ul? Trebuie să luăm în considerare că codul terță parte care a alimentat metabox-uri de ani de zile poate să nu aibă luxul de a fi actualizat pentru a fi compatibil într-un iframe.”

Conducătorul designului Gutenberg, Tammie Lister, a răspuns îngrijorărilor lui Hoffman, indicând că implementarea actuală a metabox-urilor este pur și simplu un experiment și nu neapărat ceea ce ar ateriza în WordPress 5.0:

Este bine să ne gândim puțin că ceea ce avem astăzi pentru metabox-uri în Gutenberg este un experiment, în multe privințe este un model de reținere, deoarece proiectul stabilește direcția de urmat. Spunând că este unul care funcționează „deocamdată”, dar nu este ceea ce am livra.

Toate cele spuse mai sus, cred că este important să ne uităm la ce vor fi folosite în viitor metabox-urile. Care sunt cazurile (dacă există) care nu ar fi convertite în blocuri? Toate metabox-urile trebuie să funcționeze pe mobil? Există măcar o interfață alternativă pe care nu am explorat-o? Pun pariu că există. În acest moment, este vorba de a privi acele posibilități și de a merge pe un drum care funcționează pentru stat chiar acum și pentru viitorul stat.

Prezentarea acestei implementări ca un experiment care „funcționează deocamdată” (dar nu ar fi livrat) vine ca o surpriză după ce Gutenberg 1.5 a sosit cu anunțul că „această versiune include suport mult așteptat pentru meta-box-uri (necesită testare!)”

Hoffman susține că abordarea iframe nici măcar nu funcționează „deocamdată”, deoarece problema a fost deschisă pentru a cita mai multe moduri majore în care este ruptă. Dacă Gutenberg va merge mai departe cu abordarea actuală, ar necesita modificarea multor plugin-uri pentru a fi compatibile cu WordPress 5.0, despre care Hoffman a spus că ar învinge întregul scop de a sprijini casetele meta vechi.

„Nu am văzut nicio dovadă până în prezent care să sugereze că metabox-urile vor continua să lucreze cu Gutenberg”, a spus Hoffman. „Dacă răspunsul este nu, atunci ar trebui să încetăm să ne prefacem că 5.0 va fi doar o altă lansare WordPress și să începem să fim sinceri cu privire la ruperea compatibilității cu versiunea inversă.”

Edwin Cromley, un colaborator la proiect, a spus că echipa anticipează că anumite teme și plugin-uri vor fi rupte și că nu este posibil să se găsească orice caz de utilizare posibil. El a recunoscut că soluția iframe ar putea să nu îndeplinească obiectivele proiectului. În schimb, el susține crearea celei mai bune experiențe pentru marea majoritate a utilizatorilor.

Cu toate acestea, abordarea actuală ar afecta negativ multe site-uri care folosesc WordPress în primul rând ca CMS cu casete meta. Scott Taylor, comisarul de bază pentru WordPress, și-a exprimat îngrijorarea cu privire la tipurile de postări personalizate, multe dintre ele nu folosesc secțiunea tradițională „conținut” în favoarea metaboxelor.

„În această iterație actuală, suportul metabox este un supliment, când în realitatea multor oameni, metabox-urile SUNT interfața de utilizare, API-ul, mecanismul pe care îl folosesc pentru a-și compune CMS-ul”, a spus Taylor. „Iframe-urile sunt gulagul.

„Și uităm de valorile pe care a fost construit WP pentru totdeauna: ar trebui să pot actualiza la cea mai recentă versiune de WP și să nu trebuie să rescriu nimic. Am atât de multe proiecte în sălbăticie pe WP pe care nu le voi mai atinge niciodată. Pot fi încrezător că unii dintre ei nu se vor rupe nebunești cu această schimbare?”

Hoffman a susținut reducerea sferei de aplicare a proiectului pentru a se concentra pe componenta editor, o opinie populară pe care mulți dezvoltatori de plugin-uri o împărtășesc și una care a fost ilustrată în detaliu în postarea lui Yoast care propune o abordare alternativă a lui Gutenberg. Această abordare elaborează modificările la ecranul de editare, oferind dezvoltatorilor mai mult timp pentru a-și actualiza pluginurile, precum și permițând echipei Gutenberg să găsească o soluție adecvată pentru casetele meta.

„Cred că acest obiectiv ar fi mult mai realizabil dacă Gutenberg s-ar menține să revizuiască editorul, mai degrabă decât să preia întreaga pagină”, a spus Hoffman. „Atunci am putea lăsa cârligele existente la locul lor și meta-cutiile ar putea continua să comunice între ele așa cum fac acum. De asemenea, punerea în coadă a activelor nu ar fi o problemă, deoarece ar funcționa așa cum funcționează astăzi.

„Sunt puternic de acord cu acest concept propus de Yoast, care mi se pare că ar menține o mare parte din munca deja făcută, reducând în același timp domeniul de aplicare al proiectului pentru a se concentra pe componenta editor.”

Inginerul Gutenberg Riad Benguella a indicat că echipa nu este prea dornică să lucreze la acest concept.

„Reutilizarea pieselor Gutenberg pentru a construi acest concept este relativ fezabilă, dar acesta nu este UX-ul pentru care dorim să o optimizăm, vrem să construim mai întâi cel mai bun editor posibil și să-l punem la dispoziție pentru persoanele fără probleme de compatibilitate inversă (instalări noi, fără metabox-uri... ),” a spus Benguella.

„Când credem că viziunea ideală a lui Gutenberg este gata de livrare, vom avea timp să discutăm despre strategiile de upgrade, un concept ca acesta este o opțiune pentru o cale de upgrade, dar cu siguranță nu ca produs final. Sunt posibile și alte căi de upgrade.”

Comunitatea dezvoltatorilor WordPress nu este, totuși, în favoarea amânării acestei discuții încă o dată. Mulți sunt dornici să răspundă în sfârșit la întrebarea cum se vor potrivi casetele meta în contextul editorului Gutenberg, astfel încât să știe cum să se pregătească. Având în vedere numeroasele probleme legate de abordarea iframes, redarea casetelor meta PHP vechi sub noul editor va necesita mai multă experimentare și, eventual, o soluție alternativă.

„De ce să dedică mii de ore dezvoltării editorului ideal dacă acesta nu poate fi compatibil cu site-urile existente?” spuse Hoffman. „Dacă prima impresie este că rupe interfața de utilizare de care depind, utilizatorii nu vor experimenta niciodată editorul ideal în primul rând.”

„Cred că ar putea fi o greșeală să amâni asta prea mult”, a spus Aaron Jorbin, comisarul de bază WordPress. „Mai ales că multe organizații vor avea nevoie de cel puțin 1-2 trimestre pentru a se pregăti.”

Mark Kaplun sugerează ca echipa Gutenberg să folosească un plugin popular ca indicator pentru succesul experimentelor actuale și viitoare de suport metabox.

„Sugestia mea productivă este să nu declar metaboxele gata, atâta timp cât Yoast SEO nu funcționează corect în ele”, a spus Kaplun. „Este atât ușor complex în ceea ce privește interacțiunile și este instalat pe o mulțime de site-uri. Dacă Gutenberg nu poate lucra cu ea, probabil că nimeni nu o va folosi.”

Greg Schoppe, care a testat și a scris pe larg despre dezvoltarea continuă a lui Gutenberg, s-a alăturat conversației pentru a susține și abordarea alternativă a proiectului lui Yoast.

„Sustin cu căldură punctul de vedere al lui Yoast despre Gutenberg”, a spus Schoppe. „Nu este clar pentru mine cum „actualizați editorul vizual” a fost reinterpretat pentru a fi „înlocuiți întreaga interfață post-editare” de către echipa Gutenberg, dar pare direct în contradicție cu așa-numita „Nava lui Tezeu”.

„În acest caz, lipsa unei direcții clare și a suportului pentru fluxurile de lucru standard existente afectează în mod activ dezvoltatorii acum. Cum pot merge mai departe construind un proiect, fără un set de încredere de cârlige și instrumente pe care să mă pot baza? Este de neconceput să credem că un proiect software atât de mare ar schimba complet fluxul de lucru standard pentru dezvoltatori într-o singură actualizare. și este o nebunie că aceste conversații au loc abia acum, în noiembrie, când planul este să fie aprobată o fuziune la începutul anului.”

Discuția cu privire la abordarea iframes a meta boxelor a fost deschisă ieri este încă relativ nouă, dar până acum răspunsurile echipei Gutenberg nu au reușit să abordeze în mod adecvat preocupările comunității de dezvoltatori în acest thread. Găsirea unei abordări a metabox-urilor care păstrează capabilitățile CMS puternice ale WordPress, fără a înstrăina utilizatorii și dezvoltatorii, este una dintre cele mai mari provocări ale echipei Gutenberg. Ei încă urmăresc să producă o propunere de fuziune la începutul anului viitor, dar cu metaboxele încă în stadiul de experimentare, calendarul anticipat al echipei continuă să pună proiectul în contradicție cu comunitatea de dezvoltatori WordPress.