Halvparten av plugin-katalogen er forlatt

#Innledning

Vi målte WordPress.org sin programtilleggskatalog 10. august 2026. Av 69 286 programtillegg hadde 35 696 ikke fått oppdatering på minst to år, altså 51,5 prosent. Tallet er ikke hentet fra andres rapport, for en slik rapport finnes ikke. Under følger metoden, resultatene ved fire terskler, og hva som følger av dem for den som drifter andres nettsteder.

#Kort sagt

• 35 696 av 69 286 programtillegg uten oppdatering på to år, 51,5 prosent av katalogen.
• 28 146, eller 40,6 prosent, uten oppdatering på fem år.
• 20 242, eller 29,2 prosent, uten oppdatering på åtte år.
• I en stikkprøve på 5250 forlatte programtillegg har 5,9 prosent tusen eller flere aktive installasjoner, som gir rundt 2100 i hele halen.
• Tallene som sirkulerer, 43,8 prosent og 59 prosent, har ingen primærkilde. Jeg sjekket begge. Sannheten ligger mellom dem.
• Metoden er dokumentert og kan gjentas med én kommando, for et tall du ikke kan etterprøve er nøyaktig like mye verdt som de to.

#Hvorfor jeg målte i det hele tatt

Jeg skulle skrive en tekst bygget på tallet 43,8 prosent forlatte programtillegg. Før jeg brukte det, lette jeg etter kilden. Den finnes ikke.

Jeg lette etter et alternativ og fant 59 prosent, gjentatt mange steder sammen med et tall på rundt 34 000 programtillegg. Det virker mer solid fordi det kommer med et absolutt tall. Jeg leste teksten som innfører det, og der finnes heller ingen henvisning. Forfatteren siterer WordPress.org og WPExperts, men for det totale antallet programtillegg, og for selve andelen forlatte oppgir han ingenting.

Dette er den vanlige livssyklusen til en statistikk i denne bransjen. Noen publiserer et tall uten kilde, den neste siterer den første med lenke, en tredje siterer den andre, og et år senere leses det som allmennkunnskap. Hos oss gjelder en regel fra 31. juli 2026, etter at vi fjernet alle tall vi ikke kunne belegge fra vårt eget nettsted. Å publisere dette tallet ville brutt den direkte.

Da sto én ærlig vei igjen: telle.

#Metoden, slik at den kan gjentas

WordPress.org tilbyr et offentlig katalog-API på api.wordpress.org/plugins/info/1.2/. Modusen browse=updated returnerer programtillegg sortert synkende etter dato for siste oppdatering.

Siden listen er sortert, er svaret på spørsmålet om hvor mange programtillegg som er eldre enn to år ganske enkelt rangen til det første programtillegget eldre enn terskelen. Å finne den krever ikke å laste ned hele katalogen, bare et binærsøk over sidene. Ni forespørsler i stedet for sju hundre.

Hele målingen ligger i repositoriet vårt som npm run measure:plugin-abandonment, og å gjenta den tar under ett minutt. Leser du dette om et halvt år og tallene ser annerledes ut, er det ikke fordi noen av oss tar feil. Det er fordi katalogen lever.

#Resultater ved fire terskler

Katalogen inneholdt 69 286 programtillegg da målingen ble gjort, og den ferskeste oppdateringen var minutter gammel.

Det interessante er formen på fordelingen, ikke ett enkelt tall. Mellom to- og åtteårsterskelen faller bare rundt 15 000 programtillegg bort, altså ble de fleste forlatte programtillegg ikke forlatt nylig. Nesten tre tideler av hele katalogen er kode ingen har rørt på åtte år: før Gutenberg, før PHP 7.2, før blokker.

#Tallet som betyr noe i praksis

Andelen forlatte programtillegg er i seg selv en kuriositet. Katalogen kan inneholde vilkårlig mye død kode uten å skade noen, så lenge ingen bruker den.

Derfor målte jeg en ting til: hvor mange av de forlatte programtilleggene som fortsatt kjører på nettsteder. Jeg tok en systematisk stikkprøve fra halen av katalogen, hver sjuende resultatside, 5250 programtillegg, og telte aktive installasjoner.

