מדריך שדרוג גרסאות PHP לאתרי WordPress: איך לעשות זאת בבטחה?

מבוא

בעבר, כאשר שיניתי את גרסת ⁦PHP⁩ במהלך עדכון ⁦WordPress⁩, התרחש ⁦HTTP⁩ 500 (⁦Internal Server Error⁩).

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

באותו זמן לא הצלחתי לזהות את הסיבה.

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

כשבדקתי באתר ⁦WordPress⁩ שלי, גרסת ⁦PHP⁩ הייתה 7.4. זו הייתה גרסה שהתמיכה הרשמית בה כבר הסתיימה.

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

לכן, החלטתי לעדכן ל-⁦PHP⁩ 8.5.

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

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

למרות שיש לי ניסיון בפיתוח מערכות עסקיות שבמרכזן ⁦Java⁩, אין לי ניסיון רב בהפעלת ⁦WordPress⁩ או ⁦PHP⁩.

הפעם, גם בדקתי עד כמה אני יכול להשאיר את החקירה וארגון ההליכים ל-⁦AI⁩.

שגיאת 500 הקודמת נותרה בלתי מוסברת

זהו סיפור מהזמן שבו עדכנתי את ליבת ה-WordPress שלי.

באותו זמן, הגרסה של WordPress הייתה ישנה, וה-PHP בסביבת ה-staging היה בגרסה 8.3.

כאשר ניגשתי לאתר במצב זה, התרחשה ⁦HTTP⁩ 500.

זה חזר לתצוגה רגילה כשהחזרתי את ⁦PHP⁩ ל-7.4, אבל לא זיהיתי את הסיבה הישירה.

למרות שחשדתי בבעיות תאימות עם ליבת ה-WordPress, ערכות הנושא והתוספים, הדבר לא אושר.

לאחר מכן, הצלחתי לעדכן את הליבה ⁦WordPress⁩.

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

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

ראשית, אישרתי את שיטות הגיבוי והחזרה.

התצורה לזמן זה היא כדלקמן.

• שרת אירוח: Lolipop • גרסת WordPress: 7.1.4 • גרסת PHP: 7.4 CGI • יעד עדכון: PHP 8.5 CGI • ערכת נושא: ערכת נושא מסחרית מדור ישן • תוספים: בשימוש מרובה • ניהול קבצים: WinSCP • ניהול בסיס נתונים: phpMyAdmin

השתמשתי שוב הפעם בסביבת ה-staging שנוצרה במהלך עדכון ה-WordPress הקודם.

ראשית, הורדתי את כל הקבצים של ⁦WordPress⁩ מסביבת ה-Staging ל-⁦PC⁩ שלי באמצעות ⁦WinSCP⁩, וייצאתי את ⁦DB⁩ בפורמט ⁦SQL⁩ מ-⁦phpMyAdmin⁩.

יתר על כן, אישרתי במסך הניהול ⁦Lolipop⁩ שניתן להחזיר את ⁦PHP⁩ לגרסה 7.4 המקורית.

עם זה, הייתי מוכן להמשיך בעבודת העדכון.

נקודת מפתח הפעם: פלט של שגיאות ⁦PHP⁩ ליומן

הפעם, הדבר החשוב ביותר היה להיות מסוגל להשיג יומני שגיאות לפני עדכון ⁦PHP⁩.

מה שהוצע על ידי ⁦ChatGPT⁩ היה להשתמש ב-⁦WP_DEBUG_LOG⁩ של ⁦WordPress⁩.

בקובץ התצורה של סביבת הבמה ⁦wp-config.php⁩, זה היה בתחילה במצב הבא.

⁦define('WP_DEBUG', false);⁩

⁦define('WP_DEBUG', true); define( 'WP_DEBUG_LOG', __DIR__ . '/wp-content/php-debug-logs/debug.log' ); define('WP_DEBUG_DISPLAY', false);⁩

המשמעות של כל הגדרה היא כדלקמן: • WP_DEBUG: הפעלת מצב ניפוי באגים • WP_DEBUG_LOG: ציון יעד שמירת היומן • WP_DEBUG_DISPLAY: אי-הצגת שגיאות בדפדפן

הגדרתי אותו להקליט לקובץ יומן מבלי להציג שגיאות על המסך.

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

לכן, יצרתי תיקיה ייעודית לשמירת יומנים והוספתי הגדרות מניעת גישה ל-.htaccess.

