قطعه کد پاک‌سازی داده‌های اضافی وردپرس

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

داده‌های اضافی در وردپرس دقیقاً چیست؟

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

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

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

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

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

چرا پاک‌سازی داده‌های اضافی اهمیت دارد

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

دلیل اول: کاهش حجم دیتابیس. این واضح‌ترین اثر است. در پروژه‌ای، پاک‌سازی هدفمند ترنزینت‌ها و متادیتای یتیم، حجم دیتابیس را از ۲.۸ گیگابایت به کمتر از ۴۰۰ مگابایت رساند. این کاهش، مستقیماً بر زمان بکاپ، سرعت مهاجرت و مصرف فضای هاست اثر داشت.

دلیل دوم: بهبود سرعت کوئری‌ها. هرچه جدول‌های دیتابیس کوچک‌تر باشند، کوئری‌های وردپرس سریع‌تر اجرا می‌شوند. این اثر در جدول‌هایی مثل wp_postmeta و wp_options بیشتر محسوس است؛ چون این دو جدول، تقریباً در هر بازدید از سایت درگیر می‌شوند.

دلیل سوم: پیشگیری از خطاهای مرموز. در پروژه‌ای، سایتی گاهی با خطای «Allowed memory size exhausted» مواجه می‌شد. بررسی نشان داد که جدول wp_options بیش از ۵۰ مگابایت دادهٔ autoload شده داشت که در هر بازدید از سایت، بارگذاری می‌شد. پس از پاک‌سازی، این خطا برای همیشه از بین رفت. این نوع خطاها را نمی‌شود با افزونه‌های بهینه‌سازی حل کرد، مگر اینکه ریشه در دیتابیس باشد.

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

نقشهٔ داده‌های انباشتی: هشت دستهٔ اصلی

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

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

پروتکل امن پیش از هر پاک‌سازی

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

1. بکاپ کامل دیتابیس: پیش از هر تغییری، یک نسخهٔ کامل از دیتابیس در جای امنِ بیرون از هاست ذخیره کنید. اصول این کار در چگونه از سایت وردپرسی بکاپ بگیریم و بهترین افزونه‌های پشتیبان‌گیری وردپرس آمده است.
2. تست بازیابی در استجینگ: یک نسخهٔ از سایت را در محیط استجینگ بالا بیاورید و عملیات پاک‌سازی را ابتدا در آنجا اجرا کنید. اگر سایت پس از پاک‌سازی سالم ماند، آنگاه به محیط اصلی منتقل کنید.
3. اجرای هدفمند، نه دسته‌ای: در هر مرحله، تنها یک دستهٔ داده را پاک‌سازی کنید. بعد از هر مرحله، سایت را بررسی کنید و در صورت بروز مشکل، فقط همان یک مرحله را برگردانید.
4. پایش پس از پاک‌سازی: در ۲۴ ساعت اول پس از پاک‌سازی، پنل هاست، لاگ خطاها و رفتار front-end را با دقت بیشتری بررسی کنید. اگر خطایی ظاهر شد، بلافاصله از بکاپ بازگردانید.

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

پاک‌سازی ترنزینت‌های منقضی

ترنزینت‌ها (Transients)، پرتکرارترین دادهٔ اضافی در دیتابیس سایت‌های وردپرسی هستند. وردپرس برای کش موقت از آن‌ها استفاده می‌کند، ولی از آنجایی که رفتار پاک‌سازی خودکارش قابل‌اتکا نیست، اکثر سایت‌ها حجم زیادی از ترنزینت‌های منقضی را در دیتابیس خود نگه می‌دارند. الگوی پاک‌سازی هدفمند:

/**
 * Snippet: Clean expired transients on schedule.
 *
 * @since 2026-09-16
 * @author WordPressKar
 *
 * Purpose: Delete expired transients from wp_options on a daily schedule.
 * Location: mu-plugins directory or custom plugin.
 */

add_action( 'wphk_daily_cleanup', 'wphk_delete_expired_transients' );

function wphk_delete_expired_transients() {
    global $wpdb;

    $time = time();

    // 1. حذف مقدار ترنزینت‌های منقضی
    $wpdb->query(
        $wpdb->prepare(
            "DELETE FROM {$wpdb->options}
             WHERE option_name LIKE %s
             AND option_value < %d",
            '_transient_timeout_%',
            $time
        )
    );

    // 2. حذف نسخهٔ بدون timeout متناظر با ترنزینت‌های حذف‌شده
    $wpdb->query(
        "DELETE t1 FROM {$wpdb->options} t1
         LEFT JOIN {$wpdb->options} t2
         ON t2.option_name = REPLACE(t1.option_name, '_transient_', '_transient_timeout_')
         WHERE t1.option_name LIKE '_transient_%'
         AND t1.option_name NOT LIKE '_transient_timeout_%'
         AND t2.option_id IS NULL"
    );
}

