WooCommerce: Warum es mühsam ist, zwischen Staging und Produktion zu wechseln … und wie man es umgeht

Auch wenn wir gerne unsere Expertise in WordPress verkünden, ist dies nicht der Fall ohne Herausforderungen. Ein ziemlich frustrierendes Problem ist die verwendete Datenbankarchitektur WooCommerce. Konkret werden darin verschiedene Datensätze gespeichert wp_posts Tabelle in WordPress und ihr Beitragstyp kategorisiert sie. Hier ist eine Liste einiger gängiger Beitragstypen zusammen mit einer kurzen Beschreibung jedes einzelnen:

1. Produkt: Post-Typ product wird verwendet, um Informationen zu einzelnen Produkten in Ihrem WooCommerce-Shop zu speichern. Dazu gehören Produktname, Preis, Beschreibung und weitere Details.
2. Produktvariation: Post-Typ product_variation stellt verschiedene Produktvarianten dar, wie z. B. Größen- oder Farboptionen. Diese sind mit dem Hauptprodukt verknüpft.
3. Order: Post-Typ shop_order speichert Informationen zu Kundenbestellungen, einschließlich Bestellstatus, Kundendetails und bestellten Artikeln.
4. Rückerstattung beantragen: Post-Typ shop_order_refund verfolgt Rückerstattungen im Zusammenhang mit bestimmten Bestellungen.
5. Gutschein: Post-Typ shop_coupon speichert Details zu Gutscheinen und Rabatten, die auf Bestellungen angewendet werden können.
6. Shop Webhook: Post-Typ shop_webhook wird zum Speichern von Informationen im Zusammenhang mit Webhooks verwendet, die zum Auslösen von Aktionen als Reaktion auf Ereignisse in Ihrem WooCommerce-Shop verwendet werden können.
7. Shop-Abonnement: Post-Typ shop_subscription Dies ist relevant, wenn Ihr Shop abonnementbasierte Produkte anbietet und Informationen zu Kundenabonnements speichert.
8. Verlängerung des Shop-Abonnements: Post-Typ shop_subscription_renewal wird zur Erfassung von Abonnementverlängerungen verwendet.
9. Shop-Abonnement-Schalter: Post-Typ shop_subscription_switch Verfolgt Änderungen oder Umstellungen bei Abonnementprodukten.
10. Shop-Abonnement mit ausstehender Zahlung: Post-Typ shop_subscription_pending_payment stellt Abonnementbestellungen mit ausstehenden Zahlungen dar.
11. Shop-Abonnement fehlgeschlagen: Post-Typ shop_subscription_failed wird verwendet, um fehlgeschlagene Abonnementzahlungen zu erfassen.
12. Product Review: Post-Typ product_review wird verwendet, um Kundenbewertungen für Produkte zu speichern. Jede Rezension wird als separater Beitrag behandelt, einschließlich Rezensenteninformationen, Rezensionstext und Bewertungen für das zugehörige Produkt.

Wenn Sie ein neues Theme für WordPress entwerfen oder implementieren, übertragen Sie normalerweise eine Kopie der Website und der Datenbank in eine Staging- oder lokale Entwicklungsumgebung. In der Zwischenzeit sammelt die Website weiterhin Bestellungen und andere E-Commerce-relevante Ereignisse.

Datenbankkonflikte in wp_posts

Mit anderen Worten: In der Produktion werden Datensätze erstellt, die mit ihnen in Konflikt stehen. Beispiel: Sie fügen beim Staging eine neue Seite hinzu und die nächste inkrementelle ID ist 6702. In Ihrer Produktionsumgebung gibt es jedoch einen Auftrag, der dieselbe inkrementelle ID 6702 verwendet. Dabei gibt es einige Probleme:

• Auftrags-IDs sind nicht sequentiell. Wenn Sie eine Bestellung mit 5 haben und dann 3 Seiten erstellen, ist Ihre nächste Bestell-ID 9. Wenn Sie Ihre Bestell-ID anzeigen, erhalten Sie keinerlei Einblick in die Anzahl der Bestellungen, die Sie auf Ihrer Website ausgeführt haben.
• Auftrags-IDs kann nicht geändert werden! WooCommerce nutzt diese ID und teilt sie Ihrem Kunden in allen nachfolgenden Rechnungen und Bestellreferenzen direkt mit.

Es ist ziemlich beunruhigend, dass die WooCommerce-Ingenieure kein zusätzliches Feld für Bestellungen verwendet haben, das sowohl sequentiell als auch eindeutig ist, sich aber von ihrer internen ID unterscheidet. Mit anderen Worten, die ID 6702 hätte Rechnung 4322 sein können … und problemlos zwischen Datenbanken mit einer anderen ID hinzugefügt werden können wp_posts. Produkte tun dies mit einem optionalen SKU Feld, aber es ist auch nicht vollständig in die Plattform integriert, um es als Primärschlüssel zu verwenden.

