قطعه کد تغییر تعداد Revision های وردپرس

پروژه‌ای را به یاد می‌آورم که در آن، سایتی سه‌ساله با کمتر از پانصد نوشته، دیتابیسی بیش از دو گیگابایت داشت. هیچ افزونهٔ سنگینی روی آن نبود و هاست هم کیفیت مناسبی داشت. وقتی شروع به تحلیل جدول‌های دیتابیس کردم، متوجه شدم بیش از ۹۰ درصد حجم آن، ردیف‌هایی با نام post_type = 'revision' است. هر نوشته به‌طور میانگین حدود چهل نسخهٔ ذخیره‌شده داشت و بعضی نوشته‌های قدیمی، بالای دویست نسخه. جالب اینکه مدیر سایت هیچ‌وقت از این نسخه‌ها استفاده نکرده بود و حتی نمی‌دانست وجود دارند. با محدودسازی تعداد نسخه‌ها و پاک‌سازی نسخه‌های قدیمی، دیتابیس از دو گیگابایت به کمتر از ۲۰۰ مگابایت کاهش پیدا کرد و سرعت پیشخوان به‌طور محسوس بهبود یافت. آن پروژه، یک باور رایج را در کارم اصلاح کرد: اینکه «وردپرس به‌طور پیش‌فرض خوب تنظیم شده» درست نیست؛ بعضی تنظیمات پیش‌فرض، برای پروژه‌های کوچک مناسب است ولی در سایت‌های واقعی به یک بدهی پنهان تبدیل می‌شود. در این مقاله، دربارهٔ قطعه کد تغییر تعداد Revision های وردپرس صحبت می‌کنیم: این تنظیم دقیقاً چه کاری انجام می‌دهد، با چه ثابتی کنترل می‌شود، چگونه نسخه‌های قدیمی را پاک کنیم، و چه ملاحظات کارایی و امنیتی در آن وجود دارد. اگر با مفهوم پایهٔ اسنیپت آشنا نیستید، پیش از ادامه قطعه کد وردپرس چیست و چگونه از آن استفاده کنیم نقطهٔ شروع بهتری است.

Revision یا نسخهٔ ذخیره‌شده چیست؟

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

از دید فنی، هر Revision در جدول wp_posts یک ردیف با post_type = 'revision' است و در جدول wp_postmeta، ردیف‌های اضافی برای اطلاعات نسخه دارد. این یعنی هر Revision، در واقع چند ردیف دیتابیس اشغال می‌کند. در پروژه‌ای که ابتدای مقاله به آن اشاره کردم، هر نوشتهٔ قدیمی به‌طور میانگین چهل Revision داشت که معادل حدود دویست ردیف دیتابیس بود.

سه نکتهٔ کلیدی که در این مقاله به آن‌ها بازمی‌گردیم:

• Revision‌ها به‌طور خودکار ساخته می‌شوند؛ نیازی به تنظیم خاصی ندارند.
• تا وقتی نوشته را منتشر می‌کنید، هیچ Revision جدید ساخته نمی‌شود؛ فقط در ویرایش‌های بعدی.
• Revision‌ها در نسخه‌های پیش‌فرض، بی‌نهایت ذخیره می‌شوند — یعنی مشکلی که در ابتدای مقاله دیدم، پیش‌فرضِ وردپرس است، نه یک اشتباه کاربر.

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

چرا محدودسازی تعداد نسخه‌ها اهمیت دارد

محدود کردن تعداد Revision‌ها، سه دلیل مهم دارد که در پروژه‌های واقعی به آن‌ها برخورده‌ام:

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

دلیل دوم: سرعت پیشخوان. در ویرایشگر نوشته‌ها، وردپرس فهرست تمام Revision‌ها را بررسی می‌کند تا در صورت نیاز، گزینهٔ «مقایسهٔ نسخه‌ها» را نمایش دهد. اگر تعداد Revision‌ها زیاد باشد، این بررسی زمان می‌برد. در پروژه‌ای، باز کردن ویرایشگر یک نوشتهٔ قدیمی با ۲۵۰ Revision حدود پنج ثانیه طول می‌کشید؛ پس از پاک‌سازی و محدودسازی، این زمان به کمتر از یک ثانیه رسید.

