Połowa katalogu wtyczek jest porzucona

#Wprowadzenie

Zmierzyliśmy katalog wtyczek WordPress.org 10 sierpnia 2026. Z 69 286 wtyczek 35 696 nie dostało aktualizacji od co najmniej dwóch lat, czyli 51,5 procent. Nie jest to liczba przepisana z cudzego raportu, bo takiego raportu nie ma. Poniżej metoda, wyniki przy czterech progach i to, co z nich wynika dla kogoś, kto utrzymuje cudze strony.

#W skrócie

• 35 696 z 69 286 wtyczek bez aktualizacji od dwóch lat, czyli 51,5 procent katalogu.
• 28 146, czyli 40,6 procent, bez aktualizacji od pięciu lat.
• 20 242, czyli 29,2 procent, bez aktualizacji od ośmiu lat.
• W próbie 5250 porzuconych wtyczek 5,9 procent ma tysiąc lub więcej aktywnych instalacji, co daje około 2100 takich wtyczek w całym ogonie.
• Krążące w sieci 43,8 procent i 59 procent nie mają źródła pierwotnego. Sprawdziłem oba. Prawda leży między nimi.
• Metoda jest opisana i powtarzalna jednym poleceniem, bo liczba, której nie da się sprawdzić, jest warta tyle co tamte dwie.

#Dlaczego w ogóle mierzyłem

Miałem napisać tekst oparty na liczbie 43,8 procent porzuconych wtyczek. Zanim ją użyłem, poszukałem źródła. Nie ma żadnego.

Poszukałem alternatywy i znalazłem powtarzaną w wielu miejscach liczbę 59 procent, przy około 34 tysiącach wtyczek. Wygląda solidniej, bo pojawia się z liczbą bezwzględną. Sprawdziłem tekst, który ją wprowadza, i tam też nie ma odniesienia. Autor cytuje WordPress.org i WPExperts, ale na łączną liczbę wtyczek w katalogu, a przy samym odsetku porzuconych nie podaje niczego.

To jest typowy cykl życia statystyki w tej branży. Ktoś podaje liczbę bez źródła, kolejny ją cytuje z linkiem do pierwszego, trzeci cytuje drugiego, a po roku wygląda to na wiedzę powszechną. U nas obowiązuje reguła przyjęta 31 lipca 2026, po tym jak usunęliśmy z serwisu wszystkie kwoty i statystyki, których nie dało się podeprzeć. Publikowanie tej liczby złamałoby ją wprost.

Została więc jedna uczciwa droga: policzyć.

#Metoda, żeby dało się to powtórzyć

WordPress.org wystawia publiczne API katalogu pod adresem api.wordpress.org/plugins/info/1.2/. Tryb browse=updated zwraca wtyczki posortowane malejąco po dacie ostatniej aktualizacji.

Skoro lista jest posortowana, odpowiedź na pytanie „ile wtyczek jest starszych niż dwa lata” to po prostu ranga pierwszej wtyczki starszej od progu. Do jej znalezienia nie trzeba pobierać całego katalogu, wystarczy wyszukiwanie binarne po stronach. Dziewięć zapytań zamiast siedmiuset.

Cały pomiar siedzi w repozytorium jako npm run measure:plugin-abandonment i powtórzenie go zajmuje kilkadziesiąt sekund. Jeżeli czytasz to za pół roku i liczby wyglądają inaczej, to nie dlatego, że któreś z nas się myli, tylko dlatego, że katalog żyje.

#Wyniki przy czterech progach

Katalog liczył w chwili pomiaru 69 286 wtyczek, a najświeższa aktualizacja pochodziła sprzed kilkunastu minut.

Najciekawszy jest kształt tego rozkładu, nie pojedyncza liczba. Między progiem dwóch a ośmiu lat ubywa tylko 15 tysięcy wtyczek, czyli większość porzuconych wtyczek nie została porzucona niedawno. Prawie trzy dziesiąte całego katalogu to kod, którego nikt nie dotknął od ośmiu lat, czyli od czasów WordPressa 4.8, sprzed Gutenberga, sprzed PHP 7.2, sprzed bloków.

