صلاحيات المستخدمين في WordPress 2026: Roles وCapabilities وإدارتها بأمان

صلاحيات المستخدمين في WordPress تُدار عبر مفهومين: Roles وهي مجموعات جاهزة من الصلاحيات، وCapabilities وهي الأفعال الدقيقة التي يستطيع المستخدم تنفيذها مثل edit_posts أوmanage_options.

المبدأ الأهم ليس إعطاء “رتبة أعلى”، بل إعطاء كل مستخدم أقل مجموعة صلاحيات تكفي مسؤوليته. WordPress نفسها توضح أن Roles تحدد المسؤوليات، ولا يجب النظر إليها كسلم إداري فقط.

المصدر الرسمي: WordPress – Roles and Capabilities.

الأدوار الافتراضية في WordPress

Subscriber

Subscriber هو الدور الأقل صلاحية افتراضيًا. مناسب عندما يحتاج المستخدم حسابًا لتسجيل الدخول أوإدارة Profile بدون تحرير محتوى.

وجود Capability مثل read لا يعني “قراءة المقالات العامة فقط”؛ المقالات العامة يستطيع الزائر قراءتها أصلًا. الدور يتعلق بالوصول إلى حساب WordPress ووظائف المستخدم المرتبطة به.

Contributor

Contributor يستطيع كتابة وإدارة مسوداته لكنه لا يستطيع نشرها. مناسب لفريق تحرير يحتاج Approval من Editor قبل النشر.

هذا أفضل من إعطاء كل كاتب Author إذا كان Workflow التحرير يتطلب مراجعة مركزية.

Author

Author يستطيع عادة نشر وإدارة محتواه ورفع Media. لا يستطيع إدارة مقالات مستخدمين آخرين مثل Editor.

استخدمه فقط عندما تثق أن الكاتب يستطيع النشر بدون Approval.

Editor

Editor يدير Posts/Pages ومحتوى المستخدمين الآخرين والتصنيفات والتعليقات، لكنه لا يحتاج عادة إلى إدارة Plugins أوThemes أوUsers.

هذه نقطة مهمة: فريق المحتوى لا يحتاج Administrator لمجرد أنه يدير كل المقالات.

unfiltered_html

Capability unfiltered_html حساسة لأنها تسمح بإدخال HTML غير مفلتر. سلوكها يختلف بين Single Site وMultisite، ولا يجب بناء سياسة الصلاحيات على افتراض أن كل Role يمتلكها دائمًا.

راجع Capability table في وثائق WordPress الرسمية عند إنشاء Custom Role، خصوصًا إذا كان فريقك يحرر HTML أوBlocks مخصصة.

Administrator

Administrator في Single Site يملك صلاحيات واسعة جدًا مثل إدارة Plugins/Themes/Users/Settings. لذلك الحساب الإداري يعتبر High-value account.

لا تمنح Administrator لمطور أوكاتب أومسوق إذا كانت المهمة يمكن تنفيذها بدور أقل أوCustom Role.

Super Admin

Super Admin يظهر في WordPress Multisite ويملك صلاحيات Network-level مثل إدارة المواقع والمستخدمين والقوالب والإضافات على مستوى الشبكة.

في Single Site لا يوجد Super Admin role بنفس مفهوم Multisite.

ما هي Capabilities؟

Capabilities أمثلةها:

• edit_posts
• publish_posts
• edit_others_posts
• moderate_comments
• manage_categories
• upload_files
• manage_options
• install_plugins
• edit_users

Role هي حزمة من Capabilities. Plugins مثل WooCommerce تضيف Capabilities وأدوارًا إضافية حسب الوظائف.

كيف تختار Role لكل مستخدم؟

ابدأ بالمهمة وليس باسم الشخص:

ثم أضف أوأزل Capabilities فقط إذا كان Workflow الحقيقي يحتاج ذلك.

مبدأ Least Privilege

أقل صلاحية تعني أن المستخدم يحصل فقط على ما يحتاجه الآن. هذا يقلل أثر:

• سرقة Password.
• Malware على جهاز المستخدم.
• خطأ بشري.
• حساب موظف سابق.
• Plugin vulnerability تستغل Session المستخدم.

لا تشارك حساب Administrator واحدًا

أنشئ حسابًا منفصلًا لكل شخص. مشاركة Username/Password واحدة تمنعك من معرفة من نفذ التغيير، وتصعّب إلغاء وصول فرد واحد.

2FA للحسابات الحساسة

فعّل Two-Factor Authentication للحسابات الإدارية عندما تسمح منظومتك بذلك. 2FA تقلل مخاطر Password compromise لكنها لا تعوض Updates أوإزالة الحسابات القديمة.

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

Custom Roles: متى تحتاجها؟

تحتاج Custom Role عندما لا يطابق أي Role افتراضي مسؤولية المستخدم. مثال:

• موظف متجر يحتاج Orders بدون Plugins.
• SEO specialist يحتاج تحرير Posts وMetadata بدون Theme settings.
• Support agent يحتاج Users/Orders في نطاق محدود.

لا تنشئ Role جديدة لكل شخص؛ أنشئها لكل وظيفة متكررة.

إضافات إدارة Capabilities

WordPress Core لا توفر UI لتعديل كل Capability داخل Role، لذلك يمكن استخدام Plugins مثل Members أوUser Role Editor أوPublishPress Capabilities.

قبل تركيب Plugin:

• راجع آخر Update والتوافق.
• خذ Backup.
• صدّر أووثق Role configuration إذا كانت الأداة تدعم ذلك.
• اختبر حسابًا تجريبيًا بالدور الجديد.

لا تعتمد على إخفاء القائمة فقط

إخفاء Menu item في wp-admin لا يعني منع الصلاحية. Security يجب أن تعتمد على Capability checks في Server-side code.

إذا كان Custom Plugin ينفذ إجراءً حساسًا، استخدم current_user_can() أوAPI WordPress المناسبة، وليس CSS لإخفاء زر.

WooCommerce Roles

WooCommerce تضيف أدوارًا مثل Customer وShop Manager. لا تعطي Store staff Administrator تلقائيًا.

Shop Manager يستطيع إدارة أجزاء واسعة من المتجر، لذلك راجع ما إذا كان الموظف يحتاج Orders فقط أومنتجات أيضًا.

Activity Logs

في المواقع التي يديرها فريق، Activity Log تساعد في Audit: من سجل الدخول، من عدّل Plugin، من نشر Post، ومن غيّر User role.

Plugins مثل WP Activity Log يمكن أن تضيف هذه الطبقة، لكن حدد Retention للـlogs ولا تجمع بيانات بلا حدود.

مراجعة المستخدمين شهريًا

ضمن صيانة WordPress:

• راجع Administrators.
• احذف أوخفض صلاحية الحسابات غير المستخدمة.
• راجع Accounts التي غادر أصحابها الفريق.
• راجع API/application passwords والتكاملات المرتبطة بالحسابات.
• تأكد أن Admin email وRecovery paths محدثة.

لروتين الإدارة الأوسع راجع إدارة موقع WordPress في 2026.

أخطاء شائعة

• كل الفريق Administrator.
• مشاركة Account واحدة بين عدة أشخاص.
• Custom Role بلا توثيق.
• إخفاء Menu بدل منع Capability.
• نسيان المستخدمين السابقين.
• إعطاء Editor صلاحيات Plugins لمجرد أنه “مدير محتوى”.

Checklist للصلاحيات

• Role لكل وظيفة.
• Least Privilege.
• 2FA للحسابات الحساسة.
• لا Shared admin accounts.
• Audit log عند الحاجة.
• مراجعة شهرية للحسابات.
• اختبار Custom Roles بحساب تجريبي.

الخلاصة

إدارة صلاحيات WordPress تبدأ بفهم الفرق بين Roles وCapabilities. لا تمنح Administrator لتسهيل العمل؛ اختر Role الأقرب للمهمة ثم خصص فقط ما تحتاجه. كلما قل الوصول غير الضروري، قل أثر الأخطاء والاختراقات وأصبح Audit التغييرات أوضح.