Overført på hele halen gir andelen på 5,9 prosent rundt 2100 programtillegg som ikke har fått oppdatering på to år og likevel kjører på tusen nettsteder eller mer hver.

Det er tallet å huske i stedet for prosentandelen. To tusen kodebiter, hver på minst tusen nettsteder, hver uten vedlikeholder i to år.

For å være tydelig: dette er en stikkprøve, ikke en fulltelling. Den er tatt systematisk og ikke tilfeldig, så dersom aktive installasjoner skulle følge et regelmessig mønster med periode på sju sider, ville resultatet vært skjevt. Jeg ser ingen grunn til at de skulle det, men jeg noterer det heller enn å late som om jeg telte alle 35 696.

#Hva denne målingen ikke ser

Tre ting metoden utelukker ved konstruksjon. Jeg nevner dem fordi 51,5 prosent ellers ville framstå mer presist enn det er.

Den ser ikke programtillegg utenfor katalogen. Ethvert premium-programtillegg kjøpt direkte fra utvikleren eller på en markedsplass ligger utenfor dette API-et og finnes ikke i noen av tallene over. En typisk WooCommerce-butikk kjører flere av dem, ofte de mest følsomme, for de berører betaling, frakt og kundedata. Tilstanden deres må sjekkes for hånd, ett om gangen, og det arbeidet erstattes ikke av én spørring.

Den ser ikke lukkede programtillegg. Når et programtillegg trekkes fra katalogen, forsvinner det fra API-et og havner verken i telleren eller nevneren. Paradoksalt nok betyr det at programtillegg lukket av sikkerhetshensyn forbedrer statistikken, fordi de faller ut av mengden. De 51,5 prosentene er en andel blant dem som fortsatt er oppført.

Aktive installasjoner oppgis av WordPress.org i intervaller, ikke eksakt. Derfor bruker tabellen over intervaller og ikke summer. Et programtillegg merket tusen installasjoner kan ha tolv hundre eller nitten hundre, og katalogen skiller ikke. For konklusjonen jeg trekker holder den oppløsningen, for noe finere ville den ikke holdt.

#Hva åtte år uten oppdatering betyr konkret

Tallet 20 242 programtillegg urørt i åtte år forblir abstrakt til man husker hvordan WordPress så ut den gangen.

August 2018 er WordPress 4.9. Gutenberg var ennå ikke i kjernen, det kom først i desember med 5.0. Blokkredigereren, som praktisk talt alt innhold lages med i dag, er for denne koden en framtid som aldri kom. Et programtillegg fra den tiden vet ingenting om blokker, om register_block_type, om theme.json, om redigering av hele nettstedet.

På PHP-siden er bildet det samme. PHP 7.0 og 7.1 var vanlige, og mange leverandører kjørte fortsatt 5.6. Siden da kom typede egenskaper, navngitte argumenter, match-uttrykk, attributter og framfor alt PHP 8, som gjorde mange advarsler om til fatale feil. Kode som i 2018 skrev en notice til loggen, kan i dag legge et nettsted ned.

Ingenting av dette betyr at hvert slikt programtillegg er ødelagt. Det betyr at ingen har sjekket, og at avstanden mellom antakelsene dets og dagens miljø er åtte år.

#Hva tallet ikke betyr

Et forlatt programtillegg er ikke automatisk sårbart, og denne teksten skal ikke leses som skremselspropaganda.

Et programtillegg som legger til én kortkode og ikke tar imot eksterne inndata, kan kjøre i ti år uten oppdatering og være helt trygt. Manglende oppdateringer kan også bety at koden er ferdig, noe som klinger fremmed i en verden av ukentlige utgivelser, men som stemmer for virkelig små verktøy.

Risiko oppstår ikke av alder, men av angrepsflate. Den stiger der et programtillegg tar imot brukerinndata, registrerer REST-endepunkter, håndterer opplastinger, bygger databasespørringer av parametere eller berører betaling og personopplysninger. Alder er da en multiplikator, ikke en årsak: gammel filhåndteringskode er ikke farlig fordi den er gammel, men fordi både PHP og angrepsteknikkene har gått videre og den ikke har det.

