Nowa propozycja wzywa współtwórców do zaprzestania łączenia eksperymentalnych interfejsów API od Gutenberga do WordPress Core

Praktyka łączenia eksperymentalnych interfejsów API Gutenberga z rdzeniem WordPressa może wkrótce się skończyć. Nowa propozycja, opublikowana przez współautora sponsorowanego przez Automattic, Adama Zielińskiego, wzywa współtwórców do stabilizacji interfejsów API przed połączeniem ich z rdzeniem.

Na przestrzeni lat około 280 eksperymentalnych interfejsów API zostało połączonych z wtyczką Gutenberg, którą Zieliński skontrolował w zgłoszeniu, które otworzył w kwietniu. Równoważąc dążenie do szybkiego poruszania się z iteracją edytora(ów) wbrew zobowiązaniu WordPressa do wstecznej kompatybilności, liczba eksperymentalnych interfejsów API stała się nie do utrzymania, a praktyka łączenia ich w rdzeń jest obecnie aktywnie rozważana.

Oficjalnie eksperymentalne interfejsy API są oznaczane jako takie, aby zniechęcić do korzystania z nich przez osoby trzecie, ponieważ oczekuje się, że ulegną zmianie. W praktyce ludzie tworzący dla edytora bloków i tak ich używają, ponieważ są w rdzeniu i chcą rozszerzyć funkcje, które umożliwiają te interfejsy API.

„Autorzy wtyczek i motywów są zmuszeni polegać na __experimental funkcjach, które mogą zostać usunięte lub zmienione w sposób niekompatybilny wstecz w dowolnym momencie” – powiedział Zieliński, powtarzając frustrację i obawy, jakie wielu programistów miało z projektem w ciągu ostatnich kilku lat. „To poważne obciążenie związane z utrzymaniem. Każde nowe wydanie Gutenberga/WordPressa oznacza potencjalnie przełomowe zmiany.”

Peter Wilson, główny koordynator WordPressa, skomentował zgłoszenie, mówiąc, że jest za ograniczeniem eksperymentalnych interfejsów API do krwawiącego produktu. Zwracając uwagę na potrzebę tej zmiany, przytoczył szereg negatywnych skutków, jakie te podstawowe eksperymentalne interfejsy API wywarły na ekosystem:

• główni autorzy, którzy nie chcą korzystać z niektórych funkcji biblioteki, aby ułatwić wykonywanie podstawowych zadań, ponieważ nie ufają niezawodności
• programiści nie aktualizują już witryn klienckich WP. Jako główny twórca, który od lat stara się zachować kompatybilność wsteczną, rozczarowuje mnie to. Jako członek zespołu ds. bezpieczeństwa jest to bardzo niepokojące
• programiści decydujący się na umieszczanie kopii pakietów w motywach i wtyczkach, zamiast polegać na globalnych funkcjach wp.* . Znowu dotyczy to mnie z punktu widzenia bezpieczeństwa, ale zwiększa też znacznie ładunek JavaScriptu niż zachowanie wstecznej kompatybilności
• raporty o błędach kompatybilności wstecznej w mniejszych wersjach: „nie oczekujesz, że wydanie 5.9.1 zepsuje responsywność wielu obrazów w naszych witrynach poza edytorem bloków”
• programiści rozważający, aby nigdy nie używać podstawowych bloków, ponieważ są zbyt niestabilne: „Przestałem używać / rozszerzać podstawowe bloki, ponieważ zmieniały się zbyt wiele i używałem bloków ACF, więc przynajmniej wiem, że mogę tworzyć bloki, które nie będą przerwanie. To prawda, że ​​interfejs użytkownika nie jest tak dobry, jak bloki podstawowe, ale w każdej chwili przejmę stabilność nad blokami, które się psują.”

Wtyczka Gutenberg miała funkcjonować jako wtyczka funkcji, w której spodziewane są przerwy w kompatybilności wstecznej, podczas gdy współtwórcy szlifują funkcje przed połączeniem ich z rdzeniem. Powrót do korzeni tego podejścia i uczynienie edytora mniej eksperymentalnym, jest w centrum tej propozycji.

„Niestabilność między wersjami już zaczyna zrażać niektórych największych zewnętrznych zwolenników edytorów bloków” – powiedział Wilson.

Utrzymanie tego poziomu niestabilności może zniechęcić ludzi do budowania na WordPressie, odpychając ich do innych prostszych projektów, którymi zarządza się w inny sposób. Możliwe, że potrzeba polegania na eksperymentalnych interfejsach API zniechęciła programistów do tworzenia większej liczby produktów, spowalniając adaptację edytora bloków.

