Die Sache verhält sich nach meinen Gedanken so:
Es fehlen in der Auflistung im Backend Einträge und andere sind mehrfach vorhanden.
Das Fehlen von Einträgen ergibt sich schon daraus, daß bei mehrfachem Vorhandensein von gleichen Einträgen die Gesamtzahl korrekt ist/bleibt.
Grund für das Verhalten;
Bei der Query die
splitPageResults() übergeben wird fehlt ein eindeutiger Parameter für das "ORDER BY" den das LIMIT benötigt um bei jeder Query gleich zu sortieren.
Wie du,
voodoopupp, bereits intuitiv vermutet hast wird das Problem behoben wenn man einen zweiten "ORDER BY"-Parameter verwendet. Dieser muß allerdings eindeutig (unique) sein. Ansonsten ist die Range die die jeweilige Query ausgibt zufällig..
Aus
$q = sprintf('SELECT * FROM %s ORDER BY %s %s', TABLE_T10_SEARCHSTATS
, $_SESSION['t10']['filter_stats']['orderField'], $_SESSION['t10']['filter_stats']['orderDirection']); sollte dies werden
$q = sprintf('SELECT * FROM %s ORDER BY %s %s, id ASC', TABLE_T10_SEARCHSTATS
, $_SESSION['t10']['filter_stats']['orderField'], $_SESSION['t10']['filter_stats']['orderDirection']); sodaß immer als zweites nach der eindeutigen 'id' sortiert wird.
Es mag sein, das es MySQL-Versionen gibt die auch bei uneindeutigem "ORDER BY" immer gleich sortieren, aber auch das ist mit hoher Wahrscheinlichkeit nicht 100% verlässlich.
Beispiel:
Da
searches (und auch andere Werte nach denen sortiert werden kann) nicht eindeutig ist, es also mehrere Ergebnisse mit demselben Wert geben kann,
SELECT * FROM t10_searchstats ORDER BY searches DESC LIMIT 0, 5
weiß MySQL nicht wie es genau sortieren soll bis nach einem zweitem eindeutigen Parameter mitsortiert wird, hier 'id'
SELECT * FROM t10_searchstats ORDER BY searches DESC, id ASC LIMIT 0, 5
was das Ergebniss dann jedesmal gleich macht und somit das LIMIT erst richtig greifen kann.
Das lässt sich leicht in PhpMyAdmin nachstellen.
Getestet mit 7.2.24 und MaraiaDB 10.1.48 .
Ich vermute, daß das Probem an weiteren Stellen im Backend und evtl. auch im Frontend auftauchen wird, da in
modified splitPageResults() an vielen Stellen verwendet wird (Stichwort z.B. Filtermöglichkeiten im Frontend).
Ich werde das mal beobachten und bitte euch dies ebenfalls zu tun.
Im Anhang noch meine korrigierte Version, wo außerdem noch potentielle Sicherheitslücken gefixt sind (GET gesichert).
Zur Erinnerung: In meiner Version gilt
- Speichern von $search_keywords anstelle von $keywords, analog zur shop-eigenen Suchfunktion.
D.h. sucht jemand juhu 5 => es wird juhu und 5 gespeichert,
sucht jemand "juhu 5", also in Anführungszeichen => es wird juhu 5 gespeichert.
Gruß,
noRiddle
[
EDIT Tomcraft 07.07.2021: Modul in
Beitrag 1 aktualisiert.]