بناء موقع مواقيت صلاة ثنائي اللغة بووردبريس

عندك تلات تطبيقات مواقيت على الموبايل وكل واحد بيقول ميعاد فجر مختلف؟ ده بالظبط اللي حصل لصاحب مطوّر في الرياض، وكان السبب إن مفيش حد شرح له إن المشكلة في “طريقة الحساب” مش في التطبيقات. المطوّر قرر يبني موقع واحد موثوق بالعربي والإنجليزي على ووردبريس، والدروس اللي طلع بيها تنفع أي حد بيبني موقع عربي يعتمد على بيانات خارجية.

المشكلة: المواقيت حسابات فلكية لا جداول ثابتة

مواقيت الصلاة تُحسب من موقع الشمس بالنسبة لإحداثيات مكان معين. الفجر والعشاء تحديداً يعتمدان على زاوية انخفاض الشمس تحت الأفق، وكل جهة تعتمد زاوية مختلفة:

فرق درجة أو درجتين في الزاوية يتحول إلى 10–20 دقيقة على الساعة. لذلك اختلفت التطبيقات الثلاثة: كل واحد يستخدم طريقة مختلفة دون أن يخبرك. اختيار الطريقة المناسبة لجمهورك هو القرار الأهم في أي منتج من هذا النوع.

لماذا أم القرى للرياض تحديداً؟

طريقة أم القرى (Umm al-Qura Method) هي الطريقة الرسمية في المملكة، وتتبعها المساجد والصحف والجهات الحكومية. أي طريقة أخرى لن تكون “قريبة”، بل ستتعارض علناً مع الأذان في كل مساجد المدينة.

انتبه لتفصيلة مهمة: أم القرى لا تحسب العشاء بزاوية، بل بفاصل ثابت بعد المغرب. لو وضعت زاوية للعشاء في الكود، سيكون جدولك خاطئاً طوال العام.

لو جمهورك في مصر: استخدم طريقة الهيئة المصرية العامة للمساحة (19.5° / 17.5°). وفي الخليج خارج السعودية راجع الطريقة المعتمدة في كل دولة؛ الإمارات والكويت وقطر لها إعدادات خاصة بها.

البنية التقنية: ووردبريس وطبقة مخصصة صغيرة

اختار المطوّر ووردبريس لأسباب عملية: أدوات سيو ناضجة، ومحرر حقيقي للمقالات ثنائية اللغة، واستضافة رخيصة وموثوقة. لكن ووردبريس لا يحسب المواقيت، فأضاف فوقه إضافة صغيرة من ثلاثة أجزاء:

1. جلب البيانات بمهمة مجدولة لا مع كل زيارة

مهمة مجدولة عبر الشيفرة الخبيثة تلقائيًا بعد كل تنظيف.">WP-Cron تستدعي Aladhan API مرة يومياً بطريقة أم القرى وإحداثيات الرياض (24.7136 شمالاً، 46.6753 شرقاً). تُخزَّن النتيجة كـ بيانات مؤقتة (الإضافات في السيرفر.">قاعدة البيانات لمدة محددة ثم تنتهي صلاحيتها، لكن المنتهي منها قد يبقى متراكمًا في جدول الإعدادات ويحتاج حذفًا دوريًا لتخفيف القاعدة.">Transients) وكبيانات وصفية منظمة، فلا تلمس الصفحة الـ API أبداً عند زيارتها.

هذا هيكل مبسط للفكرة (ليس كود الموقع الأصلي)؛ في Aladhan رقم الطريقة 4 هو أم القرى و5 هو الهيئة المصرية:

add_action( 'acms_fetch_prayer_times', function () {
    $url = add_query_arg( array(
        'latitude'  => '24.7136',
        'longitude' => '46.6753',
        'method'    => 4, // 4 = Umm al-Qura, 5 = Egyptian General Authority
    ), 'https://api.aladhan.com/v1/timings' );

    $res = wp_remote_get( $url, array( 'timeout' => 10 ) );
    if ( is_wp_error( $res ) || 200 !== wp_remote_retrieve_response_code( $res ) ) {
        return; // keep yesterday's cached data instead of showing nothing
    }
    $data = json_decode( wp_remote_retrieve_body( $res ), true );
    set_transient( 'acms_prayer_times_today', $data['data']['timings'], DAY_IN_SECONDS );
} );

if ( ! wp_next_scheduled( 'acms_fetch_prayer_times' ) ) {
    wp_schedule_event( strtotime( 'tomorrow 00:05' ), 'daily', 'acms_fetch_prayer_times' );
}

نصيحة: WP-Cron لا يعمل إلا مع زيارات الموقع، فاربطه بكرون حقيقي من لوحة الاستضافة حتى لا تتأخر بيانات الفجر في ليلة هادئة.

2. التحقق المزدوج قبل أن يرى الزائر خطأ

فحص آلي يقارن الأوقات المجلوبة بتطبيق ثانٍ مستقل لقواعد أم القرى. إذا انحرف الفجر أو العشاء أكثر من دقيقتين تقريباً، يصل تنبيه للمطوّر قبل أن يلاحظ الزوار. هذا نمط يستحق النسخ في أي موقع يعتمد على API خارجي: لا تثق بمصدر واحد في بيانات يُحكم عليك بدقتها.

3. العرض: بلوك واحد خفيف بلا منشئ صفحات

