Współtwórcy Gutenberga omawiają wady używania ramek iframe w Meta Boxach

Na GitHubie toczy się ożywiona i produktywna dyskusja na temat korzystania przez Gutenberga z ramek iframe w metaboksach. Wczoraj programista WordPress Kevin Hoffman stworzył problem zatytułowany „Czy ramki iframe są opłacalnym, długoterminowym rozwiązaniem dla metaboxów?”

Gutenberg 1.5 wprowadził początkowe wsparcie dla metaboksów. Hoffman zidentyfikował kilka problemów z ramkami iframe, które pojawiały się, gdy programiści zaczęli testować obecną implementację metabox. Przeprowadził kilka testów wydajności, które wykazały, że użycie przez Gutenberga ramek iframe potraja liczbę żądań zasobów, ponieważ umieszcza wszystkie zasoby CSS i JS w oknie nadrzędnym, a także we wszystkich ramkach iframe.

„Ogólnie rzecz biorąc, elementy iframe były od wielu lat zniechęcane do tworzenia stron internetowych z powodów, które są dobrze udokumentowane”, powiedział Hoffman, po czym przytoczył litanię problemów, które twórcy wtyczek już odkryli podczas testowania obsługi metaboxów Gutenberga. „Czy te problemy można rozwiązać bez konieczności modyfikacji motywu lub wtyczki generującej metabox? Musimy wziąć pod uwagę, że kod strony trzeciej, który od lat zasila metaboxy, może nie mieć luksusu aktualizacji, aby był kompatybilny z iframe”.

Kierowniczka projektu Gutenberg, Tammie Lister, odpowiedziała na obawy Hoffmana, wskazując, że obecna implementacja metaboksów to po prostu eksperyment i niekoniecznie to, co wyląduje w WordPress 5.0:

Dobrze jest pomyśleć, że to, co mamy dzisiaj do metaboksów w Gutenbergu, jest eksperymentem, pod wieloma względami jest to wzór trzymania się, gdy projekt wypracowuje kierunek, w którym należy. Mówiąc, że jest to taki, który działa „na razie”, ale nie jest tym, z czym byśmy wysyłali.

Wszystko, co zostało powiedziane powyżej, myślę, że ważne jest, aby przyjrzeć się, do czego w przyszłości będą używane metaboksy. Jakie są przypadki (jeśli istnieją), które nie zostaną przekonwertowane na bloki? Czy wszystkie metaboksy muszą działać na urządzeniach mobilnych? Czy istnieje w ogóle alternatywny interfejs, którego nie zbadaliśmy? Założę się, że jest. W tej chwili chodzi o przyjrzenie się tym możliwościom i wejście na drogę, która działa dla stanu teraz i dla stanu przyszłego.

Prezentacja tej implementacji jako eksperymentu, który „na razie działa” (ale nie zostanie wysłany) jest zaskoczeniem po tym, jak Gutenberg 1.5 pojawił się z ogłoszeniem, że „to wydanie zawiera długo oczekiwaną obsługę metaboxów (wymaga testów!)”

Hoffman twierdzi, że podejście iframe nie działa nawet „na razie”, ponieważ problem został otwarty w celu przytoczenia kilku głównych sposobów, w których jest zepsuty. Jeśli Gutenberg pójdzie do przodu z obecnym podejściem, będzie wymagało modyfikacji wielu wtyczek, aby były kompatybilne z WordPress 5.0, co Hoffman powiedział, że zniweczy cały cel wspierania starszych metaboxów.

„Do tej pory nie widziałem żadnych dowodów sugerujących, że metaboxy będą nadal współpracować z Gutenbergiem” – powiedział Hoffman. „Jeśli odpowiedź brzmi „nie”, powinniśmy przestać udawać, że 5.0 będzie tylko kolejnym wydaniem WordPressa i zacząć szczerze mówić o łamaniu wstecznej kompatybilności”.

Edwin Cromley, współpracownik projektu, powiedział, że zespół przewiduje, że niektóre motywy i wtyczki zostaną zepsute i że nie jest możliwe dostosowanie do każdego możliwego przypadku użycia. Przyznał, że rozwiązanie iframe może nie spełniać celów projektu. Zamiast tego opowiada się za stworzeniem najlepszego doświadczenia dla ogromnej większości użytkowników.

Jednak obecne podejście miałoby negatywny wpływ na wiele witryn, które używają WordPressa głównie jako CMS z metaboxami. Główny twórca WordPressa, Scott Taylor, wyraził obawy dotyczące niestandardowych typów postów, z których wiele nie korzysta z tradycyjnej sekcji „treść” na rzecz metaboksów.

„W obecnej iteracji obsługa metaboxów jest dodatkiem, podczas gdy w rzeczywistości wielu ludzi metaboxy SĄ interfejsem użytkownika, interfejsem API, mechanizmem, którego używają do tworzenia CMS” – powiedział Taylor. „iframe to gułag.

„Zapominamy o wartościach, na których WP został zbudowany na zawsze: powinienem mieć możliwość aktualizacji do najnowszej wersji WP i nie muszę niczego przepisywać. Mam tak wiele projektów na wolności na WP, że już nigdy nie tknę. Czy mogę mieć pewność, że część z nich nie złamie się dziko z tą zmianą?”

