انقلوا موقعكم المبني بـ PHP إلى حزمة تقنية حديثة وأكثر أمانًا
ننقل مواقع PHP وWordPress وMagento القديمة إلى حزمة تقنية حديثة تخضع لصيانة نشطة: ترحيل المحتوى والبيانات بالبرمجة النصية، وإعادة توجيه كل رابط قديم، والحفاظ على الترتيب في محركات البحث، دون بيئة تشغيل PHP تحتاج إلى ترقيع.
ابدأوا الآنلم يكن عام 2026 رحيمًا بمواقع PHP
تشغّل PHP نحو 69% من المواقع الإلكترونية التي تُعرف لغتها من جهة الخادم (W3Techs، أكتوبر 2026)، لذا تتحول كل ثغرة في PHP أو منصاتها الشائعة إلى حدث واسع النطاق. إليكم ثلاثًا منها خلال الشهرين الماضيين:
21 أكتوبر 2026
PHP2Shell: ثغرتان حرجتان في PHP نفسها
تتيح الثغرتان CVE-2026-109618 وCVE-2026-109619 تنفيذ كود عن بُعد دون مصادقة عبر طلب HTTP عادي، قبل تشغيل أي كود للتطبيق، على كل إصدارات PHP منذ 5.4. ولا توجد إصدارات مُصلَحة إلا لإصدار PHP 8.2 وما بعده. ويؤكد مشروع PHP عدم وجود إجراءات تخفيف كاملة، وأن التحديث هو الخيار الآمن الوحيد. وبدأت محاولات الاستغلال خلال ساعات من الإفصاح.
أكتوبر 2026
استغلال إضافة WordPress لرفع ملفات دون مصادقة
رصدت Patchstack استغلالًا فعليًا لثغرة حرجة في Bricksforge (CVE-2026-85097) منذ 7 أكتوبر: يرفع المهاجمون دون مصادقة ملفات من اختيارهم ويشغّلون الكود الخاص بهم على الموقع. وتُعد ثغرات الإضافات من هذا النوع أكثر الطرق شيوعًا لاختراق مواقع WordPress، ويستمر استغلالها لفترة طويلة بعد توفر الإصلاح.
سبتمبر 2026
ثغرة يوم الصفر في Magento أصابت المتاجر قبل الإصلاح العاجل
الثغرة CVE-2026-75650، التي أطلقت عليها Sansec اسم StyleSmuggler، هي ثغرة تنفيذ كود عن بُعد دون مصادقة بدرجة CVSS 10.0 في Adobe Commerce وMagento Open Source. وتأكدت الهجمات منذ 4 سبتمبر، أي قبل ثلاثة أيام من إصدار Adobe الإصلاح العاجل.
المصادر: ملاحظات إصدار مشروع PHP (21 أكتوبر 2026)، وCisco Talos، وSecurityWeek نقلًا عن Patchstack، وSOC Prime نقلًا عن Sansec وAdobe، وW3Techs.
موقعكم لا يزال يعمل، وهذه هي المشكلة بالضبط. فهو يعمل على إصدار PHP توقفت تحديثاته الأمنية، أو على إضافات لا يصونها أحد، أو على قاعدة كود مخصصة لم يفهمها سوى مطوّر غادر منذ زمن. وكل تحذير أمني جديد يعني ترقيعًا طارئًا آخر، إن وُجد ترقيع أصلًا. وقد أظهرت ثغرات PHP2Shell في أكتوبر 2026 مدى سرعة تدهور الأمور: بدأ الاستغلال خلال ساعات، ولم تحصل المواقع العاملة على PHP 8.1 أو أقدم على أي إصلاح.
هنا يأتي دورنا. نبدأ بالتقييم ونقدّم لكم إجابة صريحة: أحيانًا يكفي إصدار PHP مدعوم مع تعزيز الحماية، ونقول ذلك بوضوح. وعندما لا يكفي، نعيد البناء على حزمة تقنية حديثة تخضع لصيانة نشطة: استضافة سحابية مُدارة، ونظام إدارة محتوى Headless (CMS) سيحبه محرّروكم فعلًا، وخط نشر يتضمن تحديثات آلية للتبعيات وجدار حماية لتطبيقات الويب وفحوصات أمنية مع كل إصدار. وننقل المحتوى والوسائط والمستخدمين والطلبات بالبرمجة النصية، ونتحقق منها مقابل الموقع القديم. ويحصل كل رابط قديم على إعادة توجيه دائمة، فتتعامل محركات البحث مع الموقع الجديد على أنه الموقع نفسه.
وقد فعلنا ذلك من قبل: استُبدل موقع WordPress القديم وإضافاته لدى Makro HORECA Academy بمنصة مصممة لغرضها، واستُبدل نظام الحجز القديم لدى GM Tour بنظام حديث. وكلتاهما منصتان هندسهما فريقنا بالكامل، ويملك العميلان النتيجة.
القدرات الرئيسية
قدرات ملموسة نقدّمها في هذا التعاون، لا مجرد شعارات.
لا شيء يحتاج إلى ترقيع
الانتقال من PHP يُخرج بيئة تشغيل PHP، وكل ثغراتها، من نطاق الهجوم على أنظمتكم. والبديل يأتي مع تحديثات تلقائية للتبعيات، وجدار حماية لتطبيقات الويب، وإدارة آمنة للأسرار، ومراجعة أمنية مع كل إصدار.
حزمة تقنية يسهل إيجاد مطورين لها
حزمة تقنية شائعة وموثّقة جيدًا على سحابة مُدارة، مع CI/CD واختبارات آلية، فلا يعود موقعكم معتمدًا على المستقل الوحيد الذي يفهم الكود القديم.
صفحات أسرع وترتيب محفوظ
صفحات تُعرض من الخادم ومحسّنة لمعايير Core Web Vitals، وخريطة إعادة توجيه لكل رابط قديم، ونقل البيانات الوصفية والبيانات المنظمة، ومقارنة تقارير الزحف قبل الانتقال وبعده.
نقل آلي بالبرمجة لا إعادة إدخال يدوي
الصفحات والمقالات والوسائط والمستخدمون والطلبات تُصدَّر من WordPress أو Drupal أو Magento أو Laravel أو تطبيق PHP مخصص، ثم تُحمَّل في المنصة الجديدة وتُطابَق مع الموقع القديم، مع تجربة كاملة قبل الإطلاق.
التقنيات التي نستخدمها
أدوات ومنصات مجرّبة نستخدمها حيث تناسب، نختارها وفق المشكلة لا وفق الموضة التقنية.
نهجنا
مسار واضح من المشكلة إلى بيئة الإنتاج، يُكيَّف لكل خدمة ولا يُفرض قالبًا واحدًا على الجميع.
المراجعة
نراجع تطبيق PHP الحالي لديكم: الكود وقاعدة البيانات والتكاملات والاستضافة، ونحدد ما يجب نقله.
النقل
ننقل التطبيق إلى حزمة تقنية حديثة تخضع لصيانة نشطة، مع الإبقاء على ما يعمل وإصلاح ما لا يعمل.
الترحيل
تُنقل قاعدة بياناتكم ومحتواكم ووسائطكم بالبرمجة، مع مطابقة الأعداد والعينات مع النظام القديم.
النشر
إعداد استضافة سحابية مُدارة وخطوط CI/CD والبيئات، ثم الانتقال مع إعادة التوجيه وإبقاء الموقع القديم في وضع الاحتياط.
التأمين
تحصين وجدار حماية لتطبيقات الويب وتحديثات للاعتماديات ومراقبة مع تنبيهات، لتعرفوا بالمشكلة قبل مستخدميكم.
الدعم
دعم مُدار باتفاقيات مستوى خدمة (SLA) واضحة، أو تسليم موثّق لفريقكم. القرار لكم.
ميزانيات بجميع الأحجام
نعمل مع ميزانيات بمختلف المستويات. يكيّف الفريق النطاق والحجم ونموذج التعاون وفق ما يمكنكم إنفاقه، دون التنازل عن معايير جودة البناء.
المؤسسات
فرق تسليم متكاملة للمنصات المعقدة، مع مستوى الأمن والامتثال والانضباط الإجرائي الذي تتوقعه المؤسسات الكبرى.
الفرق النامية
نماذج تعاون مرنة تتوسّع معكم. أضيفوا قدرات عند الحاجة وقلّصوها حين لا تحتاجون إليها، دون إعادة التفاوض من البداية.
الشركات الصغيرة والناشئة
مشاريع مركّزة ورشيقة تُتقن الأساسيات. نساعدكم على تقليص النطاق لا الجودة، لتُطلقوا منتجًا متينًا حتى بميزانية متواضعة.
لماذا يهم ذلك
نتائج نسعى إليها، قابلة للقياس في جودة المنتج والسرعة والأثر على الأعمال.
إجابة صريحة أولًا
إذا كانت ترقية PHP وتحصينه كافيين لحمايتكم، نخبركم بذلك ونتوقف عند هذا الحد. نوصي بالترحيل حين يكون المسار الأقل تكلفة، لا بشكل تلقائي.
معايير المؤسسات لأي موقع
مراجعات الأمن والاختبار وانضباط الإصدارات نفسها التي نقدمها لأكبر المؤسسات في تايلاند، مطبّقة على الموقع الإلكتروني لشركتكم أو متجركم الإلكتروني.
أنظمة قديمة استبدلناها فعلًا
استُبدل موقع WordPress الخاص بـ Makro HORECA Academy ونظام الحجز لدى GM Tour بمنصات هندسناها بالكامل. نعرف أين تتعثر عمليات الترحيل لأننا نفذناها.
كل شيء ملك لكم
الكود في مستودعاتكم، والبنية التحتية في حساباتكم، والبيانات في قاعدة بياناتكم. لا ارتباط بنا ولا بمورّد إضافات ولا بخطة استضافة.
الأسئلة الشائعة
إجابات مباشرة عن طريقة عملنا.
هل يجب أن نترك PHP، أم يمكنكم فقط تأمين ما لدينا؟
ليس دائمًا. نقيّم أولًا إصدار PHP وإطار العمل والإضافات والاستضافة لديكم. إذا كان إصدار PHP مدعوم مع التحصين كافيًا لحمايتكم، فسنخبركم بذلك. لكن إصدار PHP 8.1 وما قبله لم يعد يتلقى تحديثات من مشروع PHP، وينتهي الدعم الأمني لإصدار PHP 8.2 في 31 ديسمبر 2026، والإضافات المهجورة لا تُصلح أبدًا، لذا فإن الترحيل بالنسبة إلى كثير من المواقع القديمة أقل تكلفة من عام آخر من الترقيعات الطارئة.
هل سنخسر ترتيبنا في Google؟
لا ينبغي ذلك إذا نُفّذ الترحيل بشكل صحيح. نربط كل رابط قديم بموقعه الجديد عبر عمليات إعادة توجيه دائمة، وننقل العناوين والبيانات الوصفية والبيانات المنظمة، ونقارن تقارير الزحف قبل الانتقال وبعده. والصفحات الأسرع تساعد الترتيب عادةً بدلًا من أن تضرّه.
ماذا يحدث لمحتوانا ومستخدمينا وطلباتنا؟
تنتقل معكم. نكتب نصوصًا برمجية للتصدير من WordPress أو Drupal أو Magento أو Laravel أو قاعدة بيانات مخصصة، ونحمّلها إلى المنصة الجديدة، ونتحقق من الأعداد والعيّنات مقارنةً بالموقع القديم. ويحتفظ المحررون بنظام إدارة محتوى (CMS)، عادةً من نوع Headless، فلا يصبح النشر أصعب.
كم يستغرق الترحيل؟
يعتمد ذلك على النطاق، ولهذا نحدد النطاق أولًا. ينتقل موقع المحتوى عادةً خلال أسابيع؛ أما المنصة ذات منطق الأعمال المخصص والتكاملات وحسابات المستخدمين فتستغرق بضعة أشهر. يعمل الموقعان القديم والجديد بالتوازي حتى لحظة الانتقال، فلا توجد مخاطر التحول المفاجئ دفعة واحدة.
من يملك الكود ويستضيف الموقع الجديد؟
أنتم. ملكية كاملة للكود المصدري والبنية التحتية والبيانات، مع التوثيق والتسليم كجزء أساسي من العمل. يمكننا تشغيله نيابةً عنكم بموجب اتفاقية دعم مُدار تشمل المراقبة والتحديثات واتفاقيات مستوى خدمة (SLA) واضحة، أو تسليمه إلى فريقكم.
كم تبلغ تكلفة الترحيل؟
يعتمد ذلك على حجم الأجزاء المخصصة من الموقع، وكمية المحتوى والبيانات المطلوب نقلها، والتكاملات الموجودة، ولهذا نبدأ بالتقييم. تحصلون على خطة محددة النطاق وتقدير قبل الالتزام بأي شيء، وبالنسبة إلى موقع عالق على حزمة تقنية غير مدعومة، يكون الترحيل عادةً أقل تكلفة من عام آخر من الترقيعات الطارئة.