دلیل سوم: سرعت کل سایت. حتی در front-end، کوئری‌هایی مثل فهرست نوشته‌ها یا دسته‌بندی‌ها، ممکن است با جدول wp_posts درگیر شوند. حجم زیاد Revision‌ها، روی کوئری‌های عمومی هم اثر می‌گذارد. تحلیل تفصیلی این اثر در تاثیر دیتابیس بر سرعت سایت چقدر است آمده است.

Revision‌ها، مثل نسخه‌های کاغذیِ یک نامهٔ اداری هستند. اگر هر پیش‌نویس را در کشو نگه دارید، یک روز کشو نمی‌بندد و شما باید نامه را در جای دیگری نگه دارید. Revision، همان کشو است.

ثابت WP_POST_REVISIONS: تنها ابزار رسمی

وردپرس برای محدودسازی تعداد Revision‌ها، یک ثابت اختصاصی در اختیار شما می‌گذارد: WP_POST_REVISIONS. این ثابت، در فایل wp-config.php یا در یک افزونهٔ mu-plugins تعریف می‌شود و کنترل می‌کند که وردپرس چه رفتاری با Revision‌ها داشته باشد. الگوی پایه:

/**
 * Snippet: Limit WordPress post revisions to 5.
 *
 * @since 2026-09-16
 * @author WordPressKar
 *
 * Purpose: Reduce database size by limiting revisions per post.
 * Location: wp-config.php (before 'That's all, stop editing!') or mu-plugins.
 */

if ( ! defined( 'WP_POST_REVISIONS' ) ) {
    define( 'WP_POST_REVISIONS', 5 );
}

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

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

مقادیر ممکن: true، false یا یک عدد؟

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

سه نکتهٔ کلیدی در این جدول. اول، مقدار پیش‌فرض وردپرس، true است که در عمل به‌معنای «بی‌نهایت» است. بیشتر پروژه‌ها از این پیش‌فرض بی‌خبرند و همین موضوع، دلیل اصلی انباشت Revision در سایت‌های قدیمی است. دوم، مقدار false در نگاه اول جذاب است ولی در تجربهٔ من توصیه نمی‌شود؛ چون در صورت اشتباه در ویرایش، هیچ راهی برای بازگشت به نسخهٔ قبلی وجود ندارد. سوم، انتخاب عدد مناسب، به ماهیت پروژه بستگی دارد که در ادامه به تفصیل می‌آید. برای مطالعهٔ مفهوم مشابه در بخش‌های دیگر، چگونه دیتابیس وردپرس را پاک‌سازی کنیم مرجع خوبی است.

محل درست تعریف ثابت: wp-config.php یا افزونه؟

ثابت WP_POST_REVISIONS دو محل درست برای قرارگیری دارد که هرکدام ویژگی‌های متفاوتی دارند:

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

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

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

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

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

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

<?php
/**
 * Plugin Name: WPHK Configuration
 * Description: Central configuration for WPHK-controlled sites.
 */

if ( ! defined( 'WP_POST_REVISIONS' ) ) {
    define( 'WP_POST_REVISIONS', 5 );
}

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

پاک‌سازی نسخه‌های قدیمی موجود

حتی با تعریف ثابت WP_POST_REVISIONS، نسخه‌های قدیمی که پیش از این تنظیم ایجاد شده‌اند، همچنان در دیتابیس باقی می‌مانند. این موضوع، در تجربهٔ من یکی از بزرگ‌ترین منابع سردرگمی کاربران است: «ثابت را تنظیم کردم ولی هنوز دیتابیسم بزرگ است.» سه راه برای پاک‌سازی Revision‌های قدیمی وجود دارد:

راه اول: استفاده از WP-CLI

اگر به SSH دسترسی دارید، WP-CLI راه سریع‌ترین و امن‌ترین مسیر است:

# حذف نسخه‌های اضافی براساس مقدار ثابت فعلی
wp post delete $(wp post list --post_type='revision' --format=ids) --force

# یا با افزونهٔ اختصاصی:
wp revision delete-all

سه نکتهٔ کلیدی. اول، پارامتر --force که Revision‌ها را به‌طور کامل حذف می‌کند، نه انتقال به سطل زباله. دوم، اجرای حذف در مراحل دسته‌ای برای جلوگیری از تایم‌اوت در سایت‌های حجیم. سوم، آزمایش روی محیط استجینگ پیش از اجرا روی سایت زنده. توضیح جامع این فرآیند در چگونه دیتابیس وردپرس را پاک‌سازی کنیم و تاثیر دیتابیس بر سرعت سایت چقدر است آمده است.

