כש-WordPress מתעדכן לגרסה חדשה, לעיתים מבנה הטבלאות עצמו משתנה - שדות נוספים, אינדקסים חדשים, או טבלאות חדשות. הקבצים מתעדכנים מיד בהורדה, אבל ה-DB דורש שלב נוסף שלא קורה אוטומטית. כל זמן שהשלב הזה לא בוצע, האתר במצב ביניים: קבצים חדשים מול schema ישן.
למה זה משנה
וורדפרס שומר ב-wp_options את המפתח db_version - מספר שמייצג את הגרסה האחרונה שעבורה ה-schema עודכן. בקבצי הליבה יש קבוע $wp_db_version שמייצג את ה-schema הנדרש. כשהשניים לא תואמים, וורדפרס מציג לכל אדמין שנכנס ל-/wp-admin/ את מסך "Database Update Required" עד שהמשתמש לוחץ "Update WordPress Database". בזמן הזה: API פנימיים שמסתמכים על מבני נתונים חדשים יכשלו, תוספים שמשתמשים ב-dbDelta() לטבלאות שלהם עלולים לכתוב ל-schema לא נכון, ושאילתות מסוימות יחזירו שגיאת "Unknown column". באתר multisite עם הרבה sub-sites, מצב הביניים יכול להישאר ימים אם אף אדמין לא נכנס לכל sub-site.
איך לזהות
הסימן הברור ביותר: מסך "Database Update Required" כשנכנסים ל-wp-admin. ידנית, השווה את $wp_db_version בקובץ wp-includes/version.php לבין הערך ב-wp_options:
wp option get db_version
grep wp_db_version wp-includes/version.phpאם הערכים שונים, נדרש upgrade. RankPlus קורא את שניהם דרך REST API ומסמן אם יש פער.
איך לתקן
- גבה את ה-DB לפני הכל. השלב הזה משנה schema ולא ניתן לחזרה אחורה אוטומטית. השתמש ב-UpdraftPlus, או ב-
wp db export pre-upgrade.sql, או ב-mysqldumpדרך SSH. - הדרך המומלצת: WP-CLI - מהיר, מדויק וטוב במיוחד ל-multisite:
wp core update-db. ל-multisite השתמש ב---network:wp core update-db --network. - חלופה דרך הדפדפן: גש ל-
https://YOUR-SITE/wp-admin/upgrade.phpולחץ "Update WordPress Database". זה מריץ אתupgrade_all(). - באתר עם מאות אלפי שורות התהליך יכול לקחת מספר דקות. אל תעצור באמצע.
- אם נופל באמצע: הפעל
WP_DEBUGו-WP_DEBUG_LOGב-wp-config.php, נסה שוב, ובדוק אתdebug.log. השגיאה תצביע על טבלה ספציפית או על תוסף שמתערב. - אם השגיאה היא "Could not perform query" - יתכן ש-MySQL user שלך לא ALTER privilege. בקש מספק האחסון להוסיף.
טעויות נפוצות
- עדכון בלי גיבוי: אם משהו ישתבש באמצע ה-ALTER TABLE, אתה עלול להישאר עם טבלה corrupt חלקית. גיבוי הוא לא נדמה לך.
- סגירת הדפדפן באמצע: הפעולה רצה בצד השרת, אבל אם תפסיק את הבקשה לפני שסיימה, ייתכן שיישאר ALTER לא גמור. השתמש ב-WP-CLI שמתמודד עם זה טוב יותר.
- multisite עם sub-sites רבים: בלי
--network, רק האתר הראשי מתעדכן ויתר ה-sub-sites נשארים תקועים. - מערכת ב-readonly mode: חלק מספקי האחסון נועלים את ה-DB לכתיבה לאחר חריגה ממכסה. בקש פתיחה לפני העדכון.
בדיקה לאחר תיקון
הרץ שוב wp option get db_version והשווה ל-$wp_db_version בקובץ - הם חייבים להיות זהים. גש ל-/wp-admin/ - אל תקבל את מסך ה-upgrade. פתח את הדף הראשי ופוסט אקראי וודא שהכל נטען בלי "Unknown column" בלוג. ב-RankPlus הסטטוס יהפוך לירוק בסריקה הבאה.
wp core update-db בסקריפט שכר אחרי כל wp core update - כך לעולם לא תפספס את שלב ה-schema upgrade. בנוסף, באתרי multisite גדולים (מעל 100 sub-sites), הריצו את העדכון בקבוצות במקום ב-batch אחד גדול - זה מקטין את הסיכון של timeout באמצע ומאפשר rollback ספציפי אם משהו משתבש. שמירת timestamp לפני כל עדכון מאפשרת מהירות בעקבות בעיות; ניטור של db_version ב-cron של RankPlus מתריע מיד אם אתר נשאר במצב ביניים אחרי עדכון אוטומטי שנכשל.