Nettstedet ditt snegler seg av gårde, sikkerhetskopier svulmer opp til en gigabyte, og phpMyAdmin viser dusinvis av tabeller med prefikser fra utvidelser du «slettet» for et år siden. Høres det kjent ut?

Standard «Slett»-knappen i utvidelsesdelen fjerner bare mappen fra wp-content/plugins. Alt annet (tabeller, innstillinger, cron-jobber, shortkoder i innlegg) blir værende i databasen og på disk. Utviklere håndterer opprydding forskjellig: noen rydder grundig opp etter seg via uninstall.php, mens andre lar alt stå urørt.

Nedenfor finner du en komplett algoritme for å fjerne en utvidelse sporløst: fra dashbordet til manuell SQL. Med sikkerhetskopier på hvert trinn og presise instruksjoner for populære utvidelser.

💡 Rask oversikt:

• Sletting via dashbordet er bare første steg; tabeller, shortkoder og cron-jobber krever separat opprydding
• Før enhver databaseoperasjon, ta en full sikkerhetskopi (bruk innebygde verktøy hos hostingleverandøren eller en utvidelse)
• WooCommerce, Yoast SEO, Wordfence og andre populære utvidelser har sine egne konstanter og SQL-spørringer
• En deaktivert utvidelse er ikke «slått av», men «sovende»; filene er fortsatt tilgjengelige for direkte tilgang og utgjør en angrepsvektor

Hvorfor «Slett»-knappen ikke er nok

WordPress kaller en utvidelses uninstall.php eller callback fra hovedfilen når den slettes. Men dette fungerer bare hvis utvikleren har laget en slik fil. I praksis mangler omtrent halvparten av utvidelsene fra WordPress.org-katalogen enten uninstall.php eller implementerer den delvis: de sletter mappen, men lar databasen stå urørt.

Hva som gjenstår etter standard sletting:

Rader med autoload-flagget er spesielt kritiske: WordPress laster dem ved hver forespørsel. Femti ekstra autoload-rader legger til 30-80 ms i serverresponstid. Virker ubetydelig ved første øyekast, men med 100 000 månedlige visninger er det et merkbart ytelsestap.

Deaktivering vs sletting: hva er forskjellen

Forskjellen er grunnleggende, og det er nyttig å forstå den før oppryddingen begynner.

En deaktivert utvidelse er ikke «slått av», men «sovende». PHP-filer ligger fysisk på serveren. Hvis det oppdages et sikkerhetshull i koden, kan en angriper få tilgang til filen direkte via banen i wp-content/plugins/, og omgå WordPress-logikken. WAF-brannmurer løser ikke dette problemet: den beste beskyttelsen er å fjerne ubrukt kode fra serveren fullstendig.

Regelen er enkel: hvis du ikke har brukt en utvidelse på over en uke, slett den. Å konfigurere på nytt går raskere enn å håndtere et innbrudd via et hull i forlatt kode.

Trinnvis opprydding: 4 steg

Steg 1: Sletting via dashbordet

Første steg er standard. Gå til Utvidelser → Installerte, finn den du trenger. Aktive utvidelser er uthevet med en blå stripe, deaktiverte er det ikke.

Klikk «Slett» under navnet, bekreft med «Ja, slett disse filene»-knappen. WordPress vil kalle utvidelsens uninstall.php (hvis den finnes) og slette mappen fra wp-content/plugins.

For enkle utvidelser (en lettvekts-widget, erstatning av logo på innloggingssiden) er oppryddingen ferdig her. De oppretter ikke tabeller eller skriver til wp_postmeta. Men hurtigbuffer-, SEO-, sikkerhets-, galleri- og sidebygger-utvidelser krever videre handling.

Steg 2: Filopprydding via FTP

Noen utvidelser oppretter mapper utenfor wp-content/plugins/. Typiske plasseringer:

• wp-content/uploads/plugin-name/: hurtigbuffer, komprimerte bilder, eksporterte filer
• wp-content/ngg/: NextGEN Gallery
• wp-content/ewww/: EWWW Image Optimizer
• wp-content/backup/: sikkerhetskopi-utvidelser

