O nouă propunere cere contribuatorilor să oprească fuzionarea API-urilor experimentale de la Gutenberg la WordPress Core

Practica îmbinării API-urilor experimentale de la Gutenberg în nucleul WordPress s-ar putea să se încheie în curând. O nouă propunere, publicată de colaboratorul sponsorizat de Automattic, Adam Zielinski, solicită colaboratorilor să stabilizeze API-urile înainte de a le îmbina în core.

De-a lungul anilor, aproximativ 280 de API-uri experimentale au fost fuzionate din pluginul Gutenberg, pe care Zielinski l-a auditat într-un bilet pe care l-a deschis pentru această problemă în aprilie. În echilibrarea eforturilor de a mișca rapid cu iterarea editorului(elor) față de angajamentul WordPress față de compatibilitatea inversă, numărul de API-uri experimentale a devenit insuportabil, iar practica de îmbinare a acestora în core este acum reconsiderată în mod activ.

Oficial, API-urile experimentale sunt marcate ca atare pentru a descuraja utilizarea de către terți, deoarece se așteaptă să se schimbe. În practică, oamenii care creează pentru editorul de blocuri le folosesc oricum pentru că sunt în nucleu și doresc să extindă funcțiile pe care aceste API-uri le permit.

„Autorii de pluginuri și teme sunt forțați să se bazeze pe __experimental care ar putea fi eliminate sau modificate într-un mod incompatibil invers, în orice moment”, a spus Zielinski, făcând ecou frustrarea și preocupările pe care mulți dezvoltatori le-au avut față de proiect în ultimii câțiva ani. „Este o povară serioasă de întreținere. Fiecare nouă lansare Gutenberg/WordPress înseamnă schimbări potențial de ruptură.”

Compania de bază pentru WordPress Peter Wilson a comentat despre bilet, spunând că este în favoarea limitării API-urilor experimentale la un produs de vârf. Conducând acasă nevoia acestei schimbări, el a citat o serie de impacturi negative pe care aceste API-uri experimentale de bază le-au avut asupra ecosistemului:

• cei care nu sunt dispuși să folosească anumite funcții ale bibliotecii pentru a face sarcinile de bază mai ușoare, deoarece nu au încredere în fiabilitate
• dezvoltatorii nu mai actualizează site-urile client WP. Ca un committer de bază care s-a străduit să mențină compatibilitatea cu retrocompatibilitatea de ani de zile, acest lucru mă dezamăgește. Ca membru al echipei de securitate, este foarte îngrijorător
• dezvoltatorii care decid să includă copii ale pachetelor în teme și pluginuri, în loc să se bazeze pe wp.* globals. Din nou, acest lucru mă preocupă din punct de vedere al securității, dar mărește și sarcina utilă JavaScript mult mai mult decât menținerea compatibilității cu versiunea anterioară.
• rapoarte de întreruperi de compatibilitate inversă în versiunile minore: „nu vă așteptați ca o versiune 5.9.1 să distrugă capacitatea de răspuns a unei grămadă de imagini de pe site-urile noastre în afara editorului de blocuri”
• dezvoltatorii care iau în considerare să nu mai folosească blocuri de bază pentru că sunt prea instabile: „Am încetat să mai folosesc/am extins blocurile de bază pentru că se schimbau prea mult și am folosit blocuri ACF, astfel încât cel puțin să știu că pot face blocuri care nu vor pauză. Desigur, interfața de utilizare nu este la fel de bună ca blocurile de bază, dar voi lua oricând stabilitatea asupra blocurilor care se rup.”

Pluginul Gutenberg a fost menit să funcționeze ca un plugin de caracteristici în care sunt de așteptat întreruperi în compatibilitatea inversă, în timp ce colaboratorii șlefuiesc funcțiile înainte de a le îmbina în nucleu. Revenirea la rădăcinile acestei abordări și facerea editorului mai puțin experimentală se află în centrul acestei propuneri.

„Instabilitatea dintre versiuni începe deja să-i înstrăineze pe unii dintre cei mai mari avocați externi ai editorilor de bloc”, a spus Wilson.

Menținerea acestui nivel de instabilitate ar putea descuraja oamenii să construiască pe WordPress, împingându-i către alte proiecte mai simple, care sunt gestionate într-un mod diferit. Este posibil ca necesitatea de a se baza pe API-uri experimentale să-i fi descurajat pe dezvoltatori să construiască mai multe produse, încetinind adoptarea editorului de blocuri.

