چرا WP_Roles و WP_Role دو کلاس متفاوت در هسته وردپرس هستند؟

WP_Roles و WP_Role دو کلاس متفاوت در هسته وردپرس هستند چون دو سطح متفاوت از انتزاع را پوشش می‌دهند: یکی مجموعه‌ای از نقش‌ها را مدیریت می‌کند و دیگری یک نقش منفرد را نمایندگی می‌کند.

این تفکیک، بر پایه اصل مسئولیت واحد (Single Responsibility Principle) طراحی شده و از پیچیدگی و تداخل در ساختار داخلی وردپرس جلوگیری می‌کند.

کلاس WP_Roles به‌عنوان مدیر مجموعه عمل می‌کند و عملیات سطح سیستم را انجام می‌دهد، در حالی که WP_Role به‌عنوان نماینده یک نقش منفرد، عملیات سطح نقش را مدیریت می‌کند.

درک این تفکیک، پیش‌نیاز کار دقیق با ساختار نقش‌ها در وردپرس و جلوگیری از اشتباهات رایج در کد سفارشی است.

بسیاری از اشتباهات توسعه‌دهندگان، ناشی از عدم توجه به این تفکیک است و به رفتار غیرمنتظره در بررسی دسترسی منجر می‌شود.

در پروژه‌ای که یک افزونه اختصاصی برای مدیریت کاربران سازمانی توسعه می‌دادم، با خطای عجیبی روبه‌رو شدم: کدی که از WP_Roles برای دریافت قابلیت‌های یک نقش استفاده می‌کرد، نتایج نادرستی بازگرداند. پس از بررسی، علت مشخص شد: کد به‌جای استفاده از WP_Role برای یک نقش منفرد، از WP_Roles استفاده کرده بود و همین اشتباه، ساختار داده را به‌هم ریخته بود. این تجربه نشان داد که تفکیک دقیق بین این دو کلاس، پیش‌نیاز کار درست با نقش‌ها در وردپرس است.

چرا وردپرس دو کلاس جداگانه برای نقش‌ها دارد

تفکیک WP_Roles و WP_Role بر پایه چند اصل طراحی نرم‌افزاری است که در معماری وردپرس رعایت شده‌اند.

اصل مسئولیت واحد

اصل مسئولیت واحد (Single Responsibility Principle) می‌گوید هر کلاس باید فقط یک مسئولیت داشته باشد. کلاس WP_Roles مسئول مدیریت مجموعه نقش‌ها است و کلاس WP_Role مسئول نمایندگی یک نقش منفرد. این تفکیک، از پیچیدگی و تداخل جلوگیری می‌کند.

تفکیک سطوح انتزاع

دو کلاس، دو سطح متفاوت از انتزاع را پوشش می‌دهند. WP_Roles در سطح سیستم عمل می‌کند: نقش‌ها را اضافه، حذف و مدیریت می‌کند. WP_Role در سطح یک نقش منفرد عمل می‌کند: قابلیت‌های آن نقش را مدیریت می‌کند. این تفکیک سطوح، کد را خواناتر و نگهداری آن را ساده‌تر می‌کند.

کارایی و مدیریت Cache

تفکیک دو کلاس، امکان مدیریت بهتر cache را فراهم می‌کند. WP_Roles می‌تواند فهرست کامل نقش‌ها را در cache نگه دارد و WP_Role می‌تواند قابلیت‌های یک نقش را به‌صورت مستقل cache کند. این تفکیک، کارایی را در سایت‌های با تعداد بالای نقش افزایش می‌دهد.

سازگاری با ساختار داده وردپرس

ساختار داده وردپرس، نقش‌ها را به‌صورت آرایه‌ای در wp_options ذخیره می‌کند. WP_Roles این آرایه را به‌عنوان یک مجموعه مدیریت می‌کند و WP_Role هر عضو آرایه را به‌عنوان یک نقش منفرد نمایندگی می‌کند. این تفکیک، با ساختار داده هم‌راستا است. اگر با ساختار داده آشنا نیستید، راهنمای توابع مدیریت نقش‌ها و دسترسی‌ها مفاهیم پایه را روشن می‌کند.

