Zespół programistów Gutenberg potwierdza, że ​​interfejs API Meta Box nie zostanie formalnie przestarzały

Dyskusja dotycząca tego, jak Gutenberg będzie obsługiwał metaboxy, rozgrzała się w weekend po tym, jak jeden z uczestników skomentował problem GitHub z zaniepokojeniem, że obsługa metaboxów zostanie usunięta z ostatniego kamienia milowego.

„Widzę, że ten istotny problem został usunięty z każdego etapu” – powiedział @steveangstrom. „Znowu zrezygnowano z priorytetów, podczas gdy dzwonki i gwizdki do edycji blogów mają dużo pracy i są dodawane do wersji beta. To bardzo niepokojące dla przyszłości WordPressa jako CMS”.

James Nylen, jeden z głównych programistów projektu, zapewnił zwolenników tematu, że zespół Gutenberga nie zapomniał o problemie, ale raczej, że jest to „niezwykle skomplikowana kwestia, którą dopiero zaczynamy się przyglądać, wraz z wieloma, wiele innych priorytetów, aby edytor działał dobrze”. Poprosił również społeczność o pomoc w planowaniu i testowaniu wdrożeń wspierających metaboxy.

Ta odpowiedź pozostawiła wiele niejasności. Uczestnicy dyskusji, z których wielu jest programistami zaniepokojonymi perspektywą przepisania wszystkich swoich metaboksów jako komponentów React, zastanawiają się, dlaczego metaboksy nie mogą współpracować z nowym edytorem Gutenberga i dlaczego zespół zdecydował się uwzględnić metaboksy w zakres projektu.

„Czy można zastąpić istniejący edytor postów TinyMCE Gutenbergiem, pozostawiając resztę interfejsu, w tym metaboxy i istniejące hooki, niezmienione?” - zapytał Kevin Hoffman. Kiedy Nylen wyjaśnił, że Gutenberg, jak napisano dzisiaj, ma być edytorem post_content , Hoffman podsumował obawy wyrażane przez wielu programistów:

Jeśli Gutenberg naprawdę ma być edytorem post_content , to meta pola powinny zostać pozostawione w spokoju, ponieważ nie dotyczą post_content .

Co więcej, potrzeba API do tłumaczenia metaboxów PHP na metaboxy Reacta jest wytworzonym problemem. Nie musi to być problem, ale stał się problemem, ponieważ gdzieś po drodze zdecydowano, że przepisanie edytora post_content powinno również całkowicie zmienić działanie metaboxów.

W #2251 nakreśliłeś ogromne wyzwanie związane z napisaniem takiego API. Przetłumaczenie metaboksów PHP na Reacta dla popularnego rozwiązania pól niestandardowych, takiego jak ACF, jest wystarczająco trudne, nie mówiąc już o próbie zrobienia tego dla każdej istniejącej obecnie implementacji metaboksu, popularnej lub nie. Nie skaluje się.

Ponieważ współtwórcy Gutenberga podzielili się, że dopiero zaczęli przyglądać się problemowi meta boxów, teraz jasne jest, dlaczego nie ma mapy drogowej, jak projekt będzie obsługiwał „starsze” meta boxy PHP. W lipcu Nylen powiedział: „Gdybym miał zgadywać, gdzie tu trafimy: obecne metaboksy zostaną przeniesione do „starszego” obszaru, a my dostarczymy interfejsy API, dokumentację i przykłady rejestrowania bloków metaboksów „w nowym stylu”. -rzeczy.

Twórcy wtyczek, którzy zarządzają bibliotekami metabox, agencjami i innymi zainteresowanymi stronami, podążają za biletem, aby dowiedzieć się, jak zaplanować WordPress 5.0, który był celem jako wydanie Gutenberga. Andrey Savchenko zapytał, czy WordPress planuje formalnie wycofać API meta box, na co w końcu zespół otrzymał jasną odpowiedź. Matias Ventura odpowiedział:

„Czy WordPress zamierza formalnie wycofać Metabox API?”
Nie.

Pytanie, na które nie ma jeszcze pełnej odpowiedzi, dotyczy tego, jak działają meta-boxy w kontekście edytora Gutenberga. Czy powinny pozostać takie same, czy ewoluować? Jak możemy dążyć do celów projektowych przy możliwie najmniejszych zakłóceniach?