Koble til serveren via FTP (FileZilla, WinSCP) eller hostingleverandørens filbehandler. Naviger til wp-content/, finn mappen med utvidelsesnavnet og slett den. Last ned mappen lokalt før sletting; hvis den inneholdt brukeropplastinger, gjenopprett dem.

Hurtigbuffer-utvidelser (WP Rocket, W3 Total Cache, LiteSpeed Cache) skriver i tillegg til wp-content/cache/ og oppretter wp-content/advanced-cache.php. Slett filen advanced-cache.php manuelt via FTP, og finn og fjern denne linjen i wp-config.php:

1
define('WP_CACHE', true);

Steg 3: Fjerne shortkoder fra innhold

Utvidelser som legger til shortkoder (skjemaer, gallerier, slider, tabeller) etterlater nakne [shortcode] i innleggsteksten etter sletting. Det ser rotete ut og forvirrer leserne.

En rask måte å stilne ubrukte shortkoder på er én linje i det aktive temaets functions.php:

1
add_shortcode('pluginshortcode', '__return_false');

Erstatt pluginshortcode med din shortkode-tag. For eksempel: nggallery, gravityform eller contact-form-7. Funksjonen __return_false returnerer false, og shortkoden forsvinner fra frontend uten å bli fjernet fra innleggsteksten.

Legg til koden via et child theme eller Code Snippets-utvidelsen; redigeringer i hovedtemaets functions.php vil gå tapt ved neste oppdatering. Hvis du senere bestemmer deg for å gjenopprette utvidelsen, er det bare å fjerne denne linjen.

Steg 4: Databaseopprydding

Det mest kritiske steget. Ta en full databasesikkerhetskopi før enhver SQL-spørring for sletting; eksport via phpMyAdmin tar et halvt minutt og redder deg fra irreversible feil.

4a. Finn utvidelsens tabeller. Gå til phpMyAdmin (via cPanel eller ditt hosting-administrasjonspanel), velg nettstedets database. Se etter tabeller med utvidelsesprefikset: wp_wc_* (WooCommerce), wp_yoast_* (Yoast SEO), wp_wf* (Wordfence). Velg dem, velg «Drop» nederst → bekreft.

4b. Automatisering med Advanced Database Cleaner. Hvis du foretrekker å ikke jobbe direkte i phpMyAdmin, installer Advanced Database Cleaner. Denne gratisutvidelsen skanner databasen, finner foreldreløse tabeller og poster, og sletter dem med ett klikk.

4c. Rydd opp i wp_options. Selv om utvidelsen ikke opprettet egne tabeller, skrev den nesten helt sikkert til wp_options. Kjør i phpMyAdmin (SQL-fane):

1
SELECT * FROM wp_options WHERE option_name LIKE '%pluginname%';

Erstatt pluginname med en del av utvidelsesnavnet. Bekreft at radene faktisk tilhører den slettede utvidelsen, deretter:

1
DELETE FROM wp_options WHERE option_name LIKE '%pluginname%';

4d. Rydd opp i cron-jobber. Noen utvidelser registrerer sine egne cron-hendelser. Installer WP Crontrol; den viser alle registrerte cron-jobber i én liste. Finn hendelser med utvidelsesnavnet og slett dem manuelt.

Spesifikt om fjerning av populære utvidelser

Hver større utvidelse etterlater et unikt fotavtrykk. Nedenfor finner du presise instruksjoner for de vanligste.

WooCommerce

WooCommerce oppretter 16+ tabeller i databasen. For å få dem ryddet opp automatisk ved sletting, legg til i wp-config.php (før linjen /* That's all, stop editing! */):

1
define('WC_REMOVE_ALL_DATA', true);

Denne konstanten tvinger WooCommerce til å kalle sin fulle uninstall.php ved sletting; alle wp_woocommerce_*- og wp_wc_*-tabeller vil bli slettet, inkludert produkter, ordrer og kuponger. Operasjonen er irreversibel, så backup er obligatorisk.

Etter at du har slettet utvidelsen, sjekk i tillegg wp_options, siden WooCommerce skriver dusinvis av rader der med prefikset woocommerce_:

1
SELECT * FROM wp_options WHERE option_name LIKE '%wc_%';

Hvis det finnes rader og utvidelsen allerede er slettet, kjør DELETE-spørringen med samme betingelse.

Yoast SEO