امکان توسعه و نگهداری

تفکیک دو کلاس، توسعه و نگهداری کد را ساده‌تر می‌کند. اگر مسئولیت‌ها در یک کلاس واحد باشند، هر تغییر در یک بخش ممکن است بر بخش‌های دیگر اثر بگذارد. تفکیک، این خطر را کاهش می‌دهد.

انعطاف در پیاده‌سازی

تفکیک دو کلاس، امکان پیاده‌سازی‌های متفاوت را فراهم می‌کند. برای مثال، یک پیاده‌سازی سفارشی می‌تواند WP_Role را گسترش دهد بدون اینکه WP_Roles تغییر کند. این انعطاف، در پروژه‌های سفارشی ارزش بالایی دارد.

تفکیک بین مجموعه و عضو، یکی از پایه‌ای‌ترین اصول طراحی است که در ساختار نقش‌های وردپرس به‌خوبی رعایت شده است.

کلاس WP_Roles چیست و چه مسئولیتی دارد

کلاس WP_Roles، مدیر مجموعه نقش‌ها در وردپرس است. این کلاس، عملیات سطح سیستم را انجام می‌دهد و نقطه دسترسی اصلی برای کار با نقش‌ها است.

مسئولیت‌های اصلی WP_Roles

این کلاس چند مسئولیت اصلی دارد: افزودن نقش جدید، حذف نقش موجود، دریافت نقش بر پایه نام، فهرست همه نقش‌ها و بارگذاری نقش‌ها از دیتابیس. این مسئولیت‌ها در سطح مجموعه تعریف می‌شوند.

ساختار داخلی WP_Roles

این کلاس به‌صورت داخلی، یک آرایه از نقش‌ها را نگهداری می‌کند که هر عضو آن، یک شیء WP_Role است. این ساختار، دسترسی سریع به نقش‌ها را فراهم می‌کند و امکان مدیریت دقیق را ایجاد می‌کند.

متدهای کلیدی WP_Roles

متدهایی مانند add_role، remove_role، get_role، get_names و get_roles در این کلاس تعریف شده‌اند. این متدها، نقطه اصلی تعامل با مجموعه نقش‌ها هستند.

پیوند با تابع wp_roles

تابع wp_roles، نقطه دسترسی یکپارچه به شیء WP_Roles است. این تابع، جایگزین دسترسی مستقیم به متغیر سراسری $wp_roles می‌شود و کد را امن‌تر می‌کند.

مدیریت Cache در WP_Roles

این کلاس، یک cache داخلی از نقش‌ها نگهداری می‌کند که با هر بار بارگذاری، از دیتابیس خوانده نمی‌شود. این cache، در سایت‌هایی با تعداد بالای نقش، کارایی قابل توجهی ایجاد می‌کند.

پیوند با Multisite

در محیط Multisite، WP_Roles می‌تواند نقش‌های سطح سایت و سطح شبکه را مدیریت کند. این قابلیت، از طریق پارامترهای اضافی در سازنده کلاس فعال می‌شود. اگر در این حوزه کار می‌کنید، راهنمای وردپرس مولتی‌سایت نکات دقیق‌تری ارائه می‌دهد.

پیوند با فرآیند نصب و به‌روزرسانی

در فرآیند نصب و به‌روزرسانی وردپرس، WP_Roles نقش کلیدی ایفا می‌کند. این کلاس مسئول تعریف نقش‌های پیش‌فرض و هماهنگ‌سازی آنها با ساختار جدید است.

محدودیت‌ها و ملاحظات

یکی از محدودیت‌های WP_Roles این است که برای کار با یک نقش منفرد، باید از طریق آن به شیء WP_Role دسترسی پیدا کرد. استفاده مستقیم از WP_Roles برای عملیات سطح نقش، اشتباه رایجی است که به رفتار غیرمنتظره منجر می‌شود.

کلاس WP_Role چیست و چه مسئولیتی دارد

کلاس WP_Role، نماینده یک نقش منفرد در وردپرس است. این کلاس، عملیات سطح نقش را انجام می‌دهد و نقطه دسترسی برای کار با قابلیت‌های یک نقش است.

