Umzug auf eine andere Domain

Der übliche Weg: den Shop auf test.deine-domain.de fertig bauen und dann auf deine-domain.de umziehen. wavux speichert Bildadressen relativ — Bilder überstehen den Umzug.

Vorher

• PHP-Version des Ziels auf dieselbe Version stellen wie auf der Quelle. Der mitkopierte vendor/-Ordner ist an sie gebunden; passt sie nicht, antwortet der Shop mit 503.
• Dokumentstamm des Ziels auf public/ setzen.

Die Schritte

1. Packen: den kompletten Shop-Ordner einschließlich storage/ (dort liegen die Bilder) und vendor/ als ZIP.

2. Datenbank exportieren (phpMyAdmin oder mysqldump).

3. Auf dem Ziel entpacken und die Datenbank einspielen.

4. .env anpassen:

   • APP_URL auf die neue Adresse
   • Datenbankzugang
   • E-Mail-Zugang, falls er sich ändert
   • APP_KEY unverändert lassen — siehe unten.

5. Per SSH im Shop-Verzeichnis:

   sh nach-umzug.sh

   Das Skript meldet die PHP-Version, entfernt Verknüpfungen, die in die alte Installation zeigen, leert Caches, setzt Rechte, zieht Datenbank-Änderungen nach und zeigt APP_URL zur Kontrolle. Mehrfaches Ausführen ist gefahrlos.

6. Sicherheitsnetz für eingetippte Adressen:

   php artisan wavux:domain-heilen --schreiben

   Er sollte nichts finden. Findet er etwas, wurde irgendwo eine Adresse mit alter Domain von Hand eingegeben; er entfernt sie.

7. Zwei Schalter, die nach einem Umzug gern stehen bleiben (beide unter Sichtbarkeit & Live-Schaltung): Zustand auf Live, Suchmaschinen wieder einschalten.

APP_KEY nie neu erzeugen

Die Geheimnisse der Zwei-Faktor-Anmeldung sind mit diesem Schlüssel verschlüsselt. Ein neuer Schlüssel heißt: Kein Administrator mit zweitem Faktor kommt mehr hinein, und die Fehlermeldung sagt nicht, warum. Notausgang ist php artisan wavux:2fa-reset für das betroffene Konto.

Wenn nach dem Umzug ein 403 kommt

Bei Plesk stehen die Gründe in zwei Protokollen, je nachdem, ob Apache oder nginx abgelehnt hat:

tail -n 30 /var/www/vhosts/DOMAIN/logs/error_log        # Apache
tail -n 30 /var/www/vhosts/DOMAIN/logs/proxy_error_log  # nginx

Meldung	Ursache	Abhilfe
AH00529 … Permission denied … htaccess	Dateirechte aus dem ZIP	sh rechte-setzen.sh oder in Plesk Berechtigungen zurücksetzen
AH00037 Symbolic link not allowed	Verknüpfung zeigt noch ins alte Verzeichnis	sh nach-umzug.sh; sonst find public/themes -maxdepth 1 -type l -delete && rm -f public/storage und die Startseite neu laden
open_basedir restriction bei storage:link	dieselbe tote Verknüpfung	erst die Verknüpfung entfernen, dann neu anlegen

Bleibt der 403 bei intakter Verknüpfung, gehören Link und Ziel verschiedenen Benutzern (häufig nach Entpacken als root). In Plesk Berechtigungen zurücksetzen gleicht die Besitzer an.

Danach

Eine echte Testbestellung: Warenkorb, Kasse, Zahlung, Bestätigungsmail mit echten AGB, Rechnung, Sendungsnummer, Versandmail mit Verfolgungsknopf. Die Links in Mails werden aus APP_URL gebaut — stimmt sie nicht, zeigt das Backend eine Warnung.