در پروژه‌ای برای یک مجله آنلاین، سردبیر محتوایی یک روز صبح با ناراحتی زنگ زد: «ویرایشگر نوشته‌ها پر از کادرهایی است که نمی‌دانم چه‌کار می‌کنند و هر بار باید از میانشان دنبال چیزی بگردم که واقعاً نیاز دارم.» وقتی ویرایشگر را باز کردم، متوجه شدم مشکل از خود وردپرس نبود؛ سه افزونهٔ جانبی، هرکدام دو یا سه متاباکس به ویرایشگر اضافه کرده بودند — از ابزارهای سئو تا ویجت‌های اشتراک‌گذاری و آمار — و مجموعشان ویرایشگر را به یک صفحهٔ شلوغ و گیج‌کننده تبدیل کرده بود. راه‌حل، آن‌قدر ساده بود که اول باور نکرد: یک اسنیپت کوچک که با چند خط کد، سه یا چهار متاباکس غیرضروری را از دید نویسنده‌ها پنهان می‌کرد. همان تجربه، یک قاعدهٔ کوچک در کارم ساخت: پیش از هر افزودن قابلیت، بررسی کن ویرایشگر چه چیزی را تحمل می‌کند، نه اینکه فقط چه چیزی را می‌خواهد. در این مقاله، دقیقاً همان موضوع را با هم مرور می‌کنیم: قطعه کد حذف متاباکس‌های اضافی وردپرس چه کاری انجام می‌دهد، با چه هوک‌هایی کار می‌کند، چطور براساس نقش کاربر و نوع نوشته اعمال شرطی شود، و چه ملاحظات سازگاری و پایداری در آن وجود دارد. اگر با مفهوم پایهٔ اسنیپت آشنا نیستید، پیش از ادامه قطعه کد وردپرس چیست و چگونه از آن استفاده کنیم نقطهٔ شروع بهتری است.

چرا حذف متاباکس‌های اضافی، یک تصمیم ویرایشی است، نه فقط فنی

حذف متاباکس‌های اضافی، در نگاه اول یک تصمیم فنی به‌نظر می‌رسد؛ ولی در تجربهٔ من، بیشتر یک تصمیم ویرایشی و تجربی است. سه دلیل که این تصمیم را جدی می‌گیرم:

دلیل اول: کاهش بار شناختی نویسنده. ویرایشگر وردپرس، پیش از افزودن هر افزونه، حدود شش تا ده متاباکس دارد. با نصب چند افزونهٔ رایج، این تعداد می‌تواند به بیست یا بیشتر برسد. برای نویسنده‌ای که روزانه چند نوشته می‌نویسد، این حجم از اطلاعات، تمرکز را از خود نوشتن می‌گیرد. در پروژه‌ای، مدیر محتوایی از من پرسید: «چرا نویسنده‌های ما هر نوشته را با یک ساعت تأخیر منتشر می‌کنند؟» بررسی نشان داد نیمی از آن تأخیر، صرف گشتن در میان متاباکس‌های بی‌ربط می‌شد.

دلیل دوم: کاهش خطای انسانی. هر متاباکس اضافه، یک فرصت برای خطاست. در پروژه‌ای، نویسنده‌ای که در متاباکس اشتباهی وارد شده بود، تنظیمات سئوی نوشته را به‌هم ریخت و وقتی متوجه شد، چند نوشتهٔ منتشرشده آسیب دیده بود. اگر آن متاباکس برای این نقش پنهان شده بود، این اتفاق نمی‌افتاد.

دلیل سوم: سرعت بارگذاری ویرایشگر. هر متاباکس، در بارگذاری ویرایشگر یک یا چند فایل CSS/JS اضافه می‌کند. در ویرایشگرهایی که پانزده یا بیست متاباکس دارند، این فایل‌ها می‌توانند مجموعاً چند صد کیلوبایت باشند. حذف متاباکس‌های اضافه، به‌طور محسوس بارگذاری ویرایشگر را سریع‌تر می‌کند. تحلیل تفصیلی این اثر در افزونه‌های وردپرس چگونه روی سرعت سایت اثر می‌گذارند آمده است.

