Af Greg Nowak. Senest opdateret 2026-07-19.
WooCommerce har brugt Cart- og Checkout-blokke som standard i webshops, der er oprettet siden version 8.3. Det gør blokkene til det naturlige udgangspunkt for nye løsninger – men ikke til en erstatning, der uden videre kan bruges i alle etablerede webshops.
En eksisterende checkout kan være afhængig af betalingsgateways, express wallets, tilpassede felter, regler for afhentning, abonnementer, gebyrer, analytics-events eller PHP-hooks, som er blevet tilføjet gennem flere år. At ændre arkitekturen uden at kortlægge disse afhængigheder svarer mindre til at redesigne en side og mere til at udskifte et mindre forretningssystem, mens kunderne bruger det.
Det relevante spørgsmål er derfor ikke: »Er blokke bedre?« Det er: »Kan hele denne webshops købsrejse køre sikkert med blokke i dag?«
Begynd med købsforløbet, ikke sidens design
Block Editor kan vise en checkout, der ser korrekt ud, selv om et vigtigt kundeforløb stadig ikke virker. WooCommerce viser kun betalingsmetoder, der både er tilgængelige for webshoppen og kompatible med Checkout-blokken. Hvis ingen af de aktive gateways er kompatible, kan kunder nå frem til checkout uden at få tilbudt en betalingsmetode.
Express checkout tilføjer endnu et lag. En wallet-knap kan afhænge af gatewayen, produkttypen, kundens placering, valutaen, browseren, enheden, momskonfigurationen og kontoindstillingerne. En gennemført kortbetaling i en test på en desktop er ikke bevis for, at Apple Pay, Google Pay, abonnementer eller checkout som gæst fungerer efter hensigten.
Brug følgende matrix til at vælge næste skridt i stedet for at betragte migreringen som en automatisk opgradering.
| Det finder du | Anbefalet beslutning | Nødvendig dokumentation |
|---|---|---|
| Alle kritiske extensions erklærer kompatibilitet med blokke | Fortsæt til staging | Gennemførte testordrer for alle vigtige forløb |
| Kompatibiliteten er uklar eller udokumenteret | Sæt arbejdet på pause, og undersøg det nærmere | Bekræftelse fra leverandøren samt praktisk test |
| En nødvendig gateway, et felt, en wallet eller et afhentningsforløb fejler | Ret integrationen, eller behold den klassiske checkout | En verificeret workaround og regressionstest |
| Flere omsætningskritiske afhængigheder fejler | Rul Cart og Checkout tilbage samlet | Vellykkede test af den klassiske checkout efter rollback |
Kortlæg, hvad checkout faktisk gør
Begynd med en oversigt over funktionaliteten, ikke blot en liste over plugins. Registrer alle betalingsgateways og wallets, leverings- og afhentningsmetoder, checkout-felter, ordregebyrer, kuponregler, adressevalideringer, momsintegrationer, abonnementsforløb, analytics-events og automatiseringer efter købet.
Identificer derefter, hvilke elementer der er forretningsmæssigt eller driftsmæssigt afgørende. Gavebeskeder kan indgå i ordrebehandlingen. Et momsnummerfelt kan være nødvendigt til fakturering. Lokal afhentning kan styre, hvor en ordre sendes hen. En skjult fejl i analytics kan forhindre marketingteamet i at vurdere kampagnernes resultater. »Ordren gik igennem« er kun ét acceptkriterium.
Produktdokumentation er nyttig dokumentation, men kan ikke erstatte test af den installerede version og konfiguration. WooCommerces aktuelle dokumentation til Checkout Add-Ons anbefaler eksempelvis stadig klassiske shortcodes, fordi denne extension ikke er blevet opdateret med kompatibilitet til blokke. SkyVerges kompatibilitetstabel indeholder også fortsat tilfælde med afventende eller manglende understøttelse, herunder Checkout Add-Ons og Local Pickup Plus. Betragt sådanne oplysninger som konkrete advarsler, ikke som noget, der nødvendigvis gælder alle plugins fra samme leverandør.
Test transaktioner, ikke screenshots
Opbyg en testmatrix ud fra virkelige ordrer og kundetyper. Den bør som minimum omfatte:
- Køb som gæst og som bruger, der er logget ind, herunder oprettelse af konto, hvor funktionen er aktiveret.
- Alle aktive kortgateways og express wallets på understøttede enheder og i understøttede browsere.
- Fysiske og virtuelle produkter, abonnementer samt ordrer med rabat, gratis levering og et samlet beløb på nul, hvor det er relevant.
- Indenlandske og internationale adresser, skatter og afgifter, leveringsmetoder og afhentningssteder.
- Kuponer, gebyrer, tilpassede felter, valideringsmeddelelser, accept af vilkår og ordrebemærkninger.
- Vellykkede og afviste betalinger, nye betalingsforsøg, refunderinger, e-mails, fulfilment-data og analytics-events.
Kontrollér den resulterende ordre i WooCommerce og i de tilknyttede systemer. Bekræft totalbeløb, skatter og afgifter, kundedata, feltværdier, transaktionsreferencer, lagerændringer, e-mails, eksporter og webhook-drevne processer. Test i et stagingmiljø, der ligger tæt op ad produktion, og gennemfør derefter en mindre afsluttende smoke test efter lanceringen.
Hvis express-knapper fra WooPayments mangler, er den officielle fejlfindingsvejledning særlig anvendelig: Aktivér logging i WooPayments, genskab sidevisningen, og gennemgå den seneste log for meddelelser som Express Checkout Element button disabled eller WooPay Express button disabled. Den tilhørende begrundelse kan afsløre et produkt, der ikke understøttes, eller en anden begrænsning i konfigurationen.
Gamle hooks kan kræve en ny implementering
Blokke bruger en anden frontend- og Store API-model. Noget serverside-funktionalitet virker fortsat, men det gør mange hooks fra shortcode-tiden ikke. WooCommerces oversigt over alternativer til hooks viser eksempelvis, at woocommerce_order_button_text ikke kan bruges programmæssigt i checkout-blokken, mens nye checkout-felter skal anvende Additional Checkout Fields API. Betalingsmetoder skal også have en frontend-komponent, der er registreret til Payments-blokken; det er ikke tilstrækkeligt blot at registrere PHP-gatewayen.
Derfor kan et plugin godt være aktivt, uden at dets output vises. Løsningen kan kræve et JavaScript-filter, en inner block, Slot/Fill, et Store API-hook eller en opdatering fra leverandøren – ikke endnu en CSS-regel. Gennemgå tilpasset kode og snippets i temaet sammen med dine plugins, især alt, der bruger woocommerce_checkout_fields, checkout-formularens actions, ordreoversigtens fragments eller direkte HTML-ændringer i kurvens varelinjer.
Gør rollback enkelt, og øv proceduren
Rollback er en legitim del af releasekontrollen, ikke en indrømmelse af, at migreringen er mislykket. WooCommerce beskriver en konkret fremgangsmåde: Rediger siden Cart eller Checkout, vælg hovedblokken i List View, vælg Transform, vælg Classic Shortcode, og gem. Ved block themes findes siderne under Appearance → Editor; andre temaer bruger normalt Pages → All Pages.
WooCommerce anbefaler at rulle både Cart og Checkout tilbage, fordi de fungerer sammen. Kontrollér efter ændringen, at de korrekte sider fortsat er tildelt under WooCommerce → Settings → Advanced, ryd de relevante caches, og gentag testene af de kritiske transaktioner. Gå ikke ud fra, at gendannelse af shortcoden automatisk gendanner alle omgivende templates eller cachingbetingelser.
Definér »klar« inden lanceringen
En blokmigrering er klar, når de kritiske købsforløb virker, de nødvendige driftsdata når frem til de rigtige systemer, interessenterne har godkendt løsningen, overvågningen er forberedt, og teamet hurtigt kan rulle releasen tilbage. Indtil da kan den klassiske checkout fortsat være det sikreste valg i produktion, mens arbejdet med integrationerne fortsætter.
Hvis du ønsker en uafhængig vurdering af risiciene, kan Greg gennemgå checkout-stacken, koordinere udviklere og extension-leverandører og omsætte resultaterne til en praktisk plan for migrering eller rollback. Tal med Greg om din WooCommerce-checkout.
Relateret indhold på GrN.dk
- Googles udfasning af Content API den 18. august 2026: Oprydning i feedet før migrering til Merchant API
- WooCommerce HPOS: En indstilling, der dækker over et migrationsarbejde
- AI-shopping gør produktdataintegritet til en opgave for den tekniske drift
Har du brug for hjælp til denne type arbejde?
Drøft din WooCommerce-checkout: Kontakt Greg.
