In diesem Thread ( http://www.gambio-forum.de/threads/...n-PHP-Programmen?p=38698&viewfull=1#post38698 ) hatte ich ja eine Variante des "USERMOD"-Konzepts vorgestellt, die eine Reihe von Vorteilen gegenüber dem Standard-Verfahren besitzt. Und hier ( http://www.gambio-forum.de/threads/...ngen-in-GX2-quot?p=46085&viewfull=1#post46085 ) hatte ich schon mal angedeutet, dass ich mit einer Idee schwanger gehe, die das USERMOD-Konzept für PHP-Programme in eine neue Dimension bringt... Da ich mittlerweile schon recht weit damit gekommen bin, will ich mal vorstellen, worum es konkret geht.... Bei den PHP-Programmen, die direkt auf dem Server aufgerufen werden, hat mein neues "USERMOD"-Konzept ja schon die Möglichkeit geschaffen, diese automatisch durch eine eigene Version zu ersetzen, die im "USERMOD"-Verzeichnis liegt. Nun gibt es aber auch viele PHP-Programme/Module, die über "include/require" in den Ablauf eingebunden werden. Wenn man dafür nun (updatesicher) eigene Variationen dieser Module verwenden will, dann musste man in den Programmcode eingreifen, und beim "include/require" das gewünschte Modul über die "get_usermod"-Funktion einbinden. Wodurch natürlich wieder ein Stück der Updatesicherheit verloren geht.... Ein Traum wäre es, wenn man das Gambio-Shop-Programm gar nicht mehr ändern müsste, um das zu erreichen.... Ein Traum? Ab jetzt nicht mehr! Jeder hat sich sicher schon mal diese Seite angesehen: http://php.net/manual/de/function.include.php... Und jeder hat, so wie ich, das Potential dieses Satzes für den gewünschten Zweck nicht erkannt: Obwohl genau das der Schlüssel zum Paradies ist! Um PHP zu veranlassen, automatisch meine(!) geänderten Dateien zu "includen/requiren", muss ich also drei Dinge tun: die Datei, deren geänderte Version von PHP verwendet werden soll, in die gleiche Verzeichnis-Hierarchie im "USERMOD"-Pfad kopieren. die Original-Datei löschen/umbenennen. den "USERMOD"-Pfad in den PHP-"include_path" hinzufügen Da das völlig unabhängig vom Gambio-Shop funktioniert, eröffnet mir das dann alle Möglichkeiten, die ich bisher vermisst habe: Ich kann jedes(!) Programm durch meine eigene Version ersetzen, auch die Programme, die ich bisher für Änderungen immer noch direkt im Code ändern musste. Beispiele: die "get_usermod"-Routine Gambio Core-Klassen (Registry, Mainfactory, Cache,...) application_top.php, header.php, alle Klassen, usw. usw. .... Also wirklich alles(!), was über "include/require" eingebunden wird! Ich habe damit zum ersten Mal die Möglichkeit, alles(!) im Gambio-Shop updatesicher zu ändern... Und zwar ohne jegliche Code-Änderung im Gambio-Shop! (In meinen geänderten Modulen gibt es natürlich Code-Änderungen...) Ich muss nur die zu ändernde Routine in meine "USERMOD"-Hierarchie kopieren, und das Original an seinem Platz löschen.... Wobei ich diesen Prozess auch automatisiert habe.... Die neuen Module scannen das USERMOD-Verzeichnis, und löschen die darin enthaltenen Programm-Module an ihrem Originalplatz..... (Aber nur dann, wenn sie dazu angewiesen werden.) Wenn man nun ein neues Update einspielt, dann vergleicht man (mit Winmerge) USERMOD- mit dem Root-Verzeichnis, um evtl. notwendige Änderungen in die Varianten im USERMOD-Verzeichnis einzubringen. Dann lässt man wieder das USERMOD-Verzeichnis scannen, um die darin enthaltenen Programm-Module an ihrem Originalplatz wieder zu löschen..... Das große Problem bei dieser Geschichte war, dass dieser Automatismus in PHP nur dann eingreift, wenn die Module über relative(!) Pfade eingebunden werden... Was aber bei Gambio nicht der Fall ist, da z.B. die häufig dafüre verwendeten Konstanten "DIR_FS_CATALOG" und "DIR_FS_INC" absolute Pfade beschreiben.... Das musste also (updatesicher!) geändert werden, was aber erst einmal dazu führte, dass Smarty heftig in's Schleudern kam, weil es einige Verzeichnisse nicht mehr richtig kannte. Diese Probleme habe ich aber jetzt überwunden, und hier eine Version aktiv, deren Frontend das neue Konzept verwendet (der Admin muss noch getestet werden). Ich werde in den nächsten Tagen das Ganze weiter testen, und dann demnächst freigeben. Änderungen an Template-Dateien müssen aber weiterhin über die "get_usermod"-Routine eingebunden werden, da PHP das nicht interessiert. It's cool, man!
@Avenger, das ist extrem untertrieben!! Damit wäre es ja möglich alles nach meinen Bedürfnissen zu implementieren und trotzdem laufe ich niemals Gefahr das nach dem Updates etwas verloren geht. Geil, einfach Geil. Die Arbeit bleibt sicherlich die gleiche aber die Strukturen sparen min. 50% Zeitaufwand.
Ja, genau das ist der Sinn der Sache. Gerade auch wenn man z.B. Routinen aus dem "inc"-Verzeichnis ändern will/muss kam man bisher um direkte Änderungen im Shopcode nicht herum. Ebenso bei Eingriffen in Core-Klassen..... Jetzt kann ich mich da hemmungslos austoben, da ich da doch die eine oder andere Verbesserung habe...
Ich fänd's gut - und irgendwie vermiss ich es auch - wenn sich Gambio mal zu Deinen mittlerweile mehreren Pionierarbeiten hinsichtlich Updatesicherheit äussern würde. Wird davon etwas in den Standard übernommen? Wenn nicht, warum und mit welchem zeitlichen Horizont durch etwas eigenes ersetzt mit demselben Fokus?
So, ich habe jetzt mal eine erste (Beta-)Version zusammen gestellt, die mit dem Standard-Gambio-Shop getestet ist. Derzeit immer noch nur für das Frontend, der Admin-Bereich ist noch nicht getestet... Es sollten sich erst einmal nur Anwender mit diesem Teil befassen, die wissen, was sie tun, und die Erfahrung mit PHP haben! Und natürlich auch nur in einem Testshop testen! Es kann da noch Probleme geben..... Den Inhalt des angefügten Archivs in die Shop-Root kopieren. Ich habe auch ein Beispiel-USERMOD-Verzeichnis mit beigefügt, in dem einige PHP-Dateien und die "index.html" des EyeCandy-Templates enthalten sind. (In "USERMOD/inc" ist auch meine modifizierte "get_usermod.inc.php" enthalten, die dann verwendet wird...) !!!!ACHTUNG!!!!: Die Originale dieser PHP-Dateien werden automatisch gelöscht, die der HTML-Dateien bleiben erhalten! Um nicht bei jedem Durchlauf die Überprüfung für das Löschen der Original-Dateien machen zu müssen, wird das nur dann durchgeführt, wenn im "cache"-Verzeichnis die Datei "replacement_files_checked" nicht vorhanden ist (die wird nach einer Prüfung automatisch erstellt). Wenn man also einen Service-Pack eingespielt, und die evtl. neuen mit den alten Dateien abgeglichen hat, dann muss man diese Datei löschen, damit die Original-PHP-Dateien wieder entfernt werden.. Mein bisheriges USERMOD-Verfahren für das direkte Laden von PHP-Programmen über den Server ist darin ebenfalls enthalten....
Selbst wenn da nichts in den Standard einfließt kann man das problemlos verwenden..... Weil ich jetzt die Möglichkeit habe, alles(!) updatesicher im Gambio-Shop zu ändern.... Die paar Dateien in dem eben geposteten Archiv sind alles, was ich zusätzlich in den Shop einspielen muss, um diese vollständige Flexibilität zu erreichen. Aber sinnvoll wäre der Einbau schon, weil das um Größenordnungen mächtiger ist, als das bisherige USERMOD-Konzept
Hallo Avenger, ich habe mal deine Beta-Version in den Testshop gepielt, und siehe da Serverfehler! Die Anfrage kann nicht beantwortet werden, da im Server ein interner Fehler aufgetreten ist. Der Server ist entweder überlastet oder ein Fehler in einem CGI-Skript ist aufgetreten. Sofern Sie dies für eine Fehlfunktion des Servers halten, informieren Sie bitte den Webmaster hierüber. Error 500 Cache ist geleert.
So, ich denke die Schwangerschaft ist zu Ende, und das Kind geboren . Worum geht es noch mal dabei? Ein automatisches "get_usermod" für PHP-Programme, ohne "get_usermod" verwenden zu müssen. Funktionieren tut das unter Verwendung meines USERMOD-Konzepts, mit dem Gambio-Standard-Verfahren funktioniert das nicht (ist ja auch nicht so sinnvoll). Im Frontend hatte ich das Konzept schon seit einiger Zeit funktionsfähig, nur gab es noch Probleme mit dem Admin-Bereich. Aber ich denke, dass ich diese jetzt auch ausgeräumt habe... Um ein Programm-Modul für das automatische Laden einer modifizierten Variante bereit zu machen (z.B. eine Routine in "inc" oder "includes" oder sonstwo), genügt es, eine Kopie des Programms im Verzeichnis "USERMOD" (in der gleichen Verzeichnis-Hierarchie wie das Original-Programm) bereit zu stellen, und das Original-Programm zu löschen! Dieser Prozess wurde so automatisiert, dass das Löschen automatisch geschieht, wenn im USERMOD-Bereich eine Kopie des Programms existiert! (Wenn man im "cache"-Verzeichnis die Datei "auto_usermod_files_checked" löscht. dann wird dieser Prozess einmalig durchgeführt, so dass das nur notwendig wird, wenn man weitere Programme in den USERMOD-Bereich kopiert, oder ein SP eingespielt hat.) Die gelöschten Dateien werden im Verzeichnis "USERMOD_AUTO_SAVE" gesichert, so dass man durch Kopieren des Inhalts dieses Verzeichnisses in die Shop-Root jederzeit wieder den Normalzustand wiederherstellen kann.... Diese Funktion erfordert Eingriffe auch in "core"-Klassen (MainFactory, Cache), aber mit meinem USERMOD-Konzept kann man dafür auch updatesichere Lösungen bereit stellen. Letzten Endes muss man nur noch in "application_top.php" und "admin/application_top.php" hart (nicht updatesicher) eingreifen, zumindest so lange, wie Gambio meine kleinen Änderungsvorschläge da nicht berücksichtigt. Funktionieren tut das derzeit in meiner Umgebung, in den nächsten Tagen werde ich das mal in ein Standard GX2 (mit meiner USERMOD-Erweiterung) portieren. Und dann brauche ich ein paar mutige und erfahrene Tester.....
Heute Nacht ist mir klar geworden, wie ich dieses "Auto-Usermod"-Konzept nutzen kann, um auch die Admin-Klassen updatesicher überladbar zu machen... Wie so oft scheint das sehr einfach zu sein: Die Verzeichnisse "admin/classes" und "admin/gm/classes" werden umbenannt in "admin/classes_pt" und "admin/gm/classes_pt". Wenn also ein Admin-Programm mit "include(DIR_WS_CLASSES.'xxxxxx.php')" eine Klasse daraus anfordert, ist die nicht vorhanden, und das "Auto-Usermod" tritt in Aktion, und sucht in den definierten "include paths" nach solchen Dateien. Damit etwas gefunden wird, lege ich die Verzeichnisse "USERMOD/admin/classes" und "USERMOD/admin/gm/classes" an, und lege dort Dateien mit den gleichen Namen an, wie in den Original-Klassen-Verzeichnissen, Diese Dateien enthalten alle den gleichen Code! PHP: <?phpMainFactory::PrepareLagacyClass(__FILE__);?> Die (neue) "function PrepareLagacyClass($class_file)" macht nicht sehr viel, dafür aber umso wichtigeres: Sie liest den Quellcode der Original-Klasse aus dem ".../classes_pt"-Verzeichnis Sie ändert die darin enthaltenen Klassendefinitionen "class xxxxxx" zu "class xxxxxx_ORIGIN" Sie lässt diesen modifizierten Quelltext per "eval" kompilieren... Wenn dann ein Admin-Programm mit "new xxxxxx" die Klasse "xxxxxx" instantiieren will, ist diese nicht vorhanden, so dass der "Autoloader" anspringt, und die Admin-Klasse wie bisher schon die Frontend-Klassen instantiiert wird, mit der Einbeziehung evtl. definierten "Overloads" für die Klasse! Vermutlich muss man noch leichte Anpassungen an der MainFactory, dem Caching und der ClassRegistry vornehmen, was aber nicht viel, und auch updatesicher sein wird. Dann kann man sich auch endlich schon mal mit der Anpassung der Admin-Klassen "austoben", ohne auf den "großen Wurf" von Gambio warten zu müssen. Und wenn der dann mal da ist, ist zu erwarten, dass die Überladung der Admin-Klassen auch über das "xxxxxx_ORIGIN"-Konzept der jetzt bestehenden Klassen gemacht wird (wie jetzt im Frontend), so dass man dann einfach wieder die Klassen in den Verzeichnissen "admin/classes" und "admin/gm/classes" bestehen lässt, so dass dann wieder diese verwendet werden. Und man seine bisherigen Änderungen/Erweiterungen der Klassen weiter verwenden kann. It's cool, man!
Der Teil "Sie lässt diesen modifizierten Quelltext per "eval" kompilieren..." hat sich als nicht gut erwiesen, da man beim "eval" keinerlei "debug"-Möglichkeiten hat.. Die Routine schreibt daher jetzt den geänderten Klassen-Code zurück, und "included" dann den neuen Klassencode. Das Zurückschreiben erfolgt nur, wenn die Klasse noch keine "_ORIGIN"-Klasse ist, was i.d.R. nur dann der Fall ist, wenn die Klasse erstmalig oder als Update in das "classes_pt"-Verzeichnis kopiert wurde... Ich habe mal das Overloading der "categories.php"-Klasse getestet, und die "user_classes\overloads\categories\pt_test_categories.php"-Overload-Klasse wie folgt definiert: PHP: <?php/* --------------------------------------------------------------pt_categories.php 2012-05-31 gmGambio GmbHhttp://www.gambio.deCopyright (c) 2012 Gambio GmbHCopyright (c) 2012 Avenger, entwicklung@powertemplate.deAllow overloading of admin classes --------------------------------------------------------------*/class pt_test_categories extends pt_test_categories_parent{ function set_category_recursive($categories_id, $status = "0") { parent::set_category_recursive($categories_id, $status); }}?> Und tatsächlich wird beim Ändern des Kategorien-Status die "set_category_recursive"-Methode der Overload-Klasse verwendet, das Overloading der Admin-Klassen funktioniert also! Ich liebe es, wenn ein Plan funktioniert......
Mit dem gleichen Konzept kann man natürlich auch andere Klassen, die noch nicht nach dem neuen GX"-Konzept gestaltet sind (z.B. Drittanbieter-Klassen) für das Overloading bereit machen.... Und auch eine andere Möglichkeit bietet das "Auto-Usermod"-Konzept: die redundante Definition von Klassen und Funktionen im Admin und Frontend....
Da brauchts doch sicher was zum Einbau...;-) Das ZIP vom 9.10. ist doch nicht aktuell oder wo finden wir das Kleine ;-)