تصحيح digest_custom_html ليتم التعامل معه على أنه HTML (كانت: تجاوز digest.html.erb)

مطور
1

ملخص:

أحاول إضافة بعض الأشياء إلى الملخص. اعتدت على تجاوز القالب، لكن لا يمكنني فعل ذلك الآن، لأسباب غير واضحة.

نظرًا لأن تجاوز القوالب سيء، فهناك بعض الأماكن في الملخص التي يتم استبدالها بـ digest_custom_html، لكنها تُدرج النص، لذا تحتاج هذه إلى إضافة .html_safe. واحد على الأقل في المكان الخاطئ (يحتوي على “أعلى” في الاسم، ولكنه في الواقع أسفل).

أعتقد أن لدي المهارات اللازمة لتقديم طلب سحب (PR) لهذا الأمر، إلا إذا كان، نظرًا لبساطته، قد يكون من الأسهل لشخص آخر القيام بذلك.

القصة الأطول والأكثر إيلامًا.

لقد فعلت ذلك هنا: GitHub - pfaffman/discourse-add-to-summary: Add text to summary before and after title ولكن يبدو أن ذلك قد توقف عن العمل.

أعتقد أن ما أريد القيام به، دون إجراء تغييرات على النواة، هو تجاوز قالب digest.html.erb. اعتدت أن أكون قادرًا على القيام بذلك عن طريق وضعه في app/views/user_notifications/digest.html.erb وسيتم معالجة هذا الملف بدلاً من الملف الموجود في النواة. لم يعد هذا يبدو أنه يعمل.

الآن، لدينا بعض digest_custom_html الرائعة مثل هذه:

سيلاحظ القارئ الذكي أن المواضيع الشائعة تبدأ حوالي السطر 78، قبل وقت طويل من السطر 277. لست متأكدًا من مقدار الوقت الذي أضعته في التفكير في أن شيئًا لم يحدث لأنني كنت أنظر في المكان الخطأ. لكنني أبتعد عن الموضوع.

لقد تمكنت من القيام بذلك في plugin.rb بعد after_initialize.

  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
        "<div>MY COOOOOOOL TEXT</div>"
      else
        puts "doing the super for #{position_key}"
        super
      end
    end
  end

وهو بالفعل يضيف نصًا إلى المكان الذي أتوقع أن يتم تغييره فيه في القالب!

للأسف، لا يتم التعامل معه كـ HTML، بل كنص. لذا. . . .

نظرت في جميع الإضافات ولم أجد أي أمثلة لأي شخص يستخدم هذا الكود.

هل سيكون طلب سحب مرحب به إذا قمت بتغيير الأسطر مثل

        <%= digest_custom_html("below_popular_topics") %>

واستبدالها بـ

        <%= digest_custom_html("below_popular_topics").html_safe %>

وأثناء قيامي بذلك، ربما أتأكد من أن أسماء position_keys أكثر تشابهًا مع موقعها؟

إعجاب واحد (1)
2

لقد قمت بإنشاء طلب سحب (PR):

إعجابَين (2)
3

لقد قررت أن digest_custom_html لا ينتج HTML يمكن تحليله هو خطأ، لذا أقوم بإعادة تصنيفه.

إعجاب واحد (1)
4

@martin، آسف لاستدعائك، لكنك كنت آخر شخص قام بتعديل digest.html.erb (قبل عامين). هل تمانع في إلقاء نظرة على طلب السحب هذا؟

إعجاب واحد (1)
5

تم نشر هذه الإضافة وسوف أنساها على الأرجح قريبًا جدًا، لذا إذا أراد أي شخص استخدام حقول digest_custom_html هذه كما هو مقصود، يمكنك إضافة كود مثل هذا إلى ملف app.yml الخاص بك لتصحيح المصدر. كنت كسولًا جدًا لإنشاء تعبير عادي (regex) يستبدلها جميعًا، وبدلاً من ذلك قمت فقط بعمل الذي كنت أستخدمه. قم بالتعديل حسب الاقتضاء لحالة الاستخدام الخاصة بك.

لقد أنشأت قالبًا في الإضافة يمكن بعد ذلك تضمينه في ملف app.yml. هذا يجعل الأمر أسهل قليلاً من العبث بكتلة كاملة من YAML.

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)
6

