قطعه کد غیرفعال کردن ویرایش فایل وردپرس

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

چرا ویرایشگر پیشخوان، یک درِ پشتی است

وردپرس از همان نسخه‌های اولیه، یک ویرایشگر فایل داخلی در پیشخوان دارد که از مسیر «نمایش ← ویرایشگر فایل‌های پوسته» یا «افزونه‌ها ← ویرایشگر افزونه» قابل دسترسی است. کاربرد این ابزار، در ابتدا ساده بود: مدیر سایت بتواند بدون نیاز به FTP یا SSH، یک تغییر کوچک در فایل functions.php یا یک قالب بدهد. این قابلیت، در سال‌های اول وردپرس که دسترسی FTP در همه‌جا فراهم نبود، ارزش کاربردی بالایی داشت.

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

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

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

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

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

ثابت DISALLOW_FILE_EDIT دقیقاً چه کاری می‌کند؟

وردپرس برای حل این مشکل، یک ثابت ساده در نظر گرفته است: DISALLOW_FILE_EDIT. اگر این ثابت روی مقدار true تنظیم شود، وردپرس سه کار مشخص انجام می‌دهد:

منوی «ویرایشگر فایل‌های پوسته» را از بخش «نمایش» حذف می‌کند.
منوی «ویرایشگر افزونه» را از بخش «افزونه‌ها» حذف می‌کند.
اگر کسی به‌طور مستقیم نشانی theme-editor.php یا plugin-editor.php را در مرورگر وارد کند، دسترسی را رد می‌کند.

نکتهٔ کلیدی: این ثابت، ویرایشگر را برای همهٔ کاربران — از جمله مدیر سایت — غیرفعال می‌کند. تنها راه ویرایش فایل‌ها، استفاده از FTP، SSH یا ویرایشگر محلی روی سیستم توسعه‌دهنده است. این تصمیم، به‌نظر سختگیرانه می‌آید ولی در عمل، همان‌قدر که در پروژه‌هایم کارآمد بوده، در پروژه‌های مشتریان هم بازگشت سرمایهٔ امنیتی بالایی داشته است. توضیح کلی این نوع ثابت‌ها در امن‌سازی فایل wp-config در وردپرس آمده است.

یک نکتهٔ ظریف که اکثر مقالات فارسی از آن رد می‌شوند: این ثابت، فایل wp-config.php خودش را از ویرایش محافظت نمی‌کند؛ چون ویرایشگر پیشخوان اصلاً فایل‌های ریشه را قابل ویرایش نمی‌کند. پس DISALLOW_FILE_EDIT روی فایل‌های پوسته و افزونه اثر دارد، نه روی کل ریشهٔ سایت. این تفکیک، در ارزیابی واقعی‌بودن لایهٔ امنیتی اهمیت دارد.

قطعه کد پایه: سه خط که یک لایهٔ امنیتی می‌سازد

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

if ( ! defined( 'DISALLOW_FILE_EDIT' ) ) {
    define( 'DISALLOW_FILE_EDIT', true );
}

سه نکتهٔ کلیدی در همین سه خط. اول، بررسی ! defined پیش از تعریف. این شرط جلوی خطای «دوباره‌تعریف ثابت» را می‌گیرد؛ اگر همان ثابت در جای دیگری از پروژه — مثلاً در فایل wp-config.php یا در افزونهٔ دیگری — از قبل تنظیم شده باشد، این کد به‌آرامی از ادامهٔ کار دست می‌کشد و پیام خطا نمی‌دهد. دوم، استفاده از define به‌جای فیلتر یا هوک؛ چون ثابت‌ها باید پیش از بارگذاری کامل هستهٔ وردپرس تنظیم شوند. این یعنی محل قرارگیری این کد، تعیین‌کنندهٔ کارکردش است. سوم، انتخاب مقدار true که هدف نهایی این قطعه کد است.

در تجربهٔ خودم، بیشترین اشتباه در استفاده از این اسنیپت، فراموش‌کردن همان خط اول است. اسنیپتی که بدون بررسی defined نوشته شود، در پروژه‌هایی که همین ثابت قبلاً در wp-config.php تنظیم شده، خطای Fatal Error می‌دهد. این خطای کوچک، یک سایت سالم را به صفحهٔ سفید تبدیل می‌کند. نحوۀ اصولی نوشتن این نوع اسنیپت‌ها در چگونه قطعه کد وردپرس را ایمن اجرا کنیم با جزئیات بیشتر آمده است.

