frontenduser angangs selektion

[hypekermit]

hallo ich habe jetzt ca. über 300 frontenduser im system.

wenn ich auf Administration und dann frontend klicke, dann dauert die selektion eine ewigkeit.... kann man das system so einstellen, das er anfangs nicht selektiert? so das ich meinen selektionswunsche zusammenklicken kann, dann wäre die selketion kleiner.

sonst müsste ich jedesmal warten, bis er anscheinend alle daten geladen hat.. dauert etwa 4 minuten...

[mvf]

hä?

standard sind doch eh nur 25/seite

erklär mal näher für nen opa wie mich, brauche 'immer' ewtas länger

[hypekermit]

habe aber die erweiterung frontenduser logic

die enthält einen grossteil von neuen feldern.. dazu habe ich noch eigene hinzugefügt...

jetzt rechnet und rechnet und rechnet er selbst für nur 25...

kann man das standard hier auf 0 setzen????

[mvf]

habe aber die erweiterung frontenduser logic

die enthält einen grossteil von neuen feldern.. dazu habe ich noch eigene hinzugefügt...

jetzt rechnet und rechnet und rechnet er selbst für nur 25...

kann man das standard hier auf 0 setzen????

dazu muss du das core anfassen

ohne gewähr

contenido\includes\include.frontend.user_menu.php ( Zeile 84)

Code: Alles auswählen

$oSelectItemsPerPage->autoFill(array(25 => 25, 50 => 50, 75 => 75, 100 => 100));

wäre mal ein ansatz, aber alles auf deine verantwortung als BACKUP first
vor allem denke ich wäre das nur quick and dirty, mal gucken ob emergence sich meldet, denke der weiss da mehr oder herrB

[hypekermit]

hallo die gleiche idee hatte ich gerade auch und es so eingestellt...
geht aber leider nicht...

keine veränderung...