Yoast SEO etterlater poster i wp_postmeta og wp_usermeta, samt sine egne tabeller wp_yoast_indexable og wp_yoast_seo_links.

Først, rens wp_postmeta:

1
SELECT * FROM wp_postmeta WHERE meta_key LIKE '%yoast%';

Etter å ha bekreftet at dette er Yoast-data, kjør:

1
DELETE FROM wp_postmeta WHERE meta_key LIKE '%yoast%';

Deretter, wp_usermeta:

1
SELECT * FROM wp_usermeta WHERE meta_key LIKE '%yoast%';

Slett det du finner med en tilsvarende DELETE-spørring. Yoast registrerer også cron-jobben wpseo_onpage_fetch; fjern den via WP Crontrol. Slett tabellene wp_yoast_indexable og wp_yoast_seo_links manuelt via phpMyAdmin.

Akismet

Akismet er standardutvidelsen for kommentarsøppel, forhåndsinstallert med WordPress. Etter sletting ligger dataene igjen i wp_commentmeta:

1
SELECT * FROM wp_commentmeta WHERE meta_key LIKE '%akismet_%';

Deretter:

1
DELETE FROM wp_commentmeta WHERE meta_key LIKE '%akismet_%';

Hvis nettstedet har tusenvis av kommentarer, kan wp_commentmeta veie dusinvis av megabyte. Etter opprydding, optimaliser tabellen:

1
OPTIMIZE TABLE wp_commentmeta;

Flere måter å bekjempe spam på finner du i artikkelen vår slik stopper du WordPress-kommentarspam: alle 18 løsninger.

Gravity Forms

Gravity Forms oppretter 9 tabeller i databasen (wp_gf_*, wp_rg_*). Før sletting, gå til Skjemaer → Innstillinger → Avinstaller og bekreft. Slett deretter utvidelsen fra dashbordet.

Etter sletting, sjekk wp_options:

1
SELECT * FROM wp_options WHERE option_name LIKE '%gravity%' OR option_name LIKE '%gf_%';

Slett radene som ble funnet med en tilsvarende DELETE-spørring.

Wordfence

Wordfence er en av de "tyngste" sikkerhetsutvidelsene: den oppretter 23 tabeller med prefikset wp_wf*. Standard sletting via dashbordet rydder dem ikke.

Den offisielle hjelpeutvidelsen Wordfence Assistant ble avviklet av utvikleren i desember 2025. Så vi rydder manuelt: slett hovedutvidelsen Wordfence via dashbordet, gå deretter til phpMyAdmin og utfør:

1
SELECT * FROM wp_options WHERE option_name LIKE '%wordfence%' OR option_name LIKE '%wf%';

Slett radene som ble funnet med en DELETE-spørring med samme betingelse. Finn og slett deretter alle tabeller med prefikset wp_wf (det er vanligvis 23 av dem, fra wp_wfblockediplog til wp_wflivetraffichuman). Via FTP, slett mappen wp-content/wflogs/ og filen wordfence-waf.php i nettstedets rot hvis de fortsatt er der.

NextGEN Gallery

Utvidelsen oppretter 3 tabeller (wp_ngg_*) og en mappe wp-content/ngg/ med opplastede gallerier.

Først, slett utvidelsen via dashbordet. Slett deretter mappen wp-content/ngg/ via FTP, men ta vare på galleribildene først hvis du trenger dem. I phpMyAdmin, utfør:

1
SELECT * FROM wp_options WHERE option_name LIKE '%ngg%';

Slett radene som ble funnet med en DELETE-spørring med samme betingelse. Slett tabellene wp_ngg_pictures, wp_ngg_galleries og wp_ngg_album manuelt.

EWWW Image Optimizer

EWWW lagrer data om hvert optimalisert bilde i tabellen wp_ewwwio_images: filbane, opprinnelig størrelse, størrelse etter komprimering. Den oppretter også en mappe wp-content/ewww/ med cache.

Slett mappen via FTP. Deretter i phpMyAdmin:

1
SELECT * FROM wp_options WHERE option_name LIKE '%ewww%';

Slett det du finner, og slett tabellen wp_ewwwio_images.

WP All Export

