לפני עדכון ליבה

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

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

הרשימה בקצרה#

קבוצות עם "צפייה בלבד"#

זה השינוי היחיד שנמצא שובר עבודה בפועל.

עד 5.0.162 הסימון "צפייה בלבד" (קבוצה שקיבלה פאנל בלי "עריכה") הסתיר כפתורים ברשימה, אבל השמירה עצמה לא נבדקה: טופס שנפתח לקבוצה כזו נשמר. מ-5.0.162 ADMIN::may_save() בודק את הרשאת העריכה של הפאנל בכל שמירה של Form ו-panel_table, והמנהל מקבל "אין לקבוצת ההרשאות שלך הרשאת עריכה". פרטים ב-חוקי יסוד לפאנל ולבקר.

המקרים שנמצאו באתרים אמיתיים נראים כך:

• קבוצת SEO שקיבלה על פאנל הכתבות רק את ההרשאה seo, בלי edit. מסך העריכה מציג לה את לשונית ה-SEO ושומר את הטופס כולו, ולכן אחרי העדכון היא לא תוכל לשמור.
• קבוצה שכל התפקיד שלה הוא פעולה אחת בטופס (למשל שיוך פריט לרשומה), ומוגדרת "צפייה בלבד" על הפאנל של הפעולה.
• קבוצת עורכים בכירים עם צפייה בלבד על מסך הגדרות שהם בכל זאת עורכים.

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

מה עושים: מסמנים לקבוצה "עריכה" על הפאנל הזה, לפני העדכון. זה לא נותן לה יותר ממה שהייתה לה בפועל. אל תפתרו את זה עם static $admin_legacy_perms = true ב-config.php: זה מחזיר את ההתנהגות הישנה לכל הקבוצות ולכל הפאנלים באתר, ומשאיר פתוחה את הפרצה שהשינוי סגר. ההגדרה הזו קיימת לחירום של יום אחד, לא כפתרון.

SQL גולמי על עמודי התוכן#

מ-5.0.148 עמודי התוכן (CRM_pages) עובדים עם סטטוס וטיוטות: עמוד יכול להיות טיוטה, מוסתר או מתוזמן. האתר מסנן אותם אוטומטית כשקוראים דרך הבונה (DB::get_val("pages", ...), DB::query("pages", ...)). שאילתה גולמית (DB::get_all, DB::get_row, DB::sql) לא מסוננת, ותחזיר גם עמוד שעורך הסתיר.

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

איך בודקים: מחפשים בתיקיות של האתר (application, themes), בלי הליבה, את המחרוזת pages בשאילתות SQL שנכתבו ביד, למשל:

grep -rn --include=*.php -E "(db_fullprefix|db_prefix)[^;]*pages|CRM_pages" application themes

מה עושים, אחד מהשניים:

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

$where = method_exists("CONTENT", "visible_where") ? CONTENT::visible_where("pages") : "1=1";
$rows = DB::get_all("SELECT id FROM " . CONFIG::$db_fullprefix . "pages WHERE " . $where);

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

cron#

הפרסום המתוזמן לא תלוי ב-cron: עמוד שהגיע זמנו עולה בבקשה הראשונה לאתר. מה שתלוי ב-cron הוא הניקוי היומי של גרסאות ישנות (גרסאות ושחזור) ומשימות שהאתר עצמו רושם. אם בפאנל מנהל משימות רואים ש-cron לא רץ מעולם או נעצר, העדכון לא נחסם, אבל כדאי לברר למה, כי זה נוגע גם למשימות של האתר.

טבלאות גדולות#

העדכון מוסיף עמודה או אינדקס רק כשהם חסרים בטבלה שהליבה מכירה. טבלאות של האתר עצמו (אנליטיקה, לוגים, תוכן ייעודי) לא נוגעות. הטבלאות של הליבה שגדלות הכי הרבה (CRM_users_logins, CRM_emails_queue, CRM_storage) כבר במבנה הנוכחי באתרים שנבדקו, ולכן אין שם ALTER ארוך. אם יש לכם טבלת ליבה עם עשרות מיליוני שורות, כדאי לעדכן בשעה שקטה.

גיבוי בסיס הנתונים#

אתר שכבר על 5.0.170 ומעלה שומר לפני כל עדכון גיבוי מוצפן של הטבלאות שהעדכון עומד לשנות, ועדכון שנכשל מחזיר אותן (גיבוי בסיס הנתונים ושחזור). באתר על ליבה ישנה, העדכון שמביא אותו ל-5.0.170 עוד רץ בקוד הישן ובלי הגיבוי הזה: לפני העדכון הזה כדאי גיבוי מלא של בסיס הנתונים, כמו תמיד. הגיבוי נשמר בתיקייה .wizzo_update_backups שמעל שורש האתר, ואם המשתמש של PHP לא יכול לכתוב שם, ב-system/.update_backups.

שרת MariaDB 5.5#

בשרת כזה update_db לא מצליח ליצור טבלאות שיש בהן DEFAULT CURRENT_TIMESTAMP על עמודת datetime (זה נתמך מ-MariaDB 10.0), ממשיך הלאה ורושם שגיאה. הטבלאות של זרימת העבודה, הגרסאות ויומן הביקורת לא משתמשות בזה ונוצרות. אחרי העדכון קראו את השורה האחרונה ב-CRM_wizzo_update_log, ובטווח הארוך תכננו מעבר לשרת חדש יותר.

אחרי העדכון#

1. השורה האחרונה ב-CRM_wizzo_update_log היא success עם הגרסה החדשה ב-to_version. מ-5.0.170 GET {admin}/wizzo_update/backups מראה את הגיבוי של העדכון ואילו טבלאות בו (עדכון שלא שינה מבנה לא יוצר גיבוי).
2. עורך מכל קבוצה שבדקתם שומר פריט אחד בפאנל שלו.
3. SHOW COLUMNS FROM CRM_pages LIKE 'wz_status' מחזיר שורה, וכל העמודים הם published.
4. מפת האתר (/sitemap.xml) נטענת.

ראו גם#

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