[wurzelpete]

Hallo zusammen!

Ich habe folgendes Problem bei der Benutzung des Override Templates. Kurze Zustandsbeschreibung:

Ich habe ein eigenes template angelegt (noch viel 4.1.x template code) das, wenn as als sTheme in der config.inc.php eingestellt wird, einwandfrei mit der 4.3.1 funktioniert. Jetzt wollte ich die Override option nutzen, um alle Änderungen übersichtlich im "override" Ordner vorzunehmen, anstatt das alte Theme konstant zu verändern. Also habe ich einen "override" Theme-Folder im selben Verzeichnis wie "basic" und dem kompletten "mytheme" Ordner erstellt.

Leider fängt der Shop dann an, sobald ich den override Folder aktiviere, Daten aus dem "basic" Ordner zu holen anstatt aus meinem eigenen Theme. Wenn ich den basic Ordner umbenenne oder verschiebe, geht alles auch mit dem override und er holt nur daten aus dem "override" oder dem "mytheme" folder.

Mein Verständnis des Override Folders war, dass wenn Daten im "override" Folder vorliegen, diese verwendet werden, aber sonst alle Daten vom eingestellten Theme geholt werden. Dies scheint aber nicht der Fall zu sein, einige meiner Template-Files werden offensichtlich stattdessen aus dem "basic" Ordner geholt - ist diese Funktionalität gewünscht? Gibts was was ich tun kann, um disees Verhalten zu verhindern (ohne den basic Ordner umbenennen zu müssen)? Bei jedem Verändern der Ordnerstrutkur / Einstellungen lösche ich vorher den kompletten tmp Ordner, also kann das zumindest als Fehlerquelle ausgeschlossen werden.

Vielen Dank fürs Interesse.

Gruß
wurzel

[MBa]

Kann es sein, dass Du die beiden Variablen vertauscht hast?

[wurzelpete]

Die sTheme Variable enthält das vollständige Theme "mytheme", und sCustomTheme enthält nur das Theme mit den angepassten Dateien ("override").

Solange ich die Comments in der Datei nicht gänzlich falsch verstanden habe sollte das so richtig sein?

[avenger]

"tmp"-ordner geleert?

Grundsätzlich kann ich jedoch sagen, dass das Template override prächtig funktioniert...

[wurzelpete]

Ja, tmp ordner ist bei jedem reload vorher geleert worden. Mit entfernen aller im Browser noch vorhandenen cookies / cache Dateien.

Ich hatte bereits einen Post von Dir (avenger) bzgl. des override Systems gelesen, welcher mir erst das Ganze so richtig schmackhaft gemacht hatte, deswegen war ich ein wenig enttäuscht das es bei mir nicht so richtig funktionieren will.

Mein Grundproblem ist, wenn ich ein eigenes theme benutze, sollte das basic theme in keinem Fall als Datenquelle herhalten, override - Ordner aktiv oder nicht. Das ist jedoch leider bei mir aktuell der Fall. Eine Veränderung des Ordnernamens "basic" sollte keinerlei Auswirkung auf das laufende System haben, wenn ein eigenes theme aktiv ist. Dies tritt bei mir aber auf. Sobald der override Ordner aktiviert wurde, ist eine Änderung am Namen des basic Ordners nötig (löschen / verschieben würde auch gehen), um ein Funktionieren des eigenen theme's zu gewährleisten. D.h. Teile des scripts / template Systems benutzen das basic theme wenn sie es im standard-Pfad finden, auch wenn dies gar nicht in Benutzung sein sollte. Wenn es nicht gefunden wird, geht alles wie erwartet.

Ich werde versuchen, das aktuelle eigene theme nocheinmal zu durchsuchen, vielleicht kann ich irgendwelche Verweise auf den basic Ordner finden, die dort nichts zu suchen haben (habe dieses theme nicht selbst erstellt sondern von einem Kollegen übernommen). Abgesehen davon weiß ich keinen Rat mehr.

Nochmal Danke fürs Interesse.

Gruß
wurzel

[wurzelpete]

Habe ein wenig weitergeforscht und alle Dateizugriffe des Servers geprüft. Dabei kam zum Vorschein, dass folgende 4 Dateien erst im override Folder gesucht (und nicht gefunden) werden, und diese danach statt im eigenen Theme Ordner im basic Ordner geladen werden. Es handelt sich um folgende 4 Dateien:
out\basic\tpl\inc\category_options.tpl
out\basic\tpl\inc\category_tree.tpl
out\basic\tpl\inc\infobox.tpl
out\basic\tpl\inc\error.tpl
in dieser Reihenfolge werden Sie gesucht und dann nicht gefunden. In meinem Theme war keine Referenz auf den basic Ordner in irgendeiner Form zu finden, also gehe ich erstmal davon aus, dass der Fehler im System und nicht am Theme liegt. Sobald ich diese 4 Dateien in den override Folder packe, sind keine Fehler mehr in der Darstellung durch Verwendung des basic themes.