#Liczba, która ma znaczenie praktyczne

Odsetek porzuconych wtyczek jest sam w sobie ciekawostką. Katalog może zawierać dowolnie dużo martwego kodu i nie zaszkodzi to nikomu, dopóki nikt go nie używa.

Dlatego zmierzyłem drugą rzecz: ile z tych porzuconych wtyczek nadal działa na stronach. Wziąłem próbę systematyczną z ogona katalogu, co siódma strona wyników, 5250 wtyczek, i policzyłem aktywne instalacje.

Przeniesienie udziału 5,9 procent na cały ogon daje około 2100 wtyczek, które nie dostały aktualizacji od dwóch lat i mimo to działają na tysiącu lub więcej stron każda.

To jest liczba, którą warto zapamiętać zamiast tamtego odsetka. Dwa tysiące kawałków kodu, każdy na co najmniej tysiącu stron, każdy bez opiekuna od dwóch lat.

Zaznaczam wyraźnie: to jest próba, nie spis. Wzięta systematycznie, a nie losowo, więc gdyby aktywne instalacje układały się w ogonie w regularny wzór o okresie siedmiu stron, wynik byłby obciążony. Nie widzę powodu, dla którego miałyby się tak układać, ale odnotowuję to zamiast udawać, że policzyłem wszystkie 35 696.

#Czego ten pomiar nie widzi

Zanim pójdę dalej, trzy rzeczy, których ta metoda z założenia nie obejmuje. Wymieniam je, bo bez nich liczba 51,5 procent byłaby podana za dokładniejszą, niż jest.

Nie widzi wtyczek spoza katalogu. Każda wtyczka premium kupiona bezpośrednio u autora albo na marketplace jest poza tym API i nie ma jej w żadnym z powyższych zestawień. W typowym sklepie WooCommerce takich wtyczek jest kilka i to zwykle te najbardziej wrażliwe, bo dotykają płatności, wysyłki i danych klienta. Ich stan trzeba sprawdzać ręcznie, jedną po drugiej, i to jest praca, której nie da się zautomatyzować jednym zapytaniem.

Nie widzi wtyczek zamkniętych. Gdy wtyczka zostaje wycofana z katalogu, znika też z API, więc nie trafia ani do licznika, ani do mianownika. Paradoksalnie oznacza to, że wtyczki zamknięte z powodu podatności poprawiają statystykę, bo wypadają ze zbioru. Te 51,5 procent to udział wśród wtyczek, które w katalogu nadal są.

Aktywne instalacje są zaokrąglane przez WordPress.org do przedziałów, nie podawane dokładnie. Dlatego w tabeli niżej są koszyki, a nie sumy. Wtyczka z etykietą tysiąc instalacji może mieć ich tysiąc dwieście albo tysiąc dziewięćset i katalog tego nie rozróżnia. Do wniosku, który stąd wyciągam, ta rozdzielczość wystarcza, ale nie wystarczyłaby do niczego dokładniejszego.

Na polskim rynku ta pierwsza luka jest dobrze widoczna i sprawdziłem to tego samego dnia. Integracje kurierskie w katalogu są i mają opiekę: inpost-paczkomaty ma osiem tysięcy instalacji i wydanie z 31 lipca 2026, inpost-for-woocommerce dziesięć tysięcy i wydanie z rana 10 sierpnia, furgonetka siedem tysięcy i wydanie z 21 lipca. Po stronie płatności obraz jest inny. Autopay jest obecny jako platnosci-online-blue-media, imoje jako imoje, PayU jako woo-payu-payment-gateway, ale wtyczki wydawanej przez Przelewy24 ani przez Tpay w katalogu nie znalazłem, a jedyny wynik na “tpay” to gruziński klon z ostatnim wydaniem w kwietniu 2022. Sklep, który przyjmuje płatności przez któregoś z tych dwóch operatorów, ma na produkcji kod, o którym mój pomiar nie mówi absolutnie nic, i to akurat kod przy kasie.

