Af Greg Nowak. Senest opdateret 2026-07-29.
High-Performance Order Storage (HPOS) vises som en indstilling i WooCommerce. I en etableret webshop bør aktiveringen håndteres som en datamigrering.
Den skelnen er vigtig, fordi et skift af det autoritative datalager for ordrer kan påvirke checkout-udvidelser, refunderinger, abonnementer, administrationsværktøjer, eksporter, regnskabsfeeds, lagersystemer og tilpassede rapporter. Det tekniske skift kan klares hurtigt; det egentlige projekt er at dokumentere, at den omgivende drift fortsat fungerer.
Hvad HPOS ændrer
Historisk har WooCommerce gemt ordrer som WordPress-posts og post-metadata. HPOS bruger dedikerede tabeller, herunder _wc_orders, _wc_order_addresses, _wc_order_operational_data og _wc_orders_meta. Tabellerne giver WooCommerce en struktur og indekser, der er udviklet specifikt til ordredata.
HPOS har været standard i nye WooCommerce-installationer siden version 8.2, der blev udgivet i oktober 2023. Ældre webshops kan fortsat bruge posts som deres autoritative datalager, mens WooCommerce synkroniserer ordredata til HPOS-tabellerne. Efter migreringen kan rollerne byttes om: HPOS bliver autoritativt, mens posts kan bevares som en synkroniseret backup i observationsperioden.
WooCommerce tillader ikke, at det autoritative datalager ændres, mens ordrer venter på at blive synkroniseret. Den sikkerhedsforanstaltning er nyttig, men dokumenterer ikke, at alle plugins, rapporter og eksterne integrationer er kompatible.
Hvor omfattende er jeres HPOS-projekt?
Antallet af ordrer har betydning, men den driftsmæssige kompleksitet er ofte et bedre mål for projektets omfang. En mindre webshop med abonnementer, tilpasset fulfilment-logik og rapporter, der læser direkte fra databasen, kan kræve større omhu end en større webshop med en ren standardstack.
| Webshopprofil | Primær risiko | Fornuftig fremgangsmåde |
|---|---|---|
| Standardplugins og ingen tilpasset ordrekode | En udvidelse understøtter ikke HPOS fuldt ud | Kontrollér kompatibiliteten, migrér på staging, og test derefter alle vigtige ordreflows |
| Tilpassede snippets eller administrationsskærmbilleder | Koden forudsætter, at en ordre er en WordPress-post | Gennemgå og opdatér koden før migreringen i produktion |
| Abonnementer, flere betalingsmetoder eller komplekse refunderinger | Mindre almindelige hændelser i livscyklussen fejler efter overgangen | Udarbejd en testmatrix, der dækker køb, fornyelser, fejl, opsigelser og refunderinger |
| Forbindelser til BI, regnskab, fragt eller lager | Eksterne systemer læser direkte fra ældre tabeller | Kortlæg alle systemer, der bruger ordredata, og test dem mod HPOS |
| Stor ordremængde eller lang historik | Backfill-processen overskrider ændringsvinduet | Mål varigheden af hele migreringen på en nyere kopi af produktionsmiljøet |
Find de afhængigheder, som pluginskærmen ikke kan se
WooCommerce kan blokere HPOS, når en aktiv udvidelse erklærer sig inkompatibel. Betragt det som en nyttig indledende kontrol, ikke som en fuldstændig gennemgang. Ikke-deklareret tilpasset kode, ældre snippets, must-use-plugins, SQL-rapporter og eksterne systemer med direkte databaseadgang er fortsat jeres ansvar.
Det vigtigste advarselstegn i koden er direkte adgang til ordrer via wp_posts, wp_postmeta, get_post(), get_post_meta() eller rå SQL. Når HPOS er autoritativt, kan en direkte læsning fra de ældre tabeller returnere forældede data, mens en direkte skrivning kan opdatere data, som WooCommerce ikke længere bruger.
Ordrekode bør normalt benytte WooCommerce-API'erne. Hent eksempelvis en ordre med wc_get_order(), redigér metadata med metoder som update_meta_data(), og kald save(). Gennemgå også tilpassede kolonner, meta boxes, bulk actions og hooks, der er knyttet til den ældre ordreeditor: HPOS bruger sine egne administrationsskærmbilleder til ordrer.
Se derefter uden for WordPress. Spørg økonomi, fulfilment, kundeservice og det bureau eller den udvikler, som vedligeholder webshoppen, hvilke systemer der bruger ordredata. En CSV-eksport, som en medarbejder starter manuelt, kan være lige så driftskritisk som en formel API-integration.
Et mere sikkert migreringsforløb
1. Gennemfør en generalprøve med repræsentative data
Opret et stagingmiljø, der afspejler produktionen så præcist som muligt, herunder aktuelle plugins, tilpasset kode, konfiguration og en nyere kopi af databasen. Aktivér kompatibilitetstilstand, mens WordPress-posts fortsat er autoritative, og lad derefter backfill-processen for historiske ordrer køre, eller start den manuelt.
WooCommerces planlagte proces overfører 25 ordrer pr. batch. Det kan være tilstrækkeligt for en mindre webshop. Brug wp wc hpos sync til større datasæt, og registrér varigheden, så produktionsplanen bygger på dokumentation frem for gætteri.
2. Test forretningsgange – ikke kun checkout
Gennemfør checkout med alle aktive betalingsmetoder. Test fejlede og gentagne betalingsforsøg, refunderinger, ordreredigering, e-mails, lagerændringer, rabatkoder, webhooks, eksporter og overdragelser til fulfilment. Test, hvor det er relevant, abonnementskøb, fornyelser, opsigelser og ændringer af betalingsmetode.
Gentag de kritiske test med synkronisering henholdsvis aktiveret og deaktiveret. Kontrollér, hvad medarbejderne ser på ordreskærmen, og hvad downstream-systemerne modtager. Afstem et udvalg af ordrebeløb, statusser, adresser, moms, betalingsreferencer og tilpassede metadata.
3. Gennemfør overgangen med en observationsperiode
Begynd i produktion med posts som det autoritative datalager og kompatibilitetstilstand aktiveret. Fuldfør backfill-processen, bekræft, at ingen ordrer fortsat afventer behandling, og verificér dataene, før WooCommerces ordretabeller vælges som autoritative.
Vælg en periode, der normalt er mere stille, men behandl ikke dette som en indstilling, der blot kan aktiveres uden opsyn om natten. Sørg for, at tekniske og driftsmæssige ansvarlige er tilgængelige og kan overvåge nye ordrer, betalingscallbacks, planlagte handlinger, logs, supporthenvendelser og centrale integrationer.
Brug de aktuelle CLI-kommandoer
WooCommerces aktuelle CLI-værktøjer findes under wp wc hpos; det ældre namespace wp wc cot er deprecated. Nyttige kommandoer til aflæsning og migrering omfatter:
wp wc hpos status— vis status for HPOS, kompatibilitetstilstand og afventende synkronisering.wp wc hpos count_unmigrated— optæl ordrer, der fortsat afventer synkronisering.wp wc hpos sync— synkronisér fra det aktuelt autoritative datalager til det andet.wp wc hpos verify_data— sammenlign ordredata i begge datalagre, mens kompatibilitetstilstand er aktiveret.wp wc hpos diff <order_id>— undersøg forskelle for en bestemt ordre.
Den særskilte CLI-dokumentation bruger nu verify_data. Den afløser den ældre kommando verify_cot_data, som stadig findes i visse migreringsvejledninger. Vær særlig forsigtig med indstillinger til reparation, backfill og oprydning: De kan overskrive eller fjerne data og bør kun bruges efter en gennemgået analyse af uoverensstemmelser og med en aktuel backup.
Rollback er en del af releaseplanen
Bevar kompatibilitetstilstanden efter skiftet til HPOS som det autoritative datalager. Hvis der opstår et alvorligt problem, mens begge datalagre er ajour, kan WooCommerce hurtigt skifte tilbage til posts. Hvis synkroniseringen allerede er deaktiveret, er det stadig muligt at skifte tilbage, men posts skal først ajourføres.
Definér kriterierne for rollback før overgangen: Manglende betalingsdata, forkerte beløb, fejl i fornyelser, mislykkede fulfilment-eksporter eller uforklarlige forskelle mellem datalagrene er tydeligere signaler end »webshoppen virker mærkelig«. Notér, hvem der kan træffe beslutningen, og hvordan berørte ordrer efterfølgende skal kontrolleres.
Gør indstillingen til en kontrolleret ændring
Et vellykket HPOS-projekt efterlader webshoppen med mere end blot en ny databaseindstilling. Det resulterer i en oversigt over integrationer, renere kode til ordreadgang, en reproducerbar testplan, verificerede data og en forstået fallback-procedure.
Har I brug for en person, der kan koordinere den tekniske gennemgang med teams inden for betaling, rapportering og fulfilment samt jeres bureau, kan I tale med Greg om en gennemgang af jeres HPOS-migrering. Det første nyttige skridt er som regel en afgrænset gennemgang – ikke at aktivere indstillingen i produktion.
Relateret indhold på GrN.dk
- Search Console kan se opslag på sociale medier – jeres rapporter har brug for et nyt kort
- Timedata i Search Console ændrer SEO-tjeklisten efter lancering
- Opgradering fra PHP 5: Brug PHP 7 som en bro, ikke som slutmålet
Har I brug for hjælp til denne type arbejde?
Drøft jeres HPOS-migrering med Greg Kontakt Greg.
