Fixierung von digest_custom_html als HTML (bisher: Überschreiben von digest.html.erb)

Entwickler
1

TL;DR:

Ich versuche, ein paar Dinge zum Digest hinzuzufügen. Früher habe ich die Vorlage überschrieben, aber das geht jetzt aus unklaren Gründen nicht mehr.

Da das Überschreiben von Vorlagen schlecht ist, gibt es einige Stellen im Digest, die durch digest_custom_html ersetzt werden, aber dieser fügt den Text ein, sodass diese .html_safe angehängt bekommen müssen. Mindestens eine ist an der falschen Stelle (hat “above” im Namen, ist aber eigentlich darunter).

Ich denke, ich habe die Fähigkeiten für einen PR dazu, es sei denn, da es so einfach ist, ist es für jemand anderen einfacher zu erledigen.

Die längere, schmerzhaftere Geschichte.

Ich habe es hier gemacht: GitHub - pfaffman/discourse-add-to-summary: Add text to summary before and after title, aber das scheint nicht mehr zu funktionieren.

Ich denke, was ich tun möchte, ohne Änderungen am Kern, ist die Vorlage digest.html.erb zu überschreiben. Früher konnte ich das tun, indem ich sie in app/views/user_notifications/digest.html.erb abgelegt habe, und diese Datei wurde dann anstelle der Kern-Datei verarbeitet. Das scheint nicht mehr zu funktionieren.

Jetzt haben wir einige coole digest_custom_html wie diese:

Der aufmerksame Leser wird feststellen, dass die beliebten Themen etwa ab Zeile 78 beginnen, lange vor Zeile 277. Ich bin mir nicht sicher, wie viel Zeit ich damit verloren habe, zu denken, dass nichts passiert, weil ich an der falschen Stelle gesucht habe. Aber ich schweife ab.

Ich habe es nach after_initialize in plugin.rb geschafft.

  require_dependency "user_notifications"
  module ::UserNotificationsHelperOverride
    def digest_custom_html(position_key)
      puts "doing improved the digest: #{position_key}"
      if position_key == "below_popular_topics"
        puts "doing the custom html for above_popular_topics"

        # Custom HTML for the popular topics position
        "\u003cdiv class='custom-popular-topics'\u003eMY COOOOOOOL TEXT\u003c/div\u003e"
      else
        puts "doing the super for #{position_key}"
        super
      end
    end
  end

Und es fügt tatsächlich Text an der Stelle hinzu, an der ich erwarte, dass er in der Vorlage geändert wird!

Leider wird er nicht als HTML, sondern als Text behandelt. Also. . . .

Ich habe in all_the_plugins nachgesehen und keine Beispiele gefunden, bei denen jemand diesen Code verwendet.

Wäre es ein PR-willkommen, wenn ich die Zeilen ändern würde, wie z. B.

        \u003c%= digest_custom_html("below_popular_topics") %\u003e

und sie ersetzen durch

        \u003c%= digest_custom_html("below_popular_topics").html_safe %\u003e

Und während ich dabei bin, vielleicht sicherstellen, dass die Namen der position_keys ihrer Position ähnlicher sind?

1 „Gefällt mir“
2

Ich habe einen PR gemacht:

2 „Gefällt mir“
3

Ich habe beschlossen, dass digest_custom_html kein HTML erzeugt, das analysiert werden kann, daher stufe ich es neu ein.

1 „Gefällt mir“
4

@martin, entschuldige, dass ich dich namentlich nenne, aber du warst die letzte Person, die digest.html.erb angefasst hat (vor zwei Jahren). Würdest du dir bitte diesen PR ansehen?

1 „Gefällt mir“
5

Dieses Plugin wurde bereitgestellt und ich werde es wahrscheinlich sehr bald vergessen. Wenn also jemand diese digest_custom_html-Felder wie vorgesehen verwenden möchte, kann er Code wie diesen zu seiner app.yml hinzufügen, um die Quelle zu patchen. Ich war zu faul, einen Regex zu erstellen, der sie alle ersetzt, und habe stattdessen nur denjenigen gemacht, den ich verwendet habe. Passen Sie ihn entsprechend Ihrem Anwendungsfall an.

Ich habe im Plugin eine Vorlage erstellt, die dann in die app.yml aufgenommen werden kann. Das macht es ein kleines bisschen einfacher, als sich mit einem ganzen YAML-Block herumzuschlagen.

hooks:
  after_code:
    - replace:
        filename: "/var/www/discourse/app/views/user_notifications/digest.html.erb"
        from: 'digest_custom_html("above_footer") '
        to: 'digest_custom_html("above_footer").html_safe '
1 „Gefällt mir“
6

Wäre es sinnvoll, ein Tag zu haben, um das Team bei der Öffnung von Pull-Anfragen zu warnen?

