אבחון קוד ו-lint · WIZZO CMS Docs

כשמשהו נשבר באתר, יש בליבה כמה כלים שעונים על שאלות שונות: האם הקובץ שאני שומר תקין (FileLint), איזה קוד נמצא סביב השורה שנכשלה (CodeDiagnosis), האם ה-cron והשרת מוגדרים נכון (cron_manager/diagnostics), והאם הליבה בכלל עולה (core_ping). בדף הזה: מה כל כלי עושה, החתימות המדויקות, ואילו הגבלות בטיחות מובנות בו.

FileLint: בדיקת תחביר לפני שמירה#

libraries/FileLint.php היא ספריית בדיקה בצד השרת. מנהל הקבצים (ראו מנהל קבצים) קורא לה בכל שמירה, ושגיאה קשה חוסמת את הכתיבה, כדי ששמירה שבורה לא תפיל אתר חי. הבדיקה לא דורשת exec().

סיומת	מנוע	הערה
`php`, `phtml`	`token_get_all($content, TOKEN_PARSE)`	זורק `ParseError` על תחביר שגוי. כש-`exec` זמין נוסף גם `php -l` כדעה שנייה
`scss`	scssphp של הליבה	אותו מהדר שמשמש בפרודקשן
`css`	scssphp	CSS הוא תת-קבוצה של SCSS
`json`	`json_decode` + `json_last_error_msg()`	מספר השורה מחושב בקירוב, ורק לקובץ עד 2000 שורות
כל השאר	אין	`checked: false`. JS, YAML ו-HTML נבדקים רק ב-CodeMirror בצד הלקוח

מתודות ציבוריות#

חתימה	ערך החזרה
`FileLint::check(string $filename, string $content): array`	`{checked, ok, language, engine, error, line}`
`FileLint::supports(string $filename): bool`	האם הסיומת נבדקת בצד השרת

שדה בתשובה	משמעות
`checked`	האם בוצעה בדיקה אמיתית. `false` לסוג קובץ שלא נתמך או כשהמנוע לא זמין
`ok`	האם התוכן תקין. כשלא נבדק, `true`
`language`	`php`, `scss`, `css`, `json` או הסיומת
`engine`	`token_get_all`, `token_get_all + php -l`, `php -l`, `scssphp`, `json_decode`, `none` או `unavailable`
`error`, `line`	הודעת השגיאה ושורה, או `null`

$this->load->library("FileLint");

$r = FileLint::check("application/models/product.php", $source);

if ($r["checked"] && !$r["ok"])
{
    echo "Syntax error on line " . (int)$r["line"] . ": " . $r["error"];
}

איך מנהל הקבצים משתמש בה#

פעולת lint ב-API של מנהל הקבצים מחזירה את התוצאה בלי לשמור.
פעולת write מריצה את FileLint::check ואם checked ו-ok שקר, מחזירה {"success": false, "code": "lint", "lint": {...}} ולא כותבת. שליחת force בבקשה עוקפת את החסימה, וגם זה נרשם ביומן.
מנהל הקבצים עצמו פתוח רק למפתחים (ADMIN::is_developer()), והוא מחזיר 403 לכל השאר.

הערה

FILES::scss() שמהדר SCSS בפרודקשן בולע שגיאות קומפילציה ופשוט לא מייצר CSS, ולכן stylesheet שבור נראה כ"שום דבר לא קרה". FileLint מציג את הודעת השגיאה האמיתית. אם עריכת SCSS "לא משפיעה", בדקו אותו עם FileLint::check לפני שאתם מחפשים בעיית מטמון. ראו צינור הנכסים.

שימו לב

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

CodeDiagnosis: חבילת קוד לניתוח#

libraries/CodeDiagnosis.php (מחלקה שיורשת מ-wz_model) בונה חבילת קוד מוגבלת סביב מיקומים שנמצאו בבעיה, ואופציונלית שולחת אותה למודל AI. היא קריאה בלבד: כל גישה לקובץ עוברת דרך FileManager, שאוכף את גבולות האתר (jail) ואת מסכת הקבצים הרגישים. את המרת האבחנה לטיקט עושה הקורא, לא הספרייה.

קבועים#