محل درست: wp-config.php یا mu-plugins؟

قطعه کد غیرفعال‌سازی ویرایش فایل، دو محل درست برای قرارگیری دارد که هرکدام ویژگی‌های متفاوتی دارند:

محل اول: فایل wp-config.php

این محل، فایل اصلی تنظیمات وردپرس است و در ریشهٔ سایت قرار دارد. مزیت این محل، بارگذاری زودهنگام است: wp-config.php پیش از هستهٔ وردپرس بارگذاری می‌شود، بنابراین ثابت‌های تنظیم‌شده در آن، در همه‌جای سایت قابل دسترسی هستند. مثال:

/* Add any custom values between this line and the "stop editing" line. */
define( 'DISALLOW_FILE_EDIT', true );
/* That's all, stop editing! Happy publishing. */

سه نکتهٔ کلیدی در این روش. اول، محل قرارگیری خط define — باید پیش از خط «That's all, stop editing!» باشد، نه بعد از آن. دوم، عدم استفاده از کامنت طولانی، چون این فایل، نه جایی برای مستندسازی، بلکه فایلی حساس برای تنظیمات پایه است. سوم، خالی از شرط if ( ! defined ) بودن این روش؛ چون این خط در فایل wp-config.php یک‌بار اجرا می‌شود و احتمال دوباره‌تعریف بسیار کم است. اگر با ساختار این فایل آشنایی ندارید، امن‌سازی فایل wp-config در وردپرس توضیح کاملی دارد.

محل دوم: پوشهٔ mu-plugins

پوشهٔ wp-content/mu-plugins، جای ویژه‌ای برای افزونه‌های «Must-Use» است. افزونه‌هایی که در این پوشه قرار می‌گیرند، به‌طور خودکار و بدون نیاز به فعال‌سازی از پیشخوان، بارگذاری می‌شوند. مزیت این محل برای اسنیپت‌های امنیتی، واضح است: کسی نمی‌تواند این ثابت را با غیرفعال کردن یک افزونه در پیشخوان از کار بیندازد. برای این کار، یک فایل با نام دلخواه (مثلاً wphk-security.php) در پوشهٔ mu-plugins بسازید و اسنیپت را در آن قرار دهید:

<?php
/**
 * Plugin Name: WPHK Security Base
 * Description: Basic security settings for WordPress.
 */

if ( ! defined( 'DISALLOW_FILE_EDIT' ) ) {
    define( 'DISALLOW_FILE_EDIT', true );
}

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

توصیهٔ من در پروژه‌های مشتریان: از روش mu-plugins استفاده کنید، چون در تعویض قالب یا تغییر ساختار سایت پایدار می‌ماند و به‌طور صریح مستند می‌شود. روش wp-config.php برای پروژه‌های ساده‌تر و کوتاه‌مدت مناسب‌تر است. تفاوت‌ها و کاربردهای چایلد تم نیز در قالب وردپرس چایلد چیست و چه زمانی به آن نیاز داریم آمده است.

تفاوت DISALLOW_FILE_EDIT و DISALLOW_FILE_MODS

در کنار DISALLOW_FILE_EDIT، ثابت دیگری هم وجود دارد که گاهی با آن اشتباه گرفته می‌شود: DISALLOW_FILE_MODS. تفاوت این دو، از نظر کاربرد، اساسی است:

ثابت	اثر	مناسب برای
`DISALLOW_FILE_EDIT`	فقط ویرایشگر پیشخوان را غیرفعال می‌کند	پروژه‌های معمولی که به آپدیت و نصب افزونه نیاز دارند
`DISALLOW_FILE_MODS`	ویرایشگر پیشخوان، نصب و آپدیت افزونه و قالب را غیرفعال می‌کند	پروژه‌های حساس که مدیریت تغییرات کاملاً دستی است