if ( ! wp_next_scheduled( 'wphk_daily_cleanup' ) ) {
    wp_schedule_event( time(), 'daily', 'wphk_daily_cleanup' );
}

چهار نکتهٔ کلیدی در این الگو. اول، استفاده از $wpdb->prepare برای حذف کوئری‌های تزریق‌پذیر. این روش، استاندارد امنیتی وردپرس است که در هوک‌های وردپرس و افزایش امنیت کد با جزئیات بیشتر آمده است. دوم، تفکیک پاک‌سازی به دو مرحله: ابتدا ردیف‌های _transient_timeout_* که تاریخشان گذشته، سپس ردیف‌های بدون timeout متناظر که به‌جا مانده‌اند. بدون این مرحلهٔ دوم، ردیف‌های بی‌صاحب باقی می‌مانند. سوم، استفاده از wp_schedule_event برای اجرای روزانه که فشار را از ساعات شلوغی سایت برمی‌دارد. چهارم، بررسی wp_next_scheduled که از ایجاد cronهای تکراری جلوگیری می‌کند. توضیح تفصیلی این حوزه در پاک‌سازی اسپم و ترنزینت‌های دیتابیس وردپرس آمده است.

حذف متادیتای یتیم و ردیف‌های بی‌صاحب

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

add_action( 'wphk_daily_cleanup', 'wphk_delete_orphan_meta' );

function wphk_delete_orphan_meta() {
    global $wpdb;

    // حذف متادیتای یتیم نوشته‌ها
    $wpdb->query(
        "DELETE pm FROM {$wpdb->postmeta} pm
         LEFT JOIN {$wpdb->posts} p ON p.ID = pm.post_id
         WHERE p.ID IS NULL"
    );

    // حذف متادیتای یتیم کاربران
    $wpdb->query(
        "DELETE um FROM {$wpdb->usermeta} um
         LEFT JOIN {$wpdb->users} u ON u.ID = um.user_id
         WHERE u.ID IS NULL"
    );

    // حذف متادیتای یتیم کامنت‌ها
    $wpdb->query(
        "DELETE cm FROM {$wpdb->commentmeta} cm
         LEFT JOIN {$wpdb->comments} c ON c.comment_ID = cm.comment_id
         WHERE c.comment_ID IS NULL"
    );
}

چهار نکتهٔ کلیدی در این الگو. اول، استفاده از کوئری DELETE ... LEFT JOIN ... WHERE ... IS NULL که در یک مرحله، همهٔ ردیف‌های یتیم را حذف می‌کند بدون نیاز به حلقه یا کوئری‌های جداگانه. دوم، پاک‌سازی هر سه جدول متادیتا (wp_postmeta، wp_usermeta، wp_commentmeta)؛ چون یتیم‌شدن در هر سه آن‌ها ممکن است. سوم، اجرای این کوئری‌ها در cron روزانه، نه در هر بازدید. چهارم، چون این کوئری‌ها روی جدول‌های حجیم اجرا می‌شوند، توصیه می‌کنم ابتدا در محیط استجینگ تست کنید و اگر تعداد ردیف‌ها بسیار زیاد بود، آن‌ها را در دسته‌های چند هزارتایی و با تأخیر بین دسته‌ها اجرا کنید. توضیح تفصیلی این نوع کوئری‌ها در بهینه سازی کوئری های MySQL آمده است.

پاک‌سازی اسپم‌ها و کامنت‌های اضافی

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

add_action( 'wphk_daily_cleanup', 'wphk_delete_old_spam' );

function wphk_delete_old_spam() {
    global $wpdb;

    // حذف اسپم‌های قدیمی‌تر از ۳۰ روز
    $wpdb->query(
        $wpdb->prepare(
            "DELETE FROM {$wpdb->comments}
             WHERE comment_approved = 'spam'
             AND comment_date < DATE_SUB(NOW(), INTERVAL %d DAY)",
            30
        )
    );

    // حذف کامنت‌های سطل زباله قدیمی‌تر از ۳۰ روز
    $wpdb->query(
        $wpdb->prepare(
            "DELETE FROM {$wpdb->comments}
             WHERE comment_approved = 'trash'
             AND comment_date < DATE_SUB(NOW(), INTERVAL %d DAY)",
            30
        )
    );

    // پاک‌سازی متادیتای کامنت‌های حذف‌شده
    $wpdb->query(
        "DELETE cm FROM {$wpdb->commentmeta} cm
         LEFT JOIN {$wpdb->comments} c ON c.comment_ID = cm.comment_id
         WHERE c.comment_ID IS NULL"
    );
}

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