קבוע	ערך	משמעות
`MAX_BUNDLE_BYTES`	60000	סך הקוד שנשלח (בבתים, על פני כל החלקים)
`WINDOW_LINES`	90	שורות הקשר מעל ומתחת לכל מיקום
`MAX_FILES`	8	מספר קבצים מקסימלי בחבילה
`MAX_GREPS`	2	מספר מונחי חיפוש מקסימלי
`MAX_GREP_MATCHES`	20	תוצאות מקסימליות לכל מונח

מתודות ציבוריות#

חתימה	ערך החזרה	הערה
`CodeDiagnosis::collect(array $locs, array $grep_terms = [], $budget = self::MAX_BUNDLE_BYTES)`	`{sections: string[], files: string[], bytes: int, truncated: bool}`	`$locs` הם מחרוזות `"path/file.php:123"`, יחסיות ל-`CONFIG::$base_path` או מוחלטות. חלונות חופפים מאוחדים. קובץ חסר, בינארי או חסום מדולג בשקט
`CodeDiagnosis::diagnose(array $payload, $system_msg, array $json_schema, $model = "", $provider = "")`	מערך תשובה, או `null` בכישלון	קריאת AI אחת במצב JSON דרך `wizzo_ai::json`. `$model` ו-`$provider` נשלחים כזוג
`CodeDiagnosis::models()`	`[{id, name, provider}]`	רשימת מודלים לבורר. מערך ריק כשאין

חיפוש הטקסט ($grep_terms) מתבצע בתיקיית api/ של האתר אם קיימת, על קבצי php ו-tpl בלבד, ומונח קצר מ-4 תווים מדולג.

$this->load->library("CodeDiagnosis");

$bundle = CodeDiagnosis::collect(
    ["application/controllers/orders.php:214"],
    ["CRM_orders"]
);

foreach ($bundle["sections"] as $section)
{
    echo $section;
}

מי קורא לה#

OlegAgent::code_bundle($locs, $tables), מהפעולה code_bundle של perf_runner (ראו בריאות ותפקוד): קוד סביב נקודות הקריאה של שאילתות כבדות.
SeoTickets של מנוע ה-SEO המאוחסן, דרך seo_runner, כדי לצרף קוד לטיקט ב-TODO של האתר.

שימו לב

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

אבחון cron ו-exec#

{admin}/cron_manager/diagnostics מציג טבלה שעונה על השאלה "למה ה-cron לא רץ". הערכים נקראים בזמן אמת בשרת, וכוללים:

נושא	מה מוצג
סביבת PHP	`PHP_SAPI`, `PHP_OS`, קובץ ה-`php.ini` הטעון, `disable_functions`, `open_basedir`, וכתיבות לתיקיית ה-temp
משתמש התהליך	משתמש ה-PHP (`posix_getpwuid`), `PHP_BINARY` והאם הוא קובץ ובר-הרצה
`exec`	האם `exec` ו-`shell_exec` קיימות ואינן חסומות, ומבחן `exec('echo ...')`
crontab	מיקום `crontab`, התוצאה של `crontab -l` כמשתמש ה-web, והאם `cron_runner` מזוהה בו
הרצה מומלצת	שורת ה-cron המומלצת להתקנה
`cron_runner_heartbeat`	הזמן האחרון שהמנוע רץ ("מעולם לא רץ" כשאין)

חשוב להבין: התקנת crontab מהדפדפן רצה כאותו משתמש ש-PHP רץ תחתיו (למשל www-data), ולכן crontab -l ב-SSH כ-root יראה משהו אחר ממה שהעמוד מציג. ראו Cron.

שימו לב

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

core_ping: האם הליבה עולה#

GET {site}/system/core_ping מחזיר JSON קצר, בלי הרשאה ובלי מטמון (Cache-Control: no-store):

{"ok": true, "version": "5.0.115", "db": true, "php": "8.3.12"}

שדה	משמעות
`ok`	תמיד `true`. תשובה שאינה ה-JSON הזה (500, דף לבן) פירושה שהליבה לא עולה
`version`	תוכן `version.txt`
`db`	האם `SELECT 1` מול מסד הנתונים הצליח
`php`	`PHP_VERSION`

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

ראו גם#

בריאות ותפקוד, האוסף של אולג, server_load, error_log
מנהל קבצים ו-עדכון עצמי
דיבוג מסד נתונים ו-Cron
Composer, לאבחון תלויות