„Jako autor wtyczek, który obecnie korzysta z wielu __experimental interfejsów API, chciałbym, aby były one ustabilizowane”, powiedział Nick Diego, współtwórcy sponsorowani przez WP Engine. „Większość zapewnia kluczową funkcjonalność, ale budowanie produktu, który opiera się na __experimental interfejsie API, jest zawsze trochę niepokojące. Tak długo, jak proces jest wyjątkowo przejrzysty, dobrze nagłośniony, a autorom wtyczek/motywów dostarczamy przewodnik, jak przeprowadzić migrację do wersji stabilnych, podoba mi się ta inicjatywa.”

Po miesiącach dyskusji nad biletem Zieliński przekuł obawy współpracowników do planu działania zaproponowanego na blogu Make WordPress Core.

Propozycja wskazuje, że większość istniejących eksperymentalnych interfejsów API, które zostały już połączone z rdzeniem, otrzyma stabilny alias.

„Zachowałoby to kompatybilność wsteczną i nie powinno znacząco wpłynąć na rozmiar pakietu” – powiedział Zieliński. „Niektórzy będą potrzebować innego leczenia; porozmawiajmy o tym dla każdego przypadku z osobna”. Polecił również współtwórcom rozważenie, czy istniejący eksperymentalny interfejs API, który jest już w rdzeniu, musi zostać usunięty. Nie przewiduje wielu takich przypadków, ale zaleca, aby korzystali z ustalonych praktyk kontaktowania się z autorami wtyczek, używania miękkich deprecjacji i publikowania postów Core.

„Widzę tu również dwie rzeczy: użycie i nadużywanie eksperymentalnych interfejsów API podczas projektowania API (zazwyczaj do użycia i przetestowania we wtyczce Gutenberg) oraz brak starannego procesu ich stabilizacji, gdy spełniają kryteria projektowe” Główny architekt Gutenberga, Matias Ventura, skomentował oryginalny bilet. „Te, które należy uznać za de facto publiczne, to te, które istniały od wielu wydań w stabilnej formie pomimo ich nazewnictwa”.

W trosce o zachowanie zdolności WordPressa do realizacji obietnic dotyczących wstecznej kompatybilności, propozycja zaleca ograniczenie eksperymentalnych interfejsów API do wtyczki Gutenberg i nigdy nie łączenie ich z rdzeniem. W przypadkach, w których stabilna funkcja zależy od eksperymentalnego API, Zieliński zidentyfikował prostą odpowiedź:

„W takim razie nie jest właściwie stabilny. Najpierw ustabilizujmy zależności.”

Jest to zasadniczo nowy sposób postępu, który powinien zwiększyć stabilność i zaufanie do interfejsów API i aktualizacji WordPressa, ale ma kilka wad.

Użytkownicy i współtwórcy mogą spodziewać się, że funkcje Gutenberga mogą wolniej łączyć się z rdzeniem, ponieważ nie mogą polegać na eksperymentalnych interfejsach API, gdy trafią na dystrybucję w czasie największej oglądalności w głównych wydaniach. Zieliński zauważył również, że współtwórcy mogą również mieć trudności z refaktoryzacją tych interfejsów API po ich wysłaniu i uruchomieniu w milionach witryn WordPress.

Jak dotąd propozycja spotkała się z przytłaczająco pozytywnym poparciem, ponieważ wielu uważa, że ​​te interfejsy API nigdy nie powinny dotrzeć do rdzenia, gdy są jeszcze w fazie eksperymentalnej.

„Jestem bardzo za tym podejściem” — powiedział programista WordPress Mark Root-Wiley. „Tworzę niestandardowe motywy i mam kilka prostych wtyczek. W przypadku obu, byłem dość często zmuszony do radzenia sobie z eksperymentalnymi interfejsami API i trudnościami z aktualizowaniem ich, gdy funkcje są umieszczane w rdzeniu, które można wyłączyć, dostosować lub rozszerzyć tylko za pomocą eksperymentalnego interfejsu API”.

„Powrót do tego rodzaju stabilności rdzenia byłby długą drogą do odzyskania dobrej woli programistów” – skomentował tę propozycję współautor WordPressa Dovid Levine.

Termin zgłaszania uwag do propozycji upływa 7 września, co oznaczałoby zamknięcie dyskusji na zaledwie trzy tygodnie przed oczekiwaniem WordPress 6.1 Beta 1. Daje to autorom trochę czasu na dokładniejszy audyt eksperymentalnych interfejsów API przed kolejną główną wersją, jeśli osiągną konsensus w sprawie ograniczenia ich do wtyczki Gutenberg.