Det finnes en bakside. Et programtillegg oppdatert hver uke kan også være sårbart, og det ferskt. Datoen for siste oppdatering er et signal om vedlikehold, ikke om kodekvalitet.

#Slik sjekker du dine egne nettsteder på et kvarter

Tre steg i denne rekkefølgen, ingen krever betalt verktøy.

Lag listen. Hent ut slugene til alle programtillegg fra hver installasjon du drifter. Ett nettsted klarer seg med kontrollpanelet, dusinvis krever WP-CLI og en løkke. Resultatet skal være én liste, ikke tjue faner.

Spør katalogen. Hent dato for siste oppdatering og antall aktive installasjoner fra API-et for hver slug. Det er én forespørsel per programtillegg og kan gjøres samlet. Programtillegg utenfor katalogen, altså premium og egenutviklede, gir ingen svar, og den tomheten er i seg selv et resultat: de vil aldri dukke opp i en slik oversikt, og det er som regel de som berører betaling.

Sorter etter risiko, ikke etter dato. En datokolonne alene sier ingenting. Det du er ute etter er snittet av tre ting: lenge uten vedlikehold, berører data eller betaling, vanskelig å slå av uten skade for kunden. Et programtillegg som oppfyller alle tre er arbeid for denne uken, ikke for en gang.

Mens listen først er åpen, legg til en kolonne for hvilket programtillegg som kan slås av i en time uten konsekvenser. Den informasjonen er uvurderlig på dagen for en hendelse, og å samle den da er det verst tenkelige tidspunktet.

#Hva du gjør når et programtillegg virkelig er forlatt

Fra billigst til dyrest, for det første alternativet løser flere tilfeller enn man venter.

Sjekk om det fortsatt trengs. En stor andel av forlatte programtillegg på kundenettsteder gjør noe ingen bruker lenger: et skjema fra en kampanje for tre år siden, en integrasjon mot en tjeneste som er lagt ned, en modul i en bunntekst som er bygget om. Fjerning er da en fullstendig løsning og tar ett minutt.

Sjekk om kjernen gjør det nå. WordPress har de siste årene tatt opp i seg mye som før krevde et programtillegg: lazy loading, WebP, deler av blokkarbeidet, XML-nettstedskart. Et programtillegg fra 2017 er ofte rett og slett overflødig.

Let etter en vedlikeholdt erstatning. Vurder den etter utgivelsestakt og etter om utvikleren svarer i støtteforumet, ikke etter antall installasjoner. Et programtillegg med en million installasjoner og siste utgivelse for et år siden er et dårligere valg enn ett med fem tusen og en utgivelse forrige måned.

Skriv det selv om funksjonen er liten. Et programtillegg som gjør én ting på femti linjer hører oftere hjemme som femti linjer i ditt eget funksjonsprogramtillegg enn som en avhengighet til noen som har forsvunnet. Det er reelt arbeid, men det avslutter problemet i stedet for å sende det videre til neste vedlikeholder.

Behold og følg med, bevisst. Noen ganger finnes ingen erstatning og omskriving er for dyrt. Det er en legitim beslutning, forutsatt at den er skrevet ned: hvem tok den, når, og hva som skjer ved en CVE. Forskjellen på teknisk gjeld og rot er at gjeld er dokumentert.

#Tre tilfeller fra praksis, ett per beslutning

For ikke å bli stående i prinsipper, tre typiske situasjoner som fører til tre ulike konklusjoner.

Et galleriprogramtillegg, sist oppdatert for fem år siden, rundt tusen installasjoner, brukt på én underside. Sjekken tar ett minutt: gjør kjernen dette allerede. Blokkgallerier håndterer i dag oppsett, lightbox og responsive bilder, så svaret er som regel ja. Den billigste veien, å fjerne det og flytte innholdet inn i en blokk, avslutter saken uten å lete etter erstatning.

Et skjemaprogramtillegg, sist oppdatert for tre år siden, titusener av installasjoner, driver kontaktskjema og nyhetsbrevpåmelding. Her betyr alderen noe, for et skjema tar imot eksterne inndata og skriver dem til databasen, altså nettopp den flaten som eldes dårligst. Det høye installasjonstallet beroliger ikke, tvert imot gjør det programtillegget til et attraktivt mål. Dette er en kandidat for bytte til en vedlikeholdt motpart, med migrering av lagrede innsendinger, og det er en halv dags arbeid, ikke ett minutt.

