Proiectul WordPress Core Fields API caută un nou lider

În 2014, dezvoltatorul principal Pods, Scott Kingsley Clark, a preluat rolul principal principal pentru proiectul Metadata UI. În 2015, proiectul Metadata UI a renascut ca API Fields.

API-ul Fields a fost dezvoltat pentru a permite înregistrarea câmpurilor pe diferite ecrane din zona de administrare printr-un singur API. Noi casete meta și câmpuri din ele ar putea fi adăugate la postări, în timp ce noi secțiuni și câmpuri ar putea fi adăugate la ecranul de profil.

Scopul API-ului este să se integreze cu toate diferitele ecrane de administrare, inclusiv cu Postări, Termeni, Utilizatori, Media și Comentarii și să ofere standardizare.

Clark conduce proiectul de trei ani și, în ciuda interesului reînnoit anul trecut, a anunțat pe canalul Slack al proiectului că renunță.

Cu inima grea trebuie să dau torța acestui proiect. După sute de ore din timpul meu, nu mai cred că pot efectua schimbări în nucleul WordPress.

Viziunea Fields API a fost prea mare, o asumare prea mare pentru orice persoană. Cred atât de profund că WordPress are nevoie de un API Fields, dar drumul până unde ne aflăm cu API-ul Fields a fost lung și anevoios.

Adevărul este că m-am epuizat cu ani în urmă în timp ce construiam primul și al doilea prototip. Nu toată lumea a fost de acord cu privire la modul de arhitectură a codului, acesta a trecut prin multe revizuiri bazate pe feedback-ul principal al contribuitorilor. Pur și simplu nu am putut obține destui oameni entuziasmați de asta, nu am putut obține suficiente companii și oameni interesați să-l susțină.

Trebuie să las pe altcineva să aibă șansa lui, o trag în jos. Dacă cineva face un pas pentru a conduce în viitor, atunci aș fi bucuros să ajut acolo unde pot. Dar nu pot continua să conduc propunerea/proiectul API Fields. Îmi pare rău, vă rog să îmi acceptați scuzele și sper să mă puteți ierta că nu am reușit să trec acest proiect peste linia de sosire. Încă cred că sunt o parte atât de vitală a succesului viitor al WordPress.

Scott Kingsley Clark

Încercările și necazurile conducerii unui proiect cu sursă deschisă

În interviul următor, Clark explică de ce se simte personal responsabil pentru lipsa de progres a proiectului, de ce API-ul este important pentru viitorul WordPress și reflectă asupra a ceea ce ar fi putut face diferit.

Cauți să dai torța cuiva în special?

Nu, nu sunt sigur cine ar avea forța și puterea de a duce proiectul. Este un proiect la scară largă care ar trebui abordat cu o viziune pe termen lung, dar în trepte suficient de mici pentru a se transforma în nucleul WordPress. Este mult de cerut cuiva, nici nu este o prioritate pentru oameni în acest moment, deoarece sunt distrași de eliberarea lui Gutenberg în viitorul apropiat.

De ce este API-ul Fields o parte vitală a viitorului WordPress?

Oamenii se uită astăzi la WordPress și se întreabă cum au supraviețuit vreodată fără API-ul REST. Ei bine, cel puțin știu că da! Același lucru se poate spune despre API-ul Fields, deși nu este încă acolo. Există atât de multe cazuri în care este frustrant să construiești soluții pentru WordPress prin toate cârligele diferite.

Pentru coerență, este vestul sălbatic acolo. Primiți o casetă meta înregistrată și o umpleți cu orice doriți. Aveți nevoie de propriul dvs. CSS pentru a stila câmpurile de formular și fiecare are propria idee despre cum ar trebui să arate această interfață. Sunteți responsabil de propriile machete receptive care sunt prietenoase cu dispozitivele mobile, sunt atât de multe pe care trebuie să le gestionați singur. Ar trebui să puteți personaliza aparițiile, dar fiecare loc în care doriți să adăugați un câmp sau un formular ar trebui să aibă într-adevăr un API adecvat.

Pe termen lung, imaginați-vă că înregistrați câmpuri în WordPress așa cum înregistrați tipuri de postări. Imaginați-vă că câmpurile și configurațiile lor sunt disponibile pentru API-ul REST și accesibile prin aplicația WordPress sau alte aplicații personalizate.

Întreaga lume se deschide pentru că aveți un API consistent, întreaga lume are sens pentru că aveți o interfață consecventă pentru acele câmpuri în diferitele ecrane de editare. Postările, termenii, comentariile, utilizatorii, media, chiar și Personalizatorul ar avea toate aceeași API de bază pentru a adăuga grupuri, panouri și câmpuri pe ecranele lor.

Dacă Gutenberg s-a terminat după ce a fost introdus API-ul Fields, migrarea pentru oameni nu ar fi fost la fel de dificilă. Gutenberg ar fi putut să arate automat toate interfețele API Fields, așa cum o face pentru compatibilitatea cu metabox-ul. Ar fi arătat și mult mai frumos.

Luând ceva timp pentru a reflecta, ce ați fi putut face diferit pentru a determina mai mulți contributori de bază să cumpere în proiect și să-l transforme într-o prioritate mai mare?

