גרסאות פוסטים ב-WordPress: למה הן מנפחות את ה-DB וכיצד להגביל בלי לאבד היסטוריה

בכל פעם שלוחצים "שמור טיוטה" או שה-autosave מתעורר, WordPress יוצר עותק של הפוסט בטבלת wp_posts עם post_status='inherit' ו-post_type='revision'. בברירת מחדל ה-WordPress שומר את כולן ללא הגבלה. פוסט שנערך 80 פעם = 80 שורות נוספות, כל אחת עם meta משלה ב-wp_postmeta. אתר עם 500 פוסטים יכול להחזיק 30,000+ שורות revisions שאין צורך בהן.

למה זה משנה

השפעה ראשונה - גודל DB. wp_posts ו-wp_postmeta גדלים פי 5-10. גיבויים יומיים נמשכים יותר זמן (גם בעלות אם הספק מחייב לפי גודל). ייצוא ל-staging הופך כבד מיותר. שאילתות שפועלות על wp_posts סורקות הרבה יותר שורות לפני שמוצאות תוצאה - גם אם post_status='publish' מסונן ב-WHERE, MySQL חייב לעבור על שורות revisions גם אם הן יסוננו אחר כך.

השפעה שנייה - שאילתות איטיות. ה-index על wp_posts משלב post_type, post_status ו-post_date. ככל שיש יותר שורות, גם שאילתות שמסננות נכון רצות איטי יותר. ב-WP-Admin המוני - חיפוש פוסטים, סינון לפי קטגוריה, ניווט בין עמודי לוח - הופכים איטיים בעת רוויית revisions.

אין סיבה לשמור גרסאות בלתי מוגבלות. 5-10 גרסאות אחרונות מספיקות בהחלט - הן מאפשרות חזרה אחורה, השוואה, ושחזור אם משהו השתבש בעריכה. מעבר לזה, גרסה מ-2019 של פוסט ב-2024 לרוב לא רלוונטית.

איך לזהות

שאילתה מהירה לזיהוי:

SELECT COUNT(*) AS revisions,
       (SELECT COUNT(*) FROM wp_posts WHERE post_type='post') AS posts
FROM wp_posts
WHERE post_type='revision';

אם יחס revisions:posts גדול מ-10:1 - יש כאן עבודה. אתר טיפוסי בריא יראה 3-5:1.

איך לתקן

שלב 1 - הגבלת גרסאות עתידיות. הוסף ל-wp-config.php לפני /* That's all */:

define('WP_POST_REVISIONS', 5);    // שמור רק 5 גרסאות אחרונות
define('AUTOSAVE_INTERVAL', 300);   // autosave כל 5 דקות במקום 60 שניות

זה לא מוחק גרסאות קיימות - רק מגביל מכאן והלאה. כל פעם ש-WordPress יוצר revision חדשה, היא מוחקת את הישנה ביותר אם יש כבר 5.

שלב 2 - גבה DB לפני ניקוי גרסאות קיימות. mysqldump או UpdraftPlus.

שלב 3 - ניקוי גרסאות קיימות. הדרך הבטוחה היא WP-CLI:

wp post delete $(wp post list --post_type=revision --format=ids) --force

אם אין WP-CLI, דרך SQL (זהירות):

-- מחיקה של גרסאות
DELETE FROM wp_posts WHERE post_type = 'revision';

-- ניקוי postmeta יתום
DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts p ON pm.post_id = p.ID
WHERE p.ID IS NULL;

-- ניקוי term_relationships יתום
DELETE tr FROM wp_term_relationships tr
LEFT JOIN wp_posts p ON tr.object_id = p.ID
WHERE p.ID IS NULL;

שלב 4 - אופטימיזציה של הטבלאות:

OPTIMIZE TABLE wp_posts, wp_postmeta, wp_term_relationships;

InnoDB לא מצמצם את הקובץ הפיזי לבד. בלי OPTIMIZE, הקובץ נשאר בגודל המקורי גם אחרי המחיקה.

טעויות נפוצות

הטעות הראשונה: לקבוע WP_POST_REVISIONS = false - מכבה גרסאות לחלוטין. אז אם ערכת פוסט בטעות ולא יכולת לחזור - אין שום היסטוריה. עדיף 5 ולא 0. הטעות השנייה: למחוק revisions של פוסטים פעילים בטעות. revisions יש להם post_status = 'inherit'; פוסטים בסל מחזור הם post_status = 'trash'. אל תערבב. הטעות השלישית: לשכוח OPTIMIZE TABLE - הגיבוי יישאר באותו גודל למרות המחיקה. הטעות הרביעית: לסמוך על תוסף Optimize Database after Deleting Revisions בלי גיבוי - תוספים יכולים להיכשל באמצע.

בדיקה לאחר תיקון

הרץ שוב את שאילתת הספירה - מספר ה-revisions צריך להיות נמוך משמעותית (סכום של 5 לכל פוסט פעיל). בדוק את גודל ה-DB עם SELECT SUM(data_length+index_length)/1024/1024 FROM information_schema.tables WHERE table_schema=DATABASE(); - אמור להיות 30-60% קטן יותר. גודל גיבוי UpdraftPlus יקטן בהתאם.

בדוק שעריכת פוסט עדיין יוצרת revisions - ערוך פוסט קיים, רענן, ובדוק תחת "Revisions" שיש 1-5 גרסאות.