Warnung: das folgende ist nichts für schwache Nerven! Mit der Klassenüberladung und dem "USERMOD"-Konzept bietet Gambio GX2 nun schon eine ganze Reihe von Möglichkeiten, updatesichere Änderungen/Erweiterungen am Shop vorzunehmen. Es bleiben aber noch viele wichtige Programme übrig, die noch nicht als Klassen neu implementiert wurden, und so Änderungen darin direkt im Quellcode gemacht werden müssen. Das sind so wichtige Programme, wo bei fast jedem Shop Änderungen sehr schön wären: Beispiele: "index.php", "default.php", "cart_actions.php", alle "checkout_xxx.php", "send_order.php" usw. usw. Im Grunde also alle Programme auf der Ebene der "Shop-Root". Und natürlich auch alle Admin-Programme.... Da ich eigentlich bei allen Shops Änderungen in diesen Bereichen mache, war die Notwendigkeit, alles im Quellcode ändern zu müssen, immer ein Ärgernis. So dass ich schon eine ganze Zeit überlegt habe, wie man das in den Griff bekommen kann. Und, tadaaahhh: hier ist die Lösung! Mit dem USERMOD-Konzept ist im Gambio GX2-Shop ja schon ein Mechanismus vorhanden, der ähnliches leistet: das Original-Programm "xxxx.php" wird ersetzt durch das "xxxx-USERMOD.php"-Programm (falls vorhanden). Leider nützt uns das erst einmal nichts, da das Verfahren erst wirksam werden kann, wenn für unsere Zwecke alles zu spät ist... Wir müssen es also erreichen, dass der Shop-Server seine normale Aufrufsequenz ändert, und statt direkt das angeforderte Programm zu laden, ein Kontrollprogramm ("pt_shop_control.php") aktiviert, das das Vorhandensein einer "USERMOD"-Variante des aufgerufenen Programms prüft, und dann entweder des Original-Programm oder seine "USERMOD"-Variante lädt... Und genau das machen wir mit dem im folgenden vorgestellten Konzept.... (Wie so oft ist die Lösung dieses Problems dann banal einfach...) Damit der Shop-Server seine normale Aufrufsequenz ändert, müssen wir ihm das über "rewriting" Anweisungen in der ".htaccess" mitteilen... Hier die angepasste ".htaccess": PHP: ## Gambio SEO Boost## www.gambio.deRewriteEngine onRewriteCond %{REQUEST_FILENAME} ^(.*)\.(css|js|gif|jpg|jpeg|png)$ [NC]RewriteRule ^(.+) - [L]RewriteCond %{REQUEST_URI} (.*)?/images/(.*)RewriteRule ^(.+) - [L]RewriteCond %{REQUEST_URI} (.*)?/templates/(.*)RewriteRule ^(.+) - [L]RewriteCond %{REQUEST_FILENAME} -dRewriteRule ^(.+) - [L]RewriteCond %{REQUEST_FILENAME} -lRewriteRule ^(.+) - [L]RewriteRule ^(.*\.php)$ pt_shop_control.php?pt_shop_control_url=$1&%{QUERY_STRING} [L]##boosted CONTENTRewriteRule (.*/)?info/([A-Za-z0-9_-]+)\.html.* pt_shop_control.php?pt_shop_control_url=shop_content.php&gm_boosted_content=$2&%{QUERY_STRING} [PT,L]##boosted PRODUCTSRewriteRule (.*/)?([A-Za-z0-9_-]+)\.html pt_shop_control.php?pt_shop_control_url=product_info.php&gm_boosted_product=$2&%{QUERY_STRING} [PT,L]##boosted CATEGORIESRewriteRule (.*/)?([A-Za-z0-9_-]+)[/,\.html] pt_shop_control.php?pt_shop_control_url=index.php&gm_boosted_category=$2&%{QUERY_STRING} [L]php_value memory_limit 1024Mphp_value max_input_vars 1000000 Was hier jetzt geschieht, ist alle Aufrufe von Programmen mit der Endung ".php" und alle Aufrufe der SEO-Boost-URLs werden an das Programm "pt_shop_control.php" delegiert, wobei diesem Programm in dem zusätzlichen "GET"-Parameter "pt_shop_control_url" der Name des zu aktivierenden Programms mitgeteilt wird. "pt_shop_control.php" hat folgenden Code: PHP: <?php/* --------------------------------------------------------------pt_shop_control.php 2012-06-15 AvengerCopyright (c) 2012 Avenger, entwicklung@powertemplate.deAllow USERMOD conception for all(!) PHP programms directly activated on the server....Thus finally allowing update safe program modifications!(Including admin progs!)---------------------------------------------------------------------------------------*/define('STORE_MODS_IN_MOD_DIR',true); //Use USERMOD directory to store USERMODs //USERMOD version of a program has to be stored in the same relative directory //hirarchy relative to the "USERMOD"-directory, as are original programs are //relative to the shop root //"index.php" thus goes to "USERMOD/index.php" //"includes/cart_actions.php" thus goes to "USERMOD/includes/cart_actions.php" //"admin/start.php" thus goes to ""USERMOD/admin/start.php"//define('STORE_MODS_IN_MOD_DIR',false); //Use "-USERMOD" extension to filename for USERMODs in progs directory //"index.php" thus goes to "index-USERMOD.php" //"includes/cart_actions.php" thus goes to "includes/cart_actions-USERMOD.php" //"admin/start.php" thus goes to "admin/start-USERMOD.php"if (strpos($_SERVER['REQUEST_URI'],'/admin/')!==false){ chdir ('admin');}$configure='configure.php';$includes_dir='includes/';$local_config=$includes_dir.'local/'.$configure;if (file_exists($local_config)) { include ($local_config);} else { include ($includes_dir.$configure);}$pt_shop_control_url=$_GET['pt_shop_control_url'];$_SERVER['PHP_SELF']=$_SERVER['SCRIPT_NAME']=DIR_WS_CATALOG.$pt_shop_control_url;$pt_shop_control_url=pt_get_usermod($pt_shop_control_url);include($pt_shop_control_url);function pt_get_usermod($file_path, $p_debug_output=false){ $file_path = trim($file_path); if (STORE_MODS_IN_MOD_DIR===true) { $t_usermod_file_path='USERMOD/'.$file_path; } else { $t_file_name = basename($file_path); $t_file_parts = explode('.', $t_file_name); $t_file_parts[0] .= '-USERMOD'; $t_file_name = implode('.', $t_file_parts); $t_usermod_file_path = $t_file_name; } $t_usermod_file_path=DIR_FS_CATALOG.$t_usermod_file_path; # check if 'USERMOD''-file exists if (file_exists($t_usermod_file_path)) { $file_path = $t_usermod_file_path; } else { $file_path = DIR_FS_CATALOG.$file_path;; } if($p_debug_output) { echo "input: $p_file_path <br/>\n"; echo "tried: $t_usermod_file_path <br/>\n"; echo "result: $file_path <br/>\n"; } return $file_path;}?> In diesem Modul wird dann geprüft, ob es für das angeforderte Programm eine "USERMOD"-Variante gibt, und per "include" wird dann entweder das Original-Programm oder seine "USERMOD"-Variante geladen.... ("pt_shop_control.php" setzt auch noch ein paar andere notwendige Dinge, damit die Shop-Software weiterhin funktioniert, u.a. wird auch auf das "admin"-Verzeichnis umgeschaltet, wenn eine "Admin"-Anforderung zu bearbeiten ist.) Man muss hier eine eigene Variante der "get_usermod"-Routine verwenden, da die Original-Routine das Vorhandensein einer "USERMOD"-Variante mit Hilfe des Cache-Objekts prüft, das natürlich zu diesem Zeitpunkt noch nicht aktiv ist, so dass hier konventionelle PHP-Methoden dafür verwendet werden. Die eigene Routine löst auch ein anderes (aus meiner Sicht) Problem: "USERMOD"-Varianten werden ja standardmäßig mit der Erweiterung "xxxxxx-USERMOD.php" im selben Verzeichnis wie das Original-Programm angelegt. Was ich unübersichtlich finde, und das Ganze lieber in einem "USERMOD"-Verzeichnis organisiere, in dem geänderte Module in genau der gleichen Verzeichnis Hierarchie abgelegt werden, wie sie relativ zur Shop-Root gespeichert werden. (In meiner Variante gehe ich noch einen Schritt weiter: das "USERMOD"-Verzeichnis wird in das Template verlagert, da ich für verschiedene Shops unterschiedliche Änderungen benötige.) Gesteuert wird das gewünschte Verhalten über die Konstante "STORE_MODS_IN_MOD_DIR" in "pt_shop_control.php": PHP: define('STORE_MODS_IN_MOD_DIR',true); //Use USERMOD directory to store USERMODs //USERMOD version of a program has to be stored in the same relative directory //hirarchy relative to the "USERMOD"-directory, as are original programs are //relative to the shop root //"index.php" thus goes to "USERMOD/index.php" //"includes/cart_actions.php" thus goes to "USERMOD/includes/cart_actions.php" //"admin/start.php" thus goes to ""USERMOD/admin/start.php"//define('STORE_MODS_IN_MOD_DIR',false); //Use "-USERMOD" extension to filename for USERMODs in progs directory //"index.php" thus goes to "index-USERMOD.php" //"includes/cart_actions.php" thus goes to "includes/cart_actions-USERMOD.php" //"admin/start.php" thus goes to "admin/start-USERMOD.php" Was haben wir damit jetzt erreicht? Wenn es eine "USERMOD"-Variante eines vom Server aktivierten Programms gibt, wird diese aktiviert, z.B. das Programm "USERMOD/index.php" (oder index-USERMOD.php in der konventionellen Variante) . Wir können uns jetzt also in der "USERMOD"-Variante von "index.php" austoben, ohne dass der nächste Update der "index.php" meine Änderungen überschreibt. Wie geht es von da an weiter? Nehmen wir mal an, wir brauchen eine geänderte Version der "default.php": nichts leichter als das! In der "index.php" wird der Aufruf PHP: include (DIR_WS_MODULES.'default.php'); ersetzt mit PHP: include (get_usermod(DIR_WS_MODULES.'default.php')); Wir brauchen eine andere Artikelliste in der 'default.php'? Easy! Wir ersetzen in der 'default.php' PHP: include (DIR_WS_MODULES.FILENAME_PRODUCT_LISTING); mit PHP: include (get_usermod(DIR_WS_MODULES.FILENAME_PRODUCT_LISTING)); Usw., usw. Und der Knüller: das funktioniert auch für den Admin-Bereich! Man muss dann nur noch dafür sorgen, dass die "get_usermod"-Funktion auch im Admin verfügbar wird, was durch ein kleines "Overload"-Modul geschieht: Folgende Routine als "overloads\AdminApplicationTopExtenderComponent\pt_usermod_AdminApplicationTopExtender.inc.php" speichern (und Cache löschen)! PHP: <?php/* --------------------------------------------------------------pt_usermod_AdminApplicationTopExtender.inc.php 2012-01-16 gmGambio GmbHhttp://www.gambio.deCopyright (c) 2012 Gambio GmbHCopyright (c) 2012 Avenger, entwicklung@powertemplate.deInclude "get_usermod" function into adminReleased under the GNU General Public License (Version 2)[http://www.gnu.org/licenses/gpl-2.0.html]--------------------------------------------------------------*/class pt_usermod_AdminApplicationTopExtender extends pt_usermod_AdminApplicationTopExtender_parent{ function proceed() { parent::proceed(); require_once(DIR_FS_INC . 'get_usermod.inc.php'); }}?> Wir haben jetzt (endlich!) den erfreulichen Zustand erreicht, dass wir alles(!) ändern, und trotzdem das nächste Update einfach in den Shop kopieren können! Es ist zwar nur die zweitbeste Lösung, aber so lange es die beste Lösung nicht gibt (alles ist als Klasse verfügbar) ist das allemal besser als nichts! Und natürlich muss man seine geänderten Module mit den neuen Shop-Modulen abgleichen, um Änderungen zu finden, aber zunächst mal bleibt die Funktionalität erhalten. Wie immer gilt: Anwendung auf eigenes Risiko! Es gibt keinerlei Gewährleistung! Nie direkt in einem Liveshop testen! Alle Dateien sind auch in dem anhängenden Archiv enthalten.
Hallo Avenger, Spitzenleistung! Aber so richtig verstehe ich den Nutzen der USERMOD Variante nicht. Ist USERMOD nicht eher was für die jenigen die keinen Testshop unterhalten und ihre Updates im Liveshop direkt rüberbügeln? Ich mache z.Bsp. erst alle Anpassungen im Testshop und ehrlich gesagt ist es mir fast egal ob da USERMOD am Ende steht oder nicht. Also wo ist der Vorteil der USERMOD-Geschichte gegenüber ÜBERLADUNG?
Die Frage stellt sich gar nicht.... Denn eine "index.php" (und alle die anderen genannten) kann man nicht "überladen", da das keine Klasse ist, sondern ein rein prozedurales PHP-Programm... Wie willst Du sonst die "index.php" updatesicher ändern?
Sehr schön & interessant - RESPEKT!! Und genau da fäng es bei mir an: Ich kann zwar jetzt alle SP-Files gnadenlos auf dem Server blasen - fein. Nur müssen doch trotzdem alle SP-Files nun eben mit den xxx-USERMOD Files gemergt werden. Wo ist also vom Arbeitsaufwand der Gewinn?
das weiß ich ebend nicht, bin ja "nur" Shopbetreiber. Aber die UPDATES mache ich von Anfang an selbst. Und die Arbeit ist die gleiche wie vor USERMOD...
Nun, ich denke, dass man jetzt zumindest zielgerichteter weiß, was ich prüfen muss... Vielleicht ist der Gewinn für einen einzigen Shop tatsächlich nicht so groß, aber für mich, der ich viele unterschiedliche Shops mit unterschiedlichen Änderungsanforderungen verwalten muss, definitiv eine erhebliche Einsparung und ein Sicherheitsgewinn.....
Das könnte man m.E. auch und sehr viel schneller/einfache haben, wenn GM sich nicht weigern würde einen anständigen Kopft in den Quelltext einzubauen - siehe hier.. Der ganz Blödsinn der jetzt dort steht, mit teilweise falschen Angaben ist im höchsten Maße sinnlos! Warum da jetzt wieder so´ne GalaMonsterDatenbankSuperOnlineLösung her muss - ich´s begreife es nicht! Fakt ist: die Änderungen einer SP´s müssen eingearbeitet werden - ob in USERMOD- oder Original-Files! SP´s sind ständige Einrichtungen! je individueller der Shop gestaltet ist, je größer der Aufwand! außer beim KaShop näheren sich auch andere Shop´s dramatisch der Zumutbarkeitsgrenze!
Man muss natürlich auch die überladenden Klassen überprüfen, ob sich da im Original Änderungen ergeben haben... Einen automatischen Update gibt es nicht (nirgendwo) und wird es nie geben... Man kann das Ganze halt nur besser organisieren: Klassenüberladung wo möglich, USERMODs wo nicht..... Bei Deiner Argumentation kannst Du auch mit dem Vor-GX2 SP1-Zustand leben: dann änderst Du halt alles im Core-Code des Shops..
Obwohl ich das jetzt noch nicht so richtig verstanden habe, ist das Kennzeichnen von geänderten Dateien generell eine Erleichterung. Ich finde die USERMODS cool, denn ich kann auf einen Blick sehen, welche Datei nicht mehr im Originalzustand ist.
Mag sein dass ich irgendwas Grundlegendes nicht begreife! Aber, nur im Hinblick auf den Aufwand der SP-Einarbeitung bezogen .. was hat es uns für eine Erleichterung gebracht? Wäre ja heilfroh wenn ich was übersehen hätte - kannste mir glauben!
blick da schon ganz gut durch und sehe das genauso. dateien sind schneller anzupassen weil man (n) frau schnell sieht...hier wurde was geändert. avenger hat sich da richtig reingekniet...mein voller RESPEKT dafür. @manfred ich möchte um gotteswillen nicht unhöflich sein. du bist der shopprogger des kartoffel-shops. du hast in deinem shop sachen eingebaut die ein sterblicher shopbetreiber erstmal garnicht interessiert. die ganzen auswerungsteile intern usw. das mag für dich von großer bedeutung sein als codder... aber nicht für einen shopbetreiber...und darum geht es meiner meinung nach. wenn du jetzt sagst langsam stoße ich an meine grenzen mit den sp's usw.....jeder ist seines glückes schmied was mit dem shop angestell wird. ich sage nochmals...das ist keine kritik nur aus der sicht eines shopbetreibers gesprochen.
@balou: GM-Forum ist kein Ponnyhof - dann "tu mal Butter bei die Fische"! >dateien sind schneller anzupassen weil man (n) frau schnell sieht. Ach - früher hießen sie "standard-BAK.html" jetzt heißen sie "standard-USERMOD.html" Wieso geht jetzt irgendwas schneller/besser/einfacher? Nehmen wir mal an, es sind 55 Files (html und php) angepaßt - ist nicht viel. Mit einem SP kommen 111 geänderte Files - ist nicht viel. Ok - Files mergen. Blöd nur, dass "standard.html" mit "standard-USERMOD.html" verglichen werden müssen! Gäbe es in den Files eine zuverlässige Versions-Kennzeichnung .... ich sage nur "ratzfatz"! Wo ist mein Denkfehler?
Hi Manfred, natürlich ist es weiterhin viel Arbeit. Bezüglich der Kennzeichnung im Header: Selbst wenn wir jedesmal die Daten im Header aktualisieren und auch erweitern (was wir in der Regel auch machen - außer wir vergessen es), bringt es dir aber keinen großen Vorteil, denn du musst weiterhin alles mergen um auf dem aktuellsten Stand zu sein. Der Vorteil meiner Meinung nach ist, dass ihr das SP einfach reinschmeißen könnt. Ist das SP erstmal drin könnt ihr nach und nach die Änderungen mergen. Dabei hilft eine Liste mit allen USERMOD Dateien, die ihr angelegt habt. Diese vergleicht ihr mit der Liste aus dem SP. Die Schnittmenge sind dann die Dateien, die ihr prüfen bzw. mergen müsstet. Und da ist meiner Meinung nach die Zeitersparnis... MfG, Timo
Hai Timo, >Der Vorteil meiner Meinung nach ist, dass ihr das SP einfach reinschmeißen könnt. Und bei nicht USERMOD-fähigen PHP-Files? Oh oh! Ich denke wir sollte es jetzt einfach dabei belassen. Das Ergebniss der Diskussion steht fest! Die Debatte bindet nur unnütz Ressourcen! Als offensichlich Einziger ohne USERMOD-Euphorie dafür aber um so mehr mit SP-Aktualisierungs-Problemen, lohnt die Debatte nicht.
Bist Du nicht. Toll was Avenger so macht, keine Frage, aber wenns ums Updaten geht währe mir am meisten mit einem guten Changelog geholfen. Dort sollte stehen was in welcher Datei geändert wurde und schon gibt es keine Probleme mehr.
Mir ist es schon eine enorme Hilfe zu sehen wo etwas geändert wurde um bei neu eingespielten Dateien diese gezielt zu überarbeiten. Bisher sah man "von aussen" nicht wirklich welche Datei Änderungen aufwies. Mit Avenger's Hilfe gilt das für jede Datei, die die USERMOD-Erweiterung hat. Also ich sehe schon, dass ein Aufwand bleibt, ganz klar. Aber die ständige Suche WO die Änderungen nochmal sind oder das Führen von Listen oder tracken von Dateizeitangaben entfällt. DANKE!!!
Letztendlich wird der Arbeitsaufwand nicht sehr viel weniger sein. Aber zum einen ist das dann erst mal sicher gegen Fehler, die man beim Update gerne mal macht: anstatt dass die Änderungen ganz weg sind, hat man zumindest sein Overload/USERMOD noch verfügbar und im Einsatz. Und ich finde das übersichtlicher, wenn man alle sein geänderten Schäfchen an einer Stelle zusammen hat. Updates sind ein großes Problem, aber nicht nur beim Gambio-System... Auch bei OXID und Shopware, die von der Software-Struktur schon insgesamt wesentlich weiter sind als Gambio GX2, kommt man nicht umhin, seine geänderten Module auf Verträglichkeit mit einer neuen Release zu verproben. Das ist halt leider so, und wird vermutlich auch nie anders sein. Man kann sich halt nur besser organisieren.
Wie kann man das denn realisieren? Bei mir sind die USERMOD-Dateien da wo auch die originalen liegen.