עדכון עצמי של הליבה

הליבה של WIZZO CMS (התיקייה system/core באתר) מתעדכנת מתוך האתר עצמו: האתר שואל את השרת הראשי של Wizzo מה הגרסה הנוכחית, מוריד ZIP, מחליף את תיקיית הליבה ומסנכרן סכמת בסיס נתונים, פאנלים ומשימות cron. הדף הזה מתאר את התהליך שלב אחר שלב, מה נבדק לפני ואחרי ההחלפה, מתי מתבצעת חזרה אוטומטית אחורה, ומה בדיוק נוגעים בו ומה לא.

הרכיבים#

איך מפעילים עדכון#

הפלט של get הוא טקסט: true בהצלחה, false בכישלון. כל מילה נוספת שנדפסת אחריו (למשל שגיאת יצירת טבלה מהסנכרון) גורמת לממשק להציג שגיאה, למרות שהחלפת הליבה עצמה כבר בוצעה.

התהליך שלב אחר שלב#

ADMINMODULE_wizzo_update::get() מבצע את הרצף הבא:

1. רישום עוגן. יוצר את CRM_wizzo_update_log אם חסרה, קורא את head_sha של העדכון המוצלח הקודם, ושואל את השרת הראשי (/head) מה ה-sha הנוכחי. ה-sha נרשם ללוג רק אחרי הצלחה. כשל בשלב הזה לא עוצר עדכון.
2. מה מוצע. GET {MASTER}/get?ver=<מותקן>&format=json&channel=latest|stable מחזיר {ok, version, channel, url, sha256, size, php_floor}, או {ok, up_to_date: true}. מאסטר ישן שעונה טקסט מקבל את המסלול הישן (כתובת ZIP גולמית, בלי חתימה).
3. עדכון לא נדרש. אם אין גרסה חדשה בערוץ, לא יורד ZIP ולא מוחלפת ליבה, אבל שלב 11 (הסנכרונים) עדיין רץ. כך "הרצה כפויה" מסנכרנת טבלאות ופאנלים גם בלי גרסה חדשה.
4. בדיקה מקדימה (preflight). נכשל עם סיבה קצרה ביומן, ושום קובץ לא נוגע: php_too_old <יש> < <נדרש>, no_zip_extension, disk_full <פנוי> < <נדרש> (הנדרש הוא הגדול מבין 64MB ופי 4 מגודל ה-ZIP), db_unreachable.
5. הורדה. copy() בזרימה (timeout של 600 שניות) לקובץ ZIP בתיקיית העבודה. קובץ קטן מ-1KB נחשב כשל.
6. אימות sha256. במסלול ה-JSON, אי-התאמה היא zip_checksum_mismatch והקובץ נמחק.
7. פריסה בצד. הפריסה היא לתיקייה core_new_<ts> לצד הליבה החיה, שממשיכה לשרת. אם חסרים core.php או version.txt, היא נמחקת (broken_extraction).
8. החלפה. שני rename: core אל core_bup_<ts>, ואז core_new_<ts> אל core. אם השני נכשל, הראשון מוחזר מיד (swap_in_failed).
9. בדיקה אחרי (postflight). בקשה לאתר עצמו, {env_url}/system/core_ping?_wz=<rand> (עד 60 שניות, ללא מטמון). תשובה 5xx, גוף שאינו ה-JSON של core_ping, db: false, או גרסה שונה מהצפויה, מחזירות את הליבה הישנה אוטומטית ביומן postflight_failed ... (rolled back to <גרסה>). אם אין תשובת HTTP בכלל (DNS, חומת אש פנימית), הבדיקה נחשבת עוברת, כי הליבה לא נשפטת על רשת השרת.
10. הצלחה. מדפיס true, רושם ל-CRM_wizzo_update_log (status=success), ושומר את חמשת גיבויי core_bup_* האחרונים.
11. סנכרונים. בסדר: protect_system_folder() (שותל את .htaccess של /system/), update_db(), update_panel(), update_cron_system(), update_js(). אחריהם attaches_version עולה ב-1 (שובר מטמון נכסים בדפדפנים), מטמון params מנוקה, ו-external_mcp::flush() מנקה את רשימת הכלים שה-gateway מגיש.