بلوك مخصص في القالب في Elementor تصميم محفوظ يُعاد استخدامه، مثل رأس الموقع أو التذييل أو صفحة المقالة أو صفحة المنتج. تصممه مرة وتحدد شروط ظهوره، فيُطبَّق على كل…">القالب يعرض جدول اليوم والتاريخ الهجري وعداداً تنازلياً للصلاة القادمة، كـ HTML يولّده الخادم. لا منشئ صفحات ولا إضافة سلايدر بحجم 2 ميجابايت.

عزل منطق المواقيت في إضافة واحدة كان قراراً مقصوداً: هذا النوع من الكود يفسد بصمت إن دُفن داخل قالب ضخم، بينما يسهل اختباره وتخزينه مؤقتاً حين يكون مستقلاً.

في Elementor: يمكنك عرض البيانات نفسها دون بلوك مخصص؛ سجّل الأوقات كحقول عبر JetEngine أو كخيار في قاعدة البيانات، ثم اعرضها بـ Dynamic Tags داخل ودجت Heading أو Table. فقط أبقِ الجلب والتخزين في الإضافة، والعرض في Elementor.

تحديات ثنائية اللغة: RTL وتشكيل الحروف

اتجاه الصفحة: توقف عن كتابة left وright

الصفحات العربية تستخدم dir="rtl"، والدرس الأهم كان استبدال margin-left وmargin-right بـ خصائص CSS المنطقية (Logical Properties) في كل مكان:

/* Works in both Arabic (RTL) and English (LTR) */
.prayer-row {
  margin-inline-start: 1rem;
  padding-inline-end: 0.75rem;
  border-inline-start: 3px solid var(--accent);
}

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

الحروف المنفصلة في صور المشاركة

الموقع يولّد صورة مشاركة لكل يوم. النسخة الأولى أظهرت العربية بحروف منفصلة، كل حرف بشكله المستقل، لأن أداة الرسم لم تكن تدعم تشكيل الحروف (Text Shaping). العربية تحتاج أن يتغير شكل الحرف حسب جيرانه، إضافة إلى ترتيب صحيح من اليمين لليسار.

الحل كان تغيير أداة توليد الصور إلى مكتبة تدعم التشكيل فعلاً، ثم مراجعة عينة من الصور باللغتين قبل الإطلاق. إن كنت تولّد صوراً بـ PHP عبر GD فستواجه المشكلة نفسها؛ Imagick المبني مع Pango أو خدمة توليد خارجية خيار أكثر أماناً.

الأرقام: هندية أم عربية؟

بعض الزوار يتوقعون الأرقام الهندية (٠١٢٣٤٥٦٧٨٩) وآخرون اعتادوا الأرقام العربية الغربية (0–9). بدل التخمين، أضاف الموقع زر تبديل. حل بسيط يحترم جمهوراً متنوعاً بين مصر والخليج.

السيو والأداء

• احسب مسبقاً، لا لحظياً: جدول كل يوم يُولَّد مرة واحدة ويُقدَّم كـ HTML مخزن في الكاش. عرض الشهر استعلام واحد على بيانات مخزنة، لا 30 طلب API.
• رابط لكل لغة: النسخة الإنجليزية تحت /en/ والعربية في الجذر، مع وسوم hreflang حتى لا تُعامل كمحتوى مكرر.
• خرائط موقع منفصلة وبيانات منظمة (Schema): خريطة لكل لغة، وSchema للجدول اليومي لزيادة فرص الظهور كنتائج غنية.
• Core Web Vitals: HTML من الخادم، وخطوط النظام مع بديل يدعم العربية، وتحميل كسول للصور، وبلا JavaScript يعطل العرض. النتيجة LCP في المنطقة الخضراء على الهواتف المتوسطة، وهي ما يستخدمه أغلب الجمهور فعلاً.

الأسئلة الشائعة

س: لماذا تختلف مواقيت الصلاة بين التطبيقات؟
ج: لأن كل تطبيق قد يستخدم طريقة حساب مختلفة بزوايا مختلفة للفجر والعشاء، وفرق درجة واحدة قد يغير الوقت بعشر دقائق أو أكثر.

س: ما طريقة الحساب المناسبة لموقع يستهدف مصر؟
ج: طريقة الهيئة المصرية العامة للمساحة، بزاوية 19.5 درجة للفجر و17.5 درجة للعشاء، وهي رقم 5 في Aladhan API.

س: هل أستدعي الـ API في كل زيارة للصفحة؟
ج: لا. اجلب البيانات مرة يومياً بمهمة مجدولة وخزّنها كـ Transients أو بيانات وصفية، فتصبح الصفحة أسرع ولا تتوقف إن تعطل الـ API.

س: كيف أكتب CSS يعمل في العربية والإنجليزية معاً؟
ج: استخدم الخصائص المنطقية مثل margin-inline-start وpadding-inline-end بدلاً من left وright، فينعكس التصميم تلقائياً مع اتجاه الصفحة.

الخلاصة

الدرس الأكبر هنا مش تقني: الدقة هي المنتج نفسه، وجدول جميل بطريقة حساب غلط أسوأ من جدول بسيط بالطريقة الصح. اختار مصدر بياناتك صح، خزّنه بذكاء، وابنِ موقعك قطعة قطعة: إضافة للبيانات، وقالب للعرض، وRTL من أول سطر CSS.

مرجع المقال (بالإنجليزية): How I built a bilingual prayer-times site for Riyadh (WordPress + Umm al-Qura API)
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.