راه دوم: استفاده از افزونهٔ اختصاصی

برای کاربرانی که به SSH دسترسی ندارند، افزونه‌های پاک‌سازی دیتابیس مثل WP-Sweep، WP-Optimize یا افزونه‌های مشابه، این کار را با چند کلیک انجام می‌دهند. الگوی کار: نصب افزونه، رفتن به بخش «پاک‌سازی»، انتخاب گزینهٔ «حذف نسخه‌های اضافی» و اجرا. در پروژه‌های خودم، از این روش برای سایت‌های مشتریان که به SSH دسترسی ندارند استفاده می‌کنم. توضیح تفصیلی این افزونه‌ها در بهترین افزونه‌های بهینه‌سازی دیتابیس وردپرس آمده است.

راه سوم: کوئری مستقیم در دیتابیس

در مواردی که دسترسی به هر دو روش بالا ندارید، می‌توانید با یک کوئری SQL مستقیم، Revision‌ها را حذف کنید:

DELETE FROM wp_posts WHERE post_type = 'revision';
DELETE pm FROM wp_postmeta pm
  LEFT JOIN wp_posts p ON p.ID = pm.post_id
  WHERE p.ID IS NULL;

سه نکتهٔ کلیدی. اول، پیش از اجرای این کوئری، بکاپ کامل بگیرید. دوم، این کوئری، جدول wp_postmeta را هم تمیز می‌کند تا ردیف‌های یتیم باقی نمانند. سوم، این روش را فقط در موارد اضطراری استفاده کنید و بعد از آن، جدول‌ها را بهینه‌سازی (Optimize) کنید. الگوهای مشابه در بهینه‌سازی جداول MySQL برای سرعت بیشتر آمده است.

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

تفاوت Revision و Autosave

یکی از تفاوت‌های ظریف که در پروژه‌های واقعی زیاد به آن برخورده‌ام، تفاوت بین Revision و Autosave است. هر دو در جدول wp_posts ذخیره می‌شوند ولی رفتار متفاوتی دارند:

سه نکتهٔ کلیدی در این جدول. اول، Autosave به‌طور خودکار یک نسخهٔ جاری نگه می‌دارد و نسخهٔ قبلی را جایگزین می‌کند؛ بنابراین حجم آن، در مقایسه با Revision ناچیز است. دوم، ثابت WP_POST_REVISIONS روی Autosave اثری ندارد و اگر می‌خواهید رفتار آن را تغییر دهید، باید از فیلترهای اختصاصی مثل wp_revisions_to_keep استفاده کنید. سوم، در برخی پروژه‌های خاص که می‌خواهند Autosave را هم غیرفعال کنند، باید از فیلترهای جاوااسکریپت استفاده کرد که موضوع این مقاله نیست. توضیح تفصیلی این مکانیزم در ساختار هسته وردپرس چگونه کار می‌کند آمده است.

اثر بر کارایی سایت و دیتابیس

محدودسازی Revision‌ها، سه اثر مستقیم بر کارایی سایت دارد که در پروژه‌های خودم با عدد سنجیده‌ام:

اثر اول: کاهش حجم دیتابیس. این واضح‌ترین اثر است. در سایتی که در ابتدای مقاله به آن اشاره کردم، محدودسازی از بی‌نهایت به ۵ و پاک‌سازی Revision‌های قدیمی، حجم دیتابیس را از ۲.۳ گیگابایت به کمتر از ۲۰۰ مگابایت رساند. کاهش ۹۱٪ در حجم، اثر مستقیم بر زمان بکاپ، سرعت مهاجرت و کارایی کلی داشت.

اثر دوم: سرعت کوئری‌ها. در سایت‌های پرمحتوا، حتی کوئری‌های ساده مثل فهرست نوشته‌ها، ممکن است با جدول wp_posts درگیر شوند. حذف ردیف‌های اضافی، این کوئری‌ها را سریع‌تر می‌کند. در پروژه‌ای، کاهش Revision‌ها زمان بارگذاری صفحهٔ آرشیو را حدود ۴۰٪ کاهش داد.

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

برای مطالعهٔ تفصیلی این نوع بهینه‌سازی‌ها، تاثیر دیتابیس بر سرعت سایت چقدر است و افزونه‌های وردپرس چگونه روی سرعت سایت اثر می‌گذارند مراجع جامعی هستند.

