"Elemente / Seite" standardwert

[mattmarr]

Hallo!

Eine Idee für die kommende Version.

Ein riesen Problem, das hier immer mehr auftaucht, ist, das ein Kunde in Content>Artikel>[Kategorie] den wert für "Elemente/Seite" auf "alle" stellt oder der Standard 0(für alle anzeigen) gesetzt wird.

Man stelle sich eine Kategorie vor, wo seeeeeeeehr viele Artikel(>1000) drin liegen.
Genau, der Server steigt dann mit einem Internal-Server-Error aus. (Unsere Server sind nicht schwach auf der Brust!)

Jetzt wäre die Idee oder auch bitte, in der nächsten Version die Auswahl "alle" aus dem System zu tilgen und den Standardwert nicht auf "alle" sondern auf 100 oder weniger zu stellen.

im gesamten System findet man an einiges stellen das Problem wieder, das immer der wert 0 (für alle anzeigen) als Standard gesetzt wird. Nicht gut!



Gruß
Matthias

[rethus]

Einziges, worauf ich mich einlassen würde, über eine System-/Mandanten-Variable die Option "Alle" zu deaktivieren.

Ich nutze die Funktion gerne und brauche die auch in künftigen Versionen.

[mattmarr]

Halli rethus!

Einziges, worauf ich mich einlassen würde, über eine System-/Mandanten-Variable die Option "Alle" zu deaktivieren.

Ich nutze die Funktion gerne und brauche die auch in künftigen Versionen.

Dann treffen wir uns in der Mitte und einigen uns auf einen festgesetzten Standardwert jenseits von "alle anzeigen".

[rethus]

Meine Mitte ist: so lassen wie es ist, aber optional ist "alle anzeigen" über Systemvariablen ausschaltbar [Also nur für die die es explizit brauchen].

Denn:

1. Der Defaultwert bei der Seitenanzahl steht nach der Installation auf 10, somit ist
2. das Verstellen dieses Wertes ein aktives Eingreifen des Users, und
3. ist das verhindern von Fehlerfällen Sache des Contenido-Admins (der ja die Weitsicht hat, wie lang die Liste "alle" ist, und wie der Server bestückt ist). Somit ist für ihn das setzen einer Mandantenvariable nicht zu viel Arbeit.

[mattmarr]

Meine Mitte ist: so lassen wie es ist, aber optional ist "alle anzeigen" über Systemvariablen ausschaltbar [Also nur für die die es explizit brauchen].

Denn:

1. Der Defaultwert bei der Seitenanzahl steht nach der Installation auf 10, somit ist
2. das Verstellen dieses Wertes ein aktives Eingreifen des Users, und
3. ist das verhindern von Fehlerfällen Sache des Contenido-Admins (der ja die Weitsicht hat, wie lang die Liste "alle" ist, und wie der Server bestückt ist). Somit ist für ihn das setzen einer Mandantenvariable nicht zu viel Arbeit.

Ideen sind gut.
So lassen wie es ist, nicht wirklich.
Einen Standardwert der nicht "alle" entspricht, nach einer Installation, wäre echt ratsam.
Momentan haben wir mit 3 Kunden massive, sehr massive Probleme, weil viel gepostet wird, z.b. News. Wehe dort wird ausversehen auf "alle" gestellt. Dan ist mehr als nur Holland in Not.



Gruß
Matthias

[Faar]

Das Problem liegt vermutlich im Kern und da höchstwahrscheinlich in der objektorientierten Programmierung.
Man könnte darauf wetten, dass die Liste der Artikel (Elemente) für diese Ansicht nicht als Array erzeugt und ausgelesen wird, sondern für jedes Element ein Objekt erzeugt wird, das wahrscheinlich wieder irgendwelche Objekte erzeugt usw.
Es genügt, sich im navigation_main Modul mal $tree mit print_r() ausgeben zu lassen, um eine Vorstellung davon zu bekommen, wie viele Daten für eine simple NavigationsListe "erzeugt" werden.
Eine echte Lösung wird es mit Contenido nicht geben, dieses CMS ist nicht für Massendaten gemacht worden.
Oder wollte jemand den Core wieder umstricken auf Funktionen, direkte Datenbankabfragen und einfache Arrays?

