Plugin zur Textersetzung

  • Hallo zusammen,

    in meinem Forum habe ich ein Plugin installiert, welches Referenzen auf Gesetze über eine API bei dejure.org automatisch dorthin verlinkt. Ein Eventlistener hört auf assignVariables der Klassen ArticlePage, EntryPage, ConversationPage und ThreadPage.

    Das funktioniert derzeit

    - bei neuen Beiträgen auf Anhieb

    - bei Antworten auf Beiträge erst nach einem Reload

    Wie wo müsste ich mich reinhängen, damit auch der AJAX-Response der beim Absenden einer Antwort schließlich auf der Threadseite mit eingebunden wird, ebenfalls von der Verlinkung erfasst werden kann?

    Vielen Danke & Grüße

    Johannsen

  • Hallo,

    ein einziger Event-Listener auf beforeProcess@wcf\system\html\output\node\HtmlOutputNodeProcessor reicht für alles aus. Es empfiehlt sich die Prüfung von $eventObj>getOutputType() === 'text/html', damit nur die reine HTML-Ausgabe verändert wird.

  • Hallo,

    vielen Dank dafür. Damit habe ich gestern experimentiert und festgestellt, dass der Dejure-Service und HtmlOutputNodeProcessor eine "ungünstige Kombination" sind. Problem:

    Der Service nimmt Beitragstexte 1:1 entgegen und schickt eine fertig verlinkte Antwort zurück. Der Payload ist dabei einfach Plaintext, der HTML enthält.

    Wenn ich nun über den beforeProcess@HONP statt über die assignVariables@* gehe:

    habe ich das Problem, dass das vom Service zurückgegebene HTML Verbatim im Beitragstext erscheint, die <a>-Tags also in der Threadansicht mit ausgegeben werden...

  • Ah, ich verstehe. In dem Fall bleibt dir tatsächlich nur, den Inhalt mit schön vielen Event-Listenern ersetzen zu lassen. Eine Manipulation des HTML der Nachricht beim Verfassen einer Antwort ist technisch nicht vorgesehen, denn dafür existieren die HtmlInput*- bzw. HtmlOutput*-Klassen.

    Ein Eventlistener hört auf assignVariables der Klassen […], ConversationPage und […].

    Ich bin mir ziemlich sicher, dass die Übermittlung privater Kommunikation an einen Dritten zum Zwecke der Verlinkung durch keinen Erwägungsgrund in der DSGVO abgedeckt ist. Ohne ein explizites Opt-In dürfte das bei so ziemlich jedem Anwalt Schnappatmung zur Folge haben. Hier solltest du dich anwaltlich beraten lassen, bevor du dich damit in die sprichwörtlichen Nesseln setzt.

  • Ah, ich verstehe. In dem Fall bleibt dir tatsächlich nur, den Inhalt mit schön vielen Event-Listenern ersetzen zu lassen.

    Und damit zurück zur Eingangsfrage: Welches Event kommt denn in Frage, damit die AJAX-Response nach dem Absenden einer Beitragsantwort ebenfalls vom Listener erfasst wird?


    Danke für den DSGVO-Hinweis, das haben wir schon durchexerziert.

  • Welches Event kommt denn in Frage, damit die AJAX-Response nach dem Absenden einer Beitragsantwort ebenfalls vom Listener erfasst wird?

    Es ist für mich nicht klar, wie dein Event-Listener bei den übrigen Events überhaupt arbeitet. Du könntest dich auf finalizeAction@wbb\data\post\PostAction binden und dann prüfen, ob $eventObj->getActionName() === 'quickReply'. Etwas besseres kann ich dir nicht anbieten, weil die Veränderung der Nachricht abseits der genannten Implementierung nicht vorgesehen ist.

  • Das war jetzt doch nochmal etwas aufwändiger, bis ich den richtigen Codepfad ausfindig gemacht habe.

    Hier ist die execute() des Listeners - vielleicht kann's jemand brauchen. Aber natürlich ohne Gewähr.

  • Das erinnert mich an meine Anfangszeit mit dem WBB. Damals hatten wir in einem Forum, in dem auf sehr viele Gesetze in den Themen Bezug genommen wurde, ebenfalls eine solche Schnittstelle zu dejure.org. Das funktionierte einwandfrei und wurde von den Teilnehmern als große Hilfe empfunden.

    Vielleicht magst Du ja ein Plugin daraus machen und es hier im Thema oder auch im Pluginstore zur Verfügung stellen. Der eine oder andere kann das vielleicht gut gebrauchen.


    Gruß norse

    Zugang zu meinen Arbeiten und dem dazugehörigen Support bekommt Ihr bei Interesse hier.

  • Hallo,

    Vielleicht magst Du ja ein Plugin daraus machen und es hier im Thema oder auch im Pluginstore zur Verfügung stellen. Der eine oder andere kann das vielleicht gut gebrauchen.

    das würde im Rahmen der Prüfung im Plugin-Store abgelehnt. Johannsen hat es in Form von „kleinen Reflection-Sauigeleien“ schon passend bezeichnet: Der Zugriff auf „private“ Properties über Reflection mag für ein Plugin für den eigenen Einsatzzweck vertretbar sein, ist im Plugin-Store aber nicht akzeptabel. Die Properties sind schließlich nicht ohne Grund nicht für die „Öffentlichkeit“ zugänglich.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!