All-in-One Event Calendar انتهى: أخرِج فعالياتك بسلام

لو موقعك لسه شغّال بإضافة All-in-One Event Calendar، فأنت واقف على إضافة مسحوبة من المستودع الرسمي ومش هتاخد تحديث تاني منه. والخبر الحلو إن فعالياتك كلها لسه قاعدة في ووردبريس يستخدم MySQL أو MariaDB، والملفات والصور تبقى خارجها على السيرفر.">قاعدة البيانات بتاعتك، ومحدش شالها.

الشغلانة كلها إنك تعرف هي مخزّنة فين بالظبط، وإيه اللي بيتكسر وقت النقل. تعال نفتح الجداول بنفسنا.

ما حدث بالضبط

شركة Timely أغلقت صفحة الإضافة على wordpress.org في أغسطس 2025 بطلب منها، وبالتالي لم تصل أي تحديثات جديدة من المستودع بعد ذلك. والمواقع التي ما زالت تشغّلها تعمل على كود متوقف.

المشكلة الأخطر أن الإصدار الأخير يضمّ مكتبة iCal تستدعي الدالة create_function()، وهي دالة أزالتها PHP 8 نهائيًا. أي ترقية للسيرفر إلى PHP 8 تعني انهيارًا في مسار الفعاليات.

وعند التثبيت من جديد فإن الإصدار الثالث يقدّم تقويم Timely المستضاف على خدمتها بدل التقويم المحلي داخل موقعك.

تنبيه: خذ نسخة احتياطية (Backup) كاملة من قاعدة البيانات قبل أي خطوة في هذا المقال، وليس نسخة ملفات فقط. الفعاليات المتكررة تعيش في جداول مخصصة، وأي استيراد خاطئ يصعب التراجع عنه يدويًا.

أين تُخزَّن فعالياتك فعليًا

كل فعالية هي مقالة (Post) من نوع المحتوى المخصص (Custom Post Type) باسم ai1ec_event. أما المواعيد وبقية التفاصيل فتعيش في جدول خاص باسم wp_ai1ec_events بصف واحد لكل فعالية.

وهذه هي الحقول التي تهمّك في ذلك الجدول:

• البداية والنهاية مخزَّنتان كطابع زمني (Unix Timestamp) بتوقيت UTC. والحقل timezone_name يحدد المنطقة الزمنية التي أُدخلت بها الفعالية، والقيمة sys.default تعني المنطقة الزمنية للموقع نفسه.
• الحقل recurrence_rules يحمل قاعدة تكرار (RRULE) بمعيار iCalendar. والقواعد التي كتبها محرّر الإضافة تأتي بشكل مثل FREQ=WEEKLY;WKST=MO;BYday=TU,TH; بحرف صغير في كلمة day، وتواريخ الانتهاء تخرج بالشكل UNTIL=20261231T235959Z.
• الحقل exception_dates قائمة تواريخ مستثناة يفصل بينها فاصلة، والحقل exception_rules قد يحمل قاعدة كاملة من التواريخ المستبعدة.
• المكان والعنوان والمدينة وبيانات التواصل والتكلفة ورابط التذاكر أعمدة عادية، ما عدا التكلفة فهي مصفوفة مُسلسَلة (Serialized Array) من PHP.
• الفعاليات المسحوبة من تغذية تقويم خارجية تحمل ical_feed_url ومعرّف ical_uid الخاص بالتغذية، والمواعيد المفردة المنقولة تأخذ نفس المعرّف مع بادئة.

التصنيفات والوسوم موجودة في التصنيفين المخصصين (Taxonomy) events_categories وevents_tags، وألوان التصنيفات في جدول wp_ai1ec_event_category_meta.

أما جدول wp_ai1ec_event_instances فهو مجرد ذاكرة مؤقتة للمواعيد المتوسّعة من القواعد، ويمكنك تجاهله تمامًا لأنه يُعاد بناؤه.

ملاحظة: المكوّنات هنا تتفكك إلى قطع واضحة: مقالة للفعالية، وصف في جدول للمواعيد، وقاعدة تكرار، وتصنيف. أي أداة استيراد تتعامل مع هذه القطع الأربع بشكل منفصل تكون قابلة للمراجعة، وأي أداة تتعامل معها ككتلة واحدة تصعب مراجعتها.

أين تنكسر عملية النقل

هذه الأخطاء لا تظهر في تقرير الاستيراد، بل يكتشفها زوّار موقعك:

1. صفحة التقويم تصبح فارغة. الإضافة كانت ترسم التقويم داخل صفحة فارغة تختارها من إعداداتها، بدون شورت كود أو بلوك في محتوى الصفحة. وبعد تعطيل الإضافة تظهر تلك الصفحة خالية تمامًا، فاحرص على وضع التقويم الجديد فيها بالتحديد.

2. المواعيد تنزاح بساعات. الطوابع الزمنية بتوقيت UTC، فيجب تحويلها بالمنطقة الزمنية الخاصة بالفعالية لا بمنطقة السيرفر. وإلا فمحاضرة مسائية تبدأ عند منتصف الليل.

3. تواريخ انتهاء التكرار تنزلق يومًا كاملًا. القيمة في UNTIL هي لحظة بتوقيت UTC وليست تاريخًا. في منطقة متقدمة على UTC — والقاهرة والرياض كلتاهما كذلك — فإن 20261115T235959Z تقع فعليًا في 16 نوفمبر. اقرأها على أنها آخر تاريخ تبدأ فعاليته قبل تلك اللحظة.

