Nie każda ważna historia wokół WordPressa 7.0 kończy się wejściem funkcji do finalnego wydania. Dobrym przykładem jest client-side media processing, czyli przetwarzanie obrazów po stronie przeglądarki. Jeszcze w Beta 1 WordPress przedstawiał tę funkcję jako jedną z nowości 7.0: przeglądarka miała przejmować zadania takie jak zmiana rozmiaru i kompresja obrazów, żeby odciążyć serwer i usprawnić workflow pracy z mediami.
To był bardzo ciekawy kierunek. Problem w tym, że w trakcie cyklu beta pojawiły się trudności. W Beta 6 Core oficjalnie poinformował o wycofaniu funkcji z paczki 7.0 z powodu problemów z optymalizacją obrazów i rozmiarem builda, a w RC1 zapisano już wprost, że client-side media pozostaje plugin only. Innymi słowy: to nie jest martwy pomysł, ale na tym etapie nie wygląda na część finalnego Core WordPressa 7.0.
To był jeden z ciekawszych kierunków 7.0
Szkoda, bo sam pomysł był naprawdę sensowny. Oficjalna zapowiedź Beta 1 opisywała client-side media processing jako wykorzystanie możliwości przeglądarki do obsługi takich zadań jak zmiana rozmiaru i kompresja obrazów. WordPress podkreślał przy tym trzy korzyści: możliwość użycia bardziej zaawansowanych formatów i technik kompresji, mniejsze obciążenie serwera oraz płynniejszy workflow pracy z mediami — zarówno dla nowych, jak i już istniejących treści.
To ważne, bo media od dawna są jednym z tych obszarów WordPressa, w których użytkownicy odczuwają tarcie niemal natychmiast. Duże pliki, ciężkie zdjęcia, import z telefonów, różne formaty, opóźnienia przy uploadzie — to nie są problemy abstrakcyjne. To codzienność pracy z treścią. Już podczas produktowego przeglądu 7.0 zwracano uwagę, że ulepszenia po stronie client-side media i uploadów mają zmniejszyć długo istniejące tarcie, a jako konkretny przykład problemu wskazano m.in. HEIC.
O co w tym właściwie chodziło
Najprościej mówiąc, WordPress chciał przenieść część pracy związanej z obróbką obrazów z serwera do przeglądarki użytkownika. Zamiast wysyłać na serwer wszystko w pierwotnej formie i dopiero tam robić kolejne operacje, część z nich mogłaby wydarzyć się wcześniej — lokalnie, po stronie klienta. W materiałach związanych z Gutenbergiem i planowaniem 7.0 ten kierunek był obecny od dłuższego czasu, a styczniowe i lutowe aktualizacje deweloperskie pokazywały, że funkcja realnie dojrzewała w cyklu wydawniczym.
W praktyce oznaczałoby to kilka potencjalnych korzyści. Po pierwsze, serwer miałby mniej pracy przy samym przyjmowaniu i wstępnej obróbce dużych obrazów. Po drugie, użytkownik mógłby dostać sprawniejszy upload i bardziej przewidywalne zachowanie przy cięższych plikach. Po trzecie, otwierałoby to drogę do nowocześniejszych formatów i technik kompresji bliżej samego urządzenia użytkownika. To właśnie ten zestaw korzyści był komunikowany w zapowiedziach 7.0.
Dlaczego to było ciekawsze niż zwykła „optymalizacja obrazków”
Najciekawsze w tej funkcji nie było samo przyspieszenie uploadu. Ciekawsze było to, że WordPress próbował zmienić miejsce, w którym dzieje się część pracy z mediami. To subtelna, ale duża różnica. Zamiast myśleć o obróbce obrazów wyłącznie jako o zadaniu backendu, Core testował model bardziej nowoczesny: skoro przeglądarki mają dziś coraz większe możliwości, to może część procesu da się wykonać wcześniej i bliżej użytkownika.
To dobrze wpisywało się też w szerszy klimat WordPressa 7.0. W tej wersji widać sporo prób przesuwania ciężaru z dawnych, sztywnych modeli działania w stronę bardziej elastycznych, nowocześniejszych workflowów — czy to we współtworzeniu, czy w pracy z blokami, czy właśnie w mediach. Client-side media processing wyglądało jak część tej samej większej opowieści.
Dlaczego funkcja wypadła z Core
Tutaj najważniejsze są fakty. W Beta 6 zespół Core napisał wprost, że po testach ujawniono problemy związane z image optimization i package size, dlatego ta beta wraca do mniejszej paczki i reverts the Client-side Media Processing feature. To nie brzmi jak porzucenie pomysłu, ale zdecydowanie brzmi jak sygnał: funkcja nie była jeszcze gotowa, by bezpiecznie jechać dalej do finalnego wydania jako część Core.
Potem sytuację doprecyzował RC1, gdzie wśród zmian pojawia się już bardzo konkretna pozycja: “Client Side Media as plugin only”. To właściwie zamyka temat w kontekście WordPressa 7.0 jako finalnego release’u: jeśli nic się nie zmieni po drodze, funkcja nie wchodzi do Core w tej wersji, tylko zostaje poza nim, w formie pluginowej.
To zresztą jest całkiem rozsądna decyzja. Akurat media to jeden z tych obszarów, gdzie półgotowe rozwiązanie może bardzo szybko sprawić użytkownikom realne problemy. Jeśli coś dotyczy uploadu, kompresji i przetwarzania obrazów, lepiej wycofać funkcję na chwilę niż wypchnąć ją zbyt wcześnie i potem tłumaczyć się z błędów w codziennej pracy z treścią. To już jest interpretacja, ale dobrze wynika z samej natury problemu i z oficjalnego uzasadnienia wycofania.
To nie wygląda jak porażka, tylko jak niedomknięty etap
Warto tu zachować proporcje. Fakt, że client-side media processing nie trafia do finalnego 7.0 jako część Core, nie oznacza jeszcze, że cały kierunek został porzucony. Wręcz przeciwnie: ta funkcja była obecna w planowaniu 7.0, wymagała backportów jeszcze przy opóźnieniu Beta 1, była omawiana w kolejnych wpisach o Gutenbergu i dotarła aż do etapu, w którym trzeba było podjąć decyzję: wpychamy to na siłę do release’u czy zostawiamy jako plugin-only. WordPress wybrał ostrożniejszą drogę.
To w gruncie rzeczy dość zdrowy sygnał. Lepiej zobaczyć, że projekt potrafi wycofać funkcję z release’u, gdy pojawiają się realne problemy, niż udawać, że wszystko jest gotowe tylko dlatego, że temat dobrze wygląda w zapowiedziach. Zwłaszcza że media to nie jest poboczny gadżet, tylko bardzo wrażliwy fragment codziennej pracy z WordPressem.
Co mimo wszystko mówi nam ta historia o WordPressie
Nawet jako funkcja, która ostatecznie wypada z Core 7.0, client-side media processing pozostaje ciekawym sygnałem kierunku. Pokazuje, że WordPress coraz poważniej myśli o wykorzystaniu możliwości przeglądarki nie tylko w samym edytorze, ale też w zadaniach, które dawniej niemal automatycznie przypisywano backendowi. To może mieć znaczenie dużo szersze niż tylko dla obrazów.
Pokazuje też coś jeszcze: WordPress 7.0 to nie tylko lista funkcji, które „weszły”, ale też lista pomysłów, które przeszły już daleką drogę, choć nie zdążyły do końca dojrzeć na czas tego konkretnego release’u. W tym sensie client-side media processing jest ważnym tematem serii o 7.0 nawet właśnie dlatego, że nie kończy się prostym „i oto nowa funkcja w finalnej wersji”.
Co to oznacza dla użytkowników i twórców stron
Dla zwykłego użytkownika najważniejszy wniosek jest prosty: jeśli ktoś liczył, że WordPress 7.0 od razu przyniesie natywny, gotowy w Core model client-side media processing, to na dziś wszystko wskazuje, że tak się nie stanie. Beta 1 zapowiadała ten kierunek, ale późniejsze etapy release’u go wycofały.
Dla osób śledzących rozwój WordPressa to jednak nadal temat wart uwagi. Bo jeśli coś doszło tak daleko w cyklu wydawniczym, było regularnie rozwijane i ostatecznie zostało odsunięte nie z powodu braku sensu, ale z powodu jakości i gotowości, to znaczy, że najpewniej jeszcze wróci — tylko już w lepiej dopracowanej formie. To jest ostrożna inferencja, nie oficjalna zapowiedź, ale wydaje się dobrze wsparta przebiegiem całego cyklu 7.0.
Najkrótszy wniosek
Client-side media processing miało być jedną z ciekawszych, bardziej nowoczesnych nowości WordPressa 7.0: przeglądarka miała przejąć część pracy związanej z obrazami, co mogło odciążyć serwer i usprawnić workflow mediów. Tak było komunikowane na początku cyklu.
Ale na finiszu WordPress zrobił krok wstecz: Beta 6 wycofała tę funkcję z Core z powodu problemów z optymalizacją obrazów i rozmiarem paczki, a RC1 potwierdziło już model plugin only. To sprawia, że zamiast wpisu o „nowej funkcji 7.0” dostajemy ciekawszą historię: o funkcji, która dobrze pokazuje kierunek rozwoju WordPressa, ale nie zdążyła jeszcze dojrzeć na czas tego wydania.