Nu sunt sigur, este un echilibru delicat între preluarea contribuțiilor și încrederea în rezultatul final. La început, feedback-ul a fost despre modul în care API-ul era străin pentru WordPress, ei au întrebat dacă ar putea fi similar ca structură cu alte API-uri, cum ar fi Customizer.

Am abandonat codul și am reconstruit de la zero ca o furcă a Personalizatorului, chiar a acceptat ca Personalizatorul să utilizeze și API-ul Fields. La apogeul dezvoltării, am implementat toate domeniile API-ului Fields.

Versiunile de bază se mișcau destul de repede, au existat o mulțime de modificări de cod de la o versiune WordPress la o ediție cu care a trebuit să ținem pasul pentru că, în esență, am creat un proiect care era un patch gigant pentru WordPress.

Nu existau suficiente cârlige pentru a face ceea ce trebuia să facem și multe secțiuni nu erau extensibile din cauza deciziilor de cod care s-au marcat drept „finale”, ceea ce înseamnă că nu puteți extinde o anumită clasă pentru a personaliza modul în care funcționează.

Mi-aș fi dorit să fiu în toate marile WordCamps din SUA și Europa, făcând lobby pentru această funcție. Adunând susținători și altele, se simte într-un fel ca în politică. Am stat la întâlnirile Core dev, încercând să o aduc în discuție. Am încercat să legitimez caracteristica având un canal dedicat în WordPress Slack oficial, postând actualizări pe https://make.wordpress.org/core/ și ținând întâlniri săptămânale.

În cele din urmă, mi-am prioritizat timpul de dezvoltare față de timpul de adunare a trupelor. Acesta a fost căderea, am început să mă epuizez rapid după primele câteva rescrieri, deoarece aveam multe alte responsabilități în altă parte, pe lângă Fields API.

Nu este ca și cum companiile vor dori cu ușurință să te plătească pentru a lucra la un astfel de proiect pe termen nelimitat, chiar dacă atât WebDevStudios, cât și 10up mi-au dat timp să-l împing mai departe. Nu a fost un cec în alb, la un moment dat a trebuit să mă întorc la munca facturabilă. De atunci, totul a fost în timpul meu liber și asta a fost greu de gestionat în perioadele de stres financiar și de vânzare/cumpărare de case.

Există o cerere pentru un API Fields în nucleu, dar nu există suficiente mâini pentru al construi. De ce crezi că este?

Toată lumea este concentrată în altă parte. Există o mulțime de domenii ale WordPress care au nevoie de atenția oamenilor. Există lucruri precum Accesibilitatea care merită mult mai multă atenție decât primește. Dar atenția pentru mine pare să fie pe Gutenberg și REST API.

Gutenberg, în special, a fost un imens timp pentru oamenii care contribuie și cei care implementează. Este o caracteristică foarte mare. Este cu siguranță mai mare la scară decât Fields API, este ca o aplicație complet nouă care trăiește în WordPress. Integrarea cu acesta a necesitat multă educație și încercare/eroare. Concentrarea oamenilor este acolo unde trebuie să fie acum. Este regretabil că Gutenberg a venit înaintea Fields API în ceea ce privește prioritatea și nivelul de interes.

Ce sfaturi ați da următorului lider de proiect Fields API?

Acesta este un proiect mare, toată lumea va dori să spună că ar trebui să fie într-un anumit fel. Trebuie să evaluați opțiunile și să puneți ceva de mărimea unei mușcături pentru a începe cu miezul. Construiți pe asta, dar nu pierdeți niciodată din vedere obiectivul pe termen lung al integrării pe toate ecranele WordPress. Chiar și formularele de comentarii front-end ar putea prospera cu API-ul Fields.

De ce vă simțiți personal responsabil pentru faptul că proiectul nu este o prioritate de bază?

La un moment dat, am avut avânt. Aveam cel puțin trei-patru persoane care erau active. S-a prăbușit pentru că am rămas fără timp. Este miopia mea, este vina mea. Am petrecut sute de ore dezvoltând proiectul în câțiva ani. Ar fi trebuit să-mi las mult mai mult timp pentru a organiza textul propunerii de caracteristică și pentru a păstra focurile aprinse în inimile colaboratorilor noștri.

Având în vedere timpul și efortul pe care l-ați depus în proiect în ultimii câțiva ani, simțiți vreo ușurare când dați torța mai departe?

Dacă lanterna este trecută sau ridicată, mă voi simți mult mai bine. Principala ușurare este că oficial nu este o greutate pe care trebuie să o mai port singur. Este în regulă să încerci și să eșuezi, este totuși trist.

Sper că cineva sau o companie va face un pas și va pune timp în asta. Au putut chiar să reaprindă focul din propria inimă care sa stins singur. Deocamdată, am un lucru mai important de făcut. Mai am o farfurie mare, dar nu mai este la fel de grea.

Deși viitorul imediat al proiectului este neclar, cei interesați să-l preia sunt încurajați să citească postările marcate cu eticheta API Fields pe Make.WordPress.Core pentru a afla despre istoria acestuia. De asemenea, puteți consulta pagina Github a proiectului.

Dacă sunteți interesat să preluați proiectul, îl puteți contacta pe Clark pe Twitter, Slack sau prin site-ul său.