Neuinstsallation von 4.9.3 und bei Sprachenswitch "offline.html"

sandra77 · February 10, 2015, 4:16pm

Hi,
habe soeben die CE Version 4.9.3 installiert, Shop auf aktiv gesetzt, die Sprache en aktiviert und sobald ich nun im Frontend einen der Demoartikel in Sprache de aufrufe und danach nach en switche, wird mir "Shop offline! " angezeigt.

Die Startseite selbst lässt sich beliebig switchen.
Ebenso die Contentseiten.

Nur die Kategorien und die Artikel verweisen bei Sprachenswitch auf “offline”, obwohl alles zweisprachig angelegt und aktiv ist (es sind die Demodaten)

Ich habe die Installation mit den Demodaten wiederholt und das gleiche Problem.
Gibt es hierzu noch irgendeine neue Einstellung, von der ich nichts weiß?
Kann im Backend auch nichts dazu finden.

Liebe Grüße, Sandra

patchwork.de · February 10, 2015, 4:58pm

steht was in der exeption_log.txt?

sandra77 · February 10, 2015, 5:08pm

ja, das steht alles in der exeption_log.txt

patchwork.de · February 10, 2015, 5:30pm

die ersten beiden Einträge in der exeption_log.txt haben nicht damit zu tun.
Aber die weiteren betreffen exakt den gleichen Fehler, den ich in einem Shop habe
http://forum.oxid-esales.com/showthread.php?p=153708#post153708

sandra77 · February 10, 2015, 5:48pm

das ist eine komplett neue reine Installation.
Wo steckt da der Fehler?
LG S

patchwork.de · February 10, 2015, 6:07pm

ich sehe es als bug …
Da der Shop, in dem der Fehler auftritt noch nicht online ist, habe ich als ‘workaround’ in der oxlist.php in der selectString() folgendes reingebastelt:

public function selectString( $sSql )
{
// ergänzt von Patchwork.de
if (strpos($sSql, ‘oxv_oxarticles_de.OXTIMESTAMP’) && strpos($sSql, ‘oxv_oxarticles_en’)) {
$sSql = str_replace(‘oxv_oxarticles_de.OXTIMESTAMP’, ‘oxv_oxarticles_en.OXTIMESTAMP’, $sSql);
}
if (strpos($sSql, ‘oxv_oxarticles_en.OXTIMESTAMP’) && strpos($sSql, ‘oxv_oxarticles_de’)) {
$sSql = str_replace(‘oxv_oxarticles_en.OXTIMESTAMP’, ‘oxv_oxarticles_de.OXTIMESTAMP’, $sSql);
}
…

seitdem ist Ruhe und wir warten auf eine Lösung …

sandra77 · February 10, 2015, 8:05pm

die Erweiterung in der public funktion selectString($sSql) bring bei mir leider keine Wirksamkeit (cache geleert).

Hier die f[I]unction,[/I] sieht sie bei Dir genauso aus?

public function selectString($sSql)
{

// ergänzt von Patchwork.de

if (strpos($sSql, ‘oxv_oxarticles_de.OXTIMESTAMP’) && strpos($sSql, ‘oxv_oxarticles_en’)) {
$sSql = str_replace(‘oxv_oxarticles_de.OXTIMESTAMP’, ‘oxv_oxarticles_en.OXTIMESTAMP’, $sSql);
}
if (strpos($sSql, ‘oxv_oxarticles_en.OXTIMESTAMP’) && strpos($sSql, ‘oxv_oxarticles_de’)) {
$sSql = str_replace(‘oxv_oxarticles_en.OXTIMESTAMP’, ‘oxv_oxarticles_de.OXTIMESTAMP’, $sSql);
}

    $oDb = oxDb::getDb(oxDb::FETCH_MODE_ASSOC);
    if ($this-&gt;_aSqlLimit[0] || $this-&gt;_aSqlLimit[1]) {
        $rs = $oDb-&gt;selectLimit($sSql, $this-&gt;_aSqlLimit[1], $this-&gt;_aSqlLimit[0]);
    } else {
        $rs = $oDb-&gt;select($sSql);
    }

    if ($rs != false && $rs-&gt;recordCount() &gt; 0) {

        $oSaved = clone $this-&gt;getBaseObject();

        while (!$rs-&gt;EOF) {

            $oListObject = clone $oSaved;

            $this-&gt;_assignElement($oListObject, $rs-&gt;fields);

            $this-&gt;add($oListObject);

            $rs-&gt;moveNext();
        }
    }
}

patchwork.de · February 10, 2015, 10:52pm

Die default-Sortierung laut deiner exeption_log.txt ist wohl - so wie es aussieht - die Artikelnummer. Ersetze also OXTIMESTAMP mit OXARTNUM:

public function selectString( $sSql )
{
// ergänzt von Patchwork.de
if (strpos($sSql, ‘oxv_oxarticles_de.OXARTNUM’) && strpos($sSql, ‘oxv_oxarticles_en’)) {
$sSql = str_replace(‘oxv_oxarticles_de.OXARTNUM’, ‘oxv_oxarticles_en.OXARTNUM’, $sSql);
}
if (strpos($sSql, 'oxv_oxarticles_en.OXARTNUM) && strpos($sSql, ‘oxv_oxarticles_de’)) {
$sSql = str_replace(‘oxv_oxarticles_en.OXARTNUM’, ‘oxv_oxarticles_de.OXARTNUM’, $sSql);
}
…

Wie gesagt: das ist nicht die Lösung sondern nur ein workaround, da ich bisher nicht herausgefunden habe, warum hier die falsche view-Tabelle im sql-String verwendet wird.

marco.steinhaeuser · February 10, 2015, 11:15pm

@patchwork, gibt’s dazu einen Bugreport mit dedizierten Daten über Serverkonfiguration etc? Ich kann das nämlich weder lokal noch im Demoshop reproduzieren.

Gruß

patchwork.de · February 10, 2015, 11:32pm

@marco: im Demoshop kann ich es auch nicht reproduzieren. Und solange ich nicht weiss woher der KuddelMuddel in den views kommt, lohnt auch ein Bugreport nicht

marco.steinhaeuser · February 10, 2015, 11:35pm

Doch doch. Der lohnt insofern als dass sich das mal jemand genauer anschauen wird. Das Problem ist: gibt es keinen Bugreport, wird sich das niemand jemals genauer anschauen und beheben können

Gruß

patchwork.de · February 10, 2015, 11:57pm

nee nee - ohne es im Demoshop reproduzieren zu können oder den Finger in die Wunde zu legen, lohnt ein Bugreport sich nicht - erfahrungsgemäß kommt dann nur: can’t reproduce - closed :rolleyes:

aber wie schon im post http://forum.oxid-esales.com/showthread.php?p=153708 geschrieben: falls es sich ein profi live anschauen möchte …

marco.steinhaeuser · February 11, 2015, 2:21am

Nun ja. Aber wer soll dann was machen? Ein Bug ist nur ein bug, wenn er reproduziert werden kann.

Gruß

martin.wegele · February 11, 2015, 2:02pm

[QUOTE=sandra77;156010]das ist eine komplett neue reine Installation.
Wo steckt da der Fehler?
[/QUOTE]
Um das herauszufinden, wäre es gut, wenn du uns sagen könntest, ob nach der Installation irgendwelche Anpassungen der Einstellungen (insb. Sortierung in Kategorien) vorgenommen wurden?

Ich vermute, dass der Fehler durch den Parameter zustande kommt, der an oxArticleList::setCustomSorting() übergeben wird. Den könnte man ja mal mit einem Modul mitloggen, wenn er übergeben wird. Grob skizziert könnte man das so machen:

 
<?php
class myArticleListLogger extends myArticleListLogger_parent // überlädt oxArticleList -> metadata.php
{
/**
     * Log the param
     *
     * @param string $sSorting Custom sorting
     */
    public function setCustomSorting($sSorting)
    {
 ob_start();
        debug_print_backtrace();
    $trace = ob_get_contents();
    ob_end_clean();
$sMessage = $sSorting . " ". $trace
;
oxRegistry::getUtils()->oxUtils::writeToLog($sMessage, 'log5382.txt');
        parent::setCustomSorting($sSorting);
    }

(geht wahrscheinlich nicht so, weil der Shop da schon nen ob offen hat.)
Die Aufrufe sind über die folgenden Klassen verteilt:
[ul]
[li]oxLocator (Komponente)[/li][li]aList (Controller)[/li][li]manufacturerlist (Controller)[/li][li]tag (Controller)[/li][li]vendorlist (Controller)[/li][li]oxrssfeed (Model)[/li][/ul]

patchwork.de · February 11, 2015, 3:37pm

greife mal sandra77 vor weil ich in einem Projekt die gleichen Probleme habe

[QUOTE=martin.wegele;156052]
Ich vermute, dass der Fehler durch den Parameter zustande kommt, der an oxArticleList::setCustomSorting() übergeben wird. [/QUOTE]
Genau! Hier wird zB ‘oxv_oxarticles_[B]de[/B].OXARTNUM’ übergeben - soll sein ‘oxv_oxarticles_[B]en[/B].OXARTNUM’

Habe das Logging (etwas abgewandelt) eingebaut in oxlist::selectString(),
steige aber beim Lesen aus
habe sie hierhingelegt
Wonach soll ich suchen?

martin.wegele · February 11, 2015, 6:34pm

Ja, das ist wohl ein bisschen zu viel Information.
Ich habe nochmal etwas tiefer gewühlt und vermute, dass in aList::getDefaultSorting() die Funktion getViewName() das falsche Sprachkürzel liefert. Aber ich habe keine Idee, warum das so ist.

oxRegistry::getLang()->getBaseLanguage();

müsste beim Wechsel der Sprache ja die neue Sprache zurückgeben:

if ($blAdmin && (($iSeLang = oxRegistry::getConfig()->getRequestParameter('changelang')) !== null)) {
                $this->_iBaseLanguageId = $iSeLang;
            }

Noch jemand eine Idee?

sandra77 · February 11, 2015, 6:57pm

Hi,
mit der Scriptergänzung OXARTNUM von patchwork funktioniert es nun [I](war nur ein fehlendes Hochkomma drin)[/I] :

[I]// ergänzt von Patchwork.de
if (strpos($sSql, ‘oxv_oxarticles_de.OXARTNUM’) && strpos($sSql, ‘oxv_oxarticles_en’)) {
$sSql = str_replace(‘oxv_oxarticles_de.OXARTNUM’, ‘oxv_oxarticles_en.OXARTNUM’, $sSql);
}
if (strpos($sSql, ‘oxv_oxarticles_en.OXARTNUM’) && strpos($sSql, ‘oxv_oxarticles_de’)) {
$sSql = str_replace(‘oxv_oxarticles_en.OXARTNUM’, ‘oxv_oxarticles_de.OXARTNUM’, $sSql);
} [/I]

[B]Aber weswegen soll man diese Scriptanpassung nur als Workaround ansehen? Kann es so nicht bleiben, wenn es funktioniert?[/B]

Das einzige, was mir unpassend mit der Version 4.9.3 zu meinem Server auffällt, ist meine PHP Version 5.5.9.
Dafür ist diese Version 4.9.3 ja nicht optimiert, sondern nur für "Runs on PHP 5.4 and PHP 5.3. "

Vielleicht ist das der Grund für das Dilemma?

Liebe Grüße, Sandra

Earlybird · February 11, 2015, 8:11pm

PHP-Versions-Problem:
Genau das ist es nach meiner Erfahrung: Umstellen auf php 5.4. und dann noch prüfen ob auch die Fremd-Module und ggf. Zend/IonCube dazu passen.