⁦<IfModule mod_authz_core.c> Require all denied </IfModule> <IfModule !mod_authz_core.c> Deny from all </IfModule>⁩

לאחר הגדרתו, כאשר הנחתי קובץ בדיקה וניגשתי אליו מדפדפן, הוחזר ⁦HTTP⁩ 403 ⁦Forbidden⁩.

יתר על כן, אישרתי שגם לאחר יצירת קובץ היומן בפועל, ציון ה-⁦URL⁩ הביא ישירות ל-403.

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

בדקתי אם יומנים באמת מופקים.

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

לפעמים לא נוצר קובץ אם לא מתרחשות שגיאות שמתועדות ביומן.

אז, בהתבסס על ההצעה של ⁦ChatGPT⁩, יצרתי קובץ ⁦PHP⁩ זמני בסביבת הבמה.

⁦<?php require_once __DIR__ . '/wp-load.php'; error_log('WP_DEBUG_LOG_TEST'); echo 'TEST_COMPLETED';⁩

כאשר ביצעתי את זה, '⁦TEST_COMPLETED⁩' הוצג בדפדפן, וגם מחרוזת הבדיקה נרשמה בקובץ היומן.

הצלחתי לאשר שכתיבת יומן פעלה כרגיל.

לאחר אימות, מחקתי את הקובץ ⁦PHP⁩ שנוצר באופן זמני.

⁦ChatGPT⁩ הציע ⁦PHP⁩ 8.4. עם זאת, ניסיתי תחילה 8.5.

בתחילה, ההצעה של ChatGPT הייתה לבצע אימות עם PHP 8.4 לפני שממשיכים ל-8.5.

הסיבה הייתה ש-8.4 שוחרר זמן רב יותר והיה בו יותר מידע תאימות מצטבר.

עם זאת, המטרה הפעם היא להפעיל אותו בסופו של דבר ב-⁦PHP⁩ 8.5.

גם אם אין בעיות עם 8.4, יש צורך לבדוק שוב עם 8.5.

במקרה כזה, האם לא יהיה יעיל יותר לנסות 8.5 מההתחלה ולשקול 8.4 או אחרים אם מתעוררות בעיות?

כשהעברתי את המחשבה הזו ל-ChatGPT, ההצעה עודכנה.

זה היה מצב שבו אדם עשה שיקול דעת על בסיס המטרה, במקום לאמץ את ההצעה של ⁦AI⁩ כפי שהיא.

עדכון ל-⁦PHP⁩ 8.5. הפעם, לא אירעה שגיאת 500.

ממסך הניהול ⁦Lolipop⁩ שיניתי את ⁦PHP⁩ של סביבת הבמה מ-7.4 ל-8.5.

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

תמונות, סרטונים, קישורים ולוח המחוונים של הניהול ⁦WordPress⁩ כולם פעלו כרגיל.

הצלחתי גם לאשר מהדף ⁦Site Health⁩ שהוא אכן פועל ב-⁦PHP⁩ 8.5.

500 השגיאות ⁦HTTP⁩ שהתרחשו בעבר לא התרחשו הפעם.

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

למרות שהתצוגה הייתה תקינה, היו מספר רב של הודעות ⁦Deprecated⁩ ביומנים.

לאחר עדכון ל-⁦PHP⁩ 8.5, העברתי את יומני השגיאה ל-⁦ChatGPT⁩ לצורך ניתוח.

למרות שלא היו בעיות בתצוגת המסך, נרשמו מספר רב של הודעות ⁦Deprecated⁩.

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

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

דוגמאות כוללות יצירת מאפיינים דינמיים ותהליכים המעבירים פונקציות Null למחרוזת.

סידרתי ⁦ChatGPT⁩ את קבצי המקור וסוגי ההתראות, והמשכתי באימות.

לאחר מכן, עדכנתי את כל התוספים הפעילים מלוח המחוונים של הניהול ⁦WordPress⁩.

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

לא נרשמו ⁦Fatal⁩ שגיאות או ⁦Warnings⁩ ביומנים שבדקתי.

לא תיקנתי את כל ההודעות ⁦Deprecated⁩ הפעם.

המטרה הפעם הייתה ההגירה ל-⁦PHP⁩ 8.5, ולא אושרו בעיות בהפעלת הפונקציות העיקריות.