حذف پیش‌نویس‌های خودکار و ردیف‌های زائد جدول posts

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

add_action( 'wphk_daily_cleanup', 'wphk_delete_old_autodrafts' );

function wphk_delete_old_autodrafts() {
    global $wpdb;

    // حذف پیش‌نویس‌های خودکار قدیمی‌تر از ۷ روز
    $wpdb->query(
        $wpdb->prepare(
            "DELETE FROM {$wpdb->posts}
             WHERE post_status = 'auto-draft'
             AND post_date < DATE_SUB(NOW(), INTERVAL %d DAY)",
            7
        )
    );

    // حذف ردیف‌های سطل زباله‌ای که بیش از ۳۰ روز در آن‌جا مانده‌اند
    $wpdb->query(
        $wpdb->prepare(
            "DELETE FROM {$wpdb->posts}
             WHERE post_status = 'trash'
             AND post_modified < DATE_SUB(NOW(), INTERVAL %d DAY)",
            30
        )
    );

    // پاک‌سازی متادیتای نوشته‌های حذف‌شده
    $wpdb->query(
        "DELETE pm FROM {$wpdb->postmeta} pm
         LEFT JOIN {$wpdb->posts} p ON p.ID = pm.post_id
         WHERE p.ID IS NULL"
    );
}

سه نکتهٔ کلیدی در این الگو. اول، انتخاب بازهٔ زمانی مناسب برای هر دسته: پیش‌نویس‌های خودکار پس از ۷ روز و ردیف‌های سطل زباله پس از ۳۰ روز حذف می‌شوند. این تفاوت، به‌دلیل رفتار کاربران است: پیش‌نویس‌های خودکار معمولاً در نیمهٔ اول ویرایش رها می‌شوند، ولی کاربر ممکن است بعد از حذف یک نوشته، تا چند هفته بخواهد آن را بازگرداند. دوم، حذف متادیتای وابسته در همان اجرا که از انباشت ردیف‌های یتیم جلوگیری می‌کند. سوم، در صورت نیاز به دقت بیشتر، می‌توانید نوشته‌های نوع revision را نیز به این کوئری اضافه کنید؛ ولی چون در مقالهٔ جداگانه‌ای به آن پرداخته‌ام، در این اسنیپت نگنجانده‌ام. برای مطالعهٔ آن حوزه، قطعه کد تغییر تعداد Revision های وردپرس مرجع کاملی است.

حذف روابط بی‌صاحب تاکسونومی

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

add_action( 'wphk_daily_cleanup', 'wphk_delete_orphan_term_relationships' );

function wphk_delete_orphan_term_relationships() {
    global $wpdb;

    // حذف روابط یتیم که به نوشتهٔ ناموجود اشاره می‌کنند
    $wpdb->query(
        "DELETE tr FROM {$wpdb->term_relationships} tr
         LEFT JOIN {$wpdb->posts} p ON p.ID = tr.object_id
         WHERE p.ID IS NULL"
    );

    // حذف روابط یتیم که به ترم ناموجود اشاره می‌کنند
    $wpdb->query(
        "DELETE tr FROM {$wpdb->term_relationships} tr
         LEFT JOIN {$wpdb->term_taxonomy} tt ON tt.term_taxonomy_id = tr.term_taxonomy_id
         WHERE tt.term_taxonomy_id IS NULL"
    );
}

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

زمان‌بندی خودکار با cron

پاک‌سازی داده‌ها باید یک بار باشد، نه یک کار دائمی. برای اجرای منظم و بدون فشار روی سایت، از cron وردپرس استفاده می‌کنیم. الگوی ثبت cron و اتصال توابع پاک‌سازی به آن:

/**
 * Snippet: Schedule daily cleanup of extra data.
 *
 * @since 2026-09-16
 * @author WordPressKar
 *
 * Purpose: Register and schedule a daily cleanup routine.
 */

add_action( 'init', 'wphk_schedule_cleanup_cron' );

function wphk_schedule_cleanup_cron() {
    if ( ! wp_next_scheduled( 'wphk_daily_cleanup' ) ) {
        wp_schedule_event( time(), 'daily', 'wphk_daily_cleanup' );
    }
}

// در زمان غیرفعال‌سازی افزونه، cron را حذف کنید:
register_deactivation_hook( __FILE__, 'wphk_unschedule_cleanup_cron' );

function wphk_unschedule_cleanup_cron() {
    $timestamp = wp_next_scheduled( 'wphk_daily_cleanup' );
    if ( $timestamp ) {
        wp_unschedule_event( $timestamp, 'wphk_daily_cleanup' );
    }
}