Eine andere Lösung wäre, dem PHP mehr Arbeits-Speicher zur Verfügung zu stellen, denn dort stehen alle die schönen Objekte.
Ansonsten ist die Lösung von Rethus die beste, dass man als Sysadmin die Anzeige begrenzen kann, bzw. "alle" ausschalten kann.

Ob auch eine Chain an dieser Stelle greifen würde?

[Faar]

Schaut mal in CONTENIDO/contenido/includes/include.con_art_overview.php
Dort ist in Zeile 132 die Abfrage, ob elementsperpage gesetzt wurde, also die Anzahl der Artikel in dem Fall.
Die Anzahl wird aber auch aus den User-Properties ausgelesen: getUserProperty("system", "elemperpage-idlang-$lang-idcat-$idcat"), falls nichts eingegeben wurde.
Der Ansatz wäre schon da, die Anzahl der Elemente mit dem Systemeinstellungen vorzugeben, bzw. einzuschränken.
In Zeile 234 wird das LIMIT in die SQL eingebaut.
Wer will, kann hier zur Not etwas einbauen, das $elemperpage eingrenzt.

Code: Alles auswählen

if($elemperpage > 100)$elemperpage = 100;

Und ab Zeile 842 stehen dann die Zahlen 10, 25, bis 100 fest einprogrammiert drin.
Da kann man gleich am Anfang "alle" in 100 ändern statt in 0 zu belassen.

Nun, wenn man dann die darauf folgende SQL ansieht, die zusammengebaut wird, dann kann man sich vorstellen, dass es bei vielen Artikeln eng wird.
Aber in dem Fall sind es nicht Objekte, die den Server ausbremsen, sondern eine Monster-SQL, die für kleine DBs und kleine Datenmengen noch geht, aber nicht für lange Tabellen.
Man muss sich vorstellen, dass mySQL für jede Sortierung die Tabelle in eine Sortiertabelle kopiert und nicht nur die Sucharbeit die Datenbank belastet sondern auch der ihr zur Verfügung stehende RAM-Speicher.

Ohne den Quellcode zu verändern, kann man hier der Datenbank in den MySQL Einstellungen deutlich mehr RAM zur Verfügung stellen, dann läuft das auch durch.
Es muss halt so viel RAM sein, dass die DB nicht auf die Festplatte auslagern muss.

Bei einem Projekt mit Tabellenlängen von teils über 40 Millionen Einträgen hatten wir einen 12Kern-Server mit 32 GB alleine nur für MySQL.
Und das lief sehr flott, trotz vieler Millionen DB Zugriffe am Tag.
Aber ich hatte damals auch keine Monster SQL gebaut
Da blieb der Server auch stehen, als ich es mal versuchte

[Faar]

An Frederic:
Es müsste doch möglich sein, ab Zeile 223 in includes/include.con_art_overview.php eine Abfrage einzubauen, die Mandanten, System oder User Einstellungen berücksichtigt.
Die könnte vor Zeile 234 eingesetzt werden und die Einstellung selbst könnte so aussehen:

Code: Alles auswählen

$elemperpage = getEffectiveSetting('elementperpage', 'limit', 80);

Und in Zeile 843 wird in dem Fall 0 => i18n("All") durch den eingestellten Limit Wert ersetzt (wobei dann noch die Frage ist, was dann mit der Zahl 100 geschieht, wenn 80 als Limit eingestellt wäre?).

Zusätzlich könnte man die ganze Liste hier...

Code: Alles auswählen

            0 => i18n("All"),
            10 => "10",
            25 => "25",
            50 => "50",
            75 => "75",
            100 => "100"

...auch als String-Array in den Einstellungen übergeben, die Werte mit Komma separiert.

Code: Alles auswählen

$elemperpageList = getEffectiveSetting('elementperpage', 'list', '5,10,25,60,100,0');

Und die 0 am Ende wäre dann für "alle".
Und falls niemand was in Mandanten, User oder Systemeinstellungen rein geschrieben hat, würde die Standardliste gelten.
Dann wäre das sehr flexibel.
Oder?

[frederic.schneider_4fb]

Vielen Dank für Eure Diskussion und die konkreten Vorschläge. Wir haben uns teamintern abgestimmt und finden die Anregung grundsätzlich nicht schlecht. Ich habe deshalb dafür ein Ticket angelegt. Wir werden das aller Voraussicht nach aber nicht unmittelbar umsetzen, da wir das eher als "Nice to have" sehen und die kommende Version soweit bereits durchgeplant ist