1 „Gefällt mir“
7

Hallo @david. Ich werde noch einmal versuchen, ob jemand an diesem PR interessiert ist. Wie oben beschrieben; der Code funktioniert eindeutig nicht wie beabsichtigt, aber es hat sich noch nie jemand darum gekümmert. Ich habe eine Problemumgehung vorgenommen und den Code mit einer Korrektur bereitgestellt, um die Vorlage bei der Bereitstellung zu patchen, aber es ist keine schöne Lösung.

1 „Gefällt mir“
8

Könnten Sie .html_safe zum Ergebnis Ihrer Methodenüberschreibung hinzufügen? Ich glaube nicht, dass es im ERB-Template sein muss?

Das allgemeine Ziel, sowohl in Rails als auch in Ember, ist es, den String “this string is html safe” so nah wie möglich am Erstellungs-/Generierungspunkt zu platzieren, damit es für Entwickler sehr klar ist, dass sie sicherstellen müssen, dass das HTML tatsächlich sicher ist (d. h. Benutzereingaben maskiert sind).

Was Sie tun, ist in Ordnung (solange es getestet wird), aber es ist nicht die “vorgesehene” Verwendung für diese Methoden. Wenn es sich um eine absichtliche Plugin-API handeln würde, wäre sie in plugin/instance.rb zusammen mit den anderen.

Die vorgesehene Verwendung für diese Methode ist, Markdown in den entsprechenden Überschreibungsschlüssel einzufügen:

(Beachten Sie auch das html_safe dort - das ist dieselbe Technik, die Sie bei jeder Überschreibung verwenden müssten)

2 „Gefällt mir“
9

O.M.G. Anscheinend . . . kann ich das!!! Es wäre mir nie in den Sinn gekommen, dass ich es dort einfügen könnte und nicht ganz oben in der Vorlage, wo es (zumindest in meinem Kopf) gerendert wird.

Ich sehe und verstehe jetzt, dass digest_custom und dass es .html_safe aufruft, hübsch wie es ist, in Code, den ich mir angesehen und zu verstehen versucht habe, aber es ist verwirrend (für mich), dass es diese seltsame Syntax ohne Klammern verwendet. (Oder vielleicht hätte ich es nie gesehen).

Nun, ich sehe die Werte in den Lokalisierungen, aber im Vergleich zur Überschreibung der Vorlage, wie ich es zuvor getan habe, ist dies eine weitaus weniger riskante Lösung.

Vielen Dank, dass Sie mich auf den richtigen Weg gebracht haben!

Hier ist noch eine Sache, die ich mache und die sich albern anfühlt. Mein digest_custom_html benötigt den Benutzer, für den es gerendert wird. Deshalb überschreibe ich digest, um @user festzulegen, damit mein digets_custom_html Zugriff auf den Benutzer hat, für den der Digest bestimmt ist. Gibt es eine super einfache Möglichkeit, dies zu vermeiden?

after_initialize do
  # Code, der ausgeführt werden soll, nachdem Rails das Booten abgeschlossen hat

  # require_relative "lib/discourse_add_jobs_to_digest/user_notifications_helper_override"
  require_relative "lib/discourse_add_jobs_to_digest/engine"
  require_relative "lib/discourse_add_jobs_to_digest/job_api"

  require_dependency "user_notifications"
  module ::UserNotificationsHelperOverride
    def digest_custom_html(position_key)
      if position_key == "above_footer"
        DiscourseAddJobsToDigest::JobApi.get_jobs_html(@user).html_safe
      else
        super
      end
    end
  end

  UserNotificationsHelper.prepend(::UserNotificationsHelperOverride)

  module ::UserNotificationsOverride
    def digest(user, opts = {})
      @user = user
      super
    end
  end
  UserNotifications.prepend(::UserNotificationsOverride)
end
2 „Gefällt mir“
10

Ich sehe nichts weiter in der Vorlage/den Methoden, das eine user-Variable verwendet, also ist das, was Sie getan haben, wahrscheinlich der beste Weg, es zu tun.

Aber dennoch können diese Art von Überschreibungen nicht „unterstützt“ werden und können jederzeit fehlschlagen. Stellen Sie sicher, dass Sie einige Tests haben, um dies aufzufangen, wenn es schließlich passiert.

1 „Gefällt mir“
11

Danke für die Bestätigung! Ich schätze deine Zeit.

Verstanden. Das ist immer noch viel besser, als die gesamte Vorlage zu überschreiben, was meine vorherige Lösung für ein ähnliches Plugin war.

Und ja, es sollte Tests geben. :wink:

1 „Gefällt mir“
12

Dieses Thema wurde 30 Tage nach der letzten Antwort automatisch geschlossen. Neue Antworten sind nicht mehr erlaubt.