متاباکس اضافه، مثل برگهٔ اضافه در دفتر کار نویسنده است. او وقتی می‌خواهد چیزی بنویسد، اول باید کل دفتر را ورق بزند تا صفحهٔ سفید پیدا کند. هرچه دفتر ضخیم‌تر، نوشتن کندتر.

متاباکس دقیقاً چیست؟

متاباکس (Metabox) یک کادر یا پنل قابل‌فروکشی در ویرایشگر نوشته یا صفحه‌های پیشخوان است که اطلاعات یا ابزارهای مرتبط با نوشته را نمایش می‌دهد. از دیدگاه فنی، متاباکس یک عنصر رابط کاربری است که با توابع add_meta_box و remove_meta_box مدیریت می‌شود. در وردپرس، سه دستهٔ اصلی متاباکس وجود دارد:

  • متاباکس‌های محتوایی: در ویرایشگر نوشته یا برگه نمایش داده می‌شوند و اطلاعات نوشته را مدیریت می‌کنند (مثل متاباکس «انتشار»، «دسته‌بندی»، «تصویر شاخص»).
  • متاباکس‌های پیشخوان: در صفحهٔ پیشخوان یا Dashboard نمایش داده می‌شوند (مثل «به یک نگاه»، «اخبار وردپرس»، «پیش‌نویس سریع»).
  • متاباکس‌های افزونه‌ها: توسط افزونه‌های جانبی اضافه می‌شوند و می‌توانند در هر بخشی از پیشخوان باشند (مثل متاباکس سئو، آمار، اشتراک‌گذاری).

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

متاباکس‌های پیش‌فرض وردپرس: نقشهٔ اولیه

پیش از هر تغییری، باید بدانید وردپرس چه متاباکس‌هایی را به‌طور پیش‌فرض نمایش می‌دهد. این آگاهی، از حذف متاباکس‌های ضروری جلوگیری می‌کند:

متاباکسشناسهمحل نمایش
انتشارsubmitdivویرایشگر نوشته، ستون کنار
دسته‌بندی‌هاcategorydivویرایشگر نوشته، ستون کنار
برچسب‌هاtagsdiv-post_tagویرایشگر نوشته، ستون کنار
تصویر شاخصpostimagedivویرایشگر نوشته، ستون کنار
چکیدهpostexcerptویرایشگر نوشته، بخش اصلی
اسلاگslugdivویرایشگر نوشته، بخش اصلی
به یک نگاهdashboard_right_nowپیشخوان، بخش اصلی
پیش‌نویس سریعdashboard_quick_pressپیشخوان، ستون کنار

سه نکتهٔ کلیدی در این جدول. اول، شناسهٔ هر متاباکس (پارامتر اول remove_meta_box) دقیقاً همان نامی است که در جدول آمده؛ اگر یک حرف اشتباه باشد، متاباکس حذف نمی‌شود و وردپرس هیچ پیام خطایی نمی‌دهد. دوم، برخی متاباکس‌ها در «ستون کنار» و برخی در «بخش اصلی» ویرایشگر نمایش داده می‌شوند؛ پارامتر سوم remove_meta_box باید با محل نمایش مطابق باشد (side، normal، یا advanced). سوم، فهرست بالا تنها متاباکس‌های پیش‌فرض وردپرس است؛ افزونه‌های جانبی می‌توانند ده‌ها متاباکس دیگر اضافه کنند که شناسه‌هایشان متفاوت است. توضیح تکمیلی دربارهٔ ساختار داخلی پیشخوان در قطعه کد افزودن ستون سفارشی به مدیریت وردپرس آمده است.

تابع remove_meta_box: پایه‌ای‌ترین ابزار