معنی این تفاوت در عمل چیست؟ اگر DISALLOW_FILE_MODS را روی true بگذارید، وردپرس نه‌فقط ویرایشگر پیشخوان، بلکه امکان آپدیت افزونه‌ها و قالب‌ها را هم از پیشخوان حذف می‌کند. این تصمیم، در پروژه‌های سازمانی که آپدیت‌ها فقط از طریق گیت و CI/CD انجام می‌شوند منطقی است، ولی در پروژه‌های معمولی، مدیریت سایت را پیچیده می‌کند و آپدیت امنیتی را به تأخیر می‌اندازد.

در تجربهٔ خودم، برای ۹۰٪ سایت‌های مشتریان، فقط DISALLOW_FILE_EDIT را استفاده می‌کنم. DISALLOW_FILE_MODS را فقط در پروژه‌های سازمانی یا پروژه‌هایی که مشتری به‌طور صریح خواسته، فعال کرده‌ام. دلیل این تصمیم: آپدیت به‌موقع افزونه‌ها، بزرگ‌ترین لایهٔ امنیتی است، و محدود کردن آن می‌تواند بیشتر از ویرایشگر پیشخوان خطرآفرین باشد. توضیح این تفکر در راهنمای امنیت وردپرس برای مبتدیان آمده است.

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

پس از غیرفعال‌سازی، چه چیزهایی تغییر می‌کند؟

پس از اعمال این اسنیپت، چند تغییر قابل مشاهده در سایت ایجاد می‌شود که ارزش دارد آن‌ها را بشناسید تا نگران نباشید:

تغییر اول: ناپدید شدن منوها

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

تغییر دوم: پیام‌های خطا در دسترسی مستقیم

اگر کسی به‌طور مستقیم آدرس /wp-admin/theme-editor.php یا /wp-admin/plugin-editor.php را وارد کند، وردپرس پیام «شما مجاز به ویرایش فایل‌ها نیستید» یا مشابهش را نمایش می‌دهد. این پیام، در ابتدا ممکن است نگران‌کننده به‌نظر برسد، ولی در واقع نشانهٔ کارکرد درست اسنیپت است.

تغییر سوم: عدم تأثیر روی سایر قابلیت‌ها

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

محدودیت‌ها: این قطعه کد چه چیزی را حل نمی‌کند

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

محدودیت اول: دسترسی از طریق FTP/SSH. این اسنیپت، فقط ویرایشگر پیشخوان را می‌بندد. اگر مهاجم به حساب FTP یا SSH شما دسترسی پیدا کند، می‌تواند فایل‌ها را آزادانه ویرایش کند. بنابراین، امنیت FTP و SSH، لایهٔ جداگانهٔ امنیتی است که در کنار این اسنیپت باید جدی گرفته شود. راهنمای کامل این لایه در بهترین افزونه‌های امنیتی وردپرس برای محافظت از سایت آمده است.

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

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

محدودیت چهارم: نبود شرط defined. اگر اسنیپت شما بدون بررسی defined نوشته شده باشد و همان ثابت در جای دیگری تنظیم شده باشد، ممکن است سایت با خطای Fatal Error روبرو شود. این نکته، در بخش نمونهٔ کد به آن پرداختیم و بارها تکرار می‌کنم: همیشه با بررسی defined شروع کنید.

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

ترکیب با سایر لایه‌های امنیتی

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

احراز هویت دو مرحله‌ای (2FA) برای مدیران: این لایه، مهم‌ترین لایهٔ دفاعی در برابر دسترسی غیرمجاز به پیشخوان است. حتی اگر رمز مدیر فاش شود، 2FA می‌تواند جلوی ورود را بگیرد. راهنمای عملی در امن‌سازی لاگین ادمین در وردپرس.
محدودسازی تلاش‌های ورود: بدون این لایه، مهاجم می‌تواند با Brute Force رمز را پیدا کند و از طریق پیشخوان وارد شود. جزئیات در جلوگیری از حملات Brute Force در وردپرس.
به‌روزرسانی منظم: این اسنیپت را نباید جایگزین به‌روزرسانی افزونه‌ها و هسته در نظر گرفت. هفته‌ای یک بار، فهرست به‌روزرسانی‌های موجود را مرور کنید. اگر با فرآیند ساده‌سازی مواجه شدید، چگونه افزونه‌های وردپرس را ایمن به‌روزرسانی کنیم مرجع خوبی است.
بکاپ منظم: این لایه، آخرین سنگر دفاعی است. حتی اگر همهٔ لایه‌ها شکست بخورد، بکاپ سالم می‌تواند سایت را نجات دهد. توضیح در چگونه از سایت وردپرسی بکاپ بگیریم و بهترین افزونه‌های پشتیبان‌گیری وردپرس.
اسکن دوره‌ای بدافزار: حتی با همهٔ لایه‌ها، اسکن منظم می‌تواند بدافزارهای پنهان را کشف کند. ابزارها در بهترین ابزارهای اسکن بدافزار.
حذف فایل‌های اضافی: پیش از هر چیز، فایل‌هایی مثل readme.html و license.txt را از ریشهٔ سایت حذف کنید یا دسترسی‌شان را مسدود کنید. اگر با این روش آشنایی ندارید، قطعه کد حذف نسخه وردپرس از سایت نکات مفیدی دارد.

