Ein Kunde hat mich gebeten, ein benutzerdefiniertes Verzeichnis auf Kartenbasis zu erstellen.
Da er auf discourse.org gehostet ist, habe ich zunächst gesagt, dass dies nicht möglich sei (abgesehen von möglichen Leistungsproblemen), da die Attribute, die für die Füllung einer Benutzerkarte erforderlich sind, nicht im Benutzerobjekt verfügbar sind, das mit den Verzeichniselementen serialisiert wird.
Nach weiterer Diskussion habe ich jedoch festgestellt, dass ein Ansatz darin bestehen könnte, einen PR in den Core einzubringen, der Benutzerattribute über eine Site-Einstellung zum Serialisierer der Verzeichniselemente hinzufügt. Die Idee dahinter ist, dass diese Funktionalität für verschiedene Arten von Benutzerverzeichnissen nützlich sein wird, die unterschiedliche Kombinationen von Benutzerattributen erfordern (Beispiel unten).
Bei der Erprobung dieses Ansatzes habe ich eine relativ einfache Lösung entwickelt, die Sie in diesem Diff sehen können:
Ich glaube, dass @blake und @awesomerobot mit einem anderen Kunden mit ähnlichen Anforderungen zusammenarbeiten. Ich bin grundsätzlich offen für eine Site-Einstellung, ähnlich wie wir always_include_topic_excerpts haben.
Einschränkung ist, dass ich dies getestet haben möchte und die Site-Einstellung versteckt sein soll.
Ich weiß, dass sich @david ebenfalls für das Problem interessiert hat. Ich bin hier etwas hin- und hergerissen, aber vielleicht wäre eine langfristigere, sauberere Lösung:
Versteckte Site-Einstellungen für “Ermögliche Plugins und Themes, sich für zusätzliche serialisierte Informationen zu entscheiden” (Standard: aus) hinzufügen.
Anschließend ein Protokoll in Themes/Plugins für das “Anfragen” der zusätzlichen Informationen implementieren.
Der Vorteil hierbei ist, dass einige Themes dann die zusätzlichen serialisierten Informationen haben und andere nicht.
Ich möchte hier noch etwas auf David warten, bevor ich dir grünes Licht gebe.
Wie wäre es, wenn der Serialisierer für das Benutzer-Verzeichnis einen neuen Parameter wie users.json?include_profile=true akzeptieren würde?
Dann könnten wir eine JS-Plugin-API hinzufügen, die es Themes ermöglicht, diesen Parameter hinzuzufügen:
api.userListIncludeProfile(true)
“Profile” würde alle Elemente des regulären Benutzer-Serialisierers umfassen (wobei darauf zu achten ist, keine N+1-Abfragen einzuführen). Ich denke nicht, dass die Angabe einzelner Felder einen großen Unterschied für die Leistung macht, daher sollten wir es meiner Meinung nach einfach halten.
Der gleiche Ansatz könnte auch für Themenlisten funktionieren: ?include_excerpts=true.
Das gefällt mir auch, weil dadurch die “pro-Theme-Serialisierer-Konfiguration” nicht durch den Anon-Cache beeinträchtigt wird!
Fast, aber das funktioniert nicht sauber, denn wenn du zur Startseite der Seite oder zum u-Pfad navigierst, hast du nicht die Möglichkeit, einen Parameter zum Pfad hinzuzufügen. Wir müssen die Standardwerte ändern
In diesem Fall halte ich eine versteckte Site-Einstellung für einen guten Ausgangspunkt. Es wäre schön, dies pro Theme zu gestalten, aber dafür müssen wir zunächst einige Infrastruktur aufbauen. Ich bin immer noch der Meinung, dass eine boolesche Einstellung „Benutzerliste enthält Profil
Cool. Lasst uns wissen, ob ihr das als pr-welcome betrachtet und in welcher Form, und wir erstellen es gerne. Von unserer Seite aus wird @fzngagan das ab jetzt übernehmen.
Eine Sache, die wir hier klären sollten, ist das protocol für die Anforderung zusätzlicher Daten. Können wir uns auf die Frontend-Einstellung verlassen, um die Daten anzufordern, oder sollen wir, wie von dir vorgeschlagen, eine weitere API im plugin-api hinzufügen?
Lass es uns einfach halten: Ignoriere meinen Beitrag über Parameter und JavaScript-APIs.
Wenn die Site-Einstellung auf dem Server aktiviert ist, gib die zusätzlichen Informationen zurück. Ist die Site-Einstellung deaktiviert, tue es nicht.
Aktuell müssen Administratoren die Einstellung manuell aktivieren. Möglicherweise prüfen wir in Zukunft, ob Themes diese Einstellung automatisch umschalten können.
