Beiträge von jooomlaa

    Hallo Milbo,


    muss mich noch mal zu dem thema der Limit-Listboxen melden. In meinem Projekt mit 2.0.22c, wo ich o.g. Mod hatte, funktionierte die LimitListbox (siehe).


    Nun in meinem neuen Projekt mit 2.0.24 wo mit ,false gearbeitet wird, spinnt das Teil wieder (s.: siehe). Die Liste enthält immer nur die Option 10. Es wird weder mit den default-Werten befüllt noch mit denen die ich für den Seitenumbruch konfiguriere.


    Einstellungen in der Kategorie f. Listenlimit und Startanzahl zeigen bewirken zumindest das die Listen korrekt gefüllt sind, aber auch damit wirkt sich die Startanzahl nicht aus und der selektierte Wert auch nicht ... Es ist auch hier wieder so, der erste Wert der in der Liste steht wird unveränderlich gesetzt.


    Funktioniert das in 2.0.24 immer noch nicht sauber?
    Nehme doch eher an, ich mache was falsch?



    Nachtrag:
    Durch viel Rumprobieren habe ich nun einen Zustand erzielt, der wohl funktioniert:


    In den Shop-Stilvorlagen:
    - Anzahl der Artikel pro Listenansicht im Frontend: 25
    - Für Ansichten mit 1 Artikel pro Zeile: 10,25,50,100,200


    In der Kategorie:
    - Standard Anzahl der Produkte pro Reihe: 1
    - Kategorie Formular Listenlimit Schrittgrösse: 10,25,50,100,200 (Feld, kann leer gelessen werden, wenn die Werte aus den Stilvorlagen verwendet werden sollen)
    - Startzahl anzuzeigender Artikel: 0 (würde also aus der glob. Shop-Einst. genutzt werden, aber sobald man hier irgendein Wert ungl. 0 eingibt, funktioniert das Teil schon nicht mehr! Es wird dann immer mit diesem Wert gelistet, egal was man als User auswählt - also ich denke schon dass das ein Fehler ist.)

    Hallo Milbo,
    Hatte mich auch mit dem Problem beschäftigt. Grund war, dass auch in meinen Projekten die Konfiguraiton der Limit-SelectBoxen nicht zuverlässig funktionierte. 2 Probleme:
    1. wie im Thema beschrieben, die Konfig.-Parameter für die Anzahl der Prod. greift nicht. Wenn ich im Reiter Stilvorlagen "Seitenumbuch festlegen" eine Liste eingebe, wird wenigstens der 1. Wert als Standard gesetzt. Das ist aber unbefriedigend, weil man ja nicht immer den ersten auch als Standardwert haben will.
    2. Wenn ich dann im Frontend einen Wert auswähle, wird zwar mit diesem gelistet, aber der Wert wird in der Liste nicht als selectiert markiert. Grund, das Attribut selected="selected" wird nicht gesetzt. Deshalb kommt man dann z.B. auch nie wieder auf den ersten Wert zurück, weil dieser markiert wird aber nicht selected ist, weil keiner selected ist (s. HTML-Src)


    Der ganzen Sache bin ich mal nachgegegangen. Grund für dieses Fehlverhalten ist ein Bug im VM-Script vmmodel.php und mündet in der Methode options() in der libraries/joomla/html/html/select.php. Hier soll ja das selected-Attribut für die jeweils akt. Option gesetzt werden, so wie im letzten Parameter von

    PHP
    1. $html = JHTML::_('select.genericlist', $limits, '', 'class="inputbox" size="1" '.$js , 'value', 'text', $selected);

    im Script vmmodel.php übergeben.


    Erwartet wird in der Methode options() für $options['list.select'] entweder ein array oder ein string. Hier übergeben wird die URI als string für den Vergleich bezüglich des limit-Wertes. Nun der konkrete Fehler:
    In der Zeile 615 in select.php wird wie folgt verglichen:

    PHP
    1. elseif ((string) $key == (string) $options['list.select'])

    .


    In der vmmodel.php Zeile 713 erzeugen wir den URi-String mit

    PHP
    1. $selected= JRoute::_( $link.'&limit='. $selected) ;


    Das Problem ist dass dieser String html-specialchar-encodet ist also "&" umgewandelt wird in &. Damit schläg o.g. Stringvergleich in der select.php zwangsläufig fehl.


    Vorschlag: Wir sollten in der vmmodel.php die Zeile 713 ändern zu:

    PHP
    1. $selected= htmlspecialchars_decode(JRoute::_( $link.'&limit='. $selected));


    Damit hätten die Strings eine Chance gleich zu sein.


    Bei mir funktioniert dieser Mod. Vielleicht sollte es in den Core?