סקריפטים ופיקסלים

"סקריפטים ופיקסלים" ({admin}/tag_manager) הוא המקום היחיד שבו אתר מוסיף קוד לעמודים שלו: פיקסל של Meta או של Google, תג אימות של Search Console, ווידג'ט צ'אט, כלי מדידה. עד גרסה 5.0.186 היו לזה שני מסכים, Scripts (טבלת CRM_scripts, קוד שנכתב ישר ל-HTML) ו-tag_manager (קבוצות שנטענות מקובץ JS). מגרסה 5.0.186 יש מסך אחד, טבלה אחת (CRM_tag_manager), ובכל שורה בוחרים איך הקוד נטען (תוכנית הסקייל, משימה 5).

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

שתי הדרכים#

תג אימות (<meta name="google-site-verification"> וכדומה) חייב להיות בתוך העמוד: הבודק של Google או של Meta קורא את ה-HTML ולא מריץ JS. שורה בתוך העמוד נשמרת תמיד בלי קבוצה ובלי מפתח עמוד, גם אם הטופס שלח אותם.

הסביבה (environment) עובדת בשתי הדרכים באותו כלל: all או ריק נטען תמיד, וערך אחר נטען רק כש-CONFIG::$environment שווה לו (TAG_MANAGER::env_ok()).

איפה הקוד נכתב בעמוד#

PAGE::output() קורא פעם אחת ל-TAG_MANAGER::inline_rows() וכותב את השורות של כל אזור עם TAG_MANAGER::inline_html($rows, $area), באותם מקומות שבהם CRM_scripts נכתב קודם:

1. סוף ה-head: אחרי SEO::get_schema("WebPage"), בצד לקוח בלבד.
2. מיד אחרי פתיחת ה-body: אחרי נכסי body_start.
3. סוף ה-body: אחרי writeLoadedFile(), לפני print_meta_tags("body_end") ו-/tag_manager.js?id=system.

כל שורה נכתבת כמו שהיא ואחריה ירידת שורה, בסדר ord ואז id. הפלט זהה בית בבית למה שהפאנל הישן הוציא, וזה נבדק ב-HTML של המאסטר לפני ההעתקה ואחריה.

השורות נשמרות במטמון 48 שעות במפתח scripts_inline. כל שמירה, מחיקה, הפעלה או שינוי סדר במסך מנקים אותו ואת הקובץ של הקבוצה שנגעו בה (TAG_MANAGER::clear_cache($groupIds)). המפתח לא נקרא scripts, כי cache_engine::remove() מוחק לפי prefix, ופאנל Scripts ישן של אתר מנקה scripts.

הטבלה#

CRM_tag_manager קיבלה שתי עמודות. update_db מוסיף אותן מהמבנה של המאסטר, ו-TAG_MANAGER::ensure_schema() מוסיף אותן גם באתר שעוד לא הריץ את update_db החדש.

/tag_manager.js (בקר minify) מגיש רק שורות file. שורת inline לא נכנסת לקובץ גם אם יש לה קבוצה.

ההעתקה של CRM_scripts#

TAG_MANAGER::migrate() מעתיק כל שורה של CRM_scripts לשורת inline ב-CRM_tag_manager, עם אותו שם, אזור, קוד, סדר ומצב פעיל, ו-legacy_script_id שמצביע על המקור. היא רצה פעם אחת לאתר:

• בעדכון גרסה: wizzo_update קורא ל-migrate_scripts() אחרי audit_update.
• בעמוד הראשון: העדכון שמביא את 5.0.186 עדיין רץ עם wizzo_update הישן, ולכן inline_rows() מריץ את ההעתקה בעצמו כשהיא עוד לא נעשתה. ניסיון שנכשל לא חוזר לפני שש שעות (מפתח המטמון tag_manager_migrate_try).

ההעתקה בטוחה להרצה חוזרת: היא רצה תחת GET_LOCK, מעתיקה רק שורות שאין להן עדיין legacy_script_id תואם, וכותבת את הסימן tag_manager_scripts_migrated ב-CRM_params (תאריך ומספר שורות) רק כשכל השורות הגיעו. אחרי הסימן היא לא רצה יותר, ושורה שנמחקה במסך החדש לא חוזרת.

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

אתר עם פאנל Scripts משלו#

admin/Scripts.php יצא מהליבה, והפאנל Scripts נכנס ל-AdminModule::RETIRED_PANELS: העדכון מוחק את השורה שלו מהתפריט. אבל אתר שיש לו עותק משלו ב-application/admin/Scripts.php שומר את הפאנל (AdminModule::is_retired() מחזיר false), וממשיך לכתוב ל-CRM_scripts. באתר כזה:

• ההעתקה לא רצה (TAG_MANAGER::may_migrate() מחזיר false), כדי ששורה חדשה בפאנל שלו לא תיתקע מחוץ למסך החדש.
• העמוד כותב קודם את CRM_scripts ואחר כך את שורות ה-inline של המסך החדש.
• במסך החדש מופיעה פסקה שמסבירה שיש לאתר פאנל "סקריפטים" משלו, ושהקוד שבו נטען לפני הקוד של המסך.
• השם בתפריט הוא "סקריפטים (הפאנל הישן)" (AdminModule::PANEL_NAMES).

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

הכתובות#

כל הטפסים עוברים את בדיקת ה-CSRF הכללית של הניהול (מגרסה 5.0.162), וכל שמירה ומחיקה נרשמות ביומן השינויים כמו כל Form ו-panel_table.

ראו גם#

• מחזור החיים של בקשה: איפה PAGE::output() כותב כל חלק בעמוד.
• PAGE: output() והאזורים שלו.
• הפאנלים המובנים.