„Ca autor de pluginuri care utilizează în prezent multe __experimental -uri experimentale, mi-ar plăcea să le văd stabilizate”, a spus Nick Diego, colaboratorii sponsorizați de WP Engine. „Majoritatea oferă funcționalități cruciale, dar construirea unui produs care se bazează pe un API __experimental este întotdeauna puțin deconcertant. Atâta timp cât procesul este extrem de transparent, este bine mediatizat și oferim autorilor de pluginuri/teme un ghid despre cum să migrați la versiuni stabile, atunci îmi place această inițiativă.”

După luni de discuții despre bilet, Zielinski a distilat preocupările contribuitorilor în planul de acțiune propus pe blogul Make WordPress Core.

Propunerea indică faptul că cele mai multe dintre API-urile experimentale existente deja îmbinate în core ar obține un alias stabil.

„Ar păstra compatibilitatea inversă și nu ar trebui să afecteze în mod semnificativ dimensiunea pachetului”, a spus Zielinski. „Unii vor avea nevoie de un tratament diferit; hai să discutăm despre asta de la caz la caz.” El a recomandat, de asemenea, contribuitorilor să ia în considerare dacă un API experimental existent deja în nucleu trebuie eliminat. El nu anticipează multe cazuri în acest sens, dar recomandă ca acestea să utilizeze practici consacrate de a contacta autorii de pluginuri, de a folosi deprecieri ușoare și de a publica postări de bază.

„Văd, de asemenea, două lucruri în joc aici: utilizarea și abuzul de API-uri experimentale în timpul proiectării API (în general, pentru a fi utilizate și testate în plugin-ul Gutenberg) și lipsa unui proces diligent de stabilizare a acestora atunci când îndeplinesc criteriile de proiectare.” Arhitectul principal al lui Gutenberg, Matias Ventura, a comentat biletul original. „Cele care trebuie considerate publice de facto sunt cele care au existat pentru multe lansări într-o formă stabilă, în ciuda nomenclaturii lor.”

În interesul păstrării capacității WordPress de a-și îndeplini promisiunile de compatibilitate inversă, propunerea recomandă ca API-urile experimentale să fie limitate la pluginul Gutenberg și să nu fie niciodată îmbinate în core. În cazurile în care o caracteristică stabilă depinde de un API experimental, Zielinski a identificat un răspuns simplu:

„Atunci nu este de fapt stabil. Să stabilizăm mai întâi dependențele.”

Acesta este în esență o nouă modalitate de a merge mai departe, care ar trebui să crească stabilitatea și încrederea în API-urile și actualizările WordPress, dar are câteva dezavantaje.

Utilizatorii și colaboratorii se pot aștepta ca funcțiile Gutenberg să se îmbină mai lentă în core, deoarece nu se pot baza pe API-uri experimentale atunci când ajung la distribuția în orele de maximă audiență în versiunile majore. Zielinski a remarcat, de asemenea, că contribuitorii pot avea dificultăți în refactorizarea acestor API-uri odată ce au fost livrate și intră în uz pe milioane de site-uri WordPress.

Până acum, propunerea a avut un sprijin covârșitor de pozitiv, deoarece mulți cred că aceste API-uri nu ar fi trebuit niciodată să ajungă la bază în primul rând, în timp ce încă se aflau în stadiul experimental.

„Sunt foarte în favoarea acestei abordări”, a spus dezvoltatorul WordPress Mark Root-Wiley. „Creez teme personalizate și am câteva plugin-uri simple. Pentru ambele, m-am trezit oarecum frecvent forțat să mă ocup de API-urile experimentale și de dificultățile de a fi la curent cu acestea atunci când sunt introduse funcții de bază care pot fi dezactivate, ajustate sau extinse doar printr-un API experimental.”

„O întoarcere la acest tip de stabilitate în nucleu ar contribui în mare măsură la recâștigarea unei oarecare bunăvoință a dezvoltatorului”, a comentat colaboratorul WordPress Dovid Levine cu privire la propunere.

Termenul limită pentru comentarea propunerii este 7 septembrie, ceea ce ar închide discuția cu doar trei săptămâni înainte ca WordPress 6.1 Beta 1 să fie așteptat. Acest lucru le oferă colaboratorilor ceva timp pentru a audita mai profund API-urile experimentale înainte de următoarea lansare majoră, în cazul în care ajung la un consens cu privire la limitarea lor la pluginul Gutenberg.