مسئولیت‌های اصلی WP_Role

این کلاس چند مسئولیت اصلی دارد: نگهداری نام نقش، نگهداری فهرست قابلیت‌ها، بررسی وجود یک قابلیت، افزودن قابلیت به نقش و حذف قابلیت از نقش. این مسئولیت‌ها در سطح یک نقش منفرد تعریف می‌شوند.

ساختار داخلی WP_Role

این کلاس به‌صورت داخلی، دو مقدار اصلی را نگهداری می‌کند: نام نقش (به‌عنوان name) و آرایه‌ای از قابلیت‌ها (به‌عنوان capabilities). این ساختار ساده، دسترسی سریع به اطلاعات نقش را فراهم می‌کند.

متدهای کلیدی WP_Role

متدهایی مانند has_cap، add_cap، remove_cap و get_capabilities در این کلاس تعریف شده‌اند. این متدها، نقطه اصلی تعامل با قابلیت‌های یک نقش هستند.

پیوند با Capabilityها

هر قابلیت در WP_Role به‌صورت یک جفت کلید-مقدار ذخیره می‌شود که کلید آن، نام قابلیت و مقدار آن، یک مقدار منطقی (true یا false) است. این ساختار، امکان بررسی سریع وجود یک قابلیت را فراهم می‌کند. اگر با قابلیت‌ها آشنا نیستید، راهنمای قابلیت‌های سفارشی و ثبت آنها مفاهیم پایه را روشن می‌کند.

متد has_cap و کاربرد آن

متد has_cap، نقطه اصلی بررسی وجود یک قابلیت در نقش است. این متد، یک پارامتر به‌عنوان نام قابلیت می‌گیرد و یک مقدار منطقی بازمی‌گرداند. این متد، در لایه بررسی دسترسی وردپرس استفاده می‌شود.

متدهای add_cap و remove_cap

این دو متد، مسئول افزودن و حذف قابلیت از نقش هستند. این متدها، در پیاده‌سازی نقش‌های سفارشی و تغییر ساختار دسترسی استفاده می‌شوند.

پیوند با ذخیره‌سازی در دیتابیس

اطلاعات WP_Role در جدول wp_options و کلید wp_user_roles ذخیره می‌شود. هر تغییر در قابلیت‌های یک نقش، باید در این ساختار ذخیره شود تا در بارگذاری بعدی، موجود باشد.

محدودیت‌ها و ملاحظات

یکی از محدودیت‌های WP_Role این است که برای کار با مجموعه نقش‌ها، باید از طریق WP_Roles استفاده کرد. این کلاس فقط یک نقش منفرد را نمایندگی می‌کند و نمی‌تواند نقش‌های دیگر را ببیند.

نحوه تعامل دو کلاس با هم

دو کلاس WP_Roles و WP_Role به‌صورت هماهنگ کار می‌کنند. درک نحوه این تعامل، پیش‌نیاز استفاده درست از این ساختار است.

سازنده کلاس WP_Roles

در زمان ساخت یک شیء WP_Roles، این کلاس فهرست نقش‌ها را از دیتابیس می‌خواند و برای هر نقش، یک شیء WP_Role می‌سازد. این ساختار، امکان دسترسی سریع به هر نقش را فراهم می‌کند.

دسترسی به WP_Role از طریق WP_Roles

برای دسترسی به یک نقش منفرد، باید از متد get_role روی شیء WP_Roles استفاده کرد. این متد، یک شیء WP_Role بازمی‌گرداند که می‌توان روی آن عملیات سطح نقش انجام داد.

هماهنگی در زمان افزودن نقش جدید

در زمان افزودن نقش جدید با متد add_role، شیء WP_Roles یک شیء WP_Role جدید می‌سازد و آن را به فهرست داخلی خود اضافه می‌کند. سپس این تغییر در دیتابیس ذخیره می‌شود.

هماهنگی در زمان حذف نقش