در کنار این لایه‌ها، مدیریت رمز عبور امن نیز پایه‌ای است. اصول آن در اصول مدیریت رمز عبور امن آمده است.

اشتباهات رایج در استفاده از این قطعه کد

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

اشتباه	پیامد واقعی	اصلاح
نبود بررسی `defined` پیش از تعریف ثابت	Fatal Error در پروژه‌های چند‌افزونه‌ای	افزودن شرط در ابتدای اسنیپت
قرار دادن اسنیپت در فایل قالب والد	ناپدیدشدن با آپدیت قالب	استفاده از `wp-config.php` یا `mu-plugins`
فعال‌کردن `DISALLOW_FILE_MODS` بدون درک اثرش	غیرفعال‌شدن آپدیت افزونه از پیشخوان	محدود کردن به شرایط سازمانی
باور «حذف ویرایشگر = امنیت کامل»	غفلت از لایه‌های اصلی امنیت	ترکیب با 2FA، بکاپ، به‌روزرسانی
نبود مستندسازی در فایل	فراموشی دلیل این خط در ماه‌های بعد	کامنت توضیحی در بالای اسنیپت
نبود نسخه‌بندی در گیت	عدم امکان بازگشت در صورت بروز مشکل	نگهداری فایل در مخزن گیت

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

دو پروندهٔ واقعی از پروژه‌ها

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

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

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

پروندهٔ دوم: سایتی که با یک آپدیت، اسنیپت از کار افتاد

در پروژهٔ دیگری، تیم قبلی اسنیپت را بدون بررسی defined نوشته بود. مدیر سایت پیش‌تر در فایل wp-config.php همین ثابت را تنظیم کرده بود، ولی از قضا یادش رفته بود. آپدیت افزونه‌ای باعث شد اسنیپت دوباره اجرا شود و سایت با خطای «Cannot redeclare function» مواجه شود. راه‌حل: بازگرداندن فایل از بکاپ، سپس بازنویسی اسنیپت با بررسی defined. این پرونده، برای من درس مهمی داشت: کوچک‌ترین اسنیپت هم اگر بدون اصول نوشته شود، می‌تواند سایت را از کار بیندازد. مسیر رفع این نوع خطاها در چگونه خطای قالب وردپرس را عیب‌یابی کنیم و رفع خطای Fatal error بعد از فعال‌سازی افزونه آمده است.

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

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

قطعه کد غیرفعال کردن ویرایش فایل وردپرس، یکی از کوتاه‌ترین ولی مؤثرترین اسنیپت‌های امنیتی است. در سه خط، یک مسیر مستقیم به کد اجرایی سایت را می‌بندد. محل درست این اسنیپت، wp-config.php یا پوشهٔ mu-plugins است، نه فایل قالب. تفاوت DISALLOW_FILE_EDIT و DISALLOW_FILE_MODS در این است که اولی فقط ویرایشگر پیشخوان را می‌بندد و دومی همهٔ امکان نصب و آپدیت از پیشخوان را. برای اکثر پروژه‌ها، فقط اولی کافی است. محدودیت‌های این اسنیپت (دسترسی FTP/SSH، دیتابیس، افزونه‌های آسیب‌پذیر) در کنار سایر لایه‌های امنیتی (2FA، محدودسازی ورود، بکاپ، اسکن بدافزار) باید پوشش داده شوند. و در نهایت، نوشتن اصولی این اسنیپت (بررسی defined، مستندسازی، نگهداری در گیت) به همان اندازهٔ خودش اهمیت دارد.

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