الابتعاد البطيء عن WordPress
لا يزال WordPress يشغّل أربعة من كل عشرة مواقع. لكن حصته تتراجع، وتحمل الإضافات معظم مخاطره، والنزاع في قلب المشروع متجه إلى المحاكمة.
WordPress من أعظم قصص النجاح في المصدر المفتوح. بدأ أداةً للمدونات ثم كبر ليصير البرنامج الذي يقف وراء جزء كبير من الويب، مجاني الاستخدام، حر التعديل، ومعه منظومة من القوالب والإضافات والمضيّفين تتيح لكل من يريد أن ينشر.
وبصفتنا وكالة، بنينا مواقع WordPress ورعيناها سنوات، وما زال كثير من المواقع الجيدة يعمل عليه. وهذه ليست نعيًا. لكن ثلاثة أمور تغيّرت دفعة واحدة، وينبغي لكل شركة تشغّل موقعها على WordPress أن تعرفها كلها: الحصة انعطفت، والخطر يقع في الإضافات، وقيادة المشروع أمضت عامين في نزاع يتجه الآن إلى هيئة محلفين.
الحصة انعطفت
تُظهر W3Techs، التي ترصد التقنية وراء المواقع، أن WordPress صعد طوال معظم عقد: من 23.3 بالمئة من جميع المواقع في مطلع 2015 إلى 43.2 بالمئة في مطلع 2022. ثم استقر. فبلغ 43.6 بالمئة في يناير 2025 و43.0 بالمئة في يناير 2026. وفي 12 أكتوبر 2026 كان الرقم 40.1 بالمئة.
وهذا لا يزال أكثر من جميع أنظمة إدارة المحتوى الأخرى مجتمعةً، ويمثل 58.6 بالمئة من المواقع التي تستطيع W3Techs تحديد نظامها. لكن الاتجاه جديد. فعلى مدى الفترة نفسها نما Shopify من 4.7 إلى 5.4 بالمئة من جميع المواقع، وWix من 3.3 إلى 4.2 بالمئة، بينما واصل Joomla وDrupal الانكماش. وأمثال هذه الإحصاءات تتوقف على المنهج، ولذلك فالاتجاه أهم من الأرقام العشرية.
الخطر يقع في الإضافات
نواة WordPress في حال جيدة. فقد أحصت Patchstack، شركة الأمن التي ترصد المنظومة، ست ثغرات فقط في نواة WordPress في 2025، كلها منخفضة الأولوية.
أما المنظومة المحيطة بها فشأن آخر. أحصت Patchstack في 2025 عدد 11,334 ثغرة جديدة في WordPress، بزيادة 42 بالمئة عن 2024. وكان 91 بالمئة منها في الإضافات و9 بالمئة في القوالب. وفي 46 بالمئة منها لم يكن لدى المطوّر إصلاح جاهز حين أُعلن عن الخلل. أما في الثغرات التي اشتد عليها المهاجمون أكثر من غيرها، فكان الزمن الوسيط من الإفصاح إلى الاستغلال الجماعي خمس ساعات.
وتبيع Patchstack الحماية من هذا بالضبط، ولذلك تستحق صياغتها العناية المعتادة. غير أن النمط بنيوي. فموقع الشركة يشغّل في الغالب إضافات كثيرة من مؤلفين كثيرين، لكل منهم إيقاع تحديثه وجودته ونموذج أعماله. وكل واحدة منها شيفرة على الخادم العام. وإبقاؤها محدّثة مهمة أسبوعية، والأسابيع التي تُهمل فيها هي الأسابيع التي تُحدث الفرق.
عامان من الاضطراب
في سبتمبر 2024، في مؤتمر WordCamp US، حثّ مات مولنويغ (Matt Mullenweg)، الرئيس التنفيذي لشركة Automattic والوجه الأبرز لمشروع WordPress، المجتمع على التوقف عن الدفع لـ WP Engine، إحدى أكبر شركات استضافة WordPress. وفي منشور تلاه وصف الشركة بأنها «سرطان» يصيب WordPress. وكان مولنويغ قد طالب بإتاوة مقابل استخدام العلامة التجارية WordPress: 8 بالمئة من الإيرادات الإجمالية الشهرية لـ WP Engine.
وفي 25 سبتمبر حظرت WordPress.org شركة WP Engine من مواردها، مما عطّل تحديثات الإضافات والقوالب لبعض المواقع التي تستضيفها. وفي أكتوبر رفعت WP Engine دعوى على Automattic ومولنويغ، وسيطرت WordPress.org على Advanced Custom Fields، وهي إضافة شائعة كانت WP Engine تتولى صيانتها. وفي ديسمبر منح قاضٍ اتحادي أمرًا قضائيًا أوليًا أعاد إلى WP Engine وصولها وإضافتها.
وما تلا ذلك أضرّ بالمشروع أكثر مما أضرّ بالمضيِّف. ففي يناير 2025 خفّضت Automattic مساهمتها المتعهَّد بها في WordPress إلى نحو 45 ساعة أسبوعيًا، بعد أن كانت نحو 2,560، لتوجّه مواردها إلى المعركة القانونية. وفي أبريل سرّحت 16 بالمئة من موظفيها، وقال WordPress إن الإصدار 6.8 سيكون آخر إصدار رئيسي في 2025. وفي نهاية مايو تراجعت Automattic وعادت إلى النواة. وفي يونيو أطلقت Linux Foundation مشروع FAIR، وهو مستودع اتحادي للإضافات والقوالب، صُمم بحيث لا يتحكم مصدر واحد في التحديثات.
والقضية بعيدة عن نهايتها. ففي 24 سبتمبر 2026 أحيت القاضية دعاوى مكافحة الاحتكار التي رفعتها WP Engine، وكانت قد ردّتها قبل عام، وانتهت إلى أن Automattic ومولنويغ ليسا مالكين ولا مسجِّلين للعلامات الخاصة بـ WordPress التي ادّعيا ملكيتها. ومعظم الدعاوى المضادة لـ Automattic باقية أيضًا. وحُدّدت محاكمة أمام هيئة محلفين لمدة عشرة أيام في أكتوبر 2027.
ماذا يعني ذلك لشركة تعمل على WordPress
لا شيء من هذا يجعل موقع WordPress غير آمن بين عشية وضحاها. فالتركيب المصان جيدًا بإضافات قليلة ومضيّف جيد وشخص مسمّى مسؤول عن التحديثات يستطيع أن يخدم الشركة سنوات. وبالنسبة إلى مدونة أو موقع تعريفي صغير أو فريق يعرف المنصة جيدًا، فالبقاء غالبًا هو الخيار الحكيم.
ما أظهره العامان الأخيران هو الاعتماد. فتحديثات الموقع وإضافاته والثقة في سلسلة توريده كلها تمر عبر مستودع واحد، وقد اتُّخذت لفترة القرارات المتعلقة بهذا المستودع داخل نزاع تجاري. أضيفوا إلى ذلك منظومة يُعلن فيها عن قرابة نصف الثغرات الجديدة قبل إصلاحها، فلا يعود السؤال هل يعمل WordPress. بل كم من الموقع تريد الشركة أن تقيمه على أجزاء لا تتحكم فيها.
مواقع مبنية ومن فوقها نظام إدارة محتوى
ولهذا تنتقل شركات أكثر إلى المواقع المبنية: موقع يُجمَّع من الشيفرة إلى صفحات سريعة، وفوقه نظام لإدارة المحتوى لمن يحرّرونه. فلا يكون في الموقع العلني إضافات ولا تسجيل دخول إداري يُهاجَم. وكل تغيير يمر عبر عملية بناء تُختبر قبل أن تُنشر. ويقيم المحتوى في ملفات تملكها الشركة، لا في قاعدة بيانات صاغها مورّد.
والمقايضة حقيقية. فالموقع المبني يحتاج إلى مطورين لكل ميزة جديدة، بينما لـ WordPress إضافة لكل شيء تقريبًا. ويجب أن يُبنى التحرير بإتقان، وإلا اشتاق فريق التسويق إلى لوحة الإدارة القديمة في غضون أسبوع.
وهذه هي المشكلة التي صُنع Studio من أجلها. نواته نظام لإدارة المحتوى فوق مواقع مبنية بـ Next.js أو Vite أو TanStack، دون إضافات ودون PHP على الموقع العلني. وكل نشر يُفحص ويُبنى مرة واحدة ويُختبر ويُطلق ويُتحقق منه، ويتراجع من تلقاء نفسه إذا أخفق أي شيء، وكل نشر يودع المحتوى في مستودع الشركة نفسها. ينقر المحررون على كلمة ليغيّروها ويرون الصفحة الحية. Studio في مرحلة الوصول المبكر.
تستطيع الآلات أن تتولى عمليات البناء والاختبار والتراجع. أما ما تقوله الصفحة، وهل هي جيدة بما يكفي لتخرج، فيبقى بيد من يُسألون عنها.
من أين تبدؤون
أحصوا إضافاتكم ودوّنوا من يتولى صيانة كل واحدة، ومتى حُدّثت آخر مرة، وماذا تفعل. وأزيلوا ما لا يحتاج إليه أحد. وتأكدوا من أن كل إضافة، بما فيها المدفوعة، تتلقى تحديثاتها، وأن شخصًا مسمّى يتحقق منها كل أسبوع. وصدّروا محتواكم مرة واحدة وانظروا هل تستطيعون نقله إن اضطررتم.
ثم قرروا عن قصد. أبقوا WordPress حيث يخدمكم، بأجزاء أقل ومالك واضح. وحيث يكون الموقع محوريًا للعمل، فإن موقعًا مبنيًا بنظام لإدارة المحتوى فوقه يستحق حديثًا.
