Magento-Datenbank in die lokale Entwicklungsumgebung importieren

Es gibt einige Stolperfallen die Du kennen solltest.

Wer regelmäßig an Magento-Projekten arbeitet, kennt das Problem: Die Datenbank des Dev-, des Staging-Systems oder des Kollegen wird lokal eingespielt, der Shop startet und plötzlich funktionieren Login, Weiterleitungen oder sogar das gesamte Backend nicht mehr.

Viele dieser Probleme haben nichts mit Magento selbst zu tun, sondern entstehen durch Konfigurationswerte, die nach dem Import an die lokale Entwicklungsumgebung angepasst werden müssen.

In diesem Artikel zeige ich die wichtigsten Schritte und erkläre, warum insbesondere die Cookie-Domain häufig für stundenlange Fehlersuchen sorgt.

1. Die Base URLs anpassen

Nach dem Import enthält die Datenbank weiterhin die URLs des ursprünglichen Systems.

Diese müssen zunächst auf die lokale Entwicklungsumgebung geändert werden.

Beispielsweise:

UPDATE core_config_data 
SET value = 'https://meine-lokale-domain.local/' 
WHERE path = 'web/unsecure/base_url';

UPDATE core_config_data
SET value = 'https://meine-lokale-domain.local/' 
WHERE path = 'web/secure/base_url';

Dabei sollte unbedingt auf den abschließenden Slash (/) geachtet werden.

Anschließend empfiehlt sich ein Cache Flush:

bin/magento cache:flush

2. Die Cookie-Domain nicht vergessen

Dieser Punkt wird erstaunlich häufig übersehen.

Magento speichert die Cookie-Domain ebenfalls in der Datenbank:

SELECT * FROM core_config_data 
WHERE path = 'web/cookie/cookie_domain';

Befindet sich dort beispielsweise noch

www.meinshop.de

während die lokale Entwicklungsumgebung unter meine-lokale-domain.local läuft, entstehen äußerst merkwürdige Fehler.

Das typische Verhalten: Der Login scheint zunächst zu funktionieren.

Nach dem Absenden des Formulars folgt jedoch lediglich ein HTTP-302-Redirect zurück auf die Login-Seite.

Es erscheint:

• keine Fehlermeldung

• kein Eintrag in den Magento-Logs

• keine Exception

• keine Meldung im Browser

Es sieht so aus, als würde Magento den Login einfach ignorieren.

Die eigentliche Ursache

Der Browser akzeptiert den Session-Cookie nicht.

Der Grund ist simpel:

Der Cookie wurde für eine Domain erstellt, die mit der aktuell aufgerufenen Domain nicht übereinstimmt.

Dadurch sendet der Browser den Session-Cookie bei der nächsten Anfrage nicht mehr mit.

Magento erkennt deshalb keine gültige Session und leitet den Benutzer unmittelbar wieder auf die Login-Seite zurück.

Da aus Sicht von Magento technisch alles korrekt funktioniert, entstehen dabei weder Exceptions noch Logeinträge.

Gerade deshalb gehört dieser Fehler zu den schwierigeren Ursachen bei lokalen Entwicklungsumgebungen.

Lösung

Entweder die Cookie-Domain vollständig entfernen:

UPDATE core_config_data
SET value = NULL
WHERE path = 'web/cookie/cookie_domain';

oder den Wert auf die lokale Entwicklungsdomain setzen.

In den meisten Entwicklungsumgebungen ist das Entfernen des Eintrags die einfachste und robusteste Lösung.

3. Standardbefehle nach dem Import ausführen

Nachdem die Datenbank angepasst wurde, sollten die üblichen Magento-Befehle ausgeführt werden.

bin/magento setup:upgrade
bin/magento cache:flush

Je nach Projekt kommen zusätzlich hinzu:

bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f

Während der Entwicklung werden diese Befehle allerdings häufig nicht benötigt, sofern sich keine PHP-Klassen oder Abhängigkeiten geändert haben.

4. Session- und Cache-Daten löschen

Gerade nach einem Datenbankimport können alte Sessions oder generierte Dateien Probleme verursachen.

Deshalb empfiehlt sich zusätzlich:

rm -rf generated/*
rm -rf var/cache/*
rm -rf var/page_cache/*

Anschließend:

bin/magento cache:flush

5. Indexer prüfen

Je nach Umfang des Imports kann es sinnvoll sein, die Indexer neu aufzubauen.

bin/magento indexer:reindex

Gerade bei Produkt- oder Katalogänderungen verhindert dies zahlreiche Folgefehler.

6. Suchmaschine prüfen

Viele lokale Entwicklungsumgebungen verwenden OpenSearch oder Elasticsearch.

Nach einem Datenbankimport sollte geprüft werden, ob die Konfiguration noch auf den lokalen Dienst zeigt.

Andernfalls funktionieren beispielsweise Produktsuche oder Kategorieseiten nicht mehr korrekt.

7. Cron-Jobs und Warteschlangen

Je nach Projekt werden zahlreiche Prozesse über Cron oder Message Queues verarbeitet.

Dazu gehören unter anderem:

• Newsletter

• E-Mails

• Reindexierungen

• Importprozesse

• Bildverarbeitung

Nach dem Import lohnt sich deshalb ein Blick auf laufende Cron-Jobs oder Queue-Worker.

Fazit

Der eigentliche Datenbankimport ist meist innerhalb weniger Minuten erledigt.

Die anschließende Fehlersuche kann dagegen schnell mehrere Stunden kosten.

Besonders die Cookie-Domain gehört zu den häufigsten Ursachen für scheinbar unerklärliche Login-Probleme.

Wenn der Magento-Login lediglich einen 302-Redirect zurück auf die Login-Seite ausführt und weder Browser noch Logs einen Fehler anzeigen, sollte die Cookie-Domain zu den ersten Punkten gehören, die überprüft werden.

Wer zusätzlich Base URLs, Sessions, Caches und die wichtigsten Magento-Befehle im Blick behält, erspart sich bei nahezu jedem Projekt eine Menge Zeit.