Uruchomienie przetwarzania wsadowego na istniejącej bibliotece mediów

Co robi przebieg — i co musi być wcześniej włączone

Oba moduły obrazów w Kakapo Performance pracują w momencie, w którym WordPress tworzy rozmiary obrazów: kompresja ustawia jakość i usuwa znaczniki EXIF, IPTC i XMP z utworzonych rozmiarów, moduł formatów zakłada pliki pochodne WebP i AVIF. Oba działają więc od następnego przesłania pliku. Dla obrazów, które już leżą w bibliotece mediów, nie dzieje się nic — i właśnie tę lukę zamyka przebieg wsadowy.

Przebieg nie wymyśla pracy. Do istniejących zasobów stosuje dokładnie to, co powyżej zostało włączone dla nowych plików: WebP i/lub AVIF oraz „Usuń metadane”. Jeśli nic z tego nie jest włączone, przycisk startu jest zablokowany i podaje powód — na przykład że serwer nie potrafi zapisywać WebP albo że po prostu żadne ustawienie nie jest aktywne. Kartę „Przetwórz istniejącą bibliotekę mediów” znajdziesz w sekcji „Obrazy” pod ustawieniami obrazów; kolejność w interfejsie odpowiada kolejności obsługi: najpierw ustawienia, potem przebieg po istniejących zasobach.

Ruszane są wyłącznie załączniki typu JPEG i PNG, które nie leżą w koszu. Wiersz „Obrazy JPEG/PNG w zasobie” podaje ci tę liczbę, zanim wystartujesz.

Uruchamianie, obserwowanie, zatrzymywanie

Kliknięcie „Uruchom przebieg zbiorczy” tworzy przebieg i rozpoczyna go natychmiast. Praca odbywa się w turach z budżetem czasu 8 sekund; potem tura zgłasza wynik, wskazania są aktualizowane, a następna startuje po 200 milisekundach. Jeśli na końcu tury pozostaje mniej niż 3,5 sekundy, żaden kolejny załącznik nie jest już rozpoczynany — moduł formatów liczy wewnętrznie co najmniej trzy sekundy na obraz. Na serwerach z ustawionym max_execution_time budżet jest dodatkowo ograniczony do 80 procent tej granicy, aby tura nie została ucięta w środku żądania.

Pasek pokazuje rzeczywisty postęp: liczbę załatwionych załączników podzieloną przez liczbę całkowitą. Poniżej widnieją bieżące liczby — utworzone i pominięte pliki pochodne, po jednym wierszu dla WebP i AVIF, do tego odchudzone pliki i zwolnione bajty. Na samym dole przewija się ostatnich 14 wierszy protokołu, każdorazowo z nazwą pliku i tym, co przy tym pliku wyszło.

„Zatrzymaj” wstrzymuje przebieg. Przycisk nazywa się potem „Kontynuuj”, a następny start podejmuje pracę dokładnie przy tym załączniku, przy którym się zatrzymała. To samo dzieje się, gdy po prostu zamkniesz kartę: przebieg się wstrzymuje, nic nie ginie. Po ponownym otwarciu strona odpytuje stan i sama popycha dalej wciąż otwarty przebieg.

Jak przebieg znosi przerwanie

Stan zapisywany jest przed pracą nad każdym pojedynczym załącznikiem, a nie dopiero po niej. Jeżeli przebieg umrze w połowie — limit wykonania serwera WWW, pamięć operacyjna, plik, którym GD się zakrztusi — to następny przebieg wie, gdzie się zacięło. Jeżeli ten sam załącznik przez trzy podejścia nie robi żadnego postępu, zostaje pominięty z opisanym wprost wierszem w protokole, zamiast trzymać przebieg trwale przy jednym pliku.

Dwie jednocześnie otwarte strony administracyjne nie mogą sobie wejść w drogę: blokada dopuszcza zawsze tylko jeden przebieg. Jeżeli serwer WWW ubije przebieg, a blokada pozostanie, po 180 sekundach uchodzi ona za osieroconą i zostaje przejęta.

Przy kontynuowaniu liczba całkowita ustalana jest na nowo, zamiast być zamrożoną — między zatrzymaniem a kontynuacją coś mogło zostać przesłane albo usunięte. Jeżeli w środku przebiegu wyłączysz wszystkie ustawienia obrazów, zatrzyma się on sam, zamiast wykonywać pracę, której nikt już nie zlecił. „Zresetuj” odrzuca postęp i raport; już utworzone pliki pozostają.

Prawidłowe czytanie raportu

Na końcu widnieje wiersz końcowy ze zmierzonymi rozmiarami plików — nie z szacunkami. Dla każdego utworzonego pliku pochodnego przebieg porównuje rozmiar pliku źródłowego z rozmiarem wyniku, w obu przypadkach są to rzeczywiste wartości z chwili utworzenia. Liczone jest tylko to, co powstało na nowo w tym przebiegu; to, co zostało przekształcone już przy przesyłaniu, nie pojawia się po raz drugi.

Trzy rzeczy są tam podane świadomie właśnie tak, a nie ładniej: WebP i AVIF dostają osobne wiersze, ponieważ z tego samego pliku źródłowego powstają dwa pliki pochodne — wspólna suma liczyłaby plik źródłowy podwójnie. Wartości procentowe obowiązują dlatego dla każdego wiersza z osobna i nie wolno ich dodawać; przeglądarka pobiera zawsze tylko jeden z obu formatów. A nowe pliki zajmują dodatkowo miejsce na dysku twardym: oszczędza się przy przesyłaniu do gościa. Miejsce na dysku naprawdę zwalnia wyłącznie usuwanie metadanych, a te bajty widnieją w osobnym wierszu.

Jeżeli nic nie powstało, raport mówi także o tym: albo dla całego zasobu wszystko było już zrobione, albo żaden wynik nie był mniejszy od swojego pliku źródłowego. Wynik, który nie jest mniejszy, zostaje odrzucony i liczony jako „pominięty” — nigdy jako zysk.

Gdy coś zostaje pominięte

Każdy nieutworzony plik pochodny otrzymuje powód opisany wprost, a powody zebrane są w wierszu końcowym:

• „nie mniejszy niż plik źródłowy” — normalne, plik źródłowy pozostaje. • „za duży na dostępną pamięć operacyjną” — moduł formatów sprawdza wymiary obrazu przed dekodowaniem i odmawia, zamiast pozwolić PHP wejść w limit pamięci. • „w miejscu docelowym leżał już plik” — nie zostaje nadpisany. Dzieje się tak zwykle wtedy, gdy notatka przy załączniku zaginęła, a pliki nadal leżą. • „nie da się odczytać” — uszkodzony, JPEG w CMYK albo egzotyczna odmiana. • „nie da się zapisać” — sprawdzić uprawnienia w folderze uploads. • „format niedostępny na tym serwerze” — AVIF wymaga PHP 8.1 lub nowszego z libavif, WebP biblioteki GD z libwebp.

Dwie rzeczy, które często brane są za błędy, choć nimi nie są: drugi przebieg nie pokazuje już prawie żadnego ruchu, ponieważ to, co załatwione, nie jest powtarzane — znacznik przy załączniku odnotowuje, dla ilu plików usuwanie metadanych jest już zrobione. A kto zmienia stopień jakości, nie odnawia tym żadnego już utworzonego pliku; do tego pliki pochodne musiałyby najpierw zniknąć.