En integrasjon mot et transportselskap, sist oppdatert for to år siden, noen hundre installasjoner, ingen erstatning, koblet inn i kassen. Det vanskeligste tilfellet, for det kan verken slås av eller byttes. Den eneste ærlige beslutningen er å beholde og skrive ned: hvem bestemte, når, hva som skjer ved en CVE, og hvem som sjekker kvartalsvis om utvikleren er tilbake. Uten den noteringen husker ingen om et år at det var en beslutning og ikke en forglemmelse.

Fellesnevneren er at datoen for siste oppdatering aldri er en konklusjon i seg selv. Den er en inngang til en avveining der også angrepsflate, kostnaden ved å slå av og hvorvidt en erstatning finnes teller.

#Hvorfor dette ikke ordner seg selv

Katalogen har ingen mekanisme som fjerner et programtillegg bare fordi det ikke oppdateres, og det er riktig, for en slik mekanisme ville også slettet kode som er ferdig og virker. Den har en mekanisme for å lukke programtillegg av sikkerhetshensyn, og den virker.

Problemet er at de to sammen skaper et landskap der normaltilstanden for et programtillegg er å bli værende. Utvikleren slutter å svare, programtillegget blir. Installasjonene synker sakte, for nettsteder fjerner sjelden noe. Åtte år senere står tjue tusen programtillegg i katalogen uten noen på den andre siden.

Legg til tallet Patchstack oppgir i State of WordPress Security in 2026: 46 prosent av sårbarhetene manglet en fiks da de ble offentliggjort. Ved et vedlikeholdt programtillegg er en manglende fiks et spørsmål om timer eller dager. Ved et forlatt kommer det aldri noen, fordi ingen er der til å skrive den.

Jeg avslutter ikke med en oppfordring til katalogen, for katalogen er ikke hovedaktøren her. Den eneste parten som kan gjøre noe med et forlatt programtillegg på et konkret nettsted, er personen som drifter det nettstedet.

#Hvordan dette henger sammen med de seks timene

For noen dager siden skrev jeg om Protect the Shire-initiativet, som holder igjen hver ny programtilleggsutgivelse i inntil seks timer slik at en automatisk gjennomgang kan se på det som er i ferd med å nå auto-oppdateringene. Å legge den teksten ved siden av denne målingen gir en konklusjon ingen av dem gir alene.

Ventetiden beskytter mot en ondsinnet utgivelse. For at den skal virke i det hele tatt, må det finnes en utgivelse. Hele verdien gjelder derfor programtillegg noen fortsatt gir ut, altså den halvparten av katalogen som har en vedlikeholder.

Den andre halvparten, den som er målt her, ligger helt utenfor mekanismen. Et programtillegg urørt i åtte år vil ikke levere en ondsinnet utgivelse, men heller ingen fiks. Det finnes ingenting å holde igjen, fordi ingenting kommer. Risikoen flytter seg fra det som kommer, til det som allerede er installert.

Dette er to ulike problemer med et felles ord i navnet, og de bør ikke forveksles. Det første løser katalogen, og den løser det stadig bedre. Det andre kan katalogen ikke løse, fordi løsningen består i at noen ser på et konkret nettsted og bestemmer noe om et konkret programtillegg.

#Gjenta målingen selv

Skriptet ligger offentlig i repositoriet vårt og kjører med én kommando. Det spør bare det offentlige WordPress.org-API-et, trenger ingen nøkkel og gjør færre enn femti forespørsler for hele målingen.

Får du et annet svar enn meg, si fra. Jeg blir heller korrigert med et tall enn sitert uten kontroll, for det er nettopp manglende kontroll de 43,8 og de 59 prosentene jeg startet med er laget av.

#Kilder

• API-et til WordPress.org sin programtilleggskatalog, modus browse=updated, målt 10. august 2026
• Patchstack, State of WordPress Security in 2026, 25. februar 2026

Sist verifisert: 10. august 2026.