Du öppnar WooCommerce-adminpanelen och ser tre tusen produkter, hälften dubbletter från en misslyckad import, med attribut som "Color 1", "Color 2", "Size_copy_2023". Gränssnittet "Produkter → markera alla → Ta bort" ger timeout efter de första par hundra. Låter det bekant? Massrensning av kataloger är en uppgift alla ställs inför vid migrering av en butik, sammanslagning av en staging-databas med produktion eller relansering av en butik efter en omprofilering.

Problemet bottnar i hur WooCommerce är uppbyggt: produkter är utspridda över fyra tabeller (wp_posts, wp_postmeta, wp_term_relationships och wp_term_taxonomy), och attribut lagras i ytterligare tre. Du kan inte bara klicka "Ta bort alla"; motorn kraschar innan den når slutet av listan. Du behöver ett verktyg som går förbi gränssnittet och träffar databasen direkt, eller arbetar via CLI.

Här nedan följer tre fungerande metoder, från radikal SQL till säkra plugins. Med backup, med prefixkontroller och med förståelse för exakt vad som händer i varje tabell.

💡 Snabb översikt:

• Gör en fullständig databasdump; DELETE är oåterkalleligt, det finns ingen papperskorg
• Kontrollera tabellprefixet i wp-config.php och ersätt wp_ med det
• Kör SQL-kommandona i kaskadordning: attribut → produkter → föräldralös postmeta
• Om du har SSH hanterar WP-CLI det med ett enda kommando och kör nödvändiga hooks
• För en produktionsbutik utan SQL-erfarenhet är plugins med en "Ta bort"-knapp säkrare

Försiktighetsåtgärder: backup och prefix

Alla SQL-kommandon som ändrar innehållet i WordPress-tabeller är oåterkalleliga. DELETE frågar inte om bekräftelse, skickar inte posten till papperskorgen; raden försvinner omedelbart och permanent. Regel nummer ett: gör en fullständig databasbackup innan du kör någon av frågorna nedan.

Den mest tillförlitliga metoden är att exportera en dump via phpMyAdmin: fliken "Exportera" → SQL-format → komprimera med gzip. Eller via din webbhotellspanel (cPanel → Backup → Databas). För dig som arbetar från kommandoraden:

1
mysqldump -u username -p database_name > backup_$(date +%Y%m%d).sql

Andra punkten: alla frågor nedan använder standardprefixet wp_. Om du ändrade prefixet under WordPress-installationen till wpx_, store_ eller något annat, ersätt wp_ i varje kommando med ditt. Det faktiska prefixet finns i wp-config.php, på raden $table_prefix. Kontrollerat? Då sätter vi igång.

Metod 1: SQL-kommandon i phpMyAdmin, full kontroll

Den snabbaste och mest radikala metoden. Passar bäst när du behöver rensa hundratals eller tusentals poster i en enda körning och standardgränssnittet i WooCommerce ger timeout. Alla frågor körs i phpMyAdmin på fliken "SQL", en i taget, i strikt ordning.

Ta bort WooCommerce-attribut

Attribut finns i tre tabeller samtidigt: wp_terms, wp_term_taxonomy och wp_term_relationships. De skiljer sig från vanliga kategorier och taggar genom prefixet pa_ i fältet taxonomy, en förkortning för "product attribute". Du måste ta bort dem i kaskad, med början på termer och avslut med relationer:

1
DELETE FROM wp_terms WHERE term_id IN
2
(SELECT term_id FROM wp_term_taxonomy WHERE taxonomy LIKE 'pa_%');
3
 
4
DELETE FROM wp_term_taxonomy WHERE taxonomy LIKE 'pa_%';
5
 
6
DELETE FROM wp_term_relationships WHERE term_taxonomy_id NOT IN
7
(SELECT term_taxonomy_id FROM wp_term_taxonomy);

Den första frågan tar bort attributnamn från wp_terms. Den andra tar bort deras taxonomiposter från wp_term_taxonomy. Den tredje rensar upp föräldralösa "term-objekt"-relationer från wp_term_relationships som lämnats utan en överordnad taxonomi. Ordningen spelar roll: om du tar bort taxonomin före termerna kommer den tredje frågan att fånga upp för mycket.

Ta bort WooCommerce-produkter