در زمان حذف نقش با متد remove_role، شیء WP_Roles نقش مربوطه را از فهرست داخلی خود حذف می‌کند و این تغییر را در دیتابیس ذخیره می‌کند. اگر این نقش به کاربرانی اختصاص یافته باشد، باید این اختصاصات هم مدیریت شوند.

پیوند با تابع wp_roles

تابع wp_roles، نقطه دسترسی یکپارچه به شیء WP_Roles است. این تابع، در هر بار فراخوانی، همان شیء را بازمی‌گرداند و از ساخت نمونه‌های تکراری جلوگیری می‌کند.

پیوند با توابع بررسی دسترسی

توابعی مانند current_user_can و user_can، در لایه داخلی، از این دو کلاس برای بررسی دسترسی استفاده می‌کنند. اگر با این توابع آشنا نیستید، راهنمای توابع کار با کاربران در وردپرس نکات دقیق‌تری ارائه می‌دهد.

پیوند با فیلتر user_has_cap

فیلتر user_has_cap، امکان دخالت در لایه بررسی دسترسی را فراهم می‌کند. این فیلتر، بعد از بررسی اولیه توسط دو کلاس اجرا می‌شود و امکان اعمال سیاست‌های سفارشی را می‌دهد.

پیوند با Capability و لایه بررسی دسترسی

ساختار دو کلاس WP_Roles و WP_Role، به‌طور مستقیم با لایه Capability پیوند خورده است. درک این پیوند، پیش‌نیاز کار دقیق با کنترل دسترسی در وردپرس است.

تفاوت Capability و Role

Role یک برچسب انسانی است که به کاربر اختصاص می‌یابد و Capability یک اجازه فنی است که تعیین می‌کند کاربر چه کاری می‌تواند انجام دهد. یک کاربر می‌تواند چند Role داشته باشد و هر Role شامل مجموعه‌ای از Capabilityها است.

ذخیره Capability در WP_Role

در کلاس WP_Role، Capabilityها به‌صورت آرایه‌ای ذخیره می‌شوند. هر عضو آرایه، یک جفت کلید-مقدار است که کلید آن نام Capability و مقدار آن یک مقدار منطقی است. این ساختار، امکان بررسی سریع وجود یک Capability را فراهم می‌کند.

پیوند با متد has_cap

متد has_cap در WP_Role، نقطه اصلی بررسی وجود یک Capability است. این متد، در لایه بررسی دسترسی وردپرس استفاده می‌شود و نتیجه آن، تعیین‌کننده دسترسی کاربر است.

پیوند با map_meta_cap

تابع map_meta_cap، برای نگاشت Capabilityهای انتزاعی به Capabilityهای مشخص استفاده می‌شود. این تابع، در لایه بررسی دسترسی، قبل از استفاده از WP_Role اجرا می‌شود و ساختار Capabilityها را دقیق‌تر می‌کند.

پیوند با فیلتر user_has_cap

فیلتر user_has_cap، بعد از بررسی توسط دو کلاس اجرا می‌شود و امکان اعمال سیاست‌های سفارشی را فراهم می‌کند. این فیلتر، معمولاً توسط افزونه‌هایی که نیاز به کنترل دقیق دسترسی دارند، استفاده می‌شود. اگر با هوک‌ها آشنایی ندارید، راهنمای هوک‌های وردپرس چیستند نقطه شروع مناسبی است.

پیوند با توابع کمکی

وردپرس توابع کمکی مانند get_role، add_role و remove_role ارائه می‌دهد که به‌طور غیرمستقیم از دو کلاس استفاده می‌کنند. این توابع، کار با نقش‌ها و Capabilityها را ساده‌تر می‌کنند.

جدول تفاوت‌های کلیدی دو کلاس

اشتباهات رایج در استفاده از دو کلاس

در تجربه‌های عملی، چند اشتباه رایج در استفاده از دو کلاس دیده‌ام که هر کدام پیامدهای خاص خود را داشته است.

اشتباه اول: استفاده از WP_Roles برای یک نقش منفرد

این اشتباه شایع‌ترین است. برای کار با یک نقش منفرد، باید از شیء WP_Role استفاده کرد که از طریق متد get_role از شیء WP_Roles قابل دسترسی است. استفاده مستقیم از WP_Roles برای این کار، به رفتار غیرمنتظره منجر می‌شود.

