Echipa de dezvoltare Gutenberg confirmă că API-ul Meta Box nu va fi depreciat oficial

Discuția despre modul în care Gutenberg va gestiona metabox-urile s-a încălzit în weekend după ce un participant a comentat problema GitHub cu îngrijorare cu privire la eliminarea suportului metabox de la cea mai recentă etapă.

„Văd că această problemă vitală a fost eliminată din orice piatră de hotar”, a spus @steveangstrom. „A fost de-prioritizat din nou, în timp ce clopotele și fluierele pentru editarea blogului au multă muncă și sunt adăugate la beta. Acest lucru este foarte îngrijorător pentru viitorul WordPress ca CMS.”

James Nylen, unul dintre dezvoltatorii principali ai proiectului, i-a asigurat pe adepții subiectului că echipa Gutenberg nu a uitat de problemă, ci mai degrabă că este „o problemă extrem de complicată pe care abia începem să o analizăm, împreună cu mulți, multe alte priorități pentru ca editorul să funcționeze bine.” El a cerut, de asemenea, ajutor din partea comunității în planificarea și testarea implementărilor pentru sprijinirea casetelor meta.

Acest răspuns a lăsat multe lucruri neclare. Participanții la discuție, dintre care mulți sunt dezvoltatori preocupați de perspectiva de a fi nevoiți să rescrie toate metabox-urile ca componente React, se întreabă de ce metabox-urile nu pot funcționa împreună cu noul editor Gutenberg și de ce echipa a ales să includă metabox-uri în domeniul de aplicare al proiectului.

„Este posibil să înlocuim editorul de postări TinyMCE existent cu Gutenberg, lăsând restul interfeței, inclusiv casetele meta și cârligele existente, neschimbate?” întrebă Kevin Hoffman. Când Nylen a clarificat că Gutenberg, așa cum este scris astăzi, este destinat să fie un editor post_content , Hoffman a rezumat preocupările exprimate de mulți dezvoltatori:

Dacă Gutenberg este cu adevărat destinat să fie un editor post_content , atunci casetele meta ar trebui lăsate în pace, deoarece nu sunt preocupate de post_content .

În plus, necesitatea unui API pentru a traduce metabox-urile PHP în metabox React este o problemă fabricată. Nu trebuie să fie o problemă, dar a devenit o problemă pentru că undeva de-a lungul liniei s-a decis că rescrierea editorului post_content ar trebui, de asemenea, să schimbe complet modul în care funcționează metabox-urile.

Ați subliniat provocarea extraordinară de a scrie un astfel de API în #2251. Traducerea metabox-urilor PHP în React pentru o soluție populară de câmpuri personalizate precum ACF este destul de dificilă, cu atât mai puțin să încercăm să faceți acest lucru pentru fiecare implementare metabox care există astăzi, populară sau nu. Nu scala.

Deoarece colaboratorii Gutenberg au spus că abia au început să se uite la problema metaboxului, acum este clar de ce nu există nicio foaie de parcurs pentru modul în care proiectul va gestiona metabox-urile PHP „moștenite”. În iulie, Nylen a spus: „Dacă ar trebui să ghicesc unde vom ajunge aici: metabox-urile actuale vor fi mutate într-o zonă „moștenită” și vom oferi API-uri, documentație și exemple pentru înregistrarea blocului metabox-ului „în stil nou”. - lucruri.”

Dezvoltatorii de pluginuri care gestionează biblioteci metabox, agenții și alte părți interesate urmăresc biletul pentru a afla cum să planifice WordPress 5.0, care a fost vizat ca lansarea Gutenberg. Andrey Savchenko a întrebat dacă WordPress intenționează să deprecieze în mod oficial API-ul meta box, ceea ce a atras în cele din urmă un răspuns clar din partea echipei. Matias Ventura a răspuns:

„Intenționează WordPress să deprecieze în mod oficial API-ul Metabox?”
Nu.

Întrebarea la care încă nu s-a răspuns complet este cum funcționează meta-boxele în contextul editorului Gutenberg. Ar trebui să rămână aceleași sau să evolueze? Cum ne putem îndrepta către obiectivele de proiectare cu cel mai mic nivel de întrerupere posibil?