ابزار اصلی برای حذف متاباکس، تابع remove_meta_box است. این تابع سه پارامتر می‌گیرد:

remove_meta_box( $id, $screen, $context );

سه نکتهٔ کلیدی دربارهٔ این پارامترها. اول، $id شناسهٔ متاباکس است که در فهرست بالا نمونه‌هایی از آن را دیدیم. دوم، $screen نام صفحه‌ای است که متاباکس در آن نمایش داده می‌شود؛ برای ویرایشگر نوشته، مقدار 'post' است و برای صفحه‌ها 'page' و برای هر نوع سفارشی، نام آن نوع. سوم، $context محل نمایش متاباکس است که می‌تواند 'normal'، 'side' یا 'advanced' باشد. اگر این مقدار با محل واقعی مطابقت نداشته باشد، حذف انجام نمی‌شود.

الگوی ساده‌ترین استفاده:

add_action( 'add_meta_boxes', 'wphk_remove_simple_metabox' );

function wphk_remove_simple_metabox() {
    remove_meta_box( 'slugdiv', 'post', 'normal' );
}

سه نکتهٔ کلیدی در همین نمونهٔ کوچک. اول، استفاده از هوک add_meta_boxes که نقطهٔ استاندارد مدیریت متاباکس‌ها است. دوم، پارامتر سوم 'normal' که محل واقعی نمایش متاباکس slugdiv در ویرایشگر نوشته است. سوم، اگر این تابع را در هوک دیگری مثل init اجرا کنید، متاباکس حذف نمی‌شود؛ چون در آن زمان، متاباکس‌ها هنوز ثبت نشده‌اند. این نکته، در پروژه‌های مختلف بارها به آن برخورده‌ام که توسعه‌دهنده کد را در هوک اشتباهی قرار داده و به‌جای دیباگ، فرض کرده تابع کار نمی‌کند. الگوهای مشابه برای مدیریت متاباکس‌های سفارشی در کار با متاباکس‌ها در کدنویسی وردپرس آمده است.

هوک‌های مسئول: از add_meta_boxes تا do_meta_boxes

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

هوکزمان اجراکاربرد اصلی
add_meta_boxesپس از ثبت همهٔ متاباکس‌هاافزودن یا حذف متاباکس‌ها
add_meta_boxes_{$post_type}پس از ثبت متاباکس‌های نوع خاصافزودن یا حذف متاباکس‌های یک نوع نوشته
do_meta_boxesپیش از رندر متاباکس‌هاذخیره‌سازی یا شرطی‌سازی نمایش
save_postهنگام ذخیرهٔ نوشتهذخیره‌سازی مقدار متاباکس

سه نکتهٔ کلیدی در این نقشه. اول، هوک add_meta_boxes بهترین نقطه برای حذف متاباکس است، چون در این لحظه، همهٔ متاباکس‌ها ثبت شده‌اند ولی هنوز رندر نشده‌اند. دوم، هوک اختصاصی add_meta_boxes_{$post_type} به شما امکان می‌دهد تنها برای یک نوع نوشتهٔ خاص اقدام کنید. سوم، در کنار این هوک‌ها، توجه به اولویت اجرا اهمیت دارد؛ اگر افزونه‌ای در اولویت ۱۰ متاباکس خودش را ثبت کند و شما در اولویت ۱۰ حذف کنید، بستگی به ترتیب ثبت دارد. توصیه: از اولویت بالاتر (مثلاً ۹۹) استفاده کنید تا مطمئن شوید همهٔ متاباکس‌ها پیش از حذف، ثبت شده‌اند. توضیح این مفهوم در Priority در هوک‌های وردپرس چیست آمده است.

حذف متاباکس برای نوع نوشتهٔ خاص

