WooCommerce zu Shopware 6: Daten, Passwörter und Redirects

Schritt 1: Festlegen, wie jeder Datentyp umzieht

Für den Katalog importiert eine Store-Erweiterung, "WordPress/WooCommerce To Shopware 6", Kategorien, Produkte, Varianten, Eigenschaften, Hersteller und Bilder. Ihr Eintrag erwähnt keine Kunden, Bestellungen, Passwörter oder SEO-URLs, planen Sie diese also separat, egal wie der Katalog umzieht.

Für ein Skript exportiert die WooCommerce REST API (/wp-json/wc/v3/) Produkte, Variationen, Kunden und Bestellungen, und der Sync-Endpunkt der Shopware Admin API (/api/_action/sync) schreibt sie in Batches.

Schritt 2: Produkte und Variationen zuordnen

• Variable Produkte: ein variables WooCommerce-Produkt wird ein Hauptprodukt in Shopware, und jede Variation eine Variante.
• Attribute: die Attribute, aus denen eine Variation besteht, werden Eigenschaftsgruppen und Ausprägungen im Variantengenerator. Attribute, die nur angezeigt werden, werden einfache Eigenschaften.
• Zusatzfelder: Daten, die Plugins in Post-Meta abgelegt haben, werden Zusatzfelder in Shopware. Legen Sie zuerst fest, welche Schlüssel zählen, denn ein WordPress-Shop sammelt Meta-Daten von jedem Plugin, das er je hatte.
• Artikelnummern: übernehmen Sie sie unverändert. ERP, Feeds und die Redirect-Map gleichen alle darüber ab.

Schritt 3: Kundenpasswörter funktionsfähig halten

Shopware 6 kann einen Passwort-Hash aus einem anderen System prüfen. Jeder Kunde hat die Felder legacyEncoder und legacyPassword. Beim Login fragt Shopware den Encoder mit diesem Namen, ob das Passwort zum alten Hash passt, und ersetzt ihn bei Erfolg durch einen eigenen Hash. Nach einem Login ist der Kunde auf dem Hashing von Shopware.

Der Core bringt zwei Encoder mit, Md5 und Sha256, für Shopware 5. WordPress braucht einen eigenen, und seit WordPress 6.8 muss er zwei Formate verarbeiten: die älteren phpass-Hashes mit $P$ am Anfang und die bcrypt-basierten mit $wp$2y$. WordPress rehasht nur beim Login, ein Export enthält also meist beide.

Dieser Encoder bildet wp_check_password() aus WordPress 6.8.0 Zweig für Zweig nach. Für den phpass-Zweig nutzt er die Klasse PasswordHash, die WordPress in wp-includes/class-phpass.php mitliefert, kopiert in Ihr Plugin und über dessen Composer-Classmap geladen. Der einzige ausgelassene Zweig ist der WordPress-eigene Override $wp_hasher, den eine Migration nicht braucht.

<?php declare(strict_types=1);

namespace Acme\Migration\Password;

use Shopware\Core\Checkout\Customer\Password\LegacyEncoder\LegacyEncoderInterface;

class WordPressEncoder implements LegacyEncoderInterface
{
    public function getName(): string
    {
        return 'WordPress';
    }

    public function isPasswordValid(#[\SensitiveParameter] string $password, string $hash): bool
    {
        if (\strlen($hash) <= 32) {
            return hash_equals($hash, md5($password));
        }

        if (\strlen($password) > 4096) {
            return false;
        }

        if (str_starts_with($hash, '$wp')) {
            $prehash = base64_encode(hash_hmac('sha384', $password, 'wp-sha384', true));

            return password_verify($prehash, substr($hash, 3));
        }

        if (str_starts_with($hash, '$P$')) {
            return (new \PasswordHash(8, true))->CheckPassword($password, $hash);
        }

        return password_verify($password, $hash);
    }
}

Registrieren Sie ihn als Service mit dem Tag shopware.legacy_encoder. Setzen Sie beim Import legacyEncoder auf WordPress und legacyPassword auf den Wert user_pass aus der Tabelle wp_users. Die REST API liefert nie Hashes, sie kommen also aus der Datenbank.

Schritt 4: Die Redirect-Map bauen

Auf einer englischen Installation beginnen WooCommerce-Produkt-URLs mit /product/slug/, Kategorien mit /product-category/slug/ und Schlagwörter mit /product-tag/slug/. Andere Sprachen übersetzen diese Basen, auf deutschen Installationen finden Sie deshalb oft /produkt/slug/ und /produkt-kategorie/slug/. Shopbetreiber können diese Basen ändern, etwa auf /shop/slug/ oder /shop/hoodies/slug/, und Shops mit einfachen Permalinks nutzen /?product=ID. Nehmen Sie die echte Struktur aus einem Crawl des Live-Shops.

Der Shopware-Core hat keine Verwaltung für beliebige Redirects. Seine einzige Redirect-Einstellung sendet einen 301 von Shopwares eigenen ersetzten SEO-URLs auf die aktuelle und kennt keine WooCommerce-Pfade. Die Map gehört deshalb als 301-Regeln in den Webserver oder das CDN oder in eine Redirect-Erweiterung.

Am schnellsten entsteht die Map, wenn Sie jede alte Produkt-URL über die Artikelnummer mit der neuen verbinden. Crawlen Sie den alten Shop, exportieren Sie die neuen SEO-URLs pro Artikelnummer aus Shopware und führen Sie beide Listen zusammen. Testen Sie die Map dann mit der Schleife aus der Shopware 5 auf 6 Anleitung gegen Staging, sie funktioniert für jede Quellplattform.

Schritt 5: Die Bestellhistorie planen

Der Bestellimport ist der Teil ohne fertiges Werkzeug, und der Teil, den Händler unterschätzen. Klären Sie, wofür die Historie da ist, bevor Sie ihn kalkulieren:

• Kundenkonten: Kunden wollen frühere Bestellungen sehen. Dafür müssen die Bestellungen mit den migrierten Kunden verknüpft sein, mit Positionen und Summen wie damals.
• Buchhaltung und Retouren: das liegt meist schon im ERP. Dann braucht der Shop vielleicht nur die jüngsten Bestellungen.
• Nachbestellungen und Auswertungen: oft reicht eine Exportdatei, ganz ohne Import.

Importierte Bestellungen behalten ihre alten Preise und Steuern. Schreiben Sie sie als abgeschlossene Bestellungen mit eigenem Nummernkreis, damit sie nie mit neuen kollidieren.