Ich denke, das ist möglich. Im Event-Handler dpg_displaypage musst du $.ajax() verwenden, um deine externe API aufzurufen. Außerdem musst du deine externe API wahrscheinlich in die Discourse-Einstellung „Inhaltssicherheitsrichtlinie: Skript-Quellen
Es sieht so aus, als ob dieses Plugin weiterhin gewartet wird, aber ich habe auf meinem Server ein Problem isoliert: Die Anmeldeseite ist nicht sichtbar, wenn dieses Plugin aktiviert ist. Ich hoffe, dass dies gelöst werden kann.
Wenn das Plugin auf meinem Server aktiviert ist, kann ich bestätigen, dass die Anmeldeseite leer angezeigt wird. Sobald ich das Plugin deaktiviere, erscheint die Anmeldeseite wieder normal. Wenn ein Benutzer bereits angemeldet ist, tritt das Problem nicht auf, und der Server funktioniert wie gewohnt.
Ich suche nach Unterstützung, um dies zu lösen. Gerne stelle ich weitere Informationen zur Verfügung, die für die Fehlerbehebung erforderlich sind.
Danke, Jordan.
Ja, ich benötige noch einige weitere Informationen, da ich auf meinen verschiedenen Discourse-Instanzen nachgeschaut habe und das Problem nicht reproduzieren konnte.
Wenn du sagst, dass die Anmelde-Seite nicht sichtbar ist, meinst du damit das Anmelde-Popup, oder?
Bitte gib mir weitere Details und/oder Screenshots. Falls möglich, schicke mir auch eine private Nachricht mit der URL deiner Discourse-Instanz.
Hey Syl,
Danke für die Antwort.
Wenn ich das discpage-Plugin aktiviert habe und zur Discourse-Instanz gehe, ohne eingeloggt zu sein, wird mir eine komplett leere Seite angezeigt. Siehe unten:
Ich habe auch gerade erst die Konsolenprotokolle überprüft und festgestellt, dass es einige Fehler im Zusammenhang mit discpage gibt. Für mich bedeuten sie nichts. Vielleicht sagen sie dir etwas…
Danke für den Hinweis. Der Fehler wurde hier gemeldet:
Bis der Fehler behoben ist, besteht eine Workaround-Möglichkeit darin, die Discourse-Einstellung „Anmeldung erforderlich
Hi Syl,
Das ist etwas unangenehm
– sorry, wenn ich direkt bin. Ich habe mir aus reiner Neugier den Quellcode des Plugins angesehen, habe aber überhaupt keine Programmierkenntnisse, und die Formatierung der Lib-Datei verwirrt mich. Ich nehme an, das ist keine technische Entscheidung (aber was weiß ich schon
), und ich kann mir vorstellen, woher das kommt.
Ich habe das Gefühl, du befindest dich mitten im Prozess, und es ist bereits großartig. Ich möchte auf keinen Fall undankbar wirken, aber würdest du in Betracht ziehen, eine verständliche Version deiner Arbeit zu teilen?
Meiner Meinung nach kann das Tempo der Kern-Updates auf lange Sicht für Plugin-Autoren herausfordernd sein. Eine verständlichere Version könnte denjenigen, die die Funktionen deines Plugins nutzen möchten, aber zögern, sich auf die Schultern nur weniger Personen zu stützen, die Sorge nehmen. Wer weiß, vielleicht weckt es sogar mehr Wohlwollen und Interesse?
Trotzdem vielen Dank ![]()
Hallo Benjamin,
Der Quellcode des Plugins wurde in minifizierter Form veröffentlicht, weil ich mich dafür schäme. Er ist das Ergebnis eines F&E-Experiments und muss umfangreich umgestaltet werden. Ich habe die Aufgabe verschoben, bis das Plugin ein gewisses Interesse weckt.
![]()
Also, ich zähle mich definitiv zur Spalte „sehr interessiert
Bisher alles gut!
Mein Senf dazu:
- Meine bescheidene Meinung zum Header: Ich würde ihn lieber zentriert lassen. Das integriert die statischen Seiten des Plugins nahtloser in einen allgemein „normalen
Vielen Dank @Benjamin_D, dein Feedback ist sehr willkommen.
[quote=“Benjamin_D, post:30, topic:136841”]
Meine bescheidene Meinung zum Header: Ich würde ihn lieber zentriert lassen. Ich habe das Gefühl, dass er die statischen Seiten des Plugins nahtloser in einen global „normalen
Eigentlich wäre es eher die max-width = 1110px, die ich beibehalten würde, auch wenn auf dem geteilten Bildschirm die statische Seite unter dem Header 100% einnimmt. Ich habe den Block html.dpg header.d-header .wrap auskommentiert, und es fühlt sich gar nicht so schlecht an, ein wenig Weißraum um den Header über der statischen geteilten Seite zu haben (auch wenn die Schaltflächen „Titel bearbeiten“ und „Seite“ dort oben etwas verloren wirken, bei nicht geteiltem Layout).
Ich bin ein Dummkopf, RTFM
(zu meiner Verteidigung habe ich das wahrscheinlich letztes Jahr getan und es dann vergessen
).
Ich erinnerte mich nicht daran, dass DiscPage die Ballon-Kategorie ausblendet (ich habe es gerade als Admin getestet), aber das ist eine großartige Funktion.
Also, wenn ich das richtig verstehe, sollte man im Fall mehrerer {statische Seiten-Kategorie, Benutzerrechte} eine zugehörige Ballon-Kategorie als Unterkategorie der statischen Seite anlegen (was aus Sicht der Rechte sinnvoll ist), oder beide Kategorien als Unterkategorien derselben dritten übergeordneten Kategorie. Nicht wichtig, aber würde es auch funktionieren, wenn die statische Seite eine Unterkategorie der Ballon-Kategorie ist?
Wahrscheinlich nur die Ballonform des Symbols, in Verbindung damit, dass ich die Zitat-Schaltfläche des Editors wahrscheinlich noch nie benutzt habe, und vielleicht dachte ich: Hey, war das schon immer da? Also habe ich es ausprobiert ![]()
Es macht mir nichts aus, ein paar Zeilen „Code“ zu schreiben, aber ich kann das Jammern meiner Benutzer schon von hier hören. Vielleicht werden sie sich momentan einfach keine statischen Seiten einrichten. Manchmal habe ich das Gefühl, jeder Tastenanschlag könnte der Tropfen sein, der das Fass zum Überlaufen bringt… ![]()
Natürlich, sorry… Ich schiebe das auf mein leichtes Fieber. Ich weiß nicht, warum ich dachte, sie seien nicht ausgeblendet. Vielleicht habe ich in der Dropdown-Box für Tags im Ballon-Teil des geteilten Bildschirms kurz einen Blick auf eines erhascht? Ich verstehe jetzt das nachgestellte Komma, das ich gesehen habe, als ich alles Mögliche ausprobiert habe, sogar die Ballon-Themen getaggt!"}
Wäre es möglich, Benutzern zu erlauben, ihre statischen Beiträge zu erstellen und zu bearbeiten? Die Admin-Einschränkung ließe sich dann nur noch über die Sicherheitseinstellungen der Kategorien umsetzen.
Edit:
Vielleicht doch nicht, das Ändern von tag_groups scheint eine StaffConstraint zu sein ![]()
Ich könnte einem TL4-Benutzer erlauben, ein Balloon-Element so anzupassen, dass a = User.current()) && a.admin in User.current()) && a.trust_level >= 4 geändert wird, aber das Tag wird erst erstellt, wenn ein Admin die statische Seite bearbeitet… ![]()
Was wäre toll: Ein Kategorie-Moderator, der die Tag-Gruppe seiner Kategorie ändern kann ![]()
Übrigens habe ich festgestellt, dass die Plugin-Checkliste mit discpage zu interferieren scheint (etwas mit getmodel()).
Ich bevorzuge das aktuelle Layout. Es sollte jedoch eine einfache Möglichkeit geben, dies anzupassen. Ich werde mir das überlegen.
Nein, diese Kombination wird nicht unterstützt.
Wie du bereits festgestellt hast, ist das Erstellen statischer Seiten nicht auf Administratoren beschränkt, wohl aber das Einfügen von Ballons. Der Grund dafür ist, dass es in Discourse keine einfache Möglichkeit gibt, Tags zu erstellen (siehe diesen Thread). Daher habe ich mich dafür entschieden, die tag group-API zu verwenden, die auf Administratoren beschränkt ist. Es gab alternative Lösungen, die jedoch jeweils eigene Nachteile mit sich brachten.
Du meinst dieses Plugin? Was genau ist das Problem?
Tatsächlich: Mit beiden Plugins aktiviert führt das Aktualisieren einer statischen Seite dazu, dass discpage gewissermaßen deaktiviert wird (es wird ein normales Layout zurückgegeben), und die Konsole wirft einen Fehler aus:
Uncaught (in promise) TypeError: postModel ist undefined
checklistSyntax javascripts/discourse/initializers/checklist:29
Beide Plugins funktionieren separat einwandfrei.
Danke @Benjamin_D. Das Problem wurde hier gemeldet:
EDIT: Dies wurde in der neuesten Version (1.0.38) behoben.
Hi @syl, ich mag es nicht, die Überbringer schlechter Nachrichten zu sein
, aber ich habe ein weiteres, etwas problematischeres Kompatibilitätsproblem festgestellt: Wenn discpage aktiviert ist, führt ein Einladungslink zu einer leeren Seite (anstatt zur Registrierungsseite).
Die Browserkonsole meldet:
r.site.categories ist undefined
Wenn das Plugin deaktiviert wird, funktioniert der Einladungslink wie gewohnt.
Vielen Dank für die Meldung, @Benjamin_D. Dies ist ein weiterer Fehler im Modus „Anmeldung erforderlich“, daher habe ich das vorherige GitHub-Problem wieder geöffnet. Bis dies behoben ist, besteht eine Workaround-Möglichkeit darin, den Modus „Anmeldung erforderlich“ zu deaktivieren.
EDIT: Dies wurde in der neuesten Version (1.0.38) behoben.
Hallo @syl!
Ich denke, die kürzliche Änderung der Tag-Routen
hat etwas kaputt gemacht ![]()
Mindestens sollte der Link in den Blasen nun auf /tag/dpg-xxx und nicht auf /tags/dpg-xxx verweisen.
Danke @Benjamin_D, das wurde in v1.0.38 behoben.

