
Kort svar: Åbn det variable produkt, og kontroller kæden i denne rækkefølge: attributterne er markeret til variationer, den konkrete kombination findes, variationen er aktiveret og har en pris, og lager/backorders er sat på det rigtige niveau. Hvis data er korrekte i admin, kontroller lookup-tabeller og derefter JavaScript/tema på staging. Ved mere end 30 variationer kan dropdowns bevidst være statiske, så ugyldige kombinationer først afvises efter valg.
Fagligt gennemgået: 28. august 2026
Kontrolgrundlag: WordPress 7.1, WooCommerce 11.0.1 og Chrome 151 på isoleret staging samt aktuel produktdokumentation. Tema, swatch-plugin og ekstern lagerkilde skal verificeres i den konkrete butik.
Et variabelt produkt består af to datalag: attributter som farve og størrelse samt de konkrete variationer, der kombinerer dem. Frontenden kan kun vise og købe det, som data, pris og lagerregler tillader. Fejlsøg derfor produktet i admin, før du begynder på CSS og JavaScript.
På denne side
| Model | Parent-produkt | Variation | Hvornår giver det mening? | Typisk fejlkilde |
|---|---|---|---|---|
| Parent-lager | Fælles antal | Egen status/pris, ikke eget antal | Alle variationer deler fysisk beholdning | En variation forventes at have eget antal |
| Variation-lager | Ikke fælles antal | Hver variation har antal/status | Størrelser/farver har separat lager | Parent-status eller import overskriver |
| Kombineret model | Fælles begrænsning | Variationdata efter butikkens design | Kun med dokumenteret extension/workflow | Uklar prioritet mellem to kilder |
Dokumenter modellen før en import eller bulkændring. Hvis teamet ikke kan svare på, hvor det korrekte antal kommer fra, er lookup-regenerering ikke første løsning.
Vælg ét berørt produkt og skriv de forventede kombinationer ned, fx:
| Farve | Størrelse | Skal kunne vælges? | Pris | Lagerstyring | Forventet status |
|---|---|---|---|---|---|
| Blå | Small | Ja | Fast testpris | Variation | På lager |
| Blå | Medium | Nej | — | — | Kombination findes ikke |
Tilpas eksemplet med egne testdata fra staging. Test både en kombination, der skal virke, og en, der bevidst ikke findes.

| Symptom | Sandsynlig årsag | Kontrol | Næste skridt |
|---|---|---|---|
| Ingen dropdowns vises | Produktet er ikke variabelt, eller attributter bruges ikke til variationer | Produkttype og attributflag | Ret produktdata |
| En bestemt kombination mangler | Variationen er ikke oprettet/aktiveret | Variationslisten | Opret/aktivér korrekt kombination |
| Variation kan vælges, men ikke købes | Pris, lager eller backorder mangler | Variationsdata | Ret den konkrete variation |
| Alt står udsolgt | Lager styres på forkert niveau eller lookup er gammelt | Parent vs. variation og tools | Ret lagerkilde/regenerer kontrolleret |
| Udsolgte variationer er skjult | Global “Skjul udsolgte” + variation-level stock | Lagerindstilling | Bevar eller ændr efter forretningsregel |
| Dropdown viser tilsyneladende ugyldige valg | Over 30 variationer giver statiske dropdowns | Antal variationer | Test hele kombinationen før fejlkonklusion |
| Data er korrekt, UI reagerer ikke | JavaScript, swatchplugin eller temaoverride | Konsol og standardtema | Konflikttest på staging |
Produktet skal være “Variabelt produkt”. Under Attributter skal de relevante attributter have værdier og være markeret til brug for variationer. Gem produktet, og kontroller derefter Variations-fanen. En attribut, der kun bruges som synlig produktinformation, skaber ikke valgmuligheder.
Åbn den manglende kombination. Bekræft, at den er aktiveret, har en gyldig pris og matcher de forventede attributter. Dubletter og brede “Enhver …”-variationer kan matche før mere specifikke kombinationer afhængigt af sortering. Brug en entydig matrix frem for at oprette mange overlappende fallback-variationer.