Ich bewundere die Einfachheit dieses Ansatzes zur Ausweitung der Plattform auf den Handel. Allerdings bin ich auch schockiert, dass sie nicht einen Schritt weiter gegangen sind, um dieses Problem zu lösen. Das bedeutet, dass es keine einfache Möglichkeit gibt, eine Staging-Umgebung mit der Produktion zu synchronisieren, um ein neues Thema live zu schalten.

Hochleistungsfähiger Bestellspeicher von WooCommerce

WooCommerce High-Performance Order Storage (HPOS) ist eine Architekturverbesserung, die Bestelldaten aus den allgemeinen WordPress-Tabellen wp_posts und wp_postmeta in dedizierte, speziell für Bestellungen vorgesehene Tabellen wie wp_wc_orders und wp_wc_order_addresses verschiebt. Diese Umstellung verbessert Geschwindigkeit, Skalierbarkeit und Datenorganisation erheblich, da die Leistungsengpässe beseitigt werden, die durch die Speicherung jeder Bestellung als Datensatz entstehen. Post neben Seiten, Produkten und anderen Inhaltstypen.

HPOS modernisiert zwar die Speicherung und Abfrage von Bestellungen, beseitigt aber nicht das ursprüngliche Strukturproblem: Bestellungen behalten aus Gründen der Abwärtskompatibilität weiterhin einen Verweis auf eine Beitrags-ID. WooCommerce spiegelt weiterhin jede Bestellung einem entsprechenden shop_order-Beitrag zu, sodass ältere Themes, Plugins und API-Integrationen, die auf beitragsbasierten Daten beruhen, weiterhin funktionieren.

Infolgedessen kaschiert HPOS zwar die Ineffizienzen des Beitrags-ID-Systems und erzielt deutliche Leistungsverbesserungen, die zugrundeliegende Architektur basiert jedoch weiterhin auf dem alten Beitrags-Framework. Anders ausgedrückt: HPOS verschleiert das Problem, anstatt es vollständig zu beseitigen, und gewährleistet so eine reibungslosere Performance, ohne die Abhängigkeit von WooCommerce vom WordPress-Beitragsmodell vollständig zu kappen.

Lesen Sie mehr über WooCommerce HPOS

Wie man den Konflikt zwischen WooCommerce-Beitrags-ID und Bestell-ID behebt

Es gibt eine Lösung dafür, aber sie ist nicht einfach. Import-Export-Suite Für WooCommerce habe ich die Lösung verwendet, und sie macht diesen Prozess wesentlich einfacher.

Schritt 1: Aktuelle Auftragsdaten aus Ihrer Produktionsumgebung exportieren

Innerhalb Ihrer Produktionsumgebung können Sie jeden der kritischen Beitragstypen exportieren. Sie können auch erweiterte Filter nutzen, z. B. das Datum der letzten Bestellung in Ihrem Bereitstellungsbereich verwenden, um nur Bestellungen einzubeziehen, nachdem Ihre Daten nicht mehr synchronisiert wurden.

Schritt 2: Aktuelle Bestelldaten in Ihre Staging-Umgebung importieren

Anschließend können Sie diese Daten im Standarddateiformat in Ihre Staging-Umgebung importieren und so sicherstellen, dass Sie keine aktuellen Daten in der Datenbank überschreiben.

Schritt 3: Widersprüchliche IDs auflösen

Während das Plugin die zu importierenden Datensätze durchläuft, meldet es, ob es Konflikte bei bestimmten IDs gibt oder nicht. Dann wird es etwas schwieriger.

Direkte Verbindung zum MySQL Datenbank, ich musste nach diesen IDs in der suchen wp_posts Tabelle, um herauszufinden, um welche Art von Platte es sich handelte. Wenn es sich um eine Seite oder einen Beitrag handelte, habe ich diese einfach kopiert, um sicherzustellen, dass sie eine neue ID verwenden. Wenn es etwas anderes war, musste ich entscheiden, wie ich damit umgehen sollte.

Nachdem ich alle Konflikte beseitigt hatte, importierte ich die Daten erneut und alle Datensätze wurden erfolgreich importiert. Nachdem alle Datenkonflikte gelöst waren, konnte ich das Staging in die Produktion überführen. Eine nette Funktion des Plugins war, dass ich den Import nicht erneut hochladen musste, sondern ihn einfach im Verlaufsregister erneut ausführen konnte.