هل من المنطقي أن يكون هناك وسم لمساعدة الفريق على التنبيه لفتح طلبات السحب (PRs)؟

إعجاب واحد (1)
7

مرحباً @david. سأحاول مرة أخرى لمعرفة ما إذا كان أي شخص مهتمًا بطلب السحب هذا. كما هو موضح أعلاه؛ من الواضح أن الكود لا يعمل كما هو مقصود، ولكن لم يهتم أحد قط. لقد قمت بعمل حل بديل ونشرت الكود مع إصلاح لتصحيح القالب عند النشر، ولكنه ليس حلاً أنيقًا.

إعجاب واحد (1)
8

هل يمكنك إضافة .html_safe إلى نتيجة تجاوز الطريقة الخاصة بك؟ لا أعتقد أن هناك أي سبب لحاجتها إلى قالب erb؟

الهدف العام، سواء في Rails أو في Ember، هو وضع “هذه السلسلة آمنة بصيغة HTML” بالقرب من نقطة التأليف/الإنشاء، بحيث يكون من الواضح جدًا للمطورين أنهم بحاجة إلى التأكد من أن HTML آمن بالفعل (أي أن أي إدخال للمستخدم قد تم الهروب منه)

ما تفعله مقبول (طالما تم اختباره)، ولكنه ليس الاستخدام “المقصود” لهذه الطرق. إذا كانت واجهة برمجة تطبيقات إضافات متعمدة، فستكون في plugin/instance.rb مع الطرق الأخرى.

الاستخدام المقصود لهذه الطريقة هو وضع markdown في مفتاح الترجمة المطابق:

(لاحظ أيضًا html_safe هناك - هذه هي نفس التقنية التي ستحتاج إلى استخدامها في أي تجاوز)

إعجابَين (2)
9

يا إلهي. يبدو أنني أستطيع!!! لم يخطر ببالي قط أنني أستطيع وضعه هناك وليس في أعلى القالب حيث يتم عرضه (على الأقل في رأسي).

أرى الآن وأفهم أن digest_custom وأنها تستدعي .html_safe، بشكل جميل وسهل، في التعليمات البرمجية التي نظرت إليها وحاولت فهمها، لكنها مربكة (بالنسبة لي) أنها تستخدم هذه الصيغة الغريبة بدون أقواس. (أو ربما لم أكن لأراها أبدًا).

حسنًا، أرى القيم في اللغات المحلية، ولكن مقارنة بتجاوز القالب كما كنت أفعل من قبل، فهذا حل أقل خطورة بكثير.

شكرًا جزيلاً لك على توجيهي إلى المسار الصحيح!

إليك شيء آخر أفعله ويبدو سخيفًا. يحتاج digest_custom_html الخاص بي إلى المستخدم الذي يتم عرضه له، لذا فإن ما أفعله هو تجاوز digest لتعيين @user حتى يتمكن digets_custom_html الخاص بي من الوصول إلى المستخدم الذي يتم إرسال الملخص له. هل هناك طريقة سهلة للغاية يمكنني من خلالها تجنب القيام بذلك؟

after_initialize do
  # التعليمات البرمجية التي يجب تشغيلها بعد انتهاء Rails من التمهيد

  # 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)
10

لا أرى أي شيء آخر في القالب/الطرق يستخدم متغير user، لذا نعم، ما قمت به هو على الأرجح أفضل طريقة للقيام بذلك.

ولكن مع ذلك، لا يمكن “دعم” هذه الأنواع من التجاوزات، وقد تتعطل في أي وقت. تأكد من أن لديك بعض الاختبارات لالتقاط ذلك عندما يحدث في النهاية.

إعجاب واحد (1)
11

شكراً على التأكيد! أقدر وقتك.

مفهوم. هذا لا يزال أفضل بكثير من تجاوز القالب بأكمله، والذي كان حلي السابق لمكون إضافي مشابه.

ونعم، يجب أن تكون هناك اختبارات. :wink:

إعجاب واحد (1)
12

تم إغلاق هذا الموضوع تلقائيًا بعد 30 يومًا من آخر رد. الردود الجديدة غير مسموح بها بعد الآن.