Współtwórcy Gutenberga odkrywają alternatywę dla używania ramek iframe dla Meta Boxów

Dyskusja wokół wykorzystania ramek iframe w metaboksach w Gutenbergu stała się bardziej gorąca w ciągu weekendu, ponieważ zaniepokojeni programiści błagali zespół o rozważenie wad obecnego podejścia. Odpowiedzi kierownictwa Gutenberga początkowo odrzuciły obawy, przedstawiając implementację iframe jako eksperyment, który „działa 'na razie'”, ale nie jest tym, co zespół chciałby wysłać.

Zamiast uzyskać odpowiedź na konkretne obawy dotyczące wydajności i dostępności podejścia do ramek iframe, Kevin Hoffman został poproszony o zastanowienie się nad przyszłością metaboksów i „przypadkami (jeśli istnieją), które nie zostaną przekonwertowane na bloki”. Kiedy społeczność programistów jest wielokrotnie proszona o przetestowanie i przekazanie opinii, ale napotyka ona na problemy, które są krytyczne dla witryn korzystających z WordPressa jako CMS, dyskusje na GitHubie stają się coraz bardziej gorące.

„Ludzie są zmartwieni i sfrustrowani i wydaje mi się, że mają do tego pełne prawo, ponieważ wydaje się, że zespół pracujący nad Gutenbergiem ma niewielkie pojęcie o tym, w jaki sposób używane są metaboxy, nie ma troski o to, jaki będzie wpływ , i zamierza iść naprzód ze swoją wizją bez względu na wszystko”, powiedział Jimmy Smutek, główny programista w biurze spraw zewnętrznych w Johns Hopkins, w odpowiedzi na przyznanie się współpracowników Gutenberga do odrzucenia opinii.

Po kilku rundach programistów dołączających do wątku, aby obalić pogląd, że ramki iframe dla metaboxów „działają na teraz”, główny programista Gutenberg, Matias Ventura, dołączył wczoraj do dyskusji i potwierdził, że eksperyment prawdopodobnie zostanie wkrótce porzucony.

„Cieszę się, że rozmowa skupiła się pod koniec na temacie: czy obecne podejście do metaboxów w iframe jest opłacalne? Odpowiedź brzmi „nie” — powiedziała Ventura. „Iframe to szczegół implementacji, który, jak sądzę, możemy stosunkowo łatwo usunąć. Więc skupmy się na tym.”

Odniósł się również do popularnej opinii, że WordPress powinien wprowadzić iteracyjne ulepszenia samego edytora (a nie całej strony), zanim przejdzie do przeglądu metaboxów.

„To, co niektórzy nazywają pragmatycznym podejściem, nie jest zgodne z kierunkiem projektowania, który ten projekt miał od samego początku – zmierzając w kierunku pełnej personalizacji witryny – i co dyktowało nasze dotychczasowe decyzje” – powiedział Ventura. „Nic tutaj nie musi być ostatecznym rozwiązaniem, badamy, co jest możliwe w pomieszczeniach projektowych i wystawiamy je tam do testów”.

Ventura powiedział, że niewprowadzanie zmian w innych aspektach ekranu edycji byłoby z pewnością najprostszą ścieżką dla Gutenberga, ale że „nie byłoby to sprawiedliwe wobec celów projektu i długoterminowych użytkowników WordPressa”.

Deweloper WordPress, Gary Jones, twierdził, że bardziej iteracyjne podejście nie zmieniłoby celów projektu, ale umożliwiłoby pojawienie się większej liczby witryn w trakcie tego procesu.

„Podejście krok po kroku w żaden sposób nie zagraża celom projektu” — powiedział Jones. „Nadal możesz przejść do pełnej personalizacji, jeśli to jest celem, ale robiąc to krok po kroku, sprowadzisz ze sobą resztę społeczności programistów”. Jones przytoczył Customizer jako przykład funkcji w WordPressie, której koncepcja jest realizowana z biegiem czasu w wielu iteracjach.

Ventura odpowiedziała, wyjaśniając podejście zespołu Gutenberga do iteracji projektu, zmiana paradygmatu, która od samego początku wspiera tworzenie treści opartej na blokach.

„Zaproponowaliśmy podejście etapowe, z oryginalnego postu Matta o nowych skupieniach, który po prostu traktuje poszczególne kroki w inny sposób” – powiedział Ventura. „Projekt Gutenberg składa się z trzech etapów: od edytora postów, przez szablony stron, po budowanie witryny. Pierwotne jest to, że paradygmat to taki, w którym treść jest pojedynczym obszarem, z blokiem jako podstawową koncepcją, a wynik może być wizualnie reprezentowany z klarownością i bez nadmiernej abstrakcji”.

Ventura zapewnił również tych, którzy śledzili dyskusję, że projekt nie zrezygnuje z obsługi metaboksy, ale potrzebuje więcej czasu na eksperymentowanie z różnymi opcjami interfejsu.