اشتباه دوم: دسترسی مستقیم به متغیر سراسری

استفاده مستقیم از متغیر سراسری $wp_roles در کد سفارشی، رویکردی است که توصیه نمی‌شود. استفاده از تابع wp_roles امن‌تر و پایدارتر است.

اشتباه سوم: نادیده گرفتن Cache

کلاس WP_Roles یک cache داخلی دارد. اگر کد سفارشی این cache را نادیده بگیرد یا آن را به‌درستی مدیریت نکند، ممکن است رفتار غیرمنتظره رخ دهد. برای به‌روزرسانی cache، می‌توان از متد reinit استفاده کرد.

اشتباه چهارم: تغییر مستقیم در ساختار داخلی

برخی توسعه‌دهندگان، ساختار داخلی این کلاس‌ها را به‌صورت مستقیم تغییر می‌دهند. این کار، در نسخه‌های آینده وردپرس می‌تواند به بروز خطا منجر شود. توصیه می‌شود از متدهای عمومی این کلاس‌ها استفاده شود.

اشتباه پنجم: نادیده گرفتن Multisite

در محیط Multisite، ساختار نقش‌ها پیچیده‌تر است. اگر کد سفارشی این پیچیدگی را نادیده بگیرد، ممکن است در محیط Multisite رفتار نادرست نشان دهد. اگر در این حوزه کار می‌کنید، راهنمای مدیریت کاربران و نقش‌ها در وردپرس نکات دقیق‌تری ارائه می‌دهد.

اشتباه ششم: عدم بررسی نتیجه

متد get_role ممکن است در صورت عدم وجود نقش، مقدار null بازگرداند. اگر کد سفارشی این حالت را بررسی نکند، ممکن است به خطاهای Fatal منجر شود. همیشه نتیجه این متد باید بررسی شود.

اشتباه هفتم: استفاده از نام اشتباه برای متدها

برخی توسعه‌دهندگان، متدهای این کلاس‌ها را با نام‌های اشتباه فراخوانی می‌کنند. برای مثال، get_capability به‌جای has_cap. این اشتباه، به خطاهای Fatal منجر می‌شود.

اشتباه هشتم: عدم پیوند با Capabilityهای سفارشی

اگر قابلیت سفارشی تعریف می‌کنید، باید آن را به‌درستی در ساختار Capabilityها ثبت کنید. این ثبت، بخشی از استفاده درست از این دو کلاس است. اگر در این حوزه کار می‌کنید، راهنمای قابلیت‌های سفارشی و ثبت آنها نکات دقیق‌تری ارائه می‌دهد.

کاربردهای عملی در کد سفارشی

ساختار دو کلاس WP_Roles و WP_Role، چند کاربرد عملی در کد سفارشی دارد که هر توسعه‌دهنده باید بشناسد.

دریافت فهرست نقش‌ها

برای دریافت فهرست همه نقش‌ها، می‌توان از تابع wp_roles و متد get_names استفاده کرد. این تابع، آرایه‌ای از نام نقش‌ها را بازمی‌گرداند که می‌توان در رابط کاربری استفاده کرد.

بررسی وجود یک نقش

برای بررسی وجود یک نقش، می‌توان از متد get_role روی شیء WP_Roles استفاده کرد. اگر این متد مقدار null بازگرداند، نقش وجود ندارد.

افزودن نقش جدید

برای افزودن نقش جدید، می‌توان از متد add_role روی شیء WP_Roles استفاده کرد. این متد، دو پارامتر می‌گیرد: نام نقش و آرایه‌ای از قابلیت‌ها.

حذف نقش موجود

برای حذف نقش موجود، می‌توان از متد remove_role روی شیء WP_Roles استفاده کرد. این متد، فقط نام نقش را به‌عنوان پارامتر می‌گیرد.

افزودن قابلیت به نقش

برای افزودن قابلیت به یک نقش، می‌توان از متد add_cap روی شیء WP_Role استفاده کرد. این شیء، از طریق متد get_role از شیء WP_Roles قابل دسترسی است.

