כשתוסף וורדפרס שובר את האתר, זה קורה בדרך כלל מיד אחרי התקנה, הפעלה או עדכון של תוספים. כדי לתקן, צריך לזהות איזה תוסף אחראי ולהשבית אותו, ואז להחליט אם לחזור לגרסה קודמת, לחכות לעדכון שיתקן את הבעיה או להחליף אותו בתוסף אחר.
לזיהוי האשם וורדפרס נותנת לך כמה כלים: מייל מצב השחזור (Recovery Mode), לוג הדיבאג, השבתת תוספים דרך שינוי שם התיקייה, ומסך בריאות האתר (Site Health). לפני שמשתמשים באחד מהם עושים גיבוי מלא, ואחר כך עוברים על השלבים לפי הסדר.
אם האתר לא רק מציג שגיאה בעמוד אחד אלא קרס לגמרי, כדאי קודם לעבור על הבדיקות במדריך האתר קרס, ורק אחר כך לחזור לחיפוש התוסף האשם.
שלב 1: גיבוי לפני שנוגעים בשום תוסף
התיעוד של וורדפרס קובע שלפני עדכון, ידני או אוטומטי, מגבים גם את הקבצים וגם את מסד הנתונים. בתיקון המצב דומה. אתה עומד לשנות קבצים, ואם משהו ישתבש אתה צריך נקודה לחזור אליה.
אם אזור הניהול עובד, תוסף גיבוי כמו UpdraftPlus יכול לעשות את זה בלחיצה. אם לא, מורידים ב-FTP את wp-content ואת wp-config.php, ומייצאים את מסד הנתונים מ-phpMyAdmin דרך הלשונית Export.
שלב 2: מה השתנה לאחרונה, ועדכון תוספים אוטומטי
השאלה הראשונה היא מה השתנה מאז שהאתר עבד. תוסף חדש? עדכון? ואם לא עדכנת כלום ידנית, ייתכן שהעדכון היה אוטומטי. מאז גרסה 5.5 אפשר להפעיל עדכון אוטומטי לכל תוסף בנפרד, בעמודת העדכונים האוטומטיים שבמסך Plugins.
לפי התיעוד של וורדפרס, כברירת מחדל נשלח מייל לבעל האתר אחרי כל ניסיון עדכון אוטומטי, בין אם הוא הצליח ובין אם נכשל. לכן כדאי לחפש הודעות כאלה בתיבת המייל של מנהל האתר, ולראות איזה תוסף עודכן סמוך לרגע שבו הבעיה התחילה.
יש גם דברים שוורדפרס כבר עושה בשבילך. מאז גרסה 6.6, לעדכונים אוטומטיים של תוספים יש מנגנון חזרה לאחור (rollback), שמחזיר את הגרסה הקודמת אם העדכון שובר את האתר. גם בעדכון ידני, מאז גרסה 6.3, אם תהליך העדכון עצמו נכשל באמצע, וורדפרס מחזירה את הגרסה שהייתה מותקנת. אבל אם העדכון הושלם והבעיה מופיעה רק אחר כך, למשל בעמוד מסוים או בטופס, אף מנגנון לא יחזיר אותו בשבילך.
שלב 3: מייל ה-Recovery Mode
אם האתר מציג את ההודעה "There has been a critical error on this website", וורדפרס שולחת מאז גרסה 5.2 מייל לכתובת מנהל האתר. במייל יש פרטים על השגיאה וקישור למצב השחזור (Recovery Mode).
לפעמים תוסף בעייתי לא מציג את ההודעה הזו בכלל, אלא שגיאת שרת כללית כמו שגיאה 500 או 503 Service Unavailable. גם אז התוסף יכול להיות האשם, אבל דרך האבחון קצת שונה, והיא מפורטת במדריכים הנפרדים על כל אחת מהשגיאות.
כשהמייל הגיע, לוחצים על הקישור. במצב הזה התוספים שגורמים לשגיאה מושהים רק עבורך, ואתה יכול להיכנס לאזור הניהול ולהשבית את התוסף הבעייתי. המבקרים באתר ימשיכו לראות את השגיאה עד שתשבית אותו.
שלב 4: לוג הדיבאג, כדי לראות איזה תוסף מופיע בשגיאה
כשאין מייל, או שלא ברור ממנו מה קרה, מפעילים רישום שגיאות. בקובץ wp-config.php שבתיקייה הראשית של האתר מוסיפים את השורות האלה, לפני השורה שמתחילה ב-/* That's all, stop editing!:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );אם כבר יש בקובץ שורה של WP_DEBUG, משנים אותה ולא מוסיפים שנייה. אחר כך טוענים שוב את העמוד השבור ופותחים את wp-content/debug.log.
בשורה של PHP Fatal error מופיע נתיב לקובץ. אם הוא מתחיל ב-wp-content/plugins/, השם שמופיע מיד אחריו הוא התיקייה של התוסף האשם.
ואל תשכח לכבות את הלוג בסוף. התיעוד של וורדפרס לא ממליץ להשאיר את כלי הדיבאג פעילים באתר חי, ו-Site Health מתריע שקובץ הלוג עלול להיות נגיש לכולם. לכן מחזירים את WP_DEBUG ל-false ומוחקים את הקובץ.
שלב 5: התנגשות תוספים וורדפרס, ואיך מוצאים את הזוג הבעייתי
לפעמים אף תוסף לא שבור בפני עצמו, והבעיה מופיעה רק כששניים פועלים יחד. התיעוד של וורדפרס מציין, למשל, שכפתור Publish או Save Draft שלא עובד נגרם בדרך כלל משני תוספים שמנסים להשתמש באותם משאבים, והפתרון שהוא מציע הוא להשבית תוספים אחד אחד עד שמוצאים את המקור.
כשיש גישה לאזור הניהול, עושים את זה במסך Plugins: משביתים תוסף אחד, בודקים את הבעיה וממשיכים לתוסף הבא. כשהבעיה נעלמת, התוסף האחרון שהשבתת הוא אחד מהשניים. מפעילים אותו שוב לבד, ואז מפעילים את האחרים אחד אחד כדי למצוא את בן הזוג שלו.
כשאין גישה לאזור הניהול, נכנסים ב-FTP או במנהל הקבצים ל-wp-content ומשנים את שם התיקייה plugins ל-plugins.hold. זה משבית את כל התוספים. אחרי שנכנסים לאזור הניהול, מחזירים לתיקייה את השם plugins. לפי התיעוד של וורדפרס, התוספים יישארו מושבתים וההגדרות שלהם נשמרות, ואז מפעילים אותם אחד אחד. אם כבר ידוע לך מי החשוד, אפשר לשנות רק את שם התיקייה שלו.
שלב 6: תאימות לגרסת PHP ולגרסת וורדפרס
כל תוסף מגדיר בקובץ הראשי שלו את הדרישות שלו. Requires at least היא גרסת וורדפרס הנמוכה ביותר שהוא עובד עליה, ו-Requires PHP היא גרסת ה-PHP המינימלית. בעמוד התוסף ב-wordpress.org הנתונים האלה מופיעים תחת WordPress version, PHP version ו-Tested up to, לצד Last updated.
את גרסת ה-PHP שרצה אצלך רואים תחת Tools > Site Health > Info, בחלק Server, ומשווים אותה לדרישות של התוסף. אם הבעיה התחילה אחרי שחברת האחסון שדרגה את גרסת ה-PHP, זה כנראה הכיוון.
הפתרון הוא לעדכן את התוסף לגרסה שתומכת בגרסת ה-PHP שלך. אם אין כזו, צריך לבחור בין תוסף חלופי לבין שינוי גרסת ה-PHP מול חברת האחסון, וההחלטה הזו משפיעה על כל האתר ולא רק על התוסף.
שלב 7: חזרה לגרסה קודמת של התוסף
כשהעדכון האחרון הוא הבעיה ואתה צריך שהתוסף יעבוד עכשיו, אפשר להתקין גרסה קודמת. עם WP-CLI זה נראה כך, כשמחליפים את plugin-slug בשם התיקייה של התוסף ואת המספר בגרסה שעבדה:
wp plugin install plugin-slug --version=1.2.3 --forceהאפשרות --version מורידה את הגרסה הזו מ-wordpress.org, ו---force דורסת את הגרסה המותקנת בלי לשאול. זה עובד רק לתוספים מהמאגר של wordpress.org. לתוסף בתשלום צריך לקבל מהספק את קובץ ה-zip של הגרסה הקודמת.
לפני שבוחרים לאיזו גרסה לחזור, כדאי לקרוא בעמוד התוסף ב-wordpress.org את יומן השינויים (Changelog), שנמצא תחת הלשונית Development. שם כתוב מה השתנה בכל גרסה, ולפעמים גם אם הבעיה שלך כבר תוקנה בגרסה חדשה יותר.
גרסה ישנה היא פתרון זמני. בינתיים כדאי לכבות לתוסף הזה את העדכון האוטומטי, כדי שלא יחזור לגרסה השבורה, ולעקוב אחרי הגרסה הבאה.
לפני שמתקינים תוסף וורדפרס חדש
חלק מהתקלות אפשר למנוע כבר בבחירה. מסך Site Health של וורדפרס מזכיר שלתוספים יש גישה עמוקה לאתר, ולכן חשוב לשמור אותם מעודכנים. אותו היגיון תקף גם לפני ההתקנה, כי כל תוסף שנכנס לאתר הוא עוד קוד שרץ בכל טעינת עמוד.
לפני שמתקינים, שווה לפתוח את עמוד התוסף ב-wordpress.org ולהסתכל על שלושה נתונים. Last updated מראה אם מישהו עדיין מתחזק אותו. Tested up to מראה אם הוא נבדק מול גרסת וורדפרס עדכנית. ו-PHP version מראה אם הוא מתאים לגרסה שרצה אצלך. אם כבר יש לך תוסף שעושה אותו דבר, עדיף לא להוסיף עוד אחד לאותה משימה, כי כל תוסף נוסף הוא עוד משהו לבדוק כשמשהו נשבר.
ואם אפשר, מתקינים ומעדכנים קודם בסביבת בדיקה ולא באתר החי. כך תוסף בעייתי נשבר שם, ולא מול הלקוחות שלך.
מתי לעצור ולקרוא למומחה
- אין גיבוי, ואין דרך לייצר אחד לפני שמתחילים.
- התוסף הבעייתי הוא הבסיס של האתר, כמו WooCommerce או בונה העמודים, והשבתה שלו מפילה את האתר כולו.
- השגיאה בלוג מצביעה על קוד מותאם שנכתב במיוחד לאתר.
- הגרסה הקודמת לא עובדת עם גרסת ה-PHP הנוכחית, והחדשה שבורה.
- מופיעים סימנים לפריצה: תוסף וורדפרס שלא התקנת, משתמשי מנהל חדשים או קבצים זרים.
במצבים האלה כל ניסיון נוסף עלול להחמיר. וגם כשמישהו אחר מטפל, קודם עושים גיבוי מלא.
שאלות נפוצות
איך יודעים איזה תוסף וורדפרס שבר את האתר?
מתחילים במייל ה-Recovery Mode שוורדפרס שולחת למנהל האתר. אם אין מייל, מפעילים WP_DEBUG_LOG ובודקים ב-wp-content/debug.log איזו תיקייה תחת wp-content/plugins מופיעה בשגיאה.
מה זה התנגשות תוספים וורדפרס?
מצב שבו כל תוסף עובד לבד, אבל כששניים פעילים יחד משהו נשבר. מוצאים את הזוג על ידי השבתה והפעלה של תוספים אחד אחד.
האם להפעיל עדכון תוספים אוטומטי?
התיעוד של וורדפרס ממליץ לשמור על תוספים מעודכנים לגרסה האחרונה מסיבות אבטחה, ומאז 6.6 יש rollback אם עדכון אוטומטי שובר את האתר. לפני שמפעילים, התיעוד ממליץ לוודא שיש גיבויים אוטומטיים שאפשר לחזור אליהם.
השבתת תוסף מוחקת את ההגדרות שלו?
השבתה דרך שינוי שם תיקיית התוספים שומרת את ההגדרות, לפי התיעוד של וורדפרס. מחיקה של תוסף היא סיפור אחר, ולכן בזמן אבחון משביתים ולא מוחקים.
איך משביתים תוסף בלי גישה ללוח הבקרה?
ב-FTP או במנהל הקבצים משנים את שם התיקייה של התוסף בתוך wp-content/plugins, או את שם התיקייה plugins כולה כדי להשבית את כל התוספים.
אפשר לחזור לגרסה קודמת של תוסף?
כן. לתוספים מ-wordpress.org אפשר להתקין גרסה מסוימת עם הפקודה wp plugin install והאפשרות --version. לתוסף בתשלום מבקשים מהספק את קובץ הגרסה הקודמת.
מצאת את התוסף אבל לא ברור מה לעשות איתו, או שהאתר עדיין לא עולה? דבר איתי ואני אטפל בזה.
למקורות: שאלות התקלות הנפוצות בתיעוד של וורדפרס והמדריך הרשמי לעדכונים אוטומטיים של תוספים.