Produkter och deras variationer är poster med typen product och product_variation i tabellen wp_posts. Men att bara radera rader från wp_posts räcker inte: metadata kommer att finnas kvar i wp_postmeta (pris, SKU, fraktinställningar) och termrelationer kommer att finnas kvar i wp_term_relationships (kategorier, taggar). Tre frågor, i kaskad:

1
DELETE FROM wp_term_relationships WHERE object_id IN
2
(SELECT ID FROM wp_posts WHERE post_type IN ('product','product_variation'));
3
 
4
DELETE FROM wp_postmeta WHERE post_id IN
5
(SELECT ID FROM wp_posts WHERE post_type IN ('product','product_variation'));
6
 
7
DELETE FROM wp_posts WHERE post_type IN ('product','product_variation');

Först bryter vi produktens relationer med taxonomier, sedan tar vi bort metadatan, och först därefter själva produktposten. Om du vänder på ordningen och tar bort wp_posts först, kommer underfrågorna SELECT ID FROM wp_posts i det andra och tredje steget att returnera en tom mängd, och metadatan och relationerna blir kvar som dödvikt i databasen.

Rensa upp föräldralös postmeta

Efter alla borttagningsoperationer via SQL är det värt att kontrollera om wp_postmeta innehåller rader som refererar till icke-existerande poster. Detta händer vid avbrutna transaktioner, trasiga importer eller när poster tagits bort utan kaskad:

1
DELETE pm
2
FROM wp_postmeta pm
3
LEFT JOIN wp_posts wp ON wp.ID = pm.post_id
4
WHERE wp.ID IS NULL;

Frågan hittar alla wp_postmeta-rader som saknar en överordnad post i wp_posts och tar bort dem. Den är säker: den rör inte levande data, bara skräp.

Metod 2: WP-CLI, snabbt och utan phpMyAdmin

Om du har SSH-åtkomst till servern hanterar WP-CLI massborttagning mer elegant än några SQL-frågor. Ett kommando, så går WooCommerce själv igenom de relaterade tabellerna och lämnar inga föräldralösa data efter sig:

1
wp wc product delete $(wp wc product list --field=ID --per_page=-1) --force

Flaggan --per_page=-1 exporterar ID:n för alla produkter utan paginering. --force hoppar över papperskorgen och tar bort permanent. Om du har fler än 10 000 produkter är det bättre att dela upp i batcher om 500 för att undvika att nå minnesgränser:

1
wp wc product list --field=ID --per_page=500 --page=1 | xargs wp wc product delete --force

För att ta bort attribut via WP-CLI, använd:

1
wp wc product_attribute list --field=id --per_page=-1 | xargs -I{} wp wc product_attribute delete {} --force

Den främsta fördelen med WP-CLI jämfört med rå SQL är att den utlöser WooCommerces interna hooks, before_delete_post och after_delete_post. Det ger cachnings- och sökplugins (Elasticsearch, Redis, Relevanssi) en chans att städa upp sina index. SQL-frågor gör inte detta; efter dem kan sökningen fortsätta att visa redan raderade produkter under en tid.

Metod 3: plugins, när du inte vill röra databasen

För den som tycker att kommandoraden och phpMyAdmin är för riskabla erbjuder marknaden specialiserade plugins. De arbetar ovanpå samma SQL-frågor men döljer dem bakom en knapp.

Delete All Products for WooCommerce är ett gratis plugin från det officiella WordPress.org-arkivet. Det lägger till en enda knapp i adminpanelen. Klicka → välj "flytta till papperskorgen" eller "permanent" → bekräfta. Minimalt med steg, noll risk för ett SQL-skrivfel. Nackdelen: det fungerar bara med produkter, det rör inte attribut.

WooCommerce Store Toolkit (också känt som Store Toolkit for WooCommerce) är ett mer seriöst alternativ. Det rensar inte bara produkter och attribut utan även ordrar, kuponger, sessioner och transienter, med filter för datum och status. Passar för en fullständig djuprengöring av butiken inför en relansering.

Oavsett vilket plugin du väljer gäller fortfarande säkerhetskopieringsregeln. Ett plugin kör samma DELETE-frågor; du ser dem bara inte.

Jämförelse av metoder: vad du ska välja och när

Om du har en produkt eller ett dussin räcker WooCommerces gränssnitt "Produkter → markera → Radera". Hundratals eller tusentals kräver SQL eller WP-CLI. En liveproduktionsbutik där det inte finns utrymme för misstag kräver ett plugin eller WP-CLI.

