איך לבדוק עדכון WordPress לפני פרסום ולהכין תוכנית שחזור

את כפתורי העדכון של WordPress קל למצוא. הרבה יותר קשה לבטל עדכון שנכשל בלי לאבד תגובות, הזמנות או טיוטות חדשות. לכן תהליך העבודה הבטוח ביותר אינו פשוט “לגבות וללחוץ על עדכון”. הוא מורכב מהגדרה של מה עשוי להשתנות, בדיקה בעותק של האתר ותרגול של החזרה למצב התקין הקודם.

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

לתעד מה משתנה

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

בודקים אם לתוספים או לקוד מותאם יש מגבלות מוצהרות של גרסה או של PHP. הערות השחרור של עדכונים מועילות, אבל אינן יכולות לחזות אינטראקציות שייחודיות לאתר שלכם. משתמשים בסביבת בדיקות (staging) עם עותק עדכני של התוכן וההגדרות האמיתיים. מגינים על סביבת הבדיקות מפני אינדוקס ציבורי ומפני גישה לא מורשית.

לגבות קבצים ומסד נתונים בנפרד

ייצוא מוצלח של מסד הנתונים בלי קובצי המדיה אינו גיבוי שלם. באותו אופן, העתקה של תיקייה בלי מסד הנתונים אינה יכולה לשחזר פוסטים או הגדרות. שומרים גיבויים מחוץ לשרת שמשנים, עם בקרות גישה ומגבלות שמירה מתאימות. כוללים כל הגדרת סביבה קריטית שנדרשת כדי לחבר מחדש אתר משוחזר, בלי לשמור סודות בארכיון חשוף.

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

לבדוק את מסלולי המשתמשים, לא רק את דף הבית

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

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

להחליט איך החזרה לאחור תעבוד בפועל

ספקי אחסון מסוימים מציעים תמונות מצב (snapshots); אצל אחרים נדרש שחזור של קבצים ושל מסד נתונים. שחזור מסד נתונים ישן עלול למחוק פעילות שהתרחשה אחרי תמונת המצב. באתר עמוס, פריסה שמחזירה את הקוד לאחור בנפרד מנתוני התוכן עשויה להיות בטוחה יותר, אבל הדבר תלוי בתאימות של המיגרציות. מתעדים את הבחירה לפני חלון העבודה באתר החי.

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

לעותק בסביבת בדיקות יש סכנה נוספת: הוא עלול לשלוח בטעות הודעות דוא״ל אמיתיות, לחייב אמצעי תשלום שמורים או לפרסם פוסטים בשירותים מחוברים. משביתים התראות יוצאות, חיבורי תשלום ו-webhooks של סביבת הייצור, אלא אם הבדיקה תוכננה במפורש ובוצעה בבידוד. מחליפים פרטי גישה חיים בפרטי גישה בטוחים לבדיקה. אתר בדיקות שחסום לאינדוקס אינו מאובטח מעצם כך; משתמשים באימות ונמנעים מהעתקה מיותרת של נתוני משתמשים רגישים.

לפני חלון העדכון רושמים רשימת קבלה תמציתית: חמש כתובות של כתבות מייצגות, כתבה אחת עשירה במדיה, התחברות של צוות העריכה, שמירת טיוטה, נתיב אחד בשפה אחרת וכל תהליך שקריטי להכנסות. לכל פריט נותנים תוצאה: עבר, נכשל או לא רלוונטי. שינוי ששובר רק את פיד ה-RSS או את מפת האתר עשוי שלא להופיע בסקירה החזותית של דף הבית, אבל עדיין מצדיק בדיקה לפני הפריסה באתר החי.

נוהל החזרה לאחור צריך להבחין בין גרסה פגומה לבין נתוני תוכן שנפגמו. אם רק גיליון סגנונות או קוד של תוסף פגומים, שחזור של מסד הנתונים כולו עלול לגרום לאובדן מיותר. מנגד, שינוי בפורמט הנתונים עשוי לחייב מיגרציה שמותאמת לאפליקציה. מגדירים מי אחראים לגיבויים, לאישור הפריסה, לניטור ולשחזור. כשאין דרך בטוחה לחזור אחורה משינוי מסוים, מציגים את הסיכון הזה בתוך הארגון ובוחרים חלון תחזוקה שמרני יותר.

לפרוס, לאמת ולסגור את המעגל

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

המדריך הזה עוסק ברצף השחרור, לא בכל חובות התחזוקה. רשימת הבדיקה לתחזוקת אתר הרחבה יותר מכסה את התחזוקה השוטפת, והמדריך למעבר אחסון עוסק במעבר בין תשתיות. תוכנית חזרה לאחור יציבה אינה פחד מעדכונים; היא התנאי שהופך עדכונים נחוצים לצפויים יותר.