Utvidelsen oppretter 4 tabeller i databasen. Etter sletting via dashbordet går du til phpMyAdmin, finner tabeller med prefikset wp_pmxe_*, markerer dem og kjører «Drop». Sjekk i tillegg wp_options for nøkkelen pmxe; utvidelsen lagrer siste eksportinnstillinger der.

Flere detaljer om hele syklusen for fjerning av utvidelser finner du i videoveiledningen nedenfor.

⁉️🤔 Ofte stilte spørsmål

Er det trygt å slette utvidelsestabeller direkte via phpMyAdmin?

Det er trygt under to forutsetninger: du har tatt en full databasebackup og har nøyaktig identifisert tabellene som tilhørende en allerede slettet utvidelse. Tredjeparts utvidelsestabeller har alltid et gjenkjennelig prefiks: wp_wc_, wp_yoast_ eller wp_wf. Ikke rør WordPress-systemtabeller (wp_posts, wp_options, wp_users, wp_comments, wp_postmeta og wp_usermeta) med DROP; du kan bare rense dem med selektiv DELETE.

Hva bør jeg gjøre hvis nettstedet viser en hvit skjerm etter sletting av utvidelsen?

Gjenopprett utvidelsen fra backup: last opp mappen via FTP, importer tabellene. Årsaken ligger mest sannsynlig i temaets functions.php, der et kall til en utvidelsesfunksjon kan stå igjen uten en fallback. Finn slike kall og pakk dem inn i function_exists() eller fjern dem, og gjenta deretter slettingen av utvidelsen.

Hvordan finner jeg alle spor av en utvidelse i databasen?

Installer Advanced Database Cleaner-utvidelsen. Den skanner alle tabeller for foreldreløse data og viser en komplett liste: tabeller, rader i wp_options og wp_postmeta, cron-jobber. Dette er raskere og tryggere enn manuelt søk via phpMyAdmin.

Bør jeg slette utvidelser som fulgte med temaet?

Ja, hvis du ikke bruker dem. Utvidelser som følger med temaer (WPBakery Page Builder, Slider Revolution, ACF Pro) kommer ofte med begrensede lisenser, og sikkerhetsoppdateringer kommer ikke for dem. En deaktivert, utdatert WPBakery med et kjent sikkerhetshull er en direkte vei til et innbrudd. Hvis du ikke bruker den, slett den.

Kan jeg gjenopprette en utvidelse etter fullstendig sletting?

Bare fra backup. Etter rensing av tabeller og wp_options er alle utvidelsesinnstillinger tapt permanent. Det er nettopp derfor algoritmen over er bygget fra enkel til radikal: først standard sletting (reversibel), deretter filopprydding, og først til slutt databasen. Gå gjennom stadiene sekvensielt; ikke hopp rett til phpMyAdmin.

Blir utvidelsesdata liggende igjen i WordPress Multisite?

I Multisite har hvert undernettsted sine egne tabeller: wp_2_options, wp_2_postmeta og så videre. Etter sletting av en utvidelse via superadmin, sjekk hvert undernettsteds tabeller (wp_*_options og wp_*_postmeta for alle blogg-ID-er). Utvidelsen kan ha vært aktivert på enkelte nettsteder i nettverket og etterlatt poster i tabellene deres.

Konklusjon: når fullstendig opprydding er berettiget

Hvis du har et lite nettsted og sletter en utvidelse en gang hvert halvår, er standard sletting via dashbordet pluss en engangs opprydding av wp_options tilstrekkelig.

Men hvis nettstedet ditt er flere år gammelt, dusinvis av utvidelser har passert gjennom det, og sikkerhetskopier har vokst til en gigabyte, vil kirurgisk opprydding etter instruksjonene over redusere databasen merkbart og gjøre adminpanelet raskere. I praksis har vi ryddet tusenvis av foreldreløse poster i wp_postmeta og dusinvis av unødvendige tabeller, og responstiden i adminpanelet ble redusert nesten til det halve.

Gjør det til en vane: etter sletting av en utvidelse, gå gjennom sjekklisten (FTP → wp_options → cron → tabeller). Ti minutter i dag sparer timer i morgen, når en oppblåst database knekker nettstedet ditt ved topptrafikk.

Hvilken utvidelse etterlot mest søppel etter sletting på ditt nettsted? Fortell oss i kommentarfeltet.