Moin! Da ich beim Support abgewimmelt wurde, dass keine Hilfestellung beim "Umprogrammieren" geleistet werden kann, hier die Meldung an der für mich am ehesten geeigneten Stelle: Bei der Gestaltung meines Shops über eine usermod css-Datei viel mir folgendes unerwünschtes Verhalten auf: Obwohl über die popup_content.php im Hauptverzeichnis der Datenschutzlink im Shop an diversen Stellen, u.a. Newsletteranmeldung per iFrame eingebunden werden soll und über die Zeile: Code: <link type="text/css" rel="stylesheet" href="<?php echo 'templates/'.CURRENT_TEMPLATE.'/gm_dynamic.css.php'.$renew_cache; ?>" /> bzw. die Anweisung in der gm_dynamic.css.php PHP: $t_path_pattern = DIR_FS_CATALOG . 'templates/' . basename($_GET['current_template']) . '/usermod/css/*.css'; ja auch eigentlich die css-Anweisungen im Ordner templates/EyeCandy/usermod/css eingebunden werden sollen, werden die Anweisungen der entsprechenden Datei in diesem Fall ignoriert. Firebug zeigt mir bei Prüfung nur die Anweisungen aus der stylesheet.css Datei an. Da ich natürlich eine updatesichere Variante anstrebe, widerstrebt es mir innerlich, meine Anweisungen auf Dauer in der stylesheet.css zu verankern, was im übrigen problemlos funktioniert. Verwendete Shopversion ist 2.0.14.4 und die genannten beiden Dateien sowie die aufrufenden Dateien z.B. newsletter.php wurden nicht modifiziert. Wie gesagt wurde ein Ticket erstellt und dort wurde hier aufs Forum verwiesen, wobei es für mich eigentlich keine Hilfestellung bei einer Umprogrammierung ist, sondern es sich schlicht und ergreifend um eine Fehlfunktion im aktuellen Shopsystem handelt. Denn die Möglichkeit der updatesicheren Anpassungen des Standard-Templates EyeCandy wird ja durchaus zumindest hier im Forum "angepriesen" und damit indirekt durchaus beworben. Bei allen anderen Bereichen funktioniert dieses System glücklicherweise ja auch reibungslos, nur bei dieser iFrame Geschichte nicht. Wobei man ja grundsätzlich die derartige Einbindung des Datenschutzlinks diskutieren könnte. Ein Link mit target=_blank auf die eh vorhandene Shopseite wäre ja auch durchaus in Ordnung.
Hallo, mal sehen, ob ich es schaffe, die Standardfragen zu stellen, bevor Dennis es tut. Caches geleert? Link zur Baustelle?
Sorry! Natürlich. Hätte ich gleich dazuschreiben sollen. Die Caches wurden sowohl über die Funktion im Backend des Shops als auch sicherheitshalber nochmal radikal per FTP bis auf die index und htaccess geleert. Hmm, Baustelle ist gut. Ist ja eigentlich fertig, da ich es jetzt in der stylesheet.css reingeschrieben habe. Ich werde gleich mal eine frische Installation eines 2.0.14.4 Shops vornehmen und dann das Problem dort demonstrieren, damit auch sicher ist, dass es nicht aus mir unerfindlichen Gründen an anderen Eingriffen meiner eigenen Shopinstallation liegt. Werde den Link dann nachreichen. Ist ja auch keine eilige Baustelle, da es wie gesagt ja auch so erst einmal läuft. Geht mir halt vorrangig um die zukünftige Updatesicherheit.
Hallo, das Problem ist der Aufruf der gm_dynamic.css.php. Diese bekommt in der popup_content.php kein Template mitgeliefert, weshalb keine Usermod CSS greifen. Wir haben das für 2.0.15.0 und 2.1.0.0 bereits gefixt... Anbei die angepasste Datei: /templates/EyeCandy/gm_dynamic.css.php MfG, Timo
Dann bin ich ja beruhigt. Hatte mich gerade kritisch hinterfragt, ob ich nicht vorschnell die Pferde scheu gemacht habe, was sonst so gar nicht meiner Art entspricht. Das mit dem fehlenden Template hatte ich gar nicht geblickt, als ich mir die betreffenden Dateien angeschaut habe. Man wird manchmal doch recht schnell betriebsblind. :blush: Vielen Dank jedenfalls für die schnelle Rückmeldung. Btw: Es wäre ja eigentlich schon möglich gewesen das auch schon vom Supportmitarbeiter mitgeteilt zu bekommen oder lag es an einer schlecht formulierten Ticketmeldung meinerseits? Denn wenn es ein bekannter, mitlerweile gefixter Bug ist, sollte der Support das doch auch wissen, oder? Wobei ich natürlich auch in der Changelog der 2.1 drüber stolpern hätte können, sollen. Habe ich leider schlichtweg übersehen.
ICH habs gelesen und dachte, neee fragst nicht, da er ja im hardcoded-css auch versucht hat und es da wohl ging, dann wirds nicht am cache liegen....
Hi Sven, wir bemühen uns natürlich den Support über die Fixes zu informieren. In der Regel werden uns die Bugs, die wir fixen sollen auch vorgegeben. Manchmal ist es aber so, dass wir Entwickler einfach beim Testen Fehler finden und diese natürlich sofort beheben. Da kann es schonmal vorkommen, dass der Support über den Fix nichts weiss. Wenn ich bei jedem Fix den kompletten Support darüber informieren müsste, würde ich für einen Fix nicht 5 sondern 10-15 Minuten benötigen. Das wäre völlig unverhältnismäßig. Über deine Ticketanfrage kann ich leider nichts sagen. Natürlich ist es schade, dass mein Kollege deine Anfrage falsch verstanden hat. Nun konnten wir das Problem ja lösen... MfG, Timo
Hallo, Timo! Ja, für den erläuterten Sachverhalt habe ich natürlich Verständnis. Sollte euch nur konstruktiv gemeint sein und nicht etwa motzend daherkommen. Ich war halt verwundert, dass es da keinen Automatismus gibt. Support findet ja hier auch statt und in der Kombination mit den Mitarbeiter der Support-Abteilung und euch Entwicklern, die das Forum im Blick haben, ist es ja auch ein zufriedenstellender Mix.
Ich hatte vor einer Weile ein ähnliches Problem, wo die usermod-css einfach nicht griff, und sich der fragliche Eintrag einfach nur über Style-Edit ändern liess. Da ging's aber nicht um die popup-content.php, sondern um alle normalen Shop-Seiten (#container) (hier nachzulesen). Ist das dann auch gefixt? Grüße Johannes
Hallo Johannes, das scheint ein anderes Problem zu sein. Ich würde es mir nochmal anschauen, wenn du möchtest. Dazu einfach ein Ticket eröffnen mit Zugangsdaten zum Shop, sowie einem Hinweis, dass das Ticket an mich weitergeleitet werden soll. MfG, Timo
Hallo Timo, das war mehr als Hinweis für euch gedacht, wenn ihr offenbar gerade an der gm_dynamic.css.php herumbastelt. Also falls du dir das genauer anschauen möchtest, kannst du das gerne in meinem Shop tun, dann kriegst du von mir ein Ticket. Nur wegen mir ist das nicht nötig, mein Design-Problem ist ja mittlerweile gelöst. Grüße Johannes
Ich habe das Problem, dass die Usermod-CSS auch beim Aufruf der Detailinformationen zum Produkt in der Bestelabwicklung nicht greift. Hier wird das iFrame ja über die Datei request_port.php im Hauptverzeichnis aufgerufen und dann in der /system/request_port/AjaxHandler/ProductDetailsAjaxHandler.inc.php erzeugt. Doch nirgendwo wir ein stylesheet übergeben. Wenn ich in der ProductDetailsAjaxHandler in der Funktion proceed mit: Code: ?><link type="text/css" rel="stylesheet" href="<?php echo 'templates/'.CURRENT_TEMPLATE.'/gm_dynamic.css.php'.$renew_cache; ?>" /><?php das Stylesheet mit auf den Weg gebe, klappt es wie erwartet. Keine Ahnung, ob ihr das Problem auch schon auf dem Schirm hattet. Das Gute an der Sache ist ja, dass ich das auch selber relativ updatesicher lösen kann. im Ordner user_classes/overloads einen neuen Unterordner ProductDetailsAjaxHandler erstellen und dort eine skypc_ProductDetailsAjaxHandler.inc.php mit folgendem Inhalt gefüllt: PHP: <?phpclass skypc_ProductDetailsAjaxHandler extends skypc_ProductDetailsAjaxHandler_parent{ function proceed() { ?><link type="text/css" rel="stylesheet" href="<?php echo 'templates/'.CURRENT_TEMPLATE.'/gm_dynamic.css.php'.$renew_cache; ?>" /><?php $c_products_id = (string)$this->v_data_array['GET']['id']; $coo_product_details = MainFactory::create_object('ProductDetailsContentView'); $this->v_output_buffer = $coo_product_details->get_html($c_products_id); return true; }}?>