در پروژه‌های با چند نوع نوشته، برخی متاباکس‌ها در برخی انواع بی‌معنی هستند. مثلاً متاباکس «برچسب‌ها» برای نوع نوشتهٔ «محصول» ممکن است کاربرد نداشته باشد. الگوی اعمال محدود به یک نوع نوشته:

/**
 * Snippet: Remove unnecessary metaboxes per post type.
 *
 * @since 2026-09-16
 * @author WordPressKar
 *
 * Purpose: Remove tags metabox from products and portfolio post types.
 * Location: mu-plugins directory or child theme functions.php.
 */

add_action( 'add_meta_boxes', 'wphk_remove_metaboxes_per_post_type', 99 );

function wphk_remove_metaboxes_per_post_type() {
    // حذف متاباکس برچسب‌ها از محصولات
    remove_meta_box( 'tagsdiv-post_tag', 'product', 'side' );

    // حذف متاباکس چکیده از نمونه‌کارها
    remove_meta_box( 'postexcerpt', 'portfolio', 'normal' );

    // حذف متاباکس اسلاگ از رویدادها
    remove_meta_box( 'slugdiv', 'event', 'normal' );
}

چهار نکتهٔ کلیدی در این الگو. اول، استفاده از اولویت ۹۹ در هوک add_meta_boxes که تضمین می‌کند همهٔ متاباکس‌ها پیش از حذف، ثبت شده‌اند. دوم، تفکیک هر متاباکس با پارامتر دوم که نام نوع نوشته است؛ اگر این پارامتر اشتباه باشد، متاباکس حذف نمی‌شود. سوم، تفکیک پارامتر سوم براساس محل واقعی نمایش، نه براساس حدس. چهارم، استفاده از پیشوند اختصاصی در نام تابع که احتمال تعارض با افزونه‌های دیگر را به حداقل می‌رساند. برای مطالعهٔ ساختار انواع نوشتهٔ سفارشی، ساخت نوع نوشته سفارشی در وردپرس مرجع کاملی است.

اعمال شرطی براساس نقش کاربر

در پروژه‌های تیمی، همیشه ایدهٔ خوبی است که حذف متاباکس‌ها براساس نقش کاربر اعمال شود. مثلاً متاباکس سئو برای نقش «ویرایشگر» مفید است ولی برای نقش «نویسنده» ممکن است فقط سردرگمی ایجاد کند. الگوی اعمال شرطی:

add_action( 'add_meta_boxes', 'wphk_remove_metaboxes_by_role', 99 );

function wphk_remove_metaboxes_by_role() {
    if ( ! current_user_can( 'edit_others_posts' ) ) {
        // نویسنده‌ها: حذف متاباکس اسلاگ
        remove_meta_box( 'slugdiv', 'post', 'normal' );

        // نویسنده‌ها: حذف متاباکس چکیده
        remove_meta_box( 'postexcerpt', 'post', 'normal' );

        // نویسنده‌ها: حذف متاباکس دسته‌بندی‌های سفارشی
        remove_meta_box( 'wphk_categorydiv', 'post', 'side' );
    }

    if ( ! current_user_can( 'manage_options' ) ) {
        // مدیران: دسترسی به همه متاباکس‌ها دارند
        // سایر نقش‌ها: حذف متاباکس سئوی پیشرفته
        remove_meta_box( 'wphk_advanced_seo', 'post', 'normal' );
    }
}

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

حذف متاباکس‌های صفحهٔ پیشخوان

صفحهٔ پیشخوان وردپرس (Dashboard) نیز متاباکس‌های اختصاصی خودش را دارد که با هوک متفاوتی مدیریت می‌شود. برای حذف این متاباکس‌ها، از هوک wp_dashboard_setup استفاده کنید:

add_action( 'wp_dashboard_setup', 'wphk_clean_dashboard_metaboxes' );