עם זאת, מאחר שעדכונים עתידיים של ⁦PHP⁩ נותרו סיכוני תאימות, דחיתי לטפל בהם.

בודק גם עיבוד אימות מותאם אישית ⁦REST⁩ ⁦API⁩

באתר זה, הוספתי בעבר עיבוד עוזר אימות מותאם אישית לפלאגין ⁦MU⁩ כדי לטפל בבעיות אימות ⁦REST⁩ ⁦API⁩.

לאחר עדכון ל-⁦PHP⁩ 8.5, אישרתי שבקשות ⁦GET⁩ מאומתות קיימות עדיין מסתיימות בהצלחה.

עם זאת, לא בדקתי את כל הפונקציות ⁦REST⁩ ⁦API⁩, כולל פרסום ועדכון.

עדכון אתר הייצור ל-⁦PHP⁩ 8.5 גם כן

לאחר אימות בסביבת הבמה, החזרתי את הגדרות ניפוי הבאגים ⁦WordPress⁩ ל-⁦OFF⁩.

לאחר מכן עדכנתי את ⁦PHP⁩ ל-8.5 בסביבת הייצור ועדכנתי גם את התוספים.

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

אשאיר את ההודעות הנותרות ⁦Deprecated⁩ וכדומה למשימות תחזוקה עתידיות.

AI הוא נוח, אך לעיתים היה קפדני מדי בבדיקות

הפעם, ⁦ChatGPT⁩ הדריך אותי דרך העבודה צעד אחד בכל פעם.

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

מצד שני, פריטי האימות הפכו למפורטים ביותר באמצע הדרך.

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

אז, אמרתי ⁦ChatGPT⁩ לצמצם את זה לבדיקות הנדרשות.

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

בצד: גם מסך התגובה ⁦ChatGPT⁩ הפך נוח יותר

דבר נוסף שהיה נוח היה הממשק לאינטראקציה עם ⁦ChatGPT⁩.

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

בעוד שיש יותר מדי פריטי אימות היה נטל, פעולת המענה בפועל הפכה לקלה יותר.

זה היה מעניין ש⁦AI⁩ לא רק מציע משימות אלא גם מספק ממשק שמקל על בני אדם להגיב.

תַקצִיר

הפעם, הצלחתי להמשיך בהצלחה עם העדכון מ-⁦PHP⁩ 7.4 ל-8.5.

בעבר, אירעה שגיאת 500 במהלך עדכון ⁦PHP⁩ ונאלצתי להחזיר אותה לאחור מבלי שהצלחתי לזהות את הסיבה.

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

כתוצאה מכך, לא התרחשה שגיאת 500, כך שלא היה צורך להשתמש ביומנים המוכנים להתאוששות מאסון.

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

הפעם לא היה לי ⁦ChatGPT⁩ להפעיל את השרת ישירות.

השארתי את ארגון הנהלים, הצגת חומרי קבלת החלטות וניתוח יומן ל-⁦AI⁩, תוך שביצעתי את הפעולות בפועל וההחלטות הסופיות בעצמי.

במקום להשאיר הכל ל-⁦AI⁩, השתמשתי ב-⁦AI⁩ כדי להפחית את הסיכונים של עבודת השינוי.

הרגשתי שזו גם דרך בעלת ערך מספיק לניצול ⁦AI⁩ בעבודה מעשית.

סיכום השימוש ב-AI

• מה השארתי ל-AI: ארגון נהלי עדכון, הצעה לשיטות הפקת יומנים, ניתוח יומני שגיאות וארגון פריטי אימות. • מה עשיתי בעצמי: גיבויים, תצורת שרת, בדיקות תקינות והחלטות סופיות. • מה שיניתי מההצעה של AI: ביצוע אימות עם 8.5 מההתחלה במקום לעבור דרך PHP 8.4. • כיצד ה-AI היה מועיל: גם ללא מומחיות ב-PHP, הצלחתי לבצע בדיקות באמצעות יומנים. • מקום לשיפור ב-AI: היו מקרים שבהם הליכי האימות הפכו מפורטים מדי. • תוצאות בפועל: עדכון סביבות ה-staging וה-production ל-PHP 8.5. • נושאים לא פתורים/לא מאומתים: הודעות Deprecated הקשורות לערכות נושא נותרו. לא בוצעה בדיקה מקיפה של כל הפונקציות.