#Co osiem lat bez aktualizacji znaczy w praktyce

Liczba 20 242 wtyczek nietkniętych od ośmiu lat jest abstrakcyjna, dopóki nie przypomni się, jak wyglądał wtedy WordPress.

Sierpień 2018 to WordPress 4.9. Gutenberg jeszcze nie był w rdzeniu, wszedł dopiero w grudniu tamtego roku wraz z 5.0. Edytor blokowy, czyli sposób, w jaki dziś powstaje praktycznie każda treść, jest dla tego kodu przyszłością, która nigdy nie nadeszła. Wtyczka z tamtego czasu nie ma pojęcia o blokach, o register_block_type, o theme.json, o edycji całej witryny.

Po stronie PHP jest podobnie. Wtedy powszechnie używano PHP 7.0 i 7.1, a wiele hostingów siedziało jeszcze na 5.6. Od tego czasu weszły typy właściwości, argumenty nazwane, wyrażenia match, atrybuty, a przede wszystkim PHP 8 zmieniło wiele ostrzeżeń w błędy krytyczne. Kod, który w 2018 roku wypisywał notice do logu, dziś potrafi wyłożyć stronę.

Nie znaczy to, że każda taka wtyczka jest zepsuta. Znaczy, że nikt tego nie sprawdził, a odległość między jej założeniami a dzisiejszym środowiskiem jest ośmioletnia.

#Czego ta liczba nie znaczy

Porzucona wtyczka nie jest automatycznie dziurawa i nie chcę, żeby ten tekst czytało się jako straszak.

Wtyczka, która dodaje jeden shortcode i nie przyjmuje żadnych danych z zewnątrz, może działać dziesięć lat bez aktualizacji i być zupełnie bezpieczna. Brak aktualizacji może też znaczyć, że kod jest skończony, co w świecie, gdzie wszystko wypuszcza cotygodniowe wydania, brzmi obco, ale bywa prawdą przy naprawdę małych narzędziach.

Ryzyko nie bierze się z wieku, tylko z powierzchni ataku. Rośnie tam, gdzie wtyczka przyjmuje dane od użytkownika, tworzy własne endpointy REST, obsługuje przesyłanie plików, buduje zapytania do bazy z parametrów albo dotyka płatności i danych osobowych. Wiek jest wtedy mnożnikiem, nie przyczyną: stary kod obsługujący pliki jest groźny nie dlatego, że stary, tylko dlatego, że przez te lata zmieniły się i PHP, i sposoby ataku, a on nie.

Jest jeszcze druga strona tego samego. Wtyczka aktualizowana co tydzień też może być dziurawa, i to świeżo. Data ostatniej aktualizacji jest sygnałem o opiece, a nie o jakości kodu.

#Jak to sprawdzić u siebie w piętnaście minut

Trzy kroki, w tej kolejności, i żaden nie wymaga narzędzia płatnego.

Zrób listę. Wyciągnij slugi wszystkich wtyczek z każdej utrzymywanej instalacji. Przy jednej stronie wystarczy panel, przy kilkudziesięciu potrzebny jest WP-CLI i pętla po serwisach. Efektem ma być jedna lista, a nie dwadzieścia zakładek.

Odpytaj katalog. Dla każdego sluga pobierz z API datę ostatniej aktualizacji i liczbę aktywnych instalacji. To jedno zapytanie na wtyczkę i można je zrobić hurtem. Wtyczki spoza katalogu, czyli premium i własne, nie będą miały odpowiedzi i to samo w sobie jest wynikiem: one nigdy nie pojawią się w żadnym takim zestawieniu, a to zwykle one dotykają płatności.

Posortuj po ryzyku, nie po dacie. Kolumna z datą sama w sobie nic nie mówi. Interesuje Cię przecięcie trzech rzeczy: dawno nieaktualizowana, dotyka danych lub płatności, trudna do wyłączenia bez szkody dla klienta. Wtyczka spełniająca wszystkie trzy warunki to pozycja na najbliższy tydzień, a nie na kiedyś.