محدودسازی نسخه‌ها برای انواع نوشته

در برخی پروژه‌ها، نیاز دارید که تعداد Revision‌ها برای انواع نوشتهٔ مختلف متفاوت باشد. مثلاً برای برگه‌ها (که کمتر ویرایش می‌شوند) تعداد کمی کافی است، ولی برای نوشته‌های محتوایی که معمولاً چندین ویرایش دارند، تعداد بیشتری لازم است. این کار با فیلتر wp_revisions_to_keep انجام می‌شود:

add_filter( 'wp_revisions_to_keep', 'wphk_limit_revisions_per_post_type', 10, 2 );

function wphk_limit_revisions_per_post_type( $num, $post ) {
    if ( ! $post instanceof WP_Post ) {
        return $num;
    }

    if ( 'page' === $post->post_type ) {
        return 3;
    }

    if ( 'post' === $post->post_type ) {
        return 10;
    }

    if ( 'product' === $post->post_type ) {
        return 5;
    }

    return $num;
}

چهار نکتهٔ کلیدی در این الگو. اول، این فیلتر روی مقدار تعریف‌شده در ثابت WP_POST_REVISIONS اولویت دارد؛ یعنی حتی اگر ثابت روی ۵ تنظیم شده باشد، این فیلتر می‌تواند برای انواع مختلف، مقدار متفاوتی برگرداند. دوم، بررسی instanceof WP_Post که در سناریوهای نادر از خطا جلوگیری می‌کند. سوم، اولویت ۱۰ که استاندارد است و اگر افزونه‌ای دیگر هم روی این فیلتر کار کند، ترتیب منطقی حفظ می‌شود. چهارم، بازگشت مقدار پیش‌فرض در انتهای تابع، برای انواع نوشته‌ای که در شرایط خاص نگنجیده‌اند. توضیح تفصیلی فیلترها در نحوه استفاده از add_filter در وردپرس آمده است.

تعداد مناسب Revision برای هر پروژه

انتخاب تعداد مناسب Revision، به ماهیت پروژه بستگی دارد. در تجربهٔ خودم، این جدول تصمیم‌گیری را ساده کرده است:

سه نکتهٔ کلیدی در این جدول. اول، این اعداد، پیشنهادهای اولیه هستند، نه قواعد سختگیرانه. پس از اعمال، بهترین راه این است که چند هفته با مقدار انتخابی کار کنید و ببینید آیا کمبود یا زیادی حس می‌شود. دوم، در سایت‌هایی با تیم تحریریه، انتخاب عدد بزرگ‌تر ارزش دارد؛ چون امکان مقایسهٔ نسخه‌ها یکی از کاربردهای اصلی Revision است. سوم، در سایت‌های کوچک، انتخاب عدد ۱۰ یا حتی ۵ کافی است و کاهش حجم دیتابیس ارزشمند است. در پروژه‌های خودم، قاعدهٔ سرانگشتی من این است: «کمترین عددی که در موقعیت اضطراری به‌کار می‌آید.»

اشتباهات رایج در محدودسازی نسخه‌ها

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

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

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

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

پروندهٔ اول: سایتی که با یک خط کد، دو گیگابایت آزاد کرد

همان پروژه‌ای که در ابتدای مقاله به آن اشاره کردم. سایتی با کمتر از پانصد نوشته و دیتابیسی بیش از دو گیگابایت. راه‌حل: تعریف ثابت WP_POST_REVISIONS روی مقدار ۵ در mu-plugins، سپس پاک‌سازی نسخه‌های قدیمی با WP-CLI. نتیجه در یک هفته: حجم دیتابیس از ۲.۳ گیگابایت به کمتر از ۲۰۰ مگابایت کاهش یافت، زمان بکاپ روزانه از ۲۰ دقیقه به کمتر از ۲ دقیقه رسید، و سرعت باز کردن ویرایشگر نوشته‌های قدیمی از پنج ثانیه به کمتر از یک ثانیه کاهش یافت. تحلیل مشابه این نوع بهینه‌سازی در چگونه دیتابیس وردپرس را پاک‌سازی کنیم آمده است.

پروندهٔ دوم: مجله‌ای که با تعادل مناسب، هم راضی نگه داشت هم سبک