// maintenance script: is an update waiting, and can this PHP take it?
$ver = trim(file_get_contents(CONFIG::$core_path . "/version.txt"));
$ctx = stream_context_create(["http" => ["timeout" => 20, "ignore_errors" => true]]);
$j = json_decode((string)@file_get_contents(
    "https://wizzocms40.wizzo.co.il/system/check_version/check?ver=" . rawurlencode($ver)
    . "&format=json&channel=stable", false, $ctx), true);

if (!empty($j["update_available"]) && version_compare(PHP_VERSION, $j["php_floor"], ">="))
{
    // run the update itself only from the panel: {admin}/wizzo_update
}

ערוצים: latest ו-stable#

אם אין גרסה קפואה או שה-ZIP שלה חסר, stable נופל ל-latest והתשובה כוללת stable_fallback: true. ההקפאה (promote) דורשת סוד בוט ומקפיאה רק את הגרסה שהשרת הראשי מריץ באותו רגע (נשמרות חמש גרסאות אחרונות). פרסום גרסה לכל הצי הוא החלטה של אדם, לא של סשן אוטומטי.

אין באתר פרמטר קבוע שבוחר ערוץ: הערוץ נבחר בבקשה. סביבת פיתוח מקומית בדרך כלל לא מריצה את הפאנל כלל, אלא מציבה את api/core כ-symlink או checkout של הריפו.

מה מוחלף ומה לא#

• מוחלפת רק התיקייה system/core (שהיא api/core בריפו). application/, themes/, storage/, CONFIG_USER, המטמון ו-system/market_settings.json לא נוגעים.
• system/js מוחלפת בשלמותה בתהליך נפרד (update_js), ובלי גיבוי אטומי: התיקייה הישנה עוברת ל-js_bup_<ts> לפני הפריסה, ואם הפריסה נכשלת לא חוזרים אליה אוטומטית.
• שינויים מקומיים בתוך core/ נמחקים בעדכון הבא, והם נשארים רק בגיבוי core_bup_<ts> לחמישה עדכונים. אין מנגנון patch או overlay, ולכן כל התאמה שייכת ל-application/.
• בסיס נתונים: update_db() רק מוסיף טבלאות, עמודות ואינדקסים (טבלה חדשה בקידוד utf8mb4). הוא לא מוחק, ומרחיב עמודה רק כשזו הרחבה בטוחה.
• פאנלים: update_panel() מעדכן שורות ב-adminPanel_panels לפי panel_name (טקסט, אייקון, extra_perms, perm_developer), מוסיף אפשרויות חסרות, ויוצר קטגוריה רק לפאנל חדש.
• משימות cron: update_cron_system() הוא מקור אמת: משימות בקטגוריה 1 ("מערכת") שאינן בשרת הראשי נמחקות מהאתר. שדות ריצה (last_run, next_run, runs_count) נשמרים. משימות שלכם שייכות לקטגוריה אחרת.

טבלאות ופרמטרים#

SELECT date_created, status, from_version, to_version, error_text
FROM CRM_wizzo_update_log
ORDER BY id DESC
LIMIT 5

קודי השגיאה שמופיעים ב-error_text: master_unreachable, php_too_old, no_zip_extension, disk_full, db_unreachable, zip_download_failed, zip_checksum_mismatch, cannot_open_zip, broken_extraction, swap_out_failed, swap_in_failed, postflight_failed.

הערות שחרור בפאנל#

לשונית "מה מחכה" שואלת את השרת הראשי: GET {MASTER}/changes?ver=<מותקן>&from_sha=<קודם> מחזיר רשימת commits מסוכמת, עם סיכום שנוצר ב-WizzoAI ונשמר פעם אחת בשרת הראשי עבור כל הצי. נושא commit שמסומן [security] או [breaking] מדליק דגל מודגש בפאנל. כל תשובה מהרשת מפורקת ומורכבת מחדש לפני שהיא נכנסת לעמוד כ-HTML.

ראו גם#

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