Przy okazji tej samej listy warto od razu wpisać, którą wtyczkę da się wyłączyć na godzinę bez konsekwencji. Ta informacja jest bezcenna w dniu incydentu, a zbieranie jej wtedy jest najgorszym możliwym momentem.

#Co z tym zrobić, gdy wtyczka faktycznie jest porzucona

Kolejność od najtańszego do najdroższego, bo pierwsze wyjście rozwiązuje więcej przypadków, niż się wydaje.

Sprawdź, czy jest jeszcze potrzebna. Znaczna część porzuconych wtyczek na stronach klientów robi rzecz, której nikt już nie używa: formularz z kampanii sprzed trzech lat, integrację z serwisem, który zamknięto, widżet w stopce, którą przebudowano. Usunięcie jest wtedy pełnym rozwiązaniem i zajmuje minutę.

Sprawdź, czy rdzeń już tego nie robi. WordPress przez ostatnie lata wchłonął sporo funkcji, które kiedyś wymagały wtyczki: lazy loading obrazów, formaty WebP, część pracy z blokami, mapa strony XML. Wtyczka z 2017 roku bywa dziś nadmiarowa.

Poszukaj utrzymywanego zamiennika. Tu warto patrzeć nie na liczbę instalacji, tylko na częstotliwość wydań i na to, czy autor odpowiada w forum wsparcia. Wtyczka z milionem instalacji i ostatnim wydaniem sprzed roku jest gorszym wyborem niż ta z pięcioma tysiącami i wydaniem w zeszłym miesiącu.

Przepisz na własny kod, jeśli funkcja jest mała. Wtyczka, która robi jedną rzecz w pięćdziesięciu liniach, częściej powinna być pięćdziesięcioma liniami we własnej wtyczce funkcjonalnej niż zależnością od kogoś, kto zniknął. To jest realna praca, ale kończy problem raz na zawsze, a nie przenosi go na następnego opiekuna.

Zostaw i pilnuj, świadomie. Czasem nie ma zamiennika, a przepisanie jest zbyt drogie. To jest legalna decyzja, pod warunkiem że jest zapisana: kto ją podjął, kiedy, i co ma się stać, gdy pojawi się CVE. Różnica między długiem technicznym a bałaganem polega na tym, że dług jest udokumentowany.

#Trzy przypadki z praktyki, po jednym na każdą decyzję

Żeby nie zostawić tego na poziomie zasad, trzy typowe sytuacje, w których ta lista prowadzi do trzech różnych wniosków.

Wtyczka do galerii, ostatnia aktualizacja pięć lat temu, około tysiąca instalacji, na stronie używana na jednej podstronie. Sprawdzenie zajmuje minutę: czy rdzeń robi już to samo. Bloki galerii w WordPressie obsługują dziś układy, lightbox i obrazy responsywne, więc odpowiedź brzmi zwykle tak. Wyjście najtańsze, czyli usunięcie i przełożenie treści na blok, kończy sprawę bez szukania zamiennika.

Wtyczka do formularzy, ostatnia aktualizacja trzy lata temu, kilkadziesiąt tysięcy instalacji, na stronie obsługuje formularz kontaktowy i zapis do newslettera. Tu wiek jest istotny, bo formularz przyjmuje dane z zewnątrz i zapisuje je do bazy, czyli ma dokładnie tę powierzchnię, która się starzeje najgorzej. Duża liczba instalacji nie uspokaja, tylko przeciwnie: sprawia, że wtyczka jest atrakcyjnym celem. To jest kandydat na zamianę na utrzymywany odpowiednik, z migracją zapisanych zgłoszeń, i to jest praca na pół dnia, nie na minutę.

Wtyczka integrująca z systemem kurierskim, ostatnia aktualizacja dwa lata temu, kilkaset instalacji, bez zamiennika, wpięta w checkout. Najtrudniejszy przypadek, bo wyłączyć nie można, a zamiennika nie ma. Tu jedyną uczciwą decyzją jest zostawić i zapisać: kto zdecydował, kiedy, co się dzieje przy CVE, i kto sprawdza raz na kwartał, czy autor wrócił. Bez tego zapisu za rok nikt nie będzie pamiętał, że to była decyzja, a nie przeoczenie.