WooCommerce kan styre lager på parent-produktet, på hver variation eller i en kombination. Dokumenter butikkens valgte model. Hvis variation-level stock bruges, kontroller antal, stock status og backorders for den enkelte variation. Hvis backorders er tilladt, kan en variation fortsat vises ved nul lager.
Den globale indstilling “Skjul udsolgte varer fra kataloget” kan skjule udsolgte variationer i dropdowns, når lageret styres pr. variation og backorders er slået fra. Det er forventet adfærd, ikke en visningsfejl.
Ved 30 eller færre variationer kan WooCommerce filtrere efter hvert valg, så kun mulige næste valg vises. Ved flere end 30 kan dropdowns være statiske af performancehensyn. Kunden kan derfor vælge en ugyldig kombination og først derefter få besked. Hæv ikke grænsen med et kodefilter uden performance-test; det kan gøre store produktsider langsomme.
Hvis admin viser korrekte variationer, men katalog/filter/lager er forældet, findes WooCommerce-værktøjer til at regenerere produkt-lookup-tabeller under WooCommerce → Status → Værktøjer. Tag backup, noter før-status, og kør på staging først. Store kataloger kan bruge baggrundskø og ressourcer; følg Scheduled Actions frem for at starte værktøjet flere gange.
Hvis Storefront/standardtema viser variationerne korrekt på staging, ligger problemet i temaoverride, swatches, quick view eller optimering. Se konsollen og Netværk ved hvert valg. En variation-response med korrekte data og en forkert visning peger på frontend. Ret den ansvarlige komponent; skjul ikke problemet med CSS.
Ved ERP-/CSV-import sammenlignes variation-ID, SKU, attributslug, stock quantity og status. SKU skal være unik. Importen må ikke skrive parent-lager som variation-lager eller omvendt. Test en enkelt isoleret vare før en fuld sync genstartes.
Hvis variationen kan købes fra den direkte produktside, men parent-produktet mangler i kategori eller søgning, er produktets katalogsynlighed, parent-stockstatus og lookup/index mere relevante end variationens dropdown-JavaScript. Sammenlign direkte produkt-URL, kategori, intern søgning og eventuelle filtre.
En ekstern søge-/filterudvidelse kan have sit eget indeks. Regenerer ikke både WooCommerce lookup og et eksternt indeks samtidig. Kør én proces, verificer dens afslutning og test igen.
Vælg en variation og registrer fire felter: variation-ID, pris, billede og lagerbesked. Hvis kun billedet ikke skifter, er galleriet/temaet mere sandsynligt end lagerdata. Hvis ID og billede skifter, men prisen ikke gør, undersøg pris-/valutaudvidelsen. Den feltvise kontrol forhindrer, at hele variationssystemet genopbygges på grund af én frontendbinding.
En variation “Blå / Small” er aktiveret, har pris og lager 4 i administrationen. Produktets HTML indlæser variationens ID og data, men klik på swatchen ændrer hverken pris eller knap. Konsollen viser en fejl i swatch-pluginets script, før WooCommerces variationshåndtering kører. Her er lookup- og lagerregenerering unødvendig; data er allerede nået til browseren.
På staging deaktiveres kun swatch-pluginet. Hvis de almindelige dropdowns derefter vælger variationen, lægger korrekt variation-ID i kurven og viser lager 4, er konflikten afgrænset. Den permanente løsning er en kompatibel version eller konfiguration – ikke CSS, der får den defekte swatch til at se aktiv ud.
Hvis variationens ID derimod slet ikke indgår i produktets variation-data, går diagnosen tilbage til produktopsætning, synlighed og lookup. Konsollen kan ikke gengive en kombination, som serveren ikke har leveret.
Globale attributter bruger taxonomi og slug, mens produktspecifikke attributter kan være fritekst. En integration, der sender “Mørk blå”, mork-blaa og mørk-blå som om de var samme nøgle, kan oprette nye værdier eller miste koblingen til eksisterende variationer. Sammenlign derfor ikke kun det synlige navn; gem også attributslug og variation-ID.
Ved import testes én eksisterende og én ny testvariation. Kontrollér derefter, om importen opdaterede den forventede ID eller oprettede en dublet. Først når SKU, attributslug, pris og lager lander korrekt, køres resten af datasættet. Et fuldt importjob er en dårlig diagnose, fordi det kan overskrive hundredvis af korrekte variationer, før den første mappingfejl opdages.
Notér begge variation-ID'er i testloggen.
Gendan produkteksport/databasebackup ved bulkændringer, eller gendan den enkelte variations oprindelige pris/lager/attribut. Hvis et lookup-værktøj eller importjob kører, start ikke en konkurrerende proces. Stop/rollback efter systemejerens procedure og afstem berørte ordrer.
Tema-/swatchudvikleren skal have produktmatrix, konsolfejl og standardtema-sammenligning. Integrationsleverandøren skal have SKU/variation-ID-mapping. Hosting skal have queue-/databasefejl ved lookup-regenerering. Se WooCommerce hosting hos Hostious ved driftsproblemer.
Oftest mangler varianten en pris – så skjuler WooCommerce den. Tjek også at attributten er markeret ‘Anvendt til variationer’, og at kombinationen findes præcis som valgt.
Lager kan styres på både produkt- og variantniveau – og de kan modsige hinanden. Kontrollér variantens egen lagerstatus og backorder-indstilling, ikke kun produktets.
Ja, ved filtrerings- og visningsfejl: kør ‘Regenerate the product attributes lookup table’ under WooCommerce → Status → Værktøjer, og ryd cachen bagefter.
Gem attributflagene, en anonymiseret variationsmatrix, lagerindstillingen på både produkt og variation, frontend før og efter samt den relevante lookup-handling. Brug test-SKU'er uden leverandør- eller kundeoplysninger.
Vælg fire kombinationer, der dækker på lager, udsolgt, manglende pris og et attributnavn med specialtegn. Følg hver kombination fra den autoritative lagerkilde gennem import, WooCommerce-administration, produktvisning, kurv og checkout. Skriv forventet og observeret værdi i samme tabel. Så bliver det tydeligt, om fejlen ligger i data, opslagstabellen, variationsscriptet eller den visuelle swatch.