چهار نکتهٔ کلیدی در این الگو. اول، استفاده از هوک init برای ثبت cron، چون این هوک در هر بار بارگذاری اجرا می‌شود و بررسی wp_next_scheduled از ایجاد تکراریِ cron جلوگیری می‌کند. دوم، انتخاب بازهٔ daily که در تجربهٔ من تعادل خوبی بین تازگی داده و مصرف منابع ایجاد می‌کند. اگر سایت شما ترافیک بسیار بالایی دارد، می‌توانید آن را به twicedaily یا hourly تغییر دهید. سوم، استفاده از register_deactivation_hook برای حذف cron در زمان غیرفعال‌سازی افزونه؛ بدون این کار، cron در دیتابیس باقی می‌ماند و حتی پس از حذف افزونه، همچنان اجرا می‌شود. چهارم، توصیهٔ من این است که cron را در ساعات کم‌ترافیک سایت تنظیم کنید. توضیح تفصیلی این حوزه در رفع مشکلات کرون در وردپرس آمده است.

یک نکتهٔ ظریف که در پروژه‌ای به آن برخوردم: اگر cron وردپرس را به cron واقعی سرور منتقل کرده باشید (کاری که در پروژه‌های پربازدید توصیه می‌شود)، بازه‌های زمانی cron ممکن است متفاوت اجرا شوند. توصیه: پیش از اعتماد به اجرای منظم، در ۲۴ ساعت اول، تعداد اجرای cron را با یک لاگ ساده بشمارید.

اثر پاک‌سازی بر سرعت و کارایی

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

اثر اول: کاهش حجم دیتابیس. در سایتی که در ابتدای مقاله به آن اشاره کردم، حجم دیتابیس از ۲.۸ گیگابایت به کمتر از ۴۰۰ مگابایت کاهش یافت — کاهش ۸۵٪. این کاهش مستقیماً بر زمان بکاپ (از ۲۵ دقیقه به ۴ دقیقه)، سرعت مهاجرت و مصرف فضای هاست اثر داشت.

اثر دوم: سرعت کوئری‌های front-end. در جدول‌های wp_options و wp_postmeta که در هر بازدید از سایت درگیر می‌شوند، کاهش تعداد ردیف‌ها، سرعت اجرای کوئری‌ها را بهبود می‌دهد. در پروژه‌ای، کاهش ترنزینت‌ها و متادیتای یتیم، زمان بارگذاری TTFB را حدود ۲۰٪ کاهش داد.

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

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

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

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

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

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

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

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

اشتباهات رایج در پاک‌سازی داده‌ها

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

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

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

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

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

همان پروژهٔ ابتدای مقاله. سایتی با کمتر از هزار نوشته و دیتابیسی بیش از دو گیگابایت. تحلیل اولیه نشان داد سه دستهٔ اصلی در انباشت حجم سهم دارند: ترنزینت‌های منقضی، متادیتای یتیم نوشته و کاربر، و ردیف‌های auto-draft. راه‌حل: اجرای اسنیپت‌های پاک‌سازی به‌ترتیب، ابتدا در محیط استجینگ و سپس در محیط اصلی. نتیجه در یک روز کاری: حجم دیتابیس از ۲.۸ به ۴۰۰ مگابایت کاهش یافت و سرعت کوئری‌های front-end حدود ۲۰٪ بهبود پیدا کرد. تحلیل مشابه این نوع بهینه‌سازی در چگونه دیتابیس وردپرس را پاک‌سازی کنیم آمده است.

پروندهٔ دوم: فروشگاهی که با پاک‌سازی هدفمند، خطاهای مرموز را حذف کرد

در یک فروشگاه ووکامرسی، مدیر سایت از خطای «Allowed memory size exhausted» در برخی صفحات شکایت داشت. بررسی نشان داد جدول wp_options بیش از ۵۰ مگابایت دادهٔ autoload داشت که در هر بازدید از سایت بارگذاری می‌شد. ریشهٔ این حجم، ترنزینت‌های انباشته از چند افزونهٔ جانبی بود که پس از حذف، فایل‌هایشان باقی مانده بود. راه‌حل: اجرای اسنیپت پاک‌سازی ترنزینت‌ها با تمرکز بر ردیف‌های مرتبط با افزونه‌های حذف‌شده، سپس بهینه‌سازی جدول. نتیجه در یک هفته: خطاها متوقف شد و سرعت کوئری‌های front-end بهبود پیدا کرد. تجربهٔ مشابه در حوزهٔ ووکامرس در رفع خطاهای رایج ووکامرس آمده است.

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

نگاه معمارانه به چرخهٔ عمر داده در وردپرس

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

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

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

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

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

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

درس‌ها و مسیر پیشنهادی

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

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