Zugriff auf Shop bei composer-update -> u.a. Shop u. Module (de)aktiv schalten

Deutsches Forum
1

Hallo,

ich habe mir “pre-update-cmd”- und “post-update-cmd”-Composer-Scripte für die Shop-Updates erstellt. Dadurch habe ich bereits Zugriff auf die Dateistruktur von OXID.

Ich würde gern während des Update-Prozesses den Shop automatisch in den Maintenance-Mode setzen. Sprich ihn deaktivieren. Dazu brauch ich DB- oder Shop-Zugriff.

Ähnlich bei den Modulen. Ich würde die gern vor dem Update automatisch deaktivieren und nach dem Update wieder automatisch aktivieren. Dazu brauche ich dann nicht nur DB, sondern Shop-Zugriff.

Die Bootstrap.php zu includieren war meine erste, doofe Idee. Klappt auch nicht.

Habt Ihr evtl. einen Lösungsansatz?

Danke!

2

Script in /bin:

<?php
//init shop
require_once dirname(__FILE__) . "/../bootstrap.php";
$myConfig = oxRegistry::getConfig();
$myConfig->init();

//set shop offline
$oShop = $myConfig->getActiveShop();
$aParams['oxshops__oxactive'] = 0;
$oShop->assign($aParams);
$oShop->save();

Was machst du denn in “pre-update-cmd”- und “post-update-cmd”?

1 Like
3

Das OXID-Update-Script fragt bei Modul-Updates bei jedem Modul einzeln, ob es überschrieben werden soll. Das ist bei 20 Modulen etwas nervig. Aber selbst dann, überschreibt es nur die Dateien und löscht alte Dateien nicht.
Daher lösche ich per pre-update-cmd vorher die Module bevor ich sie dann ohne weitere Fragen installieren lasse.

Jetzt habe ich noch zwei Probleme:

  1. Ich nehme dem Shop für wenige Sekunden seinen Konstrukt weg. Wenn ich allein auf dem Server bin, ist das kein Problem, aber bei einem Live-Server sehen die Besucher mglw. unnötige Fehlermeldungen

  2. Können bei einem Modul-Update neue Controller hinzukommen oder alte wegfallen, oder Klassenerweiterungen hinzukommen oder wegfallen. Dadurch wird das Modul gern durch den Shop mal deaktivert, ohne das man es gleich merkt.

Daher meine Idee:

  • Einschalten Wartungsmodus
  • Module deaktivieren
  • Module updaten
  • Module aktivieren
  • Ausschalten Wartungsmodus

So wie bei Wordpress, nur auf Composer-Basis.

Die Technik Deines Codeschnipsels kenne ich schon. Mir geht es um einen technischen Ansatz, wie ich auf den Shop zugreifen kann, wenn ich mich nicht im Shop-Kontext befinde. Zum Verständnis noch einmal, was composer während des Updates macht:

  • Alle Repositories werden in den Vendor geklont (Meine Composer-Plugin-Class auch)
  • Ich ruf die Composer-Plugin-Class über pre-update-cmd auf
  • die Composer-Plugin-Class ist sauber mit namespaces etc. aufgebaut
  • die Composer-Plugin-Class kennt aber die Klassen aus dem OXID-Autoloader (noch nicht). Sprich ich kann OXID im Moment noch nicht direkt aus meiner Klasse aus aufrufen
  • meine Composer-Plugin-Class würde sie möglicherweise kennen, wenn ich die bootstrap.php includiere. Nur damit erzeuge ich gerade nur Fehler und sauber ist es auch nicht.
4

Glaub nicht dass es möglich ist den Shop innerhalb einer Klasse zu starten. Aber warum willst du alles in dem Composer-Plugin machen? Composer kopiert ja eigentlich nur Dateien. Du kannst das Script doch z.B. einfach in pre-update-cmd aufrufen.

5

@leofonic: Das ist glaube ich die Idee! Das probier ich aus. Mir ist bei der Doku-Recherche auch wieder das OXID-SQL-Migrationsscript “oe-eshop-db_migrate” untergekommen. Dort erfolgt auch ein OXID-Zugriff auf Commandline-Ebene. Das schaue ich mir auch noch einmal näher an …
Weißt Du ob die Reihenfolge von pre-update-cmd bestimmbar ist? In meiner composer.json kann ich das ja selbst bestimmen, aber wie sieht es mit mgl. pre-update-cmd in den repository-Abhängigkeiten aus?

6

Werden nicht ausgeführt, nur die im root-package.

7

@leofonic: Danke! Ich gebe Bescheid, wenn ich eine abschließende Lösung habe.

8

Ich habe mein “housekeeping” Composer-Plugin erweitert:

Vor einem Composer-Shop-Update kann ich jetzt den Shop in den Maintenance-Mode setzen und alle aktiven Module deaktivieren.
Anschließend lösche ich alle Module und das Theme, damit ich während der Installation nicht einzeln gefragt werde, ob ich die Module und das Theme überschreiben will.
Nach dem Composer-Shop-Update aktiviere ich wieder alle aktiven Module und schalte den Maintenance-Mode ab.

packagist->therealworld/housekeeping-plugin