Hi Stefan, Super. Danke! Bin leider noch unterwegs wird aber nachher gleich gepatcht. Bin gespannt … Danke Euch! AS
Hallo Stefan, ich habe den Patch gerade installiert. Lief alles, im Gegensatz zur 3.5.0 Installation, wirklich sehr gut! Habe nur etwas entdeckt, was ich anpassen musste, keine Ahnung ob es an meinem Installationspaket gelegen hat (alter Release?) und dem späteren Patch, aber ich musste in der Datei /engine/local_old/class/sCustomCore.php etwas anpassen: Zeile 2 vorher class sCustomCore extends myCore Zeile 2 nachher class sCustomCore Habe also das extends myCore einfach mal weggemacht, dann habe ich das Template sehen können. Habe aber ebenso noch einen neuen Fehler im Frontend-Template entdeckt, in der linken Sidebar (Wo die Links sind). Fatal error: Call to undefined method Shopware\_Proxies\_sCustomCoreProxy::sRewriteLink() in /kunden/295642\_57549/webseiten/shopware/engine/Shopware/Plugins/Default/Core/Template/plugins/modifier.rewrite.php on line 5 Meine Vermutung geht in die Richtung mod_rewrites, habe hier aber die selben Einstellungen wie bei meiner vorherigen Installation. Vielleicht kann jemand helfen?! Danke!
Patch ließ sich auch mit PHP 5.3 problemlos installieren und offensichtlich läuft alles noch, soweit ich das auf den ersten Blick sehe. Wirklich schön wäre aber wirklich ein Changelog oder ein für alle lesbarer Bugtracker. Da ich technisch keinen der im Forum erwähnten Fehler hatte bzw. noch nicht entdeckt hatte, ist eine Überprüfung auf volle Funktionsfähigkeit nach dem Update schwer.
Hi Morgen bekommst Du Dein Changelog, hab ich heute nicht mehr geschafft… Versprochen! Ich wollte Morgen ein komplettes Diff File aus dem SVN auschecken, dann siehst Du jede Aenderung bis ins Detail. Bin jetzt nur gerade nicht mehr in der Company, deshalb Morgen… Freut mich aber, dass es soweit ganz gut bei Dir aussieht. 
Eingespielt und bis jetzt steht der Shop noch 
Das unter viewtopic.php?f=9&t=297#p1816 beschriebene Problem besteht weiter… Der durchgeführte Patch war offenbar nicht die Lösung… Musste den Zweig wieder per „false“ deaktivieren, bevor es funktioniert. (Zeile 55 in „engine\backend\php\sCacheTemplate.php“.) if (false && strstr($\_SERVER['HTTP\_ACCEPT\_ENCODING'], 'gzip') && !ini\_get('zlib.output\_compression')) { Ich habe dann in „shopware.php“ versucht, mit [code]echo "shopware.php
".print\_r(ini\_get\_all ,true)."
";[/code] alle INI-Parameter zu dumpen, aber das Ergebnis ist leer. D.h. !ini\_get('zlib.output\_compression') liefert vermutlich ein leeres Ergebnis, weshalb wieder ob\_start("ob\_gzhandler"); ausgeführt wird. Das ist übrigens ein „all-inkl“ Shared Hosting Server…
Ich habe darüber noch mal nachgedacht, und glaube zu wissen, warum das Problem entsteht: wir haben per .htaccess serverweit die Zip-Kompression aktiviert <filesmatch>
php_value output_handler ob_gzhandler
</filesmatch> Offenbar wird das aber nicht in den INI-Parametern zurückgemeldet, so dass “ini_get(‘zlib.output_compression’)” diese Information nicht liefert… Da es dann wohl ziemlich schwierig ist, diese Situation zu erkennen, habe ich jetzt ganz brutal an der betreffenden Stelle das PHP Fehlerreporting deaktiviert, und dann geht es weiter… [quote]if (strstr($_SERVER[‘HTTP_ACCEPT_ENCODING’], ‘gzip’) && !ini_get(‘zlib.output_compression’)) { [color=#FF0000] $erp=error_reporting(0); [/color] ob_start(“ob_gzhandler”); echo file_get_contents($file); ob_end_flush(); [color=#FF0000] error_reporting($erp);[/color] } else { echo file_get_contents($file); }[/quote]