Această problemă persistă nu din cauza lipsei de dorință, ci a lipsei de resurse. Obiectivul principal al acestui proiect este de a oferi o interfață bogată de editare a conținutului, care să optimizeze pentru manipularea directă a conținutului utilizatorului prin noțiunea de blocuri. (După ce am folosit meta-box-uri pe scară largă pentru diverse proiecte, cred că blocurile pot oferi un pas mai bun înainte pentru multe dintre aceste nevoi, oferind în același timp o experiență mai bună pentru utilizator.)”

Ventura a enumerat mai multe opțiuni pe care echipa le-a luat în considerare pentru manipularea meta-box-urilor și a solicitat ajutor comunității pentru a construi cea mai bună soluție:

• Dacă detectăm că o meta-box este înregistrată, putem reveni la vechea interfață, nimic nu se schimbă.
• Am putea împărți editarea conținutului și modificarea meta informațiilor în două ecrane sau etape.
• Putem încerca să vedem cât de fezabil este să le redăm așa cum sunt (PHP) sub conținut: #2251.
• O temă/plugin/CPT ar putea anula înregistrarea noii interfețe după cum este necesar.
• Diverse articole care s-au bazat pe metaboxuri puteau fi convertite în blocuri pentru interfața de utilizare (încă stochează datele separat).
• Am putea implementa extensibilitatea metaboxelor bazată pe API, cum ar fi API-ul Fields.

Când a fost presat să răspundă la întrebarea de ce sunt incluse meta boxele în contextul noului editor, liderul de proiectare Gutenberg, Joen Asmussen, a clarificat modul în care echipa a decis să includă metabox-urile în domeniul de aplicare al proiectului:

Gutenberg a început doar cu caseta editorului. Scopul lansării a fost de a unifica mai multe interfețe disparate sub o singură interfață bloc unificată. A devenit rapid evident că, pentru a crea o experiență convingătoare care se învârte în jurul acestei interfețe bloc unificate, a trebuit să luăm în considerare întregul flux de scriere, inclusiv setări și publicare.

Dacă punctul forte al WordPress este acela de a face mai ușor pentru oricine să creeze postări bogate, atunci nu putem doar să proiectăm pentru cei dintre noi care știu deja să folosească editorul. Trebuie să luăm în considerare utilizatorii care nu au folosit niciodată WordPress până acum și ceea ce se așteaptă la o interfață modernă de publicare. Altfel, am adăuga doar încărcătură cognitivă unei interfețe deja grele.

Întrebarea cum se vor încadra meta boxele în contextul editorului Gutenberg este încă deschisă. Participanții la discuție sunt nerăbdători să li se răspundă la această întrebare de dragul compatibilității inverse și, de asemenea, pentru că afectează deciziile în curs privind dezvoltarea Gutenberg și designul ecranului.

„Întâlnesc complet cât de multă muncă s-a făcut pentru abordarea înlocuirii „ecranului””, a comentat Xavi Ivars despre această problemă. „Dar un proiect care a început cu scopul înlocuirii unui „editor de post conținut” nu ar trebui să se întoarcă în comunitate înainte de a decide unilateral că va înlocui întregul ecran al editorului?”

API-ul meta box nu este depreciat, dar nu există nicio cale clară pentru cum va accepta Gutenberg metabox-urile PHP „moștenite”. Echipa Gutenberg a spus că problema nu a fost rezolvată din cauza lipsei de resurse. Proiectul are nevoie de aportul comunității și de o comunicare mai bună dacă echipa va ajunge la o soluție care va introduce fără probleme majoritatea site-urilor WordPress în era Gutenberg cu cel mai mic nivel de ruptură.

În prezent, fezabilitatea redării metabox-urilor PHP vechi sub conținut este plină de provocări și încă dezbătută. Dacă nu există suficient timp sau resurse pentru clienți pentru ca dezvoltatorii să-și rescrie munca în metabox-uri bazate pe JS, atunci poate fi necesară o cale clară pentru a renunța la interfața Gutenberg pentru site-urile care trebuie să păstreze moștenirea metabox-urilor „PHP” .