Shop Kopie / Parallel-Installation


#1


nicht fündig geworden, etwas alt: 2012

Ich habe von einem laufenden Shop eine Kopie erstellt (DB und Dateien) in ein anderes Verzeichnis,
tmp, config.php, views usw. angepaßt/geleert.

Der Login ins Backend und die Funktionen dort sind alle OK.
Beim Aufruf des Frontends rödelt der Browser endlos ohne Ergebnis (weiße Seite mit nichts).
Ich benutze eine Subdomain der Hauptdomain auf der der Originalshop läuft (ist das der Fehler ?)
Bzw.: gibt es diesbezüglich (URLs) in der config noch etwas besonderes zu beachten ?

Was ich will: falls der Hauptshop einmal nicht läuft, auf den Ersatzshop umrouten
bzw. den Ersatzshop für Änderungen nutzen bevor sie im Hauptshop propagiert werden …

Ist so ein Szenario mit oxid überhaupt möglich ?
Danke für eine Info …


#2

Mal ins EXCEPTION.log bzw. PHP-Error-Log geschaut?


#3

Das ist der falsche Ansatz, und es funktioniert mit keinem Shopsystem der Welt so :slight_smile:
Grund: Transaktionen wie Orders, Anmeldungen, Registrierungen, etc. laufen auf dem normalen Shop ein. Nach drei Wochen funktioniert dieser aus irgendeinem Grund plötzlich nicht mehr. Du denkst Dir “hahaa, das Eichhörnchen war schlau und hat vorgesorgt”, schaltest auf den Ersatzshop unter anderer Adresse um und schon sind alle Transaktionen der letzten drei Wochen verschwunden. Du könntest jetzt höchstens ein Backup der originalen Shopdatenbank dranhängen. Wenn Du wirkliche Redundanz haben willst (Rechenzentrum des Hosting-Providers abgebrannt etc.), kannst Du Dir mal AWS anschauen.

So ist’s fein :slight_smile:
Profis arbeiten mit einer lokalen Entwicklungsumgebung, einem Staging-System (parallel zum Livesystem) und einem Live-System. Das ganze kann man über ein intelligentes Deployment hübsch miteinander verbinden und noch eine Versionierung über z.B. Git reinziehen.


#4

Falscher Ansatz: eventuell bei Oxid.

Ich habe in einem anderen Shop folgendes durchgeführt:
Per Klick im Admin kann der Ersatzshop auf den Hauptshop umgeleitet werden und auch umgekehrt.
Dazu werden Dateien per php copy ausgetauscht (mit entsprechenden header(location)
Per Klick erfolgt ein automatisierter DB-Dump: die jeweils aktuellere Datenbank wird in den anderen Shop geschrieben. Zusätzlich sind noch gewisse Ausnahmen definiert, die dabei berücksichtigt werden müssen.
Die Routine selbst darf natürlich nicht per Cron erfolgen, denn dann würde u.Umst. eine neuere, aber korrupte Datenbank in das jeweils andere System geschrieben werden.
Natürlich ist das keine Lösung für Shops, die täglich 1000 ende von Bestellungen haben …

Hier einmal das Grundgerüst dazu:
copy("…/temp/index_service.php", “…/index.php”);
copy("…/temp/shop_service.php", “…/shop.php”);
[Der Ersatzshop ist jetzt inaktiv und umgeleitet auf den Hauptshop]

copy("…/temp/index.php", “…/index.php”);
copy("…/temp/shop.php", “…/shop.php”);
[Der Ersatzshopbetrieb ist jetzt aktiv]

copy("…/…/shop/temp/index_service.php", “…/…/shop/index.php”);
copy("…/…/shop/temp/shop_service.php", “…/…/shop/shop.php”);
[Der Hauptshop ist jetzt umgeleitet auf den Ersatzshop]

Das Backup bzw. die Aktualität wird folgendermaßen erreicht:
if ($mode == “backup”)
{
system( ‘/usr/bin/mysqldump -u’ . $db_user_E . ’ -p’ . escapeshellarg( $db_pass_E ) . ’ -h’ . $db_host_E . ’ ’ . $db_E . ’ >’ . $wp_path_H . ‘/dump/dump.sql’, $fp_E);

	if(( $fp_E==0 ) && ( false !== chmod( $wp_path_H . '/dump/dump.sql', 0666 )))
		{
		//Schritt 2: Importieren der exportierten Datenbank in den Hauptshop:
		system( '/usr/bin/mysql -u' . $db_user_H . ' -p' . escapeshellarg( $db_pass_H ) . ' -h' . $db_host_H . ' ' . $db_H . ' <' . $wp_path_H . '/dump/dump.sql', $fp_H);
			if ($fp_H==0) 

Ist eben alles prozesshaft - also zu Fuß - kenne mich nicht aus in Objektprogrammierung…
Funktioniert allerdings einwandfrei!

über ein intelligentes Deployment hübsch miteinander verbinden und noch eine Versionierung über z.B. Git reinziehen

ja, schön, wenn man das kann - ich aber nicht :wink:
Da ich bei OXID Anfänger bin, weiß ich zur Zeit nicht einmal, ob oxid überhaupt über Parallelverzeichnisse innerhalb ein und derselben Domain ansprechbar wäre (Domainverzeichnis-> 1. Unterebene: shop1 Verzeichnis (1. Installation) + shop2 Verzeichnis (2. Installation)


#5

Das heißt du nutzt das Konstrukt weil du kein GIT kannst, richtig? Oder gibts da noch andere Gründe dafür?

Dann wirds aber höchste Zeit, vor allem wenn du dir schon so technische Ansätze fährst :wink:
https://rogerdudler.github.io/git-guide/index.de.html

ja das geht


#6

Wenn man das schon unbedingt so machen will, würde ich eine zweite Installation des Shops einrichten, mit exakt gleicher Version, und nur die Daten per PHP/SQL-replace into per cronjob regelmäßig übertragen.

Je nach cron-Intervall hat man dann ständig eine halbwegs aktuelle Version, auf die man durch Umleiten der Domain und Update der config.inc umschalten kann.

Das Ganze ist aber m.E. kein empfehlenswerter Ansatz, weil das nicht transaktionssicher ist. Die Standby-Kopie des Shops kann inkonsistent sein, da die einzelnen Tabellen zu unterschiedlichen Zeitpunkten gelesen werden. Beispielsweise kann der Kunde grade bei Paypal die Zahlung abwickeln, während die Daten übertragen werden. Dann hast du im Standby-Shop die Bestellung, aber ohne Bezahlung.

Alles in allem keine professionelle Vorgehensweise und m.E. auch unnötig, da Server bei ordentlichen Hosting Providern heutzutage nicht mehr einfach so explodieren :wink:


#7

Grundsätzlich ist Oxid da sehr flexibel, du kannst beliebig viele Installationen nebeneinander laufen lassen. Die Frage ist eher, was du erreichen willst und wie konsistente Daten sichergestellt sind.
Ein Testshop ist aus meiner Sicht zwingend notwendig, also eine Kopie um unter Live-Bedinungen (PHP-Version, etc.) alles testen zu können.
Zudem kannst du ja über die Config.ini an die Templatedateien quasi jede Shop-Datenbank ansprechen, …

Wenn dein Server defekt, überlastet gehackt oder angegriffen wird bringen dir mehrere Shop auf einem Server nichts, weil alle Shops weg sind. Außfallsicherheit erreicht man somit nicht.
Performance scheint auch nicht das Problem zu sein?
Was ist dann das Ziel der Vorgehensweise?

cya