function wphk_clean_dashboard_metaboxes() {
    // حذف متاباکس «به یک نگاه»
    remove_meta_box( 'dashboard_right_now', 'dashboard', 'normal' );

    // حذف متاباکس «فعالیت»
    remove_meta_box( 'dashboard_activity', 'dashboard', 'normal' );

    // حذف متاباکس «اخبار وردپرس»
    remove_meta_box( 'dashboard_primary', 'dashboard', 'side' );

    // حذف متاباکس «به‌روزرسانی»
    remove_meta_box( 'dashboard_secondary', 'dashboard', 'side' );

    // حذف متاباکس «پیش‌نویس سریع»
    remove_meta_box( 'dashboard_quick_press', 'dashboard', 'side' );
}

سه نکتهٔ کلیدی در این الگو. اول، پارامتر دوم همهٔ این متاباکس‌ها 'dashboard' است، چون در صفحهٔ پیشخوان نمایش داده می‌شوند. دوم، محل نمایش هر متاباکس با پارامتر سوم مطابقت دارد (بعضی 'normal' و بعضی 'side'). سوم، اگر تنها برای نقش‌های خاصی می‌خواهید این متاباکس‌ها حذف شوند، شرط current_user_can را در ابتدای تابع اضافه کنید. یک نکتهٔ عملی: در پروژه‌های خودم، این اسنیپت را با افزودن یک متاباکس ساده خوش‌آمدگویی ترکیب می‌کنم تا تجربهٔ کاربری غیرمدیر‌ها انسانی‌تر باشد. الگوهای مشابه در قطعه کد مخفی کردن منوی مدیریت وردپرس آمده است.

متاباکس‌ها و ویرایشگر گوتنبرگ

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

  • متاباکس‌های PHP کلاسیک: همان متاباکس‌هایی که با add_meta_box ثبت می‌شوند و در بخش «افزودنی‌های» (Plugins) پایین ویرایشگر نمایش داده می‌شوند.
  • پنل‌های بومی گوتنبرگ: که در ستون کنار ویرایشگر به‌شکل پنل‌های بومی نمایش داده می‌شوند و با توابع متفاوتی مدیریت می‌شوند.

خبر خوب اینکه تابع remove_meta_box روی هر دو نوع اثر می‌گذارد. یعنی برای حذف متاباکس‌های PHP کلاسیک و پنل‌های بومی که با APIهای قدیمی ثبت شده‌اند، همین تابع کافی است. ولی پنل‌هایی که با APIهای جدید گوتنبرگ (مثل PluginDocumentSettingPanel) ثبت شده‌اند، با روش متفاوتی حذف می‌شوند که بیشتر از حیطهٔ این مقاله است. برای مطالعهٔ عمیق‌تر این حوزه، گوتنبرگ و آینده ویرایش محتوا در وردپرس و بلوک‌های سفارشی گوتنبرگ را از صفر بسازید مراجع خوبی هستند.

یک نکتهٔ ظریف که در پروژه‌های اخیر به آن برخورده‌ام: در گوتنبرگ، کاربر می‌تواند از منوی تنظیمات ویرایشگر، نمایش پنل‌های کنار را شخصی‌سازی کند. اگر می‌خواهید مطمئن شوید که یک متاباکس در هیچ شرایطی نمایش داده نمی‌شود، حذف با remove_meta_box تنها راه قابل اتکا است.

حذف متاباکس‌های افزونه‌های جانبی

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

روش اول: جستجو در کد افزونه

در پوشهٔ افزونه، دنبال تابع add_meta_box بگردید. اولین پارامتر این تابع، شناسهٔ متاباکس است:

grep -rn "add_meta_box" wp-content/plugins/some-plugin/

خروجی این دستور، فهرستی از تمام فراخوانی‌های add_meta_box در آن افزونه را نشان می‌دهد. اولین پارامتر هر فراخوانی، شناسهٔ متاباکس است که باید در اسنیپت حذف استفاده کنید.

روش دوم: استفاده از افزونهٔ Query Monitor