weisst du wo das script gestartet wird (funktionsaufruf für die selektion?

dann könnte man die auskommentieren... dann würde er nicht von anfang selektieren...

Code: Alles auswählen

$oSelectItemsPerPage->autoFill(array(0 => 0, 25 => 25, 50 => 50, 75 => 75, 100 => 100));

[mvf]

muss auch gucken und wühlen

[HerrB]

Sofern nicht die Möglichkeit benötigt wird, nach den zus. Feldern zu suchen oder danach zu sortieren, kann man diese für die Liste deaktivieren.

Dazu ist folgende Mandanten- oder Gruppen- oder User-Einstellung vorzunehmen:

type:
frontendusers

name:
pluginsearch

value:
false

Ist übrigens IMHO ein prinzipbedingter Bug, dass das so lange dauert...

Gruß
HerrB

[hypekermit]

perfekt.

die abfrage ist jetzt rasend schnell...
genau so sollte es sein.

ist es denn vorgesehen das solche bugs behoben werden?

vor allem der lästige bug mit den ewigen ladezeiten beim aufruf des editors... oder gibt es hierfür auch eine type variable, um diese ladezeit zu verringern???

auf jeden fall besten dank für den tip von herrb und danke an alle die sich damit befasst haben....

[HerrB]

ist es denn vorgesehen das solche bugs behoben werden?

Nein, nie. Ist generell nicht vorgesehen, dass Bugs behoben werden. Eine etwaige Lösung ist ggf. nur Ergebnis einer zufälligen Mutierung des Codes...

Scherz beiseite: Sagen wir mal so, so wie es jetzt ist, ist es bei 100 Einträgen und mit (als Beispiel) 5 zusätzlichen Feldern für Informationen erträglich, danach wird es anstrengend.

Hintergrund:
Der vorhandene Ansatz ist eine geniale Idee und ermöglicht es sogar, Zusatzinformationen aus Text- und XML-Dateien zur verfügung zu stellen und (für diesen Bereich) ohne mySQL auszukommen.

Leider fummelt sich der Webserver dabei zu Tode, da zunächst alle Daten in ein Array geladen werden, dann (bei Verwendung der Suche) darin gesucht und anschließend das Array sortiert wird. Danach zählt er die Array-Position hoch, um zu den Einträgen zu kommen, die auf der aktuellen Seite angezeigt werden sollen...

Das Laden der Daten in das Array funktioniert unter Verwendung der Plugins so:
1. SQL-Abfrage gegen die DB liefert alle Frontend-User-Accounts
2. Pro Account werden nun auf Dateiebene die Plugin-Verzeichnisse auf vorhandene .php-Dateien gescannt und diese ggf. included
3. Enthält die Plugin-Datei eine entsprechende Prozedur, die Daten zum Array beisteuern dürfte, wird diese ausgeführt
4. Sind die Daten, die die Prozedur beisteuert, in der DB gespeichert, wird ein SQL-Statement gegen die DB gesendet

Beispiel:
2000 Frontend-User-Accounts
10 zusätzliche Felder
25 Zeilen/Seite
Suche nach "e"
Zeige Seite 12 an

Pro Account scan durch 10 Verzeichnisse, nacheinander include von 10 Dateien, ausführen von 10 Prozeduren, damit 10 Abfragen gegen die DB. Suchen im Array, Sortieren des Ergebnis, durch das Array zählen, bis wir bei Seite 12 sind, 25 Zeilen ausgeben.

D.h. für die Anzeige der 25 Einträge auf Seite 12, die ein "e" enthalten, werden 20000 + 1 Abfragen gegen die Datenbank gesandt, ein Array mit 10 + 4 Spalten und 2000 Zeilen (28000 Zellen) gefüllt, zeilenweise durchsucht, die verbleibenden Zeilen sortiert und bis zum 276. Datensatz (11 * 25 + 1) hochgezählt. Und dann werden 25 Zeilen mit den Daten aus 4 Spalten ausgegeben...

Wenn man auf das Feature der direkten Verwendung von Text- und XML-Datenquellen verzichten könnte (d.h. nur Datenbank-Zugriffe, z.B. in dem man die Text- bzw. XML-Daten einfach in einem separaten Schritt in der Datenbank einträgt), dürfte man einen Weg finden, um pro Account nur eine Abfrage gegen die DB zu senden (das wären dann nur 2000+1). Wenn man auf das Feature verzichten könnte, dass die Zusatz-Daten in einer separaten DB liegen, könnte man einen Weg finden, nur eine Abfrage gegen die DB zu senden.

Wenn man auf das Feature verzichten kann, mySQL nicht verwenden zu müssen, kann man mit LIMIT direkt die Daten für eine bestimmte Seite ermitteln. Dies gilt natürlich nur, wenn ich nicht in den Zusatzdaten suchen möchte oder die Zusatzdaten in der gleichen DB liegen.

Die Frage ist also, auf welche Möglichkeiten die Allgemeinheit eher verzichten kann - hier muss man IMHO insbesondere die Unternehmens-Brille aufsetzen, da diese u.U. Oracle-Server oder SQLServer statt mySQL einsetzen möchten, dort Zusatzdaten aus anderen Systemen geliefert werden und diese anderen Systemen "nur" das "non-plus-ultra" des flexiblen Datenaustauschs, nämlich XML zur Verfügung stellen (es seine auch Webdienste genannt).

Persönlich werde ich in der nächsten Newsletter-Überarbeitung (da besteht das Problem aufgrund der Code-Verwandschaft ebenfalls) wieder zurück in die mySQL-DB gehen. Punkt.

Gruß
HerrB

[hypekermit]

vielen dank für die erklärung.... jete kann man das auch mal verstehen.

ist mit der 4.6.8 das problem mit dem langen laden der artikel behoben?

es gab da mal ein patch mit dem man das lange laden beim aufruf des editors umgehen konnte...

ist der jetzt in der 4.6.8 mit drin???

[HerrB]

Ein wenig offtopic. Ansonsten ist mir ein Fehler beim Laden des Editors nicht bekannt, sondern nur beim Speichern eines langen Textes. Das ist nicht drin und der bisher vorgeschlagene Lösungsansatz scheint auch noch nicht fehlerfrei zu sein.

Gruß
HerrB

[Uwe]

Sofern nicht die Möglichkeit benötigt wird, nach den zus. Feldern zu suchen oder danach zu sortieren, kann man diese für die Liste deaktivieren.

Kann man die Pluginsuche auf diese Art auch eingrenzen oder geht nur an und aus?

Viele Grüsse, Uwe

[HerrB]

Z.Z. nur an und aus.

Gruß
HerrB