فجأة بعد آخر تحديث، يرسل Discourse رسائل بريد إلكتروني مع:
“Someone replied to a topic you are Watching.” (شخص ما رد على موضوع تراقبه.) تسبق كل بريد إلكتروني. جميع مستخدمي يشتكون بشدة، ولم يقم أي منهم بتغيير أي إعدادات للبريد الإلكتروني.
الجميع يقولون إن هذا مزعج للغاية.
إذًا، ما الذي حدث، وكيف يمكننا إيقاف هذا والعودة إلى السلوك العادي البسيط؟ لا أعتقد أن هذا قد تم تنفيذه بشكل جيد، ولم يهتم المطور حتى بالتحقق منه، حيث أن كلمة “watching” (مراقبة) مكتوبة بحرف W كبير لا داعي له.
أعتقد أن مصدر الإزعاج لأعضاء مجتمع أندرو هو %{header_instructions}.
تتوسع هذه العلامة (token) إلى كتلة كبيرة من النصوص القياسية (“لا ترد…”، والروابط، والتعليمات، وما إلى ذلك) وتظهر في أعلى نص البريد الإلكتروني في العديد من قوالب الإشعارات. بالنسبة للمستخدمين ذوي الخبرة، فإنها تهيمن على الرسالة وتبدو كأنها توبيخ وليست مساعدة.
لا يوجد حاليًا إعداد على مستوى الموقع لتعطيلها أو نقلها. لإزالتها، يجب على المسؤول تحرير كل قالب بريد إلكتروني على حدة ضمن الإدارة ← البريد الإلكتروني ← القوالب (Admin → Email → Templates).
في الإصدار latest-release الحالي (أنا على latest-release +17)، يجب أن يكون من الممكن معالجة هذا الأمر مركزيًا باستخدام برنامج نصي لـ Rails للقوالب التي لديها بالفعل تجاوزات لقاعدة البيانات (DB overrides)، على سبيل المثال، إزالة %{header_instructions} عندما يظهر في بداية النص. هذا الجزء سهل ويستخدم نموذج EmailTemplate.
تطبيق نفس التغيير على جميع القوالب القياسية (بما في ذلك تلك التي ليس لديها تجاوزات حالية) سيتطلب إنشاء تجاوزات عن طريق جلب نصوص القوالب الافتراضية عبر واجهات برمجة تطبيقات البحث الداخلية. هذا ممكن، ولكنه يعتمد على التفاصيل الداخلية لـ Discourse وسيحتاج إلى مراجع من أحد القائمين على الصيانة للمراجعة/التحقق قبل أن يتم التوصية به على نطاق واسع.
لذا، فإن المشكلة الأساسية ليست فقط محتوى %{header_instructions}، ولكن حقيقة أنه نص قياسي عالمي بشكل فعال بدون مفتاح تبديل على مستوى المسؤول، وإزالته أو نقله يتطلب عملاً يدويًا لكل قالب أو برمجة نصية غير مدعومة.
@Ethsim2 شكرًا لك، هذا رائع حقًا. ولكن لماذا تغير هذا فجأة؟ أنا لست خبيرًا في قراءة سجلات التغييرات أو حتى تحديد مكانها.
@Andro نعم - سؤال عادل تمامًا.
إن الجزء “فجأة” يرجع إلى أن %{header_instructions} ليس شيئًا قمت بتغييره محليًا: إنه جزء مقدم من النظام الأساسي (core) يقوم ديسكورس بحقنه في عدد من رسائل البريد الإلكتروني الخاصة بالإشعارات. إذا قام النظام الأساسي بتغيير صياغته أو متى يتم تضمينه، سيلاحظ الجميع على الفور حتى لو لم يتم المساس بأي إعدادات للمسؤول.
لا أريد المبالغة في الادعاء دون مرجع التزام (commit reference) محدد، ولكن السبب الأكثر ترجيحًا هو تغيير حديث في النظام الأساسي للنص الافتراضي الذي يتوسع إليه %{header_instructions} لإشعارات الموضوعات التي تتم مراقبتها (على سبيل المثال، إضافة سطر “أجاب شخص ما على موضوع تراقبه.”)، أو لتغيير متى يتم تضمين هذا الجزء في نص البريد الإلكتروني.
كيفية التأكد من مصدره:
%{header_instructions}، فهذا هو مصدر النص التمهيدي الجديد.%{message} / %{context} (أو حتى %{reply_instructions})، سيعيد السلوك “البسيط” السابق.لسوء الحظ، لا يوجد حاليًا زر تبديل (toggle) على مستوى الموقع لهذا. يجب تعديل كل قالب متأثر على حدة، وهذا هو السبب في أن هذا يبدو مفاجئًا ويصعب التحكم فيه عندما تتغير سلوكيات النظام الأساسي.
إذا كنت تستخدم ديسكورس المستضاف (hosted Discourse)، فإن الحل العملي هو مجرد تعديل العدد القليل من القوالب التي يتلقاها المستخدمون بالفعل، بدلاً من تعديلها جميعًا.
تمت إضافة هذه المعاينات قبل بضعة أيام
إذًا، مجرد إزالة %{email_preview} من القوالب سيحل هذه المشكلة؟
غالباً ما يتم كتابة كلمة Watching بأحرف كبيرة للإشارة إلى وظيفة Discourse المحددة.
أنا أراقب (watching) دائماً ظهور مواضيع مثيرة للاهتمام. لكنني أراقب (Watching) مواضيع معينة لأي ردود جديدة.
ثم التتبع، وما إلى ذلك، كما هو مشار إليه في القائمة المنسدلة لحالة إشعار الموضوع.
لأكون صادقًا، لم أكن لأكتشف ذلك. أفهم الأمر، ولكنه غير معتاد بعض الشيء، بطريقة ما.
شكرًا لك، هذا منطقي.
لذا في هذه الحالة، التغيير المفاجئ الذي يراه أندرو يأتي من إضافة %{email_preview} مؤخرًا (PR #36657)، مما يفسر سبب ظهوره بين عشية وضحاها دون أي تغييرات إدارية.
من وجهة نظر المسؤول، تظل نقطة الألم متشابهة في كلتا الحالتين: إنها محتوى مُحقن أساسي في الجزء العلوي من نص البريد الإلكتروني، ولا يوجد حاليًا زر تبديل على مستوى الموقع لتعطيله أو تغيير موضعه. الحل البديل الوحيد اليوم هو تعديل قوالب البريد الإلكتروني المتأثرة وإزالة أو نقل %{email_preview} (تمامًا مثل %{header_instructions}).
بالنسبة للعملاء المستضافين على وجه الخصوص، هذا هو السبب في شعورهم بأن الأمر مفاجئ - فقد تغيرت الإعدادات الافتراضية، ولكن لا يوجد تحكم عالمي مدعوم.
يمكن أيضًا تجاوز سلاسل المعاينة - يمكنك البحث عن السلسلة المحددة أو .preview ثم استخدام Ctrl-F للبحث عن user_notifications للعثور عليها.
من رسالة الالتزام (commit message):
بالنسبة لرسائل البريد الإلكتروني بتنسيق HTML، يتم إخفاء نص المعاينة هذا باستخدام
display: noneلمنعه من الظهور داخل نص البريد الإلكتروني. بالنسبة للنسخة النصية العادية من البريد الإلكتروني، سيظهر داخل نص البريد الإلكتروني.
لمن يظهر هذا الإشعار؟ لا ينبغي أن يظهر.
في برنامج البريد الإلكتروني الخاص بي، أرى في المصدر:
<div> class="email-preview" style="display:none"> <p>Someone sent you a PM.</p> </div>
وهو مخفي في كل من Thunderbird و Gmail (على الويب).
للتذكير، هكذا تظهر معاينة النص الجديدة في Outlook لنظام iOS بالنسبة لي - إنها ليست مجرد مقتطف من صندوق الوارد؛ بل تصبح السطر الأول المرئي المرتبط بالرسالة، وهو ما يتفاعل معه المستخدمون.
يبدو أن هذا يتوافق مع إضافة %{email_preview} مؤخرًا: حتى لو كان القصد منه أن يكون نصًا تمهيديًا مخفيًا لرسائل البريد الإلكتروني بتنسيق HTML، إلا أنه في الواقع مرئي للغاية للمستخدمين (على الأقل في بعض العملاء/مسارات التسليم)، مما يفسر الشكاوى المفاجئة.
من المحتمل أن يكون هذا مقصودًا لأنه يعرض سبب البريد الإلكتروني في معاينة الرسالة. أخمن أنه بدون هذا، فإن معاينة الرسالة ليست مفيدة بشكل عام؟
هذا منطقي، وأنا أتفق على أن وجود بعض النص المعاينة المفيد مفيد بشكل عام.
تبدو المشكلة التي يتفاعل معها المستخدمون (على الأقل في Outlook لنظام التشغيل iOS والعملاء المماثلين) هي أن نص المعاينة هذا لا يؤثر فقط على مقتطف الرسائل الواردة - بل يظهر بصريًا كجزء من نص الرسالة نفسه، ويظهر قبل المحتوى الفعلي. وفي الممارسة العملية، يبدو هذا مكررًا ومزعجًا بدلاً من أن يكون مفيدًا.
هناك أيضًا قدر من التوتر في الصياغة الحالية: الصياغة المجهولة (“شخص ما رد…”) مفيدة من منظور الخصوصية ومشاركة لقطات الشاشة، ولكن في الاستخدام اليومي، هي أقل إفادة من المعاينات التي تظهر فيها معلومات المرسل، حيث يريد المستخدمون بشكل أساسي معرفة من الذي رد وما إذا كان يتطلب اهتمامًا.
لذا، فالأمر يتعلق بأقل من مسألة ما إذا كان يجب أن يوجد نص المعاينة على الإطلاق، وأكثر بمسألة ما إذا كان التنفيذ الحالي، الصارم إلى حد ما، يؤدي إلى تدهور تجربة القراءة في بعض العملاء أو مسارات التسليم. ومن المرجح أن يؤدي النهج الحساس للعميل، أو طريقة مدعومة لإعادة وضعه أو تعطيله، إلى معالجة معظم الشكاوى دون فقدان فائدة المعاينات المحسّنة.
![لقطة شاشة لبريد Outlook لنظام iOS تُظهر عبارة "شخص ما رد على منشورك." تظهر بشكل بارز فوق محتوى الرسالة، مع ظهور البادئات FW/[PM]](https://d11a6trkgmumsb.cloudfront.net/original/4X/9/1/f/91f715903dc7d1007a38043b45ed779ae5c6fe6d.jpeg)