Wspólny mianownik jest taki, że data ostatniej aktualizacji nigdy nie jest sama w sobie wnioskiem. Jest wejściem do rozmowy, w której liczy się jeszcze powierzchnia ataku, koszt wyłączenia i istnienie zamiennika.

#Dlaczego to się nie naprawi samo

Katalog nie ma mechanizmu, który usuwałby wtyczkę za sam brak aktualizacji, i dobrze, bo taki mechanizm skasowałby także kod skończony i działający. Ma za to mechanizm zamykania wtyczek z powodów bezpieczeństwa, i ten działa.

Problem polega na tym, że oba te fakty razem tworzą krajobraz, w którym domyślnym stanem wtyczki jest trwanie. Autor przestaje odpowiadać, wtyczka zostaje. Instalacje spadają powoli, bo strony rzadko usuwają cokolwiek. Po ośmiu latach mamy dwadzieścia tysięcy wtyczek w katalogu i nikogo po drugiej stronie.

Do tego dochodzi liczba, którą podaje Patchstack w raporcie State of WordPress Security in 2026: 46 procent podatności nie miało łatki w momencie publicznego ujawnienia. Przy wtyczce z opiekunem brak łatki jest kwestią godzin lub dni. Przy wtyczce porzuconej łatki nie będzie nigdy, bo nie ma komu jej napisać.

Nie zamierzam kończyć apelem do katalogu, bo katalog nie jest tu głównym aktorem. Jedyna strona, która może coś zrobić z porzuconą wtyczką na konkretnej stronie, to osoba, która tę stronę utrzymuje.

#Jak to się ma do sześciogodzinnego wstrzymania

Kilka dni temu opisywałem inicjatywę Protect the Shire, która wstrzymuje każde nowe wydanie wtyczki do sześciu godzin, żeby automat zdążył się przyjrzeć temu, co idzie do auto-aktualizacji. Zestawienie tamtego tekstu z tym pomiarem daje wniosek, którego żaden z nich nie daje osobno.

Wstrzymanie chroni przed złośliwym wydaniem. Żeby zadziałało, musi istnieć wydanie. Cała jego wartość dotyczy więc wtyczek, które ktoś nadal wydaje, czyli tej połowy katalogu, która ma opiekuna.

Druga połowa, ta z tego pomiaru, jest poza zasięgiem tego mechanizmu w całości. Wtyczka nietknięta od ośmiu lat nie wypuści złośliwego wydania, ale też nie wypuści łatki. Nie ma czego wstrzymywać, bo nic nie przychodzi. Ryzyko przenosi się z tego, co przyjdzie, na to, co już leży zainstalowane.

To dwa różne problemy z tym samym słowem w nazwie i warto ich nie mylić. Pierwszy rozwiązuje katalog i robi to coraz lepiej. Drugiego katalog nie rozwiąże, bo rozwiązanie polega na tym, żeby ktoś zajrzał na konkretną stronę i podjął decyzję o konkretnej wtyczce.

#Powtórz ten pomiar sam

Skrypt jest publiczny w naszym repozytorium i uruchamia się jednym poleceniem. Odpytuje wyłącznie publiczne API WordPress.org, nie wymaga klucza i wykonuje mniej niż pięćdziesiąt zapytań na cały pomiar.

Jeśli wyjdzie Ci co innego niż mnie, napisz. Wolę być poprawiony liczbą niż cytowany bez sprawdzenia, bo dokładnie z braku sprawdzania wzięły się te 43,8 i 59 procent, od których zacząłem.

#Źródła

• API katalogu wtyczek WordPress.org, tryb browse=updated, pomiar z 10 sierpnia 2026
• Patchstack, State of WordPress Security in 2026, 25 lutego 2026

Ostatnia weryfikacja: 10 sierpnia 2026.