أضاف ووردبريس خلال السنوات الأخيرة عددًا من الواجهات التي غيرت تدريجيًا طريقة تطوير القوالب والإضافات، لكن Abilities API تختلف قليلًا؛ لأنها لا تقدم للمطور وظيفة جديدة فحسب، بل تحاول تنظيم الطريقة التي يعرّف بها ووردبريس ما الذي يستطيع فعله.
ظهرت Abilities API في نواة WordPress 6.9، ثم توسعت في WordPress 7.0 لتشمل جانب JavaScript أيضًا. وتزداد أهميتها مع أدوات الأتمتة ووكلاء الذكاء الاصطناعي، لأنها توفر طريقة موحدة يمكن من خلالها تعريف وظائف الموقع، ومدخلاتها ومخرجاتها، والصلاحيات المطلوبة لتنفيذها.
لكن لماذا احتاج ووردبريس إلى واجهة جديدة من الأساس؟
بدل أن تبقى الوظيفة مجرد دالة مخفية داخل ملفات إحدى الإضافات، يمكن تسجيلها كـAbility لها اسم ووصف ومدخلات ومخرجات وصلاحيات معروفة.
لا يتوقف التعريف عند ذلك. يمكن تحديد شكل البيانات باستخدام JSON Schema، وتحديد الصلاحيات المطلوبة، وتصنيف الـAbility، وإضافة معلومات أخرى تساعد الأنظمة التي تكتشفها على فهم طريقة استخدامها.
وبذلك لا يرى النظام الآخر اسمًا غامضًا لدالة PHP، بل يستطيع أن يفهم بصورة منظمة: ماذا تفعل الوظيفة؟ ماذا تحتاج؟ ماذا ستعيد؟ وهل يسمح للمستخدم الحالي بتنفيذها؟ وهذا هو الفرق الأساسي بين Ability وبين كتابة دالة PHP عادية. الدالة التقليدية تنفذ المهمة، بينما Ability تجعل هذه المهمة موصوفة وقابلة للاكتشاف والتعامل معها برمجيًا.
ويمكن للمطور إتاحة Ability عبر REST عندما يريد أن يستطيع عميل خارجي الوصول إليها. لذلك لا ينبغي النظر إلى Abilities API باعتبارها REST API جديدة، وإنما طبقة تصف الوظائف التي يقدمها النظام ويمكن بعد ذلك إتاحتها عبر قنوات مختلفة.
المشكلة أن الوكيل يحتاج أولًا إلى معرفة ما الذي يستطيع الموقع فعله. إذا كانت الوظائف مسجلة كـAbilities، يمكن للنظام معرفة أن هناك وظيفة لإنشاء مسودة وأخرى للحصول على مقال وثالثة لتنفيذ تحليل معين، كما يستطيع قراءة وصف كل وظيفة ومعرفة مدخلاتها ومخرجاتها.
وهنا تصبح Abilities API مناسبة جدًا لوكلاء الذكاء الاصطناعي: بدل برمجة كل عملية يدويًا داخل كل تكامل، يصبح لدينا سجل منظم للوظائف التي يستطيع النظام اكتشافها. ولهذا ترتبط Abilities API بمشروع WordPress AI وبـMCP Adapter، الذي يستطيع الاستفادة من الـAbilities العامة وإتاحتها للأدوات ووكلاء الذكاء الاصطناعي المتوافقين.
لكن هذا لا يعني أن Abilities API صُممت للذكاء الاصطناعي فقط. نفس البنية يمكن استخدامها في الأتمتة والتكامل بين الإضافات وأدوات المطورين والتطبيقات الخارجية.
كما أصبحت الـAbilities تستطيع حمل معلومات إضافية تصف طبيعة العملية، مثل:
وهذا يعكس الاتجاه الأوسع وراء Abilities API: جعل وظائف ووردبريس ليست قابلة للتنفيذ فقط، وإنما قابلة للفهم بواسطة البرمجيات أيضًا.
فوظيفة تقرأ بيانات عامة تختلف عن وظيفة تعدل مقالًا، وهذه تختلف بدورها عن وظيفة تغير إعدادات الموقع. كما أن تسجيل Ability لا يعني بالضرورة إتاحتها لكل التطبيقات الخارجية. المطور يستطيع التحكم في كونها عامة وكيفية إتاحتها للعملاء الخارجيين.
وهكذا تفصل البنية بين ثلاثة أمور مختلفة: وجود الوظيفة، واكتشافها، وامتلاك صلاحية تنفيذها. وهذا الفصل ضروري خصوصًا عندما نبدأ بربط ووردبريس بأنظمة الأتمتة والذكاء الاصطناعي.
والسبب ليس أن الطرق القديمة ستتوقف فجأة؛ فلا تزال دوال PHP وHooks وREST API وغيرها جزءًا أساسيًا من تطوير ووردبريس. لكن Abilities API تقدم طبقة لم تكن موجودة بهذه الصورة من قبل: لغة موحدة لوصف ما يستطيع الموقع فعله.
وهذا قد يجعلها أكثر أهمية مع الوقت كلما بدأت إضافات وأدوات أكثر في استخدامها.
عندما يستطيع الموقع الإجابة عن هذا السؤال بطريقة منظمة تستطيع البرامج قراءتها، يصبح من الأسهل بناء إضافات تتكامل مع بعضها، وأدوات أتمتة تعرف الوظائف المتاحة، ووكلاء ذكاء اصطناعي يستطيعون اكتشاف قدرات الموقع بدل أن تتم برمجة كل عملية لهم مسبقًا.
وهنا تكمن أهمية Abilities API الحقيقية.
فهي ليست مجرد API جديدة للذكاء الاصطناعي، وليست بديلًا عن REST API، وإنما محاولة لإنشاء طريقة موحدة يستطيع ووردبريس من خلالها وصف وظائفه للأنظمة الأخرى.
وفي الشرح التالي سننتقل من الفكرة إلى التطبيق وننشئ أول Ability في ووردبريس باستخدام
ظهرت Abilities API في نواة WordPress 6.9، ثم توسعت في WordPress 7.0 لتشمل جانب JavaScript أيضًا. وتزداد أهميتها مع أدوات الأتمتة ووكلاء الذكاء الاصطناعي، لأنها توفر طريقة موحدة يمكن من خلالها تعريف وظائف الموقع، ومدخلاتها ومخرجاتها، والصلاحيات المطلوبة لتنفيذها.
لكن لماذا احتاج ووردبريس إلى واجهة جديدة من الأساس؟
المشكلة: ووردبريس يعرف وظائفه، لكن الأنظمة الأخرى لا تعرفها
لنفترض أن لدينا موقعًا يحتوي على عدد من الإضافات. واحدة تستطيع إنشاء تقارير، وأخرى تدير الحجوزات، وثالثة تحلل المحتوى، ورابعة تتعامل مع المنتجات. كل هذه الوظائف موجودة بالفعل، لكنها موزعة بين الإضافات والدوال وواجهات API المختلفة. المطور الذي كتب الإضافة يعرف كيف يصل إليها، لكن برنامجًا آخر لا يستطيع أن يسأل ووردبريس ببساطة:ما الوظائف التي تستطيع تنفيذها؟
وحتى لو عرف بوجود وظيفة معينة، يحتاج إلى معرفة البيانات التي تستقبلها، والنتيجة التي تعيدها، ومن يملك صلاحية استخدامها. هنا جاءت فكرة Abilities API: إنشاء طريقة موحدة تستطيع مكونات ووردبريس من خلالها الإعلان عن قدراتها.بدل أن تبقى الوظيفة مجرد دالة مخفية داخل ملفات إحدى الإضافات، يمكن تسجيلها كـAbility لها اسم ووصف ومدخلات ومخرجات وصلاحيات معروفة.
ما هي Ability عمليًا؟
يمكن ترجمة Ability هنا إلى «قدرة»، لكن عمليًا من الأسهل التفكير فيها باعتبارها وظيفة مسجلة وقابلة للاكتشاف. لنفترض مثلًا أننا نطور إضافة لموقع إخباري ونحتاج إلى وظيفة تعيد أحدث المقالات المنشورة. يمكن تسجيل Ability باسم:iinkor/get-latest-posts ثم نخبر ووردبريس أن هذه الوظيفة تعيد أحدث المقالات، وأنها تستقبل عدد المقالات المطلوبة مثلًا، وتعيد قائمة تحتوي على معلومات كل مقال.لا يتوقف التعريف عند ذلك. يمكن تحديد شكل البيانات باستخدام JSON Schema، وتحديد الصلاحيات المطلوبة، وتصنيف الـAbility، وإضافة معلومات أخرى تساعد الأنظمة التي تكتشفها على فهم طريقة استخدامها.
وبذلك لا يرى النظام الآخر اسمًا غامضًا لدالة PHP، بل يستطيع أن يفهم بصورة منظمة: ماذا تفعل الوظيفة؟ ماذا تحتاج؟ ماذا ستعيد؟ وهل يسمح للمستخدم الحالي بتنفيذها؟ وهذا هو الفرق الأساسي بين Ability وبين كتابة دالة PHP عادية. الدالة التقليدية تنفذ المهمة، بينما Ability تجعل هذه المهمة موصوفة وقابلة للاكتشاف والتعامل معها برمجيًا.
كيف تعمل Abilities API؟
يمكن تبسيط العملية إلى ثلاث مراحل.- أولًا، يسجل المطور Ability ويصف وظيفتها ومدخلاتها ومخرجاتها والصلاحيات اللازمة لها.
- ثانيًا، تدخل هذه الـAbility في سجل Abilities داخل ووردبريس، بحيث تستطيع الأنظمة التي تتعامل مع هذا السجل معرفة الوظائف المتاحة.
- وثالثًا، عندما يُطلب تنفيذها، يتحقق ووردبريس من البيانات والصلاحيات ثم يشغل الكود الذي حدده المطور.
WP_Query. وقد تعتمد Ability أخرى على WooCommerce، وثالثة على API خارجي. الجديد ليس طريقة تنفيذ المهمة في الداخل، وإنما الطريقة الموحدة التي نصف بها هذه المهمة ونكشف وجودها للأنظمة الأخرى.وهل هي بديل عن REST API؟
لا، فالواجهتان تؤديان أدوارًا مختلفة ويمكنهما العمل معًا. REST API تُستخدم أساسًا للوصول إلى موارد وبيانات ووردبريس عبر HTTP، أما Abilities API فتجيب عن سؤال مختلف: ما العمليات التي يستطيع هذا النظام تنفيذها، وما الطريقة الصحيحة لتنفيذ كل واحدة منها؟ويمكن للمطور إتاحة Ability عبر REST عندما يريد أن يستطيع عميل خارجي الوصول إليها. لذلك لا ينبغي النظر إلى Abilities API باعتبارها REST API جديدة، وإنما طبقة تصف الوظائف التي يقدمها النظام ويمكن بعد ذلك إتاحتها عبر قنوات مختلفة.
لماذا أصبح الذكاء الاصطناعي جزءًا مهمًا من القصة؟
هنا تظهر القيمة الأكبر للفكرة. تخيل أن لديك وكيل ذكاء اصطناعي AI Agent وتريد السماح له بالعمل مع موقعك. قد تطلب منه مثلًا البحث عن مقال، إنشاء مسودة، تحليل محتوى أو تنفيذ وظيفة توفرها إحدى إضافاتك.المشكلة أن الوكيل يحتاج أولًا إلى معرفة ما الذي يستطيع الموقع فعله. إذا كانت الوظائف مسجلة كـAbilities، يمكن للنظام معرفة أن هناك وظيفة لإنشاء مسودة وأخرى للحصول على مقال وثالثة لتنفيذ تحليل معين، كما يستطيع قراءة وصف كل وظيفة ومعرفة مدخلاتها ومخرجاتها.
وهنا تصبح Abilities API مناسبة جدًا لوكلاء الذكاء الاصطناعي: بدل برمجة كل عملية يدويًا داخل كل تكامل، يصبح لدينا سجل منظم للوظائف التي يستطيع النظام اكتشافها. ولهذا ترتبط Abilities API بمشروع WordPress AI وبـMCP Adapter، الذي يستطيع الاستفادة من الـAbilities العامة وإتاحتها للأدوات ووكلاء الذكاء الاصطناعي المتوافقين.
لكن هذا لا يعني أن Abilities API صُممت للذكاء الاصطناعي فقط. نفس البنية يمكن استخدامها في الأتمتة والتكامل بين الإضافات وأدوات المطورين والتطبيقات الخارجية.
ماذا تغير في WordPress 7.0؟
بدأت Abilities API من جهة الخادم في WordPress 6.9، لكن WordPress 7.0 نقل الفكرة خطوة إضافية مع Client-Side Abilities API. أصبح بالإمكان تسجيل واستخدام Abilities في JavaScript، وهو ما يسمح بوجود وظائف قابلة للاكتشاف والتنفيذ من جهة العميل أيضًا، وليس PHP فقط.كما أصبحت الـAbilities تستطيع حمل معلومات إضافية تصف طبيعة العملية، مثل:
readonly— الوظيفة لا تغيّر حالة النظام.destructive— قد تؤدي إلى تغيير أو حذف بيانات.idempotent— تكرار العملية بالمدخلات نفسها لا ينتج تأثيرًا إضافيًا مختلفًا.
وهذا يعكس الاتجاه الأوسع وراء Abilities API: جعل وظائف ووردبريس ليست قابلة للتنفيذ فقط، وإنما قابلة للفهم بواسطة البرمجيات أيضًا.
ماذا عن الصلاحيات والأمان؟
إذا كان ووردبريس سيتيح للأنظمة اكتشاف وظائفه، فمن الطبيعي أن يظهر سؤال الأمان. اكتشاف Ability لا يعني تلقائيًا السماح بتنفيذها. عند تسجيلها يستطيع المطور تحديدpermission_callback التي تقرر ما إذا كان المستخدم الحالي يملك الصلاحية اللازمة لتنفيذ العملية.فوظيفة تقرأ بيانات عامة تختلف عن وظيفة تعدل مقالًا، وهذه تختلف بدورها عن وظيفة تغير إعدادات الموقع. كما أن تسجيل Ability لا يعني بالضرورة إتاحتها لكل التطبيقات الخارجية. المطور يستطيع التحكم في كونها عامة وكيفية إتاحتها للعملاء الخارجيين.
وهكذا تفصل البنية بين ثلاثة أمور مختلفة: وجود الوظيفة، واكتشافها، وامتلاك صلاحية تنفيذها. وهذا الفصل ضروري خصوصًا عندما نبدأ بربط ووردبريس بأنظمة الأتمتة والذكاء الاصطناعي.
هل أحتاج إلى Abilities API في موقعي؟
إذا كنت تستخدم ووردبريس فقط لنشر المقالات وتركيب القوالب والإضافات، فالإجابة غالبًا: ليس بصورة مباشرة حاليًا. أما إذا كنت تطور إضافات، أو تبني تكاملات، أو تعمل على الأتمتة أو ربط ووردبريس بالذكاء الاصطناعي، فالأمر يستحق المتابعة من الآن.والسبب ليس أن الطرق القديمة ستتوقف فجأة؛ فلا تزال دوال PHP وHooks وREST API وغيرها جزءًا أساسيًا من تطوير ووردبريس. لكن Abilities API تقدم طبقة لم تكن موجودة بهذه الصورة من قبل: لغة موحدة لوصف ما يستطيع الموقع فعله.
وهذا قد يجعلها أكثر أهمية مع الوقت كلما بدأت إضافات وأدوات أكثر في استخدامها.
من «ما البيانات الموجودة؟» إلى «ماذا يستطيع الموقع أن يفعل؟»
جزء كبير من تطوير التكاملات مع ووردبريس كان يدور تقليديًا حول سؤال: أين توجد البيانات وكيف أصل إليها؟ Abilities API تضيف سؤالًا آخر: ماذا يستطيع هذا الموقع أن يفعل؟عندما يستطيع الموقع الإجابة عن هذا السؤال بطريقة منظمة تستطيع البرامج قراءتها، يصبح من الأسهل بناء إضافات تتكامل مع بعضها، وأدوات أتمتة تعرف الوظائف المتاحة، ووكلاء ذكاء اصطناعي يستطيعون اكتشاف قدرات الموقع بدل أن تتم برمجة كل عملية لهم مسبقًا.
وهنا تكمن أهمية Abilities API الحقيقية.
فهي ليست مجرد API جديدة للذكاء الاصطناعي، وليست بديلًا عن REST API، وإنما محاولة لإنشاء طريقة موحدة يستطيع ووردبريس من خلالها وصف وظائفه للأنظمة الأخرى.
وفي الشرح التالي سننتقل من الفكرة إلى التطبيق وننشئ أول Ability في ووردبريس باستخدام
wp_register_ability()، مع تسجيل الفئة، وتعريف المدخلات والمخرجات، وضبط الصلاحيات، ثم تنفيذها واختبارها عمليًا.