4. فعاليات التغذية الخارجية تتضاعف. إذا استوردت فعاليات قادمة من تغذية ثم اشتركت في نفس التغذية مرة أخرى، ستحصل على نسختين لكل فعالية، إلا إذا حفظت أداة الاستيراد معرّفات ical_uid الأصلية.

5. قواعد الاستثناء تختفي. قليل من التقويمات يفهم EXRULE من الأصل. قاعدة مثل “كل يوم ما عدا الجمعة والسبت” لا تنجو إلا إذا تحولت إلى قاعدة أسبوعية على الأيام المتبقية فقط.

6. الروابط القديمة ترجع 404. طرق عرض التقويم كانت على روابط مثل /calendar/action~month/… وصفحات التصنيفات على /events_categories/your-category/. محركات البحث والمفضّلات لدى زوّارك ما زالت تحمل هذه الروابط.

إلى أين تنقل فعالياتك

المقال الأصلي — وكاتبه يصرّح بأنه يبني إحدى هذه الإضافات — يضع ثلاثة خيارات على الطاولة:

• Open Source Event Calendar: نسخة مفتوحة برخصة GPL من الإضافة الأصلية من تطوير digitaldonkey، وهي الأقرب شكلًا للإضافة القديمة. لكن ملف التعريف الخاص بها يذكر أن قاعدة البيانات غير متوافقة بالكامل مع الإصدار 2.3.4، وأن نقل الفعاليات الموجودة قد يحتاج عملًا يدويًا.
• تقويم Timely المستضاف: خدمة الشركة نفسها، يُدمج داخل موقعك ويعيش على سيرفراتها.
• Beacon Events: إضافة مجانية على wordpress.org يبنيها كاتب المقال الأصلي، وتقرأ الجداول المذكورة أعلاه مباشرة سواء كانت الإضافة القديمة مفعّلة أو مُعطَّلة بالفعل. الفعاليات المتكررة ومزامنة Google Calendar وICS مجانية فيها.

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

في Elementor: لو موقعك قائم على Elementor Pro مع JetEngine، فلديك خيار رابع: حوّل الفعاليات إلى نوع محتوى مخصص من JetEngine مع حقول تاريخ، واعرضها بـ Listing Grid وفلاتر JetSmartFilters. الميزة أنك تتحكم في التصميم بالكامل، والعيب أنك ستبني منطق التكرار ومزامنة ICS بنفسك — وهو بالضبط الجزء الذي يستهلك وقت أي مشروع تقويم.

قائمة تحقّق تصمد على أرض الواقع

اتبع هذا الترتيب بالتحديد، فلكل خطوة سبب:

1. خذ نسخة احتياطية من قاعدة البيانات.
2. ثبّت التقويم الجديد وشغّل الاستيراد بينما الإضافة القديمة لا تزال مفعّلة، ولا تحذف أي شيء بعد.
3. افحص ثلاث حالات على الأقل بنفسك: فعالية متكررة، وفعالية طوال اليوم، وفعالية جاءت من تغذية خارجية.
4. عطّل الإضافة القديمة، وضع التقويم الجديد في نفس الصفحة التي كانت تعرض التقويم، ثم اضغط على عدد من الروابط القديمة.
5. راقب أخطاء 404 في Google Search Console خلال الأسبوع الأول، وأضف تحويلات (Redirects) لما يظهر منها.

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

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

س: هل تختفي فعالياتي إذا حذفت الإضافة؟

ج: البيانات تبقى في جدول wp_ai1ec_events وفي المقالات من نوع ai1ec_event، لكن لا شيء يعرضها بعد تعطيل الإضافة. عدم الظهور ليس حذفًا، والاستيراد لا يزال ممكنًا بعد التعطيل.

س: ما الخطر الأكبر في الاستمرار على الإضافة كما هي؟

ج: ترقية السيرفر إلى PHP 8، لأن مكتبة iCal المضمَّنة تستدعي create_function() المحذوفة من اللغة. أضف إلى ذلك أنها لم تعد تستقبل تحديثات أمنية من المستودع الرسمي.

س: لماذا تتغير مواعيد الفعاليات بعد النقل؟

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

س: هل أنقل الفعاليات القديمة أم المستقبلية فقط؟

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

س: كيف أحافظ على ترتيب صفحاتي في محركات البحث؟

ج: حدّد روابط التقويم والتصنيفات القديمة من السيو تنشئها تلقائيًا، وترسلها أنت عبر Google…">خريطة الموقع أو من تقرير الصفحات في Search Console، ثم حوّلها إلى ما يقابلها في التقويم الجديد بتحويل 301 قبل تعطيل الإضافة بوقت قصير.

الخلاصة

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

خطة النقل الآمنة هي الاستيراد مع بقاء الإضافة القديمة مفعّلة، ثم المراجعة، ثم التعطيل.

قبل ما تلمس أي حاجة، خد باك أب وجرّب على نسخة اختبار. ولو التقويم بتاعك فيه بيانات مش مذكورة فوق، ابعتلي تفاصيلها في التعليقات.

مرجع المقال (بالإنجليزية): All-in-One Event Calendar is gone from wordpress.org: getting your events out
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.