Ten problem utrzymuje się nie z powodu braku chęci, ale braku zasobów. Głównym celem tego projektu jest zaoferowanie bogatego interfejsu edycji treści, który optymalizuje bezpośrednią manipulację treścią użytkownika za pomocą pojęcia bloków. (Korzystając intensywnie z metaboxów w różnych projektach, uważam, że bloki mogą zaoferować lepszy krok naprzód dla wielu z tych potrzeb, zapewniając jednocześnie lepsze wrażenia użytkownika.)”

Ventura wymienił kilka opcji, które zespół rozważył w zakresie obsługi metaboxów, i poprosił społeczność o pomoc w zbudowaniu najlepszego rozwiązania:

• Jeśli wykryjemy, że meta-box jest zarejestrowany, możemy wrócić do starego interfejsu, nic się nie zmieni.
• Możemy podzielić edycję treści i modyfikowanie metainformacji na dwa ekrany lub etapy.
• Możemy spróbować zobaczyć, jak wykonalne jest renderowanie ich takimi, jakimi są (PHP) pod treścią: #2251.
• Motyw/wtyczka/CPT może w razie potrzeby wyrejestrować nowy interfejs.
• Różne elementy, które opierały się na meta polach, można było przekonwertować na bloki dla interfejsu użytkownika (nadal przechowujące dane osobno).
• Możemy zaimplementować rozszerzalność metaboksów opartą na API, taką jak API Fields.

Po naciśnięciu, aby odpowiedzieć na pytanie, dlaczego metaboxy są uwzględniane w kontekście nowego edytora, kierownik projektu Gutenberg, Joen Asmussen, wyjaśnił, w jaki sposób zespół zdecydował się uwzględnić metaboxy w zakresie projektu:

Gutenberg zaczął właśnie od edytora. Celem startowym było ujednolicenie wielu różnych interfejsów w ramach jednego zunifikowanego interfejsu blokowego. Szybko stało się jasne, że aby stworzyć przekonujące doświadczenie oparte na tym zunifikowanym interfejsie blokowym, musieliśmy wziąć pod uwagę pełny przepływ pisania, w tym ustawienia i publikowanie.

Jeśli kluczową siłą WordPressa jest ułatwienie każdemu tworzenia bogatych postów, nie możemy po prostu projektować dla tych z nas, którzy już wiedzą, jak korzystać z edytora. Musimy wziąć pod uwagę użytkowników, którzy nigdy wcześniej nie korzystali z WordPressa i czego oczekują od nowoczesnego interfejsu publikowania. W przeciwnym razie po prostu dołożylibyśmy obciążenie poznawcze do i tak już ciężkiego interfejsu.

Pytanie, jak metaboxy wpasują się w kontekst edytora Gutenberga, wciąż pozostaje otwarte. Uczestnicy dyskusji chętnie otrzymają odpowiedź na to pytanie ze względu na kompatybilność wsteczną, a także dlatego, że wpływa to na bieżące decyzje dotyczące rozwoju i projektowania ekranów Gutenberga.

„Całkowicie rozumiem, ile pracy włożono w podejściu do wymiany „ekranu” – skomentował tę kwestię Xavi Ivars. „Ale czy projekt, który rozpoczął się od zastąpienia „edytora treści postów”, nie powinien wrócić do społeczności przed podjęciem jednostronnej decyzji, że zastąpi cały ekran edytora?”

Interfejs API metabox nie jest przestarzały, ale nie ma też jasnej ścieżki, w jaki sposób Gutenberg będzie obsługiwał „starsze” metaboxy PHP. Zespół Gutenberga powiedział, że problem nie został rozwiązany z powodu braku zasobów. Projekt wymaga wkładu społeczności i lepszej komunikacji, jeśli zespół ma zamiar wylądować na rozwiązaniu, które bezproblemowo wprowadzi większość witryn WordPress w erę Gutenberga z najmniejszą ilością uszkodzeń.

Obecnie możliwość renderowania starszych metaboxów PHP pod treścią jest pełna wyzwań i wciąż jest przedmiotem dyskusji. Jeśli nie ma wystarczającej ilości czasu lub zasobów klienta, aby programiści mogli przepisać swoją pracę w meta-polach opartych na JS, może być konieczna jasna ścieżka do rezygnacji z interfejsu Gutenberga w przypadku witryn, które muszą zachować starsze meta-pola „PHP”. .