در یک مجله آنلاین با تیم تحریریهٔ پنج‌نفره، پیش از تغییر، محدودیت Revision وجود نداشت و حجم دیتابیس به‌سرعت در حال رشد بود. ولی انتخاب مقدار پایین (مثل ۳) می‌توانست نارضایتی نویسنده‌های حرفه‌ای را به‌همراه داشته باشد که به مقایسهٔ نسخه‌ها نیاز داشتند. راه‌حل: انتخاب مقدار ۱۵ برای نوشته‌های نوع post، مقدار ۵ برای برگه‌ها و ۳ برای محصولات. نتیجه در سه ماه: حجم دیتابیس رشد کمتری داشت (حدود ۳۰٪ کمتر از قبل) و تیم تحریریه هم از کمبود Revision شکایتی نداشت. تجربهٔ مشابه در حوزهٔ تعادل کارایی و کاربری در تاثیر دیتابیس بر سرعت سایت چقدر است آمده است.

این دو پرونده، نکتهٔ مشترک دارند: انتخاب تعداد مناسب Revision، یک تصمیم ساختاری است که هم بر کارایی و هم بر تجربهٔ کاربری اثر می‌گذارد. تفاوت بین سایتی که این تصمیم را آگاهانه گرفته و سایتی که آن را به پیش‌فرض سپرده، در همین تصمیم کوچک شکل می‌گیرد.

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

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

گزینهٔ اول: فایل wp-config.php. برای پروژه‌های کوچک و متوسط، این گزینه ساده‌ترین مسیر است. ولی توجه داشته باشید که در این فایل، جای مستندسازی طولانی نیست. اگر سایت‌های متعددی دارید که با یک تنظیم مشترک کار می‌کنند، ممکن است مدیریت این فایل در هر سایت دشوار باشد.

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

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

الگوی عملی من در پروژه‌های خودم: تنظیمات ساختاری مثل WP_POST_REVISIONS و DISALLOW_FILE_EDIT را در یک فایل مشترک mu-plugins/wphk-config.php نگه می‌دارم که هم در گیت ذخیره می‌شود و هم در چند سایت مشابه قابل استفاده است. برای دیدن فهرست گسترده‌تری از اسنیپت‌های کاربردی، بهترین قطعه کدهای کاربردی وردپرس برای سایت‌ها مرجع خوبی است.

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

قطعه کد تغییر تعداد Revision های وردپرس، یکی از پرمصرف‌ترین و در عین حال کم‌سروصداترین تنظیمات ساختاری است. سه ستون این کار: تعریف ثابت WP_POST_REVISIONS با مقدار عددی مناسب، پاک‌سازی Revision‌های قدیمی با WP-CLI یا افزونهٔ اختصاصی، و انتخاب تعداد مناسب براساس نوع پروژه. سه ملاحظهٔ کارایی (کاهش حجم دیتابیس، بهبود سرعت کوئری‌ها، سرعت پیشخوان) در سایت‌های پرمحتوا اثر محسوسی دارند. سه ملاحظهٔ ایمنی (بکاپ پیش از هر پاک‌سازی، پرهیز از مقدار false، بررسی defined پیش از تعریف) در همهٔ اسنیپت‌های این حوزه باید رعایت شوند. و محل درست این اسنیپت، wp-config.php یا mu-plugins است، نه فایل قالب یا چایلد تم.

گام بعدی عملی که پیشنهاد می‌کنم: در همین امروز، به پیشخوان هاست سایت خود بروید و حجم دیتابیس را بررسی کنید. سپس با یک ابزار ساده مثل phpMyAdmin، تعداد ردیف‌های جدول wp_posts با post_type = 'revision' را بشمارید. اگر تعداد Revision‌ها از تعداد نوشته‌ها بیشتر است، احتمالاً دیتابیس شما در حال رشد ناسالم است. تنظیم ثابت WP_POST_REVISIONS روی عدد مناسب و پاک‌سازی نسخه‌های قدیمی، یکی از ارزان‌ترین و مؤثرترین بهینه‌سازی‌های دیتابیس وردپرس است. اگر تجربه‌ای با محدودسازی Revision‌ها داشته‌اید — به‌ویژه اگر در پروژه‌ای به تعادل مناسبی بین تاریخچه و کارایی رسیده‌اید — برای من جالب است بدانید چطور به آن عدد رسیدید. تجربهٔ خودتان را در دیدگاه‌ها بنویسید؛ به‌ویژه اگر روش تمیزی برای پاک‌سازی نسخه‌های قدیمی در سایت‌های پرمحتوا پیدا کرده‌اید. 🗂️