لما إيميل من Magento يوصل باسم متجر غلط، تغيير اللوغو بملف التصميم لحاله ما بحل المشكلة. الإشعار النهائي بجمّع عادةً بين قالب للـ body، والـ header، والـ footer، والمتغيرات (variables)، والإعدادات المحددة لـ store view معيّن.
بلّشوا بـ Migma بمراجعة شو لازم يشوف العميل: هوية الـ brand، اللغة، وجهة الدعم (support destination)، والهدف من الرسالة. بعدين خلّوا الشخص المسؤول عن Adobe Commerce يتبع كيف عم تترتّب وتتجمّع هالعناصر بالإشعار الفعلي للمتجر. هيك بتربطوا المراجعة الإبداعية بالإعدادات (configuration) يلي بتحدّد شكل الإيميل النهائي.
هيدا الدليل منشور من Migma. بيقدّم workflow تحريري للـ troubleshooting وحل المشاكل، ومش integration تقني مباشر مع Magento أو إجراء deployment رسمي. تمّت مراجعة إرشادات Adobe الخاصة بالـ templates بتاريخ 20 تشرين الأول/أكتوبر 2026.
حددوا المتجر والرسالة بدقة
بلّشوا بمثال واحد في مشكلة. سجّلوا الـ store view، نوع الإشعار (notification type)، الهوية المتوقعة، وين صار الاختلاف، ووقت إرسال الرسالة. استخدموا عيّنة محذوف منها أي بيانات عملاء حساسة بدل مشاركة تفاصيل مش ضرورية.
مثلاً، متجر افتراضي عنده واجهة إنجليزية للمعدات وـ outlet منفصل بلغة محلية. ممكن إيميل الترحيب (welcome email) الخاص بالـ outlet يكون فيه نص الـ body صح، بس كبسة الـ header تاخد المستخدم على متجر المعدات الأساسي. هيدي مشكلة مختلفة تماماً عن لوغو ناقص أو وصف منتج مش مترجم.
وصفوا المشكلة من منظور القارئ. عبارة متل "الـ header بيفتح المتجر التاني" بتعطي الفريق التقني خطوة واضحة يرجع يعيدها ويفحصها (reproducible check). بينما "الـ branding طالع غلط" بتضل واسعة وفيها احتمالات كتيرة.
راجعوا تركيبة الرسالة كاملة
بتوضح وثائق Adobe للـ custom email templates إنو رسائل النظام بتجمع بين body template وقوالب للـ header والـ footer. كمان بتشرح كيف بصير التخصيص على مستوى الـ website أو الـ store أو الـ store-view scope، وضرورة ربط الـ custom template الصح بالإعدادات.
هيدا الشي بيعني إنو معاينة الـ body لحاله مش كافية لتأكيد هوية الرسالة كاملة. اسألوا المسؤول عن التطبيق أي header و footer محددين، وشو الـ configuration يلي عم يختار الـ body لهيدا الإشعار. واحتفظوا بكل مراجع الـ templates بسجل المراجعة.
بالمراجعة الإبداعية، افحصوا هالعناصر سوا:
| العنصر | سؤال من جهة العميل | الإثبات المطلوب |
|---|---|---|
| Header | أي brand عم يحكي، ولوين بيودي الرابط؟ | الـ header معبى بالبيانات والوجهة الفعلية للرابط |
| Body | هل الهدف واللغة مناسبين لهيدا المتجر؟ | الـ template المعتمد ونموذج معلومات موافق عليه |
| Footer | هل بيقدر القارئ يوصل للفريق الصح؟ | روابط شغالة للدعم ولمعلومات المتجر |
| Variables | هل القيم الخاصة بالمتجر مطابقة للرسالة؟ | مثال معبى ببيانات من الـ store view المعني |
هيدي أسئلة قبول ومطابقة (acceptance questions) ومش تعليمات لتغيير إعدادات الـ production مباشرة. مسؤول Commerce لازم يتبع الإجراءات الرسمية المعتمدة لنسختكم.
ابنوا الهوية المطلوبة على Migma
تأكدوا من مراجعة سياق الـ brand على Migma قبل ما تبدوا بالمسودة. راجعوا اللوغو، الألوان، الخطوط، نبرة الصوت (tone of voice)، المراجع المحفوظة، وبيانات الشركة المعتمدة. إذا بنيتوا التصميم على سياق براند تاني، ممكن تخلقوا مشكلة جديدة بوقت عم تحاولوا تحلوا فيه المشكلة الأولى.
حددوا brief واضح لكل متجر داخل المسودة. بالنسبة للـ outlet الافتراضي، حددوا اللغة المعتمدة، وجهة الدعم، والصفحة الرئيسية. وضّحوا شو العناصر يلي رح يزودها الفريق التقني وشو النصوص يلي لازم تضل متل ما هي. وما تنقلوا أبداً بيانات حقيقية لعملاء بقلب برومبت تصميم عام.
صمموا مرجع بصري كامل بيبيّن بوضوح العلاقة بين الـ header والـ body والـ footer. وإذا كان الـ implementation النهائي على Commerce بجمّع هالأجزاء بشكل منفصل، وثّقوا آلية الـ handoff. هيدا الـ workflow ما بيفترض إنو تنزيل ملف HTML واحد رح يضبط إعدادات كل جزء من الـ template بـ Magento تلقائياً.
انتبهوا للمتغيرات (variables) وقت الـ implementation
بتنبّه Adobe من تعديل أو مسح الأكواد الموجودة بين أقواس مزدوجة {{ }} وقت تعديل محتوى الـ template. هيدا خط فاصل أساسي بين النص يلي تمت مراجعته وبين القيم الديناميكية (dynamic values) بالمنصة.
اطلبوا من الشخص التقني يحدد الـ variables والـ directives الخاصة بالإشعار. تعديل المصمم للجملة المحيطة ما لازم يغيّر بالغلط كود رقم الطلب (order number)، أو رابط المتجر، أو أي تعبير ديناميكي تاني. استخدموا قيم تجريبية معتمدة لتتأكدوا إنو صياغة الجمل مضبوطة لما تتعَبّى هالحقول.
إذا كان في متغير ناقص أو عم يظهر بطريقة غير متوقعة، اتركوا حلها لمسؤول الـ implementation. ما تخترعوا syntax من منصة تانية. إنو الـ placeholder شكله مرتب بالتصميم مش دليل إنو الإشعار الحي رح يطلّع البيانات صح.
قارنوا النتيجة المجهّزة بالمرجع
اعتمدوا على دليل التصدير من Migma لمسار الـ handoff الإبداعي المدعوم، وراجعوا النتيجة بالمنصة المستهدفة. المسؤول لازم يتأكد من الـ custom templates المختارة ومن الـ scope؛ مجرد حفظ الـ template ما بيعني أبداً إنو الـ store view عم يستخدمه.
بالنسبة للـ outlet الافتراضي، جربوا نفس سيناريو إيميل الترحيب ببيانات فحص تجريبية. تأكدوا إنو الـ header بيفتح الـ outlet، ونصوص الـ body باللغة المطلوبة، والـ footer بيوصّل لجهة الدعم الصح. وبعدها افحصوا متجر تاني للمقارنة، لتتأكدوا إنو ما صار أي تعديل مشترك غير مقصود.
هيدي الخطوة مهمة خصوصاً لما يبين التعديل شغال بالمعاينة بس الإيميل اللي بيوصل فعلياً يضل مختلف. تتبعوا الإعدادات الفعلية والرسالة الناتجة قبل ما ترجعوا تعيدوا التصميم من الأول.
كفّوا بفحوصات الـ inbox والمسؤوليات
شغّلوا Email Preflight على تصميم Migma وعالجوا التنبيهات الأساسية. افحصوا الرسالة النهائية المولّدة من المنصة بإيميلات فعلية (inboxes)، بما فيها الشاشات الصغيرة والـ dark mode إذا الفريق بيقدر يختبرها. العرض (rendering) بيختلف بين إيميل كلينت وتاني؛ ما توعدوا بنتيجة متطابقة 100%.
وثّقوا كل شي سوا: الـ store view المعني، مراجع الـ templates، نسخة Migma المعتمدة، سيناريو الفحص، الروابط النهائية، واسم المراجع. وضيفوا أي قيود تقنية بعد ما انحلت. النتيجة لازم توضّح شو بيشوف العميل ومين المسؤول تقنياً عن كل جزء.
بيقدّم دليل Brevo لأتمتة Magento سياق أوسع لإدارة إيميلات المتاجر المتعددة. بس هيدا الـ workflow مركز على نقطة محددة: التأكد إنو الإشعار النهائي طالع بالهوية الصح للمتجر بدون أي لبس. بلّشوا بمرجع واحد مراجع على Migma، وتأكدوا من تركيبة الرسالة كاملة قبل ما تطبقوا التغيير على باقي المتاجر.
Frequently Asked Questions
ليش ممكن نص الـ body يكون صح وهوية المتجر غلط؟
حسب توثيق Adobe، الرسالة بتتركب من قوالب منفصلة للـ body والـ header والـ footer، مع إعدادات على مستويات مختلفة للمتاجر (store scopes). لهيك لازم تراجعوا الرسالة الكاملة بعد تجميعها مع الـ configuration، مش الـ body لحاله.
هل حفظ الـ custom template بيعني إنو الـ store view صار عم يستخدمه؟
أكيد لا. إرشادات Adobe بتوضح ضرورة تحديث الإعدادات (configuration) لاختيار القالب المخصص. اطلبوا من مسؤول Commerce يتأكد من التعيين الفعلي للإشعار والـ scope المطلوب.
هل تصدير التصميم من Migma بيضبط إعدادات كل أجزاء إيميل Magento؟
هيدا الـ workflow ما بيقدم هالادعاء. استخدموا Migma للمرجع الإبداعي المعتمد ولتسليم كود الـ HTML، بينما مسؤول Commerce بيقوم بربط الـ header، والـ body، والـ footer، والـ variables، والإعدادات داخل المنصة.
شو لازم يتضمن سجل قبول ومطابقة هوية المتجر؟
سجّلوا الـ store view، نوع الإشعار، مراجع الـ templates المختارة، نسخة Migma المعتمدة، سيناريو الفحص المعبى بالبيانات، الروابط النهائية الشغالة، واسم المراجع. ضيفوا أي قيود ما انحلت، وافحصوا متجر مقارن للتأكد من عدم تأثر الإعدادات المشتركة.