Hoffman zalecał zmniejszenie zakresu projektu, aby skupić się na komponencie edytora, co jest popularną opinią podzielaną przez wielu twórców wtyczek i którą szczegółowo zilustrował post Yoasta, proponując alternatywne podejście do Gutenberga. Takie podejście wprowadza zmiany na ekranie edycji, dając programistom więcej czasu na aktualizację swoich wtyczek, a także pozwalając zespołowi Gutenberga na znalezienie odpowiedniego rozwiązania dla metaboxów.

„Myślę, że ten cel byłby o wiele bardziej możliwy do osiągnięcia, gdyby Gutenberg trzymał się przebudowy edytora, a nie przejmowania całej strony” – powiedział Hoffman. „Wtedy moglibyśmy pozostawić istniejące haki na miejscu, a metaboxy mogłyby nadal komunikować się ze sobą tak, jak robią to teraz. Ponadto kolejkowanie aktywów nie stanowiłoby problemu, ponieważ działałoby tak, jak obecnie.

„Zgadzam się z tą koncepcją przedstawioną przez Yoasta, która wydaje mi się, że utrzymałaby większość już wykonanej pracy, jednocześnie zmniejszając zakres projektu, aby skupić się na komponencie edytora”.

Inżynier z Gutenberga, Riad Benguella, wskazał, że zespół nie jest zbyt chętny do pracy nad tą koncepcją.

„Ponowne wykorzystanie elementów Gutenberga do zbudowania tej koncepcji jest stosunkowo wykonalne, ale nie jest to UX, dla którego chcemy zoptymalizować, najpierw chcemy zbudować najlepszy możliwy edytor i udostępnić go osobom bez problemów z kompatybilnością wsteczną (świeże instalacje, bez metaboksa… )”, powiedział Benguella.

„Kiedy uznamy, że idealna wizja Gutenberga jest gotowa do wysłania, będziemy mieli czas na omówienie strategii ścieżki aktualizacji, koncepcja taka jak ta jest opcją dla ścieżki aktualizacji, ale na pewno nie jako produkt końcowy. Możliwe są również inne ścieżki ulepszeń.”

Społeczność programistów WordPressa nie jest jednak za tym, aby ponownie opóźniać tę dyskusję. Wielu chce wreszcie odpowiedzieć na pytanie, jak metaboxy wpasują się w kontekst edytora Gutenberga, aby wiedzieli, jak się przygotować. Biorąc pod uwagę liczne problemy z podejściem iframes, renderowanie starszych metaboxów PHP w nowym edytorze będzie wymagało więcej eksperymentów i być może alternatywnego rozwiązania.

„Po co poświęcać tysiące godzin na opracowanie idealnego edytora, jeśli nie można go dostosować do istniejących witryn?” powiedział Hoffman. „Jeśli pierwsze wrażenie jest takie, że łamie interfejs, na którym polegają, użytkownicy nigdy nie doświadczą idealnego edytora”.

„Myślę, że odkładanie tego za daleko może być błędem” – powiedział główny koordynator WordPressa Aaron Jorbin. „Zwłaszcza, że ​​wiele organizacji będzie potrzebowało co najmniej 1-2 kwartałów na przygotowanie”.

Mark Kaplun sugeruje, że zespół Gutenberga używa popularnej wtyczki jako miernika sukcesu obecnych i przyszłych eksperymentów z obsługą metaboxów.

„Moją produktywną sugestią jest, aby nie deklarować gotowych metaboxów, dopóki Yoast SEO nie działa w nich prawidłowo” – powiedział Kaplun. „Jest zarówno nieco skomplikowany pod względem interakcji, jak i jest instalowany na gównianych stronach. Jeśli Gutenberg nie może z nim pracować, prawdopodobnie nikt go nie użyje”.

Greg Schoppe, który testował i intensywnie pisał o ciągłym rozwoju Gutenberga, dołączył do rozmowy, aby opowiedzieć się za alternatywnym podejściem Yoasta do projektu.

„Wysoce popieram pogląd Yoasta na temat Gutenberga” – powiedział Schoppe. „Nie jest dla mnie jasne, w jaki sposób zespół Gutenberga zinterpretował „uaktualnienie edytora wizualnego” jako „zastąp cały interfejs po edycji”, ale wydaje się, że jest to bezpośrednio sprzeczne z tak zwanym „Statkiem Tezeusza”.

„W tym przypadku brak jasnego kierunku i wsparcia dla istniejących standardowych przepływów pracy aktywnie szkodzi teraz programistom. Jak mogę kontynuować tworzenie projektu bez zaufanego zestawu haków i narzędzi, na których mogę polegać? Nierozsądne jest myślenie, że tak duży projekt oprogramowania całkowicie przewróciłby standardowy przepływ pracy dla programistów w jednej aktualizacji. i to szaleństwo, że te rozmowy odbywają się właśnie teraz, w listopadzie, kiedy plan ma zatwierdzić fuzję na początku roku”.

Dyskusja dotycząca podejścia iframe do metaboxów, która została otwarta wczoraj, jest wciąż stosunkowo nowa, ale jak dotąd odpowiedzi zespołu Gutenberga nie są w stanie odpowiednio odpowiedzieć na obawy społeczności programistów w tym wątku. Znalezienie podejścia do metaboksów, które zachowuje potężne możliwości CMS WordPressa, bez zrażania użytkowników i programistów, jest jednym z największych wyzwań zespołu Gutenberga. Wciąż dążą do stworzenia propozycji scalenia na początku przyszłego roku, ale ponieważ metaboxy wciąż znajdują się na etapie eksperymentów, oczekiwany harmonogram zespołu nadal stawia projekt w sprzeczności ze społecznością programistów WordPressa.