Vor jeder der fälschlich geladenen basic Ordner Dateien wird das php script "core.get_include_path.php" geladen, evtl. liegt hier der Hund begraben.

Sehr merkwürdig das ganze. Falls jemand mehr infos bzgl. der Ursachen hat, ich bin für jede Info dankbar.

Gruß
wurzel

[wurzelpete]

Ok, ich habe den Shop-part gefunden, der den basic Ordner fälschlicherweise (?) referenziert. Wenn ich hier den Eintrag im Script ändere, wird auch dann nur dort gesucht.

Es handelt sich um die Funktion "_fillCommonSmartyProperties" in der Datei oxutilsview.php.

Zeile 266:

PHP Code:

$aTemplateDir[] = $myConfig->getOutDir()."basic/tpl/"; 


Ich denke, dass es sich bei diesem Eintrag von basic in der 4.3.1 nur um einen Bug handeln kann. Daher habe ich hier den code verändert.

Die Stelle entsprechend angepasst lautet dann:

PHP Code:

$aTemplateDir[] = $myConfig->getOutDir().$myConfig->getConfigParam('sTheme')."/tpl/";
$aTemplateDir[] = $myConfig->getOutDir()."basic/tpl/"; 


Dann klappt's auch mit dem Nachbarn

[avenger]

Originally Posted by wurzelpete

Ok, ich habe den Shop-part gefunden, der den basic Ordner fälschlicherweise (?) referenziert. Wenn ich hier den Eintrag im Script ändere, wird auch dann nur dort gesucht.

Es handelt sich um die Funktion "_fillCommonSmartyProperties" in der Datei oxutilsview.php.

Zeile 266:

PHP Code:

$aTemplateDir[] = $myConfig->getOutDir()."basic/tpl/"; 


Ich denke, dass es sich bei diesem Eintrag von basic in der 4.3.1 nur um einen Bug handeln kann. Daher habe ich hier den code verändert.

Die Stelle entsprechend angepasst lautet dann:

PHP Code:

$aTemplateDir[] = $myConfig->getOutDir().$myConfig->getConfigParam('sTheme')."/tpl/";
$aTemplateDir[] = $myConfig->getOutDir()."basic/tpl/"; 


Dann klappt's auch mit dem Nachbarn

Jo, dicker Hund!

Allerdings meine ich, dass das

$aTemplateDir[] = $myConfig->getOutDir().$myConfig->getConfigParam('sCustomTheme')."/tpl/";

sein sollte...

Denn im Originalcode

        $aTemplateDir = array($myConfig->getTemplateDir( $this->isAdmin() ));
        $aTemplateDir[] = $myConfig->getOutDir()."basic/tpl/";

wird mit

$aTemplateDir = array($myConfig->getTemplateDir( $this->isAdmin()  ));

schon das "sTheme"-Verzeichnis geladen... (Was ja i.d.R. "basic" ist...).

Denn normalerweise wird das ja in der "config.inc.php" so definiert:

$this->sTheme = 'basic';
$this->sCustomTheme = 'mein_override_template';

Es muss mal gesagt werden:

Die Version 4.3 ist m.E. offenbar kein "Ruhmesblatt" für die OXID AG...

Da liegt m.E. doch einiges noch grundsätzlich im Argen (wenn man mal so eben das 'Template override' aushebelt)....

Und solche Code-Sequenzen

        $aTemplateDir = array($myConfig->getTemplateDir( $this->isAdmin() ));
        $aTemplateDir[] = "/htdocs/oxideshop/eshop/source/out/basic/tpl/";


        $aTemplateDir = array($myConfig->getTemplateDir( $this->isAdmin() ));
        $aTemplateDir[] = $myConfig->getOutDir()."basic/tpl/";

aus "_fillCommonSmartyProperties" der 4.3.0 sind auch nicht gerade vertrauensbildend...

Ich bin eigentlich davon ausgegangen, dass "Unit-Testing" (und ganz normales Testing) solche grundlegenden Bugs finden und ausschließen müsste.

Werde da erst noch mal weiter die Finger von lassen...

[csimon]

Ich bin eigentlich davon ausgegangen, dass "Unit-Testing" (und ganz normales Testing) solche grundlegenden Bugs finden und ausschließen müsste.

Unit testing ist nur so effektiv wies die testfälle sind. Wenn du bestimmte fälle nicht testest, dann fallen dir bugs da auch nicht auf.