بررسی وجود قابلیت در نقش

برای بررسی وجود یک قابلیت در نقش، می‌توان از متد has_cap روی شیء WP_Role استفاده کرد. این متد، یک مقدار منطقی بازمی‌گرداند.

دریافت قابلیت‌های یک نقش

برای دریافت فهرست قابلیت‌های یک نقش، می‌توان از متد capabilities روی شیء WP_Role استفاده کرد. این متد، آرایه‌ای از قابلیت‌ها را بازمی‌گرداند. اگر در این حوزه کار می‌کنید، راهنمای کنترل نقش‌ها و دسترسی‌های وردپرس نکات دقیق‌تری ارائه می‌دهد.

پیوند با فیلتر user_has_cap

برای اعمال سیاست‌های سفارشی دسترسی، می‌توان از فیلتر user_has_cap استفاده کرد. این فیلتر، در لایه بررسی دسترسی وردپرس اجرا می‌شود و امکان دخالت در نتیجه نهایی را فراهم می‌کند.

لایه مهندسی: تصمیم‌هایی که در سطح معماری گرفته می‌شوند

برای مهندسانی که این ساختار را در مقیاس طراحی می‌کنند، چند نکته اهمیت دارد. اول، استفاده از APIهای عمومی. به‌جای دسترسی مستقیم به ساختار داخلی کلاس‌ها، بهتر است از APIهای عمومی مانند wp_roles، get_role و add_role استفاده شود. این رویکرد، کد را با نسخه‌های آینده وردپرس سازگار نگه می‌دارد.

دوم، طراحی بر پایه Capability. در کد سفارشی، بهتر است بررسی دسترسی بر پایه Capability انجام شود، نه بر پایه نقش. این رویکرد، انعطاف بیشتری فراهم می‌کند و از وابستگی به ساختار نقش‌ها می‌کاهد.

سوم، استفاده از فیلتر user_has_cap. برای پیاده‌سازی سیاست‌های دسترسی پیچیده، این فیلتر نقطه اصلی دخالت است. استفاده صحیح از این فیلتر، از تغییرات مستقیم در نقش‌ها جلوگیری می‌کند.

چهارم، پیوند با map_meta_cap. برای نگاشت دقیق Capabilityها، این تابع ابزار اصلی است. استفاده صحیح از این تابع، امکان تعریف سیاست‌های دقیق دسترسی را فراهم می‌کند.

پنجم، مدیریت Cache. کلاس WP_Roles یک cache داخلی دارد. برای به‌روزرسانی این cache پس از تغییرات، می‌توان از متد reinit استفاده کرد. این مدیریت، از رفتار غیرمنتظره جلوگیری می‌کند.

ششم، توجه به Multisite. اگر پروژه در محیط Multisite اجرا می‌شود، باید تفاوت‌های شبکه‌ای و سایت‌ای در ساختار نقش‌ها لحاظ شود. این پیچیدگی، نیازمند طراحی دقیق‌تر است.

هفتم، پیوند با REST API. اگر پروژه از REST API استفاده می‌کند، بررسی دسترسی در این لایه باید به‌طور دقیق طراحی شود. این طراحی، بر پایه ساختار دو کلاس انجام می‌شود.

هشتم، تست خودکار. برای اطمینان از رفتار درست نقش‌ها، باید تست خودکار داشته باشید. این تست‌ها باید رفتار دو کلاس را در سناریوهای مختلف بررسی کنند.

نهم، مستندسازی معماری. ساختار نقش‌ها، قابلیت‌ها و تصمیمات مرتبط با آنها باید مستند شوند. این مستندسازی در زمان بازبینی معماری، از تصمیم‌های دوباره جلوگیری می‌کند.

دهم، پایش مستمر. پس از استقرار، باید پایش مستمر روی رفتار نقش‌ها اعمال شود. هر تغییر غیرمنتظره باید هشدار ایجاد کند.