افزونهٔ Query Monitor، فهرست تمام متاباکس‌های فعال در ویرایشگر را نمایش می‌دهد. با این ابزار، در چند ثانیه می‌توانید شناسهٔ هر متاباکس را ببینید بدون اینکه لازم باشد کد افزونه را جستجو کنید. توضیح تفصیلی این ابزار در دیباگ کردن Action و Filter در وردپرس آمده است.

روش سوم: استفاده از DevTools مرورگر

در ویرایشگر نوشته، با ابزار Developer Tools مرورگر، روی کادر متاباکس کلیک راست کنید و «Inspect» را انتخاب کنید. کلاس CSS این کادر معمولاً شامل شناسهٔ متاباکس است. مثلاً id="wphk_custom_field" به شما می‌گوید شناسه wphk_custom_field است.

نمونهٔ حذف متاباکس‌های افزونه‌های جانبی:

add_action( 'add_meta_boxes', 'wphk_remove_plugin_metaboxes', 99 );

function wphk_remove_plugin_metaboxes() {
    if ( current_user_can( 'manage_options' ) ) {
        return;
    }

    // حذف متاباکس سئوی یک افزونهٔ جانبی
    remove_meta_box( 'wphk_seo_metabox', 'post', 'normal' );

    // حذف متاباکس اشتراک‌گذاری اجتماعی
    remove_meta_box( 'wphk_social_metabox', 'post', 'side' );
}

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

چند نمونهٔ کاربردی از پروژه‌های واقعی

در پروژه‌های خودم، سه سناریوی زیر پرکاربردترین‌ها بوده‌اند و هرکدام نکتهٔ فنی خاصی دارند:

سناریوی اول: پاک‌سازی ویرایشگر برای تیم تحریریه

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

add_action( 'add_meta_boxes', 'wphk_clean_editor_for_writers', 99 );

function wphk_clean_editor_for_writers() {
    if ( current_user_can( 'edit_others_posts' ) ) {
        return;
    }

    remove_meta_box( 'slugdiv', 'post', 'normal' );
    remove_meta_box( 'postexcerpt', 'post', 'normal' );
    remove_meta_box( 'wphk_seo_metabox', 'post', 'normal' );
    remove_meta_box( 'wphk_social_metabox', 'post', 'side' );
}

سناریوی دوم: پاک‌سازی ویرایشگر محصولات

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

add_action( 'add_meta_boxes', 'wphk_clean_product_editor', 99 );

function wphk_clean_product_editor() {
    remove_meta_box( 'postexcerpt', 'product', 'normal' );
    remove_meta_box( 'slugdiv', 'product', 'normal' );
    remove_meta_box( 'tagsdiv-product_tag', 'product', 'side' );
}

سناریوی سوم: پاک‌سازی پیشخوان برای نقش‌های غیرمدیر

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

add_action( 'wp_dashboard_setup', 'wphk_clean_dashboard_for_editors' );

function wphk_clean_dashboard_for_editors() {
    if ( current_user_can( 'manage_options' ) ) {
        return;
    }

    remove_meta_box( 'dashboard_primary', 'dashboard', 'side' );
    remove_meta_box( 'dashboard_secondary', 'dashboard', 'side' );
    remove_meta_box( 'dashboard_quick_press', 'dashboard', 'side' );
}

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

محل درست قرارگیری این اسنیپت

مانند همهٔ اسنیپت‌های وردپرس، محل قرارگیری این کد هم تصمیم مهمی است. سه گزینه پیش روی شماست:

گزینهٔ اول: افزونهٔ اختصاصی یا mu-plugins. این اسنیپت به تجربهٔ پیشخوان مربوط است و بخشی از استراتژی کاربری سایت محسوب می‌شود؛ بنابراین جای طبیعی‌اش افزونهٔ اختصاصی است، نه فایل قالب. اگر با ساختار افزونهٔ اختصاصی آشنا نیستید، کدنویسی اختصاصی برای افزونه وردپرس و ساختار فایل‌های یک افزونه استاندارد وردپرس مراجع کاملی هستند.

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

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

