תיקיית wp-content/uploads מעל 2GB אינה מאטה את האתר ישירות - גולשים מורידים רק את התמונות שמופיעות בדף הספציפי שהם פותחים. אבל היא יוצרת שורה של בעיות תפעוליות מתמשכות שכל אדמין WordPress מנוסה מכיר: גיבויים יומיים שלוקחים שעות, סנכרון לסביבת staging שלא מעשי, שחזור איטי אחרי קריסה, מיגרציה לאחסון אחר שהופכת לפרויקט בפני עצמו, ועלויות אחסון גדלות.
למה זה משנה
השפעה ראשונה - גיבוי. UpdraftPlus או SolidBackups שמגבים אתר עם 5GB uploads זקוקים ל-30-60 דקות. אם הספק מגביל ל-300 שניות PHP execution time - הגיבוי נכשל לפני שמסתיים. הפתרון הוא לפצל לחלקים, אבל זה מסבך וגדל בכשלונות.
השפעה שנייה - staging/dev. כדי לעבוד על האתר באופן בטוח רוצים סביבת staging זהה. אם uploads זה 8GB, להעתיק אותו לוקח שעות ועולה אם משתמשים ב-rsync ב-WAN. הרבה אדמינים מוותרים על staging בגלל זה - מה שמסוכן.
השפעה שלישית - search ב-Media Library. עם 50,000+ תמונות, חיפוש ב-wp-admin הופך איטי. שאילתת SELECT על wp_posts WHERE post_type='attachment' רצה על עשרות אלפי שורות, ובלי index מתאים - זה לוקח שניות.
השפעה רביעית - cost. ספקי אחסון Cloud (S3, R2, Google Cloud Storage) מחייבים לפי GB. אתר עם 20GB uploads ב-S3 = $5/חודש; 200GB = $50/חודש. אם רוב התמונות לא בשימוש פעיל - אתה משלם על זה ללא תועלת.
איך לזהות
בדוק את הגודל של uploads מ-SSH:
du -sh wp-content/uploads/או דרך File Manager של cPanel - מציג גודל ליד שם התיקייה. שאילתה למספר attachment:
SELECT COUNT(*) FROM wp_posts WHERE post_type = 'attachment';חלוקה לפי שנה:
du -h --max-depth=2 wp-content/uploads/ | sort -hאיך לתקן
שלב 1: זיהוי קבצים יתומים. התקן "Media Cleaner" של Jordy Meow (חינמי). הוא סורק את wp_posts, wp_postmeta, ואת תוכן הפוסטים, ומזהה קבצים בתיקייה שאף פוסט לא מתייחס אליהם. אלה לרוב 20-40% מה-uploads באתרים ותיקים - העלאות שנמחקו מהפוסטים אבל נשארו על הדיסק.
תהליך: "Trash" קודם (לא Delete), חכה כמה ימים, וודא שאין רגרסיה (תמונות חסרות בפוסטים), ורק אז "Empty Trash".
שלב 2: אופטימיזציה של תמונות קיימות. הרץ Imagify או ShortPixel "Bulk Optimize" על כל המדיה. חוסך 30-50% מהגודל הכולל בלי לאבד איכות נראית לעין.
שלב 3: מחיקת intermediate sizes לא בשימוש. WordPress יוצר 4-7 גרסאות של כל תמונה (thumbnail, medium, large, וכו'). אם התבנית שלך משתמשת רק ב-2 מהן, השאר תופסות מקום לחינם. התקן "Force Regenerate Thumbnails" - הוא יודע למחוק גדלים שלא בשימוש בתבנית הפעילה.
בנוסף, ערוך את functions.php כדי להפסיק יצירת גדלים מיותרים בעתיד:
// Remove unused image sizes
add_action('init', function () {
remove_image_size('1536x1536');
remove_image_size('2048x2048');
});שלב 4: offload ל-S3/R2/Spaces. תוסף "WP Offload Media" של Delicious Brains מעביר את כל ה-uploads ל-Amazon S3, Cloudflare R2, או DigitalOcean Spaces. האתר מגיש את התמונות מ-CDN מהיר, ה-uploads המקומי נשאר ריק. חיסכון משמעותי בעלויות אחסון ובמהירות.
שלב 5: ניקוי multisite ישן. אם פעם הייתה התקנה multisite, בדוק uploads/sites/ - יכול להיות תיקיות גדולות של אתרים שכבר לא קיימים.
טעויות נפוצות
הטעות הראשונה: למחוק קבצים ישירות מ-FTP - תמונות שהיו מקושרות בפוסטים נשארות עם broken link, וקיים גם risk שתמונות שמשמשות שעדיין נדרשות יימחקו. תמיד דרך WordPress UI עם תוסף.
הטעות השנייה: לסמוך על Media Cleaner ב-100% - לפעמים הוא לא מזהה תמונה שמופיעה רק ב-shortcode מותאם אישית. בדוק תוצאות.
הטעות השלישית: למחוק את uploads/cache/ או uploads/wpforms/ ידנית - אלה תיקיות של תוספים שיוצרים אותן מחדש בכל מקרה. אבל אם הסרת את התוסף, נקה דרך ה-uninstall שלו.
הטעות הרביעית: offload בלי לוודא שה-CDN settings נכונים - ייתכן שתמונות לא יוצגו אחרי המעבר. עשה backup לפני.
בדיקה לאחר תיקון
הרץ שוב du -sh - הגודל אמור להיות 30-60% קטן יותר. גיבוי UpdraftPlus יצליח מהר יותר. בדוק את האתר ב-incognito - הסתכל על תמונות בכמה פוסטים שונים, וודא שכולן עדיין מוצגות (אין broken links). בדוק את ספריית מדיה ב-wp-admin - אמור להיות מהיר יותר לסיור בה.