یازدهم، آموزش تیم. تیم باید با تفاوت دو کلاس و کاربرد هرکدام آشنا باشد. اگر تیم این تفاوت را نداند، احتمال بروز خطا در کد سفارشی افزایش می‌یابد. اگر در این حوزه کار می‌کنید، بهترین افزونه‌های مدیریت کاربران وردپرس گزینه‌های عملی را نشان می‌دهد.

دوازدهم، پیوند با فرآیند CI/CD. تغییرات در ساختار نقش‌ها باید در پایپ‌لاین CI/CD لحاظ شوند. این کار، از بروز خطاهای ناخواسته در محیط تولید جلوگیری می‌کند. اگر در این حوزه کار می‌کنید، راهنمای CI/CD برای پروژه‌های وردپرسی نکات کاربردی دارد.

پرسش‌های پرتکرار درباره WP_Roles و WP_Role

آیا می‌توان از WP_Roles برای دسترسی به یک نقش منفرد استفاده کرد؟

بله، از طریق متد get_role. این متد، یک شیء WP_Role بازمی‌گرداند که می‌توان روی آن عملیات سطح نقش انجام داد. استفاده مستقیم از WP_Roles برای این کار، اشتباه رایجی است که به رفتار غیرمنتظره منجر می‌شود.

آیا می‌توان از WP_Role برای دسترسی به مجموعه نقش‌ها استفاده کرد؟

خیر. کلاس WP_Role فقط یک نقش منفرد را نمایندگی می‌کند و به سایر نقش‌ها دسترسی ندارد. برای دسترسی به مجموعه نقش‌ها، باید از WP_Roles استفاده کرد.

چگونه می‌توان فهرست همه نقش‌ها را دریافت کرد؟

با استفاده از تابع wp_roles و متد get_names. این تابع، آرایه‌ای از نام نقش‌ها را بازمی‌گرداند که می‌توان در رابط کاربری یا در کد سفارشی استفاده کرد.

آیا تغییرات در WP_Role به‌طور خودکار در دیتابیس ذخیره می‌شوند؟

بله. متدهای add_cap و remove_cap در WP_Role، تغییرات را در ساختار داخلی ذخیره می‌کنند و از طریق WP_Roles در دیتابیس ذخیره می‌شوند. اما برای اطمینان، بهتر است پس از تغییرات، متد reinit روی WP_Roles فراخوانی شود.

آیا می‌توان کلاس WP_Role را گسترش داد؟

از نظر فنی ممکن است اما توصیه نمی‌شود. این کلاس بخشی از هسته وردپرس است و تغییرات در آن می‌تواند با نسخه‌های آینده ناسازگار باشد. رویکرد بهتر، استفاده از فیلترها و اکشن‌های ارائه‌شده توسط وردپرس است.

آیا این دو کلاس در REST API هم استفاده می‌شوند؟

بله، در لایه REST API، بررسی دسترسی بر پایه ساختار این دو کلاس انجام می‌شود. درخواست‌های REST API، از ساختار نقش‌ها و Capabilityها برای تعیین دسترسی استفاده می‌کنند.

چگونه از رفتار درست این دو کلاس مطمئن شویم؟

با تست خودکار و پایش مستمر. همچنین با استفاده از APIهای عمومی به‌جای دسترسی مستقیم به ساختار داخلی. اگر در این حوزه کار می‌کنید، راهنمای توابع مدیریت نقش‌ها و دسترسی‌ها نکات دقیق‌تری ارائه می‌دهد.

برای درک عمیق‌تر مفاهیم پایه این حوزه، می‌توانید صفحه Single-responsibility principle را در ویکی‌پدیا ببینید.

اگر روی پروژه وردپرسی خود با این دو کلاس کار کرده‌اید و در فرآیند استفاده با موقعیت غیرمنتظره‌ای روبه‌رو شده‌اید — مثلاً رفتار نادرست در بررسی دسترسی یا مشکل در مدیریت Cache — برایم جالب است بدانید کدام بخش بیشترین وقت شما را گرفت. تجربه خودتان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر راه‌حل متفاوتی برای کار دقیق‌تر با این کلاس‌ها پیدا کرده‌اید که می‌تواند برای خواننده بعدی راهگشا باشد.