الگوی عملی من در پروژه‌های خودم: تمام کدهای مرتبط با سفارشی‌سازی ویرایشگر و پیشخوان را در یک افزونهٔ اختصاصی به نام «wphk-admin-ui» نگه می‌دارم که هم حذف متاباکس‌ها را در خود دارد، هم سفارشی‌سازی منوها و هم ابزارک‌های سفارشی. این ساختار، در پروژه‌های چندساله، پایداری و مستندسازی را تضمین می‌کند. برای دیدن فهرست گسترده‌تری از اسنیپت‌های کاربردی، بهترین قطعه کدهای کاربردی وردپرس برای سایت‌ها مرجع خوبی است.

اشتباهات رایج در حذف متاباکس‌ها

در بازبینی سایت‌های مختلف، شش اشتباه تکراری در این حوزه دیده‌ام که هرکدام درس‌آموز است:

اشتباهپیامد واقعیاصلاح
نبود اولویت بالا در هوک add_meta_boxesمتاباکس دوباره ظاهر می‌شوداستفاده از اولویت ۹۹
استفاده از شناسهٔ اشتباه متاباکسمتاباکس حذف نمی‌شود بدون هیچ خطاییبررسی دقیق شناسه با Query Monitor
نبود تطابق پارامتر سوم (محل نمایش)حذف انجام نمی‌شودبررسی محل واقعی متاباکس
حذف متاباکس‌های ضروری مثل submitdivنوشته قابل انتشار نیستحذف تنها متاباکس‌های غیرضروری
حذف برای همهٔ کاربران، از جمله مدیرمدیر سایت هم متاباکس را از دست می‌دهدشرط current_user_can در ابتدای تابع
نبود پیشوند اختصاصی در نام توابعتعارض با افزونه‌های دیگرپیشوند یکتا مثل wphk_

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

مسیر پیشنهادی و نتیجه

قطعه کد حذف متاباکس‌های اضافی وردپرس، یکی از ساده‌ترین و در عین حال اثرگذارترین کارهای سفارشی‌سازی ویرایشگر و پیشخوان است. سه ستون این کار: استفاده از هوک add_meta_boxes با اولویت بالا برای حذف متاباکس‌های ویرایشگر، استفاده از wp_dashboard_setup برای متاباکس‌های پیشخوان، و اعمال شرطی براساس capability نه نام نقش. سه ملاحظهٔ مهم (دقت در شناسهٔ متاباکس، تطابق پارامتر محل نمایش، مستندسازی دقیق) در همهٔ اسنیپت‌های این حوزه باید رعایت شوند. و محل درست این اسنیپت، افزونهٔ اختصاصی یا mu-plugins است، نه فایل قالب والد.

گام بعدی عملی که پیشنهاد می‌کنم: در همین امروز، ویرایشگر نوشته‌ها یا محصولات سایت خود را باز کنید و از خودتان بپرسید کدام متاباکس واقعاً در کار روزمره استفاده می‌شود. اگر بین ده تا بیست متاباکس می‌بینید و نیمی از آن‌ها ماه‌هاست که لمس نشده‌اند، همین هفته می‌توانید با یک اسنیپت کوچک، آن‌ها را از دید نویسنده‌ها پنهان کنید. اگر تجربه‌ای با حذف متاباکس‌ها داشته‌اید — به‌ویژه اگر متاباکس خاصی از یک افزونهٔ جانبی حذف کرده‌اید و چالش شناسهٔ آن را حل کرده‌اید — برای من جالب است بدانید چطور به نتیجه رسیدید. تجربهٔ خودتان را در دیدگاه‌ها بنویسید؛ به‌ویژه اگر روش تمیزی برای مدیریت متاباکس‌های چند افزونه در پروژه‌های بزرگ پیدا کرده‌اید. 🧩