„WordPress zawsze porusza się wraz z użytkownikiem, a my bierzemy na siebie ciężar opracowania ścieżek rozwoju, aby ułatwić przejścia dla naszego istniejącego kodu” – powiedział. „Jako projekt powiedzieliśmy wcześniej, że nie rezygnujemy z obsługi metaboxów z WordPressa, ale także, że musimy zbadać, jakie decyzje dotyczące interfejsu będziemy musieli podjąć w ramach nowego paradygmatu, w tym możliwość załadowania klasycznego edytora kiedy wykryjemy metaboxy, z którymi nie możemy sobie poradzić lub które bezpośrednio kolidują z edytorem, który stara się wyraźniej określić, co jest treścią, a co metadanymi.”

Powiedział również, że zespół planuje stworzyć więcej mechanizmów radzenia sobie z niezgodnościami, a także „pozwolić na akceptację większej liczby rzeczy (powiedzmy, że jeśli czujesz się komfortowo ze swoimi meta-boksami wyświetlanymi w Gutenbergu, możesz zadeklarować ich wsparcie lub odwrotnie. ”

Obecnie trwają prace nad nowym podejściem do renderowania metaboksów bez użycia elementów iframe. Riad Benguella stworzył pull request, który próbuje cofnąć elementy iframe i zaimplementować sugestię zaoferowaną przez Toma Nowella podczas dyskusji:

Zamiast ładować Gutenberga na stronie ustawień, załadujmy go do głównej strony klasycznych edytorów, załaduj metaboksy w ich natywnym środowisku, a następnie przenieś węzeł DOM kontenera do komponentu za pośrednictwem JS.

Następnie używamy innego rodzaju przełącznika, aby upewnić się, że klasyczny edytor nadal może być używany. Tą drogą:

– unikamy bzdur iframe
– metaboksy działają jak zawsze, jeśli chodzi o rejestrację
– istniejący JS działa zgodnie z oczekiwaniami i nie są potrzebne żadne hacki, aby wszystko działało na końcu PHP

Nowe podejście ma tę zaletę, że nie ma problemów z linkami, modalami, duplikatami arkuszy stylów i innymi wadami korzystania z ramek iframe.

Zespół Gutenberga potrzebuje nowej strategii komunikacji

Dyskusja dotycząca długoterminowej opłacalności używania ramek iframe w metaboksach zwróciła uwagę na brak jednolitego przekazu lub strategii komunikacyjnej wśród leadów Gutenberga. Współpracownicy w projekcie zniecierpliwili się, że społeczność nie pojmuje wizji, ale komunikacja jest rozproszona po różnych blogach, komentarzach, kanałach Slack i dyskusjach GitHub.

Morten Rand-Hendriksen otworzył nowy numer, prosząc o scentralizowany zasób, który może służyć jako prosty opis zakresu, kierunku i celów Gutenberga.

„Moja obserwacja jest taka, że ​​społeczność ma trudności z zobaczeniem szerszego zakresu projektu Gutenberg z powodu braku jednego wiarygodnego zasobu zawierającego te informacje w prostym języku”, powiedział Rand-Hendriksen. „Stwarza to wysoki stopień spekulacji, nieporozumień i frustracji ze strony wszystkich stron, w wyniku czego projekt cierpi”.

Gutenberg ma centrum dokumentacji, ale jak dotąd dokumenty te są bardziej techniczne i brakuje im praktycznej mapy drogowej, w jaki sposób zespół dąży do osiągnięcia swoich celów. Sekcja FAQ w aktualnych dokumentach jest najbardziej zbliżona do zasobu w prostym języku, o który prosi Rand-Hendriksen w swoim zgłoszeniu. Pliki readme.txt zarówno dla repozytorium GitHub Gutenberga, jak i wtyczki WordPress.org sprawiają wrażenie, że projekt po prostu aktualizuje bieżący edytor tak, aby był oparty na blokach, a nie przerabiał cały ekran edytora.

„Ze względu na rozdrobniony charakter tych informacji trudno jest każdemu uzyskać jasny obraz całego projektu i chociaż posty Matiasa i Matta dobrze radzą sobie z wyjaśnieniem wielkiej wizji projektu, brakuje w nich konkretnych, prostych podziałów podstawowe informacje, których społeczność potrzebuje, aby dobrze zrozumieć, czym jest ten projekt i dokąd zmierza” – powiedział Rand-Hendriksen. „Istnieją również jako niezależne satelity informacji okrążające projekt, a nie główne części samego projektu”.

Społeczność dołącza do problemu GitHub z pytaniami, na które chcieliby uzyskać odpowiedzi w bardziej przejrzystej mapie drogowej produktu w prostym języku. Taki dokument może pomóc zespołowi Gutenberga w lepszym komunikowaniu celów projektu i unikaniu wysyłania mieszanych wiadomości, które powodują niepotrzebne zamieszanie.