Und die tests für die stelle sehen so aus:

PHP Code:

    public function testFillCommonSmartyPropertiesANDSmartyCompileCheckDemoShop()
    {
        modConfig::getInstance()->setConfigParam( 'iDebug', 1 );
        modConfig::getInstance()->setConfigParam( 'blDemoShop', 1 );

        $myConfig = oxConfig::getInstance();

        $aCheck = array( 'php_handling'    => 2,
                         'security'        => true,
                         'php_handling'    => SMARTY_PHP_REMOVE,
                         'left_delimiter'  => '[{',
                         'right_delimiter' => '}]',
                         'caching'         => false,
                         'compile_dir'     => $myConfig->getConfigParam( 'sCompileDir' ),
                         'cache_dir'       => $myConfig->getConfigParam( 'sCompileDir' ),
                         'template_dir'    => array($myConfig->getTemplateDir( false ), $myConfig->getOutDir() . $myConfig->getConfigParam('sTheme') . "/tpl/"),
                         'compile_id'      => md5($myConfig->getTemplateDir( false )),
                         'debugging'       => true,
                         'compile_check'   => true );


        $oSmarty = $this->getMock( 'smarty', array( 'register_resource' ) );
        $oSmarty->expects( $this->once() )->method( 'register_resource' );

        $oUtilsView = new oxutilsview();
        $oUtilsView->UNITfillCommonSmartyProperties( $oSmarty );
        $oUtilsView->UNITsmartyCompileCheck( $oSmarty );

        foreach ( $aCheck as $sVarName => $sVarValue ) {
            $this->assertTrue( isset( $oSmarty->$sVarName ) );
            $this->assertEquals( $oSmarty->$sVarName, $sVarValue, $sVarName );
        }
    }
    // non demo mode
    public function testFillCommonSmartyPropertiesANDSmartyCompileCheck()
    {
        modConfig::getInstance()->setConfigParam( 'iDebug', 1 );
        modConfig::getInstance()->setConfigParam( 'blDemoShop', 0 );

        $myConfig = oxConfig::getInstance();

        $aCheck = array( 'php_handling'    => 2,
                         'security'        => false,
                         'php_handling'    => (int) $myConfig->getConfigParam( 'iSmartyPhpHandling' ),
                         'left_delimiter'  => '[{',
                         'right_delimiter' => '}]',
                         'caching'         => false,
                         'compile_dir'     => $myConfig->getConfigParam( 'sCompileDir' ),
                         'cache_dir'       => $myConfig->getConfigParam( 'sCompileDir' ),
                         'template_dir'    => array($myConfig->getTemplateDir( false ), $myConfig->getOutDir() . $myConfig->getConfigParam('sTheme') . "/tpl/"),
                         'compile_id'      => md5($myConfig->getTemplateDir( false )),
                         'debugging'       => true,
                         'compile_check'   => true );


        $oSmarty = $this->getMock( 'smarty', array( 'register_resource' ) );
        $oSmarty->expects( $this->once() )->method( 'register_resource' );

        $oUtilsView = new oxutilsview();
        $oUtilsView->UNITfillCommonSmartyProperties( $oSmarty );
        $oUtilsView->UNITsmartyCompileCheck( $oSmarty );

        foreach ( $aCheck as $sVarName => $sVarValue ) {
            $this->assertTrue( isset( $oSmarty->$sVarName ) );
            $this->assertEquals( $oSmarty->$sVarName, $sVarValue, $sVarName );
        }
    } 


Quelle: http://svn.oxid-esales.com/tags/CE-4...lsviewTest.php

Da wird zwar alles gecheckt, aber nicht ob auch das richtige template verwendet wird.

Ein weiterer Bug dieser Natur aus der 4.3 ist auch der hier https://bugs.oxid-esales.com/view.php?id=1759

und genannter wurde bereits gemeldet:

https://bugs.oxid-esales.com/view.php?id=1816

Aber naja, wird schon, vielleicht ging das mit der 4.3 und co auch einfach etwas zu schnell zeitlich. Solang man Bugs fleissig meldet werden sie ebenso fleissig wieder behoben

[avenger]

Originally Posted by csimon

Aber naja, wird schon, vielleicht ging das mit der 4.3 und co auch einfach etwas zu schnell zeitlich. Solang man Bugs fleissig meldet werden sie ebenso fleissig wieder behoben

So was nennt man eigentlich "Beta-Test".

Sollte man bei der nächsten Version unbedingt vor den Release schalten.

Für einen Shopbetreiber ist das äußerst mühselig und frustrierend, bei einem "fertigen" Relase von einem Problem ins nächste zu stolpern.