Viktiga begränsningar: vad som inte raderas

Massradering av produkter och attribut via SQL rör inte mediafiler. Produktbilder som laddats upp till WordPress mediebibliotek (poster med post_type = 'attachment') ligger kvar, både i filsystemet och i databasen. Om du bygger om katalogen från grunden och vill frigöra utrymme hos ditt webbhotell måste mediafiler rensas separat: via "Media → markera → Radera permanent" eller WP-CLI:

1
wp post delete $(wp post list --post_type=attachment --field=ID --per_page=-1) --force

SQL-kommandon uppdaterar inte heller WooCommerce räknare (produktantal per kategori) som cachas i wp_termmeta och wp_options som transienter med prefixet _wc_term_counts_. Efter en massradering kan adminpanelen tillfälligt visa felaktigt antal produkter per kategori. Detta åtgärdas genom omräkning:

1
wp wc tool run recount_terms

Eller via tillägget Recount Terms från tilläggsarkivet.

Videon ger en steg-för-steg-genomgång av SQL-kommandon för att radera WooCommerce-attribut i phpMyAdmin: navigera i tabellerna och verifiera resultaten efter varje fråga.

⁉️🤔 Vanliga frågor

Är det säkert att radera produkter via SQL i en livebutik?

I en produktionsbutik är rå SQL för massradering en riskabel metod. Ett enda skrivfel i ett tabellnamn eller en WHERE-sats kan påverka ordrar, användare eller inställningar. Om butiken är live och genererar intäkter, använd WP-CLI eller tillägg som inte låter dig skjuta dig själv i foten. Spara SQL för utvecklingsmiljöer, staging och situationer där admin-gränssnittet redan har slutat ladda.

Varför syns produkter fortfarande i sajtens sökning efter SQL-radering?

Söktillägg (Relevanssi, Elasticsearch, SearchWP) har sitt eget index, som inte uppdateras när wp_posts manipuleras direkt, förbi WordPress API. Efter rensning via SQL måste du bygga om sökindexet i tilläggets inställningar eller via WP-CLI: till exempel wp relevanssi index --reindex.

Hur raderar jag produkter från endast en specifik kategori, inte alla?

Lägg till ett filter på den önskade kategorins term_taxonomy_id. Tillvägagångssättet: hämta kategorins term_id → hitta term_taxonomy_id i wp_term_taxonomy → filtrera object_id i wp_term_relationships innan du raderar från wp_posts. I praktiken är det enklare att använda WP-CLI: wp wc product list --category=slug-kategorii --field=ID | xargs wp wc product delete --force.

Kan produkter återställas efter SQL-radering?

Endast från en säkerhetskopia. Till skillnad från radering via WordPress papperskorg (Flytta till papperskorgen) raderar SQL-kommandot DELETE rader fysiskt och oåterkalleligt. Det är just därför regeln "säkerhetskopia först" upprepas i varje avsnitt av denna artikel. Två minuter på en dump sparar timmar på återställning.

Vad är skillnaden mellan att radera attribut och att radera variationer?

Variationer är en undertyp av produkter (product_variation). De raderas med samma SQL-kommandon som enkla produkter: villkoret post_type IN ('product','product_variation') i det andra blocket av "Metod 1" inkluderar redan variationer. Attribut (pa_color, pa_size) är taxonomier; de raderas separat, med det första blocket av SQL-kommandon. Rätt ordning är: produkter först (inklusive variationer), sedan attribut. Om det görs i omvänd ordning förlorar variationerna sina attributkopplingar, men själva variationsposterna finns kvar i databasen.

Vad du ska använda 2026: slutresultatet

SQL-kommandon, WP-CLI och tillägg är tre verktyg med olika risknivåer för en uppgift. Valet kokar ner till en enkel matris:

• Du har SSH och kommandoradserfarenhet → WP-CLI (wp wc product delete). Säkert, snabbt, med hooks.
• Ingen SSH men du har phpMyAdmin och förstår tabellschemat → SQL. Full kontroll, omedelbara resultat. Men säkerhetskopia först.
• Du vill ha noll risk → Delete All Products eller Store Toolkit. Långsammare, men en knapp istället för en SQL-fråga.

I alla scenarier är en databassäkerhetskopia åtgärd nummer ett. Börja inte utan den.

🔗 Delete All Products for WooCommerce, gratis på WordPress.org🔗 WooCommerce Store Toolkit, avancerad butiksrensning