درباره افزونه ممبرز - ویرایشگر نقش کاربری Members
داستان این افزونه برمی‌گرده به سال ۲۰۰۹؛ وقتی یه توسعه‌دهنده آمریکایی به اسم Justin Tadlock (معروف به greenshady در جامعه وردپرس) با یه لپ‌تاپ و یه چمدون برگشت به خانه پدربزرگ و مادربزرگش در آلاباما. اون چند ماه نشست و عمیقاً روی سیستم نقش و قابلیت وردپرس کار کرد. دلیل ساختنش هم ساده بود: وردپرس یه سیستم roles و capabilities حسابی داشت، ولی هیچ رابط کاربری‌ای برای مدیریتش وجود نداشت و فقط برنامه‌نویس‌ها می‌تونستن باهاش کار کنن. Tadlock خواست این قدرت رو در اختیار همه بذاره. بعدها، وقتی Blair Williams و شرکت Caseproof (سازنده MemberPress) وارد ماجرا شدن، مالکیت افزونه منتقل شد و حالا Members زیر چتر همون اکوسیستم نگهداری می‌شه. کارش اینه که سیستم مدیریت نقش وردپرس رو از دست توسعه‌دهنده‌ها بگیره و بده دست مدیر سایت. با این افزونه می‌تونی نقش‌های جدید بسازی، نقش‌های موجود رو ویرایش یا کلون کنی، و به هر کاربر چند نقش همزمان بدی. محتوای سایت رو هم می‌شه بر اساس نقش محدود کرد؛ یعنی فقط کاربران با نقش خاص یه نوشته یا صفحه رو ببینن. علاوه بر اینا، افزودنی‌هایی مثل Block Permissions (مخفی‌کردن بلوک‌های گوتنبرگ بر اساس نقش)، Admin Access (کنترل دسترسی به پیشخوان)، Privacy Caps (برای GDPR)، و ادغام با ووکامرس، ACF و EDD هم الان کاملاً رایگان بنده و نیاز به خرید ندارن. برای کاربر ایرانی این افزونه یه مزیت بزرگ داره: هیچ وابستگی به سرویس خارجی، API خارجی، CDN بیرونی یا درگاه پرداخت خاصی نداره. کل عملیات روی پایگاه داده وردپرس خودت انجام می‌شه و هاست اشتراکی هم کاملاً باهاش کنار میاد. برای سایت‌هایی که می‌خوان بخش اعضا داشته باشن، محتوای VIP برای کاربران ثبت‌نامی بذارن، یا به ادیتورها و نویسنده‌ها دسترسی محدود بدن، این افزونه بدون هیچ دردسر تحریم یا فیلتری کار می‌کنه. اگه بعداً خواستی سیستم پرداخت اضافه کنی، می‌تونی Members رو با درگاه‌های ایرانی از طریق افزونه‌های واسط ترکیب کنی. ولی محدودیت‌هاش رو هم باید بدونی. Members اساساً یه ویرایشگر نقش و یه ابزار محدودسازی محتواست؛ سیستم پرداخت، ثبت‌نام خودکار اعضا، یا مدیریت اشتراک نداره. اگه دنبال یه سیستم عضویت پولی کامل هستی، باید کنارش یه افزونه دیگه هم نصب کنی. ضمناً بعضی کاربرها گزارش دادن که با وجود فعال‌کردن همه افزودنی‌ها، کنترل دسترسی روی فیلدهای خیلی خاص (مثل مخفی‌کردن موجودی انبار از دید نقش خاص در ووکامرس) هنوز پشتیبانی نمی‌شه. توصیه عملی: اگه سایتت چند سطح کاربری داره یا می‌خوای بخشی از محتوا رو فقط برای اعضای لاگین‌کرده نشون بدی، حتماً نصبش کن. اگه دنبال سیستم اشتراک پولی با درگاه پرداخت هستی، Members به‌تنهایی کافی نیست.
راهنمای نصب افزونه
- فایل ZIP افزونه را با کلیک روی دکمه «دانلود نسخه 3.2.26» در بالای همین صفحه دریافت کنید. فایل از سرور WPFORIRAN در ایران ارائه می‌شود و نیاز به VPN ندارد.
- وارد پنل مدیریت وردپرس خود شوید و به مسیر «افزونه‌ها → افزودن → بارگذاری افزونه» بروید.
- فایل ZIP دانلود شده (members-3.2.26.zip) را انتخاب و آپلود کنید.
- پس از پایان نصب، روی دکمه «فعال‌سازی افزونه» کلیک کنید.
- افزونه ممبرز - ویرایشگر نقش کاربری Members اکنون آماده استفاده است. برای تنظیمات، به منوی مربوطه در پنل وردپرس مراجعه کنید.
تغییرات نسخه 3.2.26
- Fixed: On the user profile / edit-user screen with Multiple User Roles enabled, the role checkboxes could appear to have no checkmark — looking “unresponsive” — when another plugin’s admin CSS overrode core checkbox styles (e.g. line-height: 0). The checkboxes always toggled and saved; only the checkmark was hidden. The Members role checkboxes now defensively assert their own rendering so the checkmark shows regardless of such global overrides.
- Fixed: Hardened the Multiple User Roles save against a possible PHP 8 TypeError from malformed submitted role data (a nested array reaching members_sanitize_role()).
- Fixed: Saving a post via the REST API as a user without the restrict_content capability (e.g. custom roles, Gutenberg + ACF Pro) failed with “Sorry, you are not allowed to edit the _members_access_role custom field,” and silently dropped other meta such as ACF fields. The request pre-processor was hooked to a non-existent action (rest_before_insert_{$post_type}) so it never ran; it now correctly strips the Content Permissions meta keys for users who cannot manage them, before the save.
- Fixed: The REST protected-posts exclusion scoped its restriction lookup to the queried post type, so posts inheriting a restriction from an ancestor of a different post type were not excluded, making X-WP-Total / pagination counts inaccurate. All restriction roots are now considered regardless of post type.