פיתוח והתקנת מודולים ב-1C-Bitrix
המלכודת העיקרית של Bitrix היא init.php. אתה מוסיף שם handler של OnBeforeIBlockElementUpdate, ואז עוד אחד — כעבור שנה הקובץ מגיע ל-2000 שורות, ובכל קריאה כל הקוד הזה רץ. אנחנו מעבירים לוגיקה עסקית למודולים מלאים עם D7 ORM, טבלאות מותאמות אישית וממשק ניהולי. ניתן להשבית את המודול, להעביר אותו לפרויקט אחר, לכסות אותו בבדיקות — כל זה בלתי אפשרי עם init.php. לצוות שלנו יש ניסיון של 10+ שנים עם Bitrix, מומחים מוסמכים ואחריות קוד ל-6 חודשים. בקשו ייעוץ — נסביר כיצד להעביר קוד legacy לארכיטקטורה מודולרית.
למה init.php הוא המקום הגרוע ביותר ללוגיקה עסקית?
Init.php אינו תומך בטעינת מחלקות אוטומטית (autoloading), חסר מרחב שמות מבודד, לא ניתן לבדוק אותו ביחידות (unit tests), ולא ניתן להשבית אותו מבלי לערוך את הקובץ עצמו. כל handler שנכתב שם רץ בכל בקשה, גם אם אינו נחוץ. במודול, רושמים handlers דרך EventManager, והם רצים רק כשהאירוע מתרחש. הבדל בביצועים: עד פי 3 עם 10+ handlers.
מודולים סטנדרטיים: בעיות אופייניות ופתרונות
בלוקי מידע (Information blocks). ארכיטקטורת IBlock היא הדבר הראשון שאנחנו בודקים בכל פרויקט. טעות קלאסית: בלוק מידע אחד לקטלוג עם 80 מאפיינים, 30 מהם מרובי ערכים. טבלת b_iblock_element_property מתנפחת למיליוני שורות, ו-CIBlockElement::GetList עם סינון על שלושה מאפיינים מבצע סריקה מלאה. אנחנו מעבירים נתוני ייחוס ל-Highload-blocks, מבטלים מאפיינים מרובי ערכים היכן שאפשר, ומתכננים את המבנה לצמיחה פי 5.
e-Store (sale). חוקי עסקיים של עגלת קניות הם סיפור נפרד. אנחנו קובעים עדיפויות הנחות כדי למנוע משני קמפיינים לתת 60% במקום 30%, מחברים handlers לתשלום, וכותבים ולידציה מותאמת אישית דרך OnSaleOrderBeforeSaved.
חיפוש. מודול החיפוש המובנה עם מורפולוגיה עובד עד 10–15 אלף פריטים. מעבר לכך — Elasticsearch. אנחנו מגדירים אותו דרך ה-API של מודול החיפוש של Bitrix, עם אינדוקס דרך CSearchFullText או אינדקסרים מותאמים אישית.
Highload-blocks למילונים, לוגים ונתוני משתמש — במקום IBlocks מנופחים. שאילתות ישירות דרך Bitrix\Highloadblock\HighloadBlockTable, טבלאות מותאמות אישית במקום מבנה EAV של בלוקי מידע סטנדרטיים. מיליון רשומות — ללא ירידה בביצועים.
אירועי דואר. התצורה אינה רק תבניות ב-b_event_message. המפתח הוא SPF, DKIM, DMARC ב-DNS, אחרת הודעות טרנזקציוניות מגיעות לספאם. אנחנו בודקים יכולת מסירה ומגדירים טיפול בהחזרות (bounce).
איך לתכנן בלוקי מידע לביצועים?
אנחנו משתמשים ב-Highload-blocks לנתוני ייחוס (צבעים, מידות, יצרנים) שאינם מעורבים בשאילתות מורכבות. עבור SKU — בלוק מידע נפרד עם קישור דרך IBLOCK_ELEMENT_PROPERTY. הפעלת INDEX_PROPERTY עבור מאפיינים המסוננים לעתים קרובות. מטמון מתויג (Tagged caching): כשפריט משתנה, רק המטמון הקשור נמחק. Highload-blocks מעבדים עד פי 10 מהר יותר מבלוקי מידע עם מאפיינים מרובי ערכים בהיקפים של 100,000 רשומות.
פיתוח מודולים מותאמים אישית
כל מודול עוקב אחר המבנה /local/modules/vendor.modulename/:
-
install/index.php— מחלקת התקנה, יצירת טבלאות דרך$DB->RunSQLBatch() -
lib/— מחלקות D7 ORM, המרחיבות אתBitrix\Main\ORM\Data\DataManager -
admin/— דפי ניהול באמצעותCAdminList,CAdminForm -
include.php— טעינה אוטומטית, רישום handlers לאירועים דרךEventManager::getInstance()->registerEventHandler() - נקודות קצה של REST API דרך
\Bitrix\Rest\RestManager
המודול נרשם במערכת, מופיע ברשימת "הפתרונות המותקנים", ויש לו הגדרות משלו ב-/bitrix/admin/settings.php?mid=vendor.modulename. ניתן להפעיל, להשבית ולעדכן אותו דרך UpdateSystem או מנגנוני migration מותאמים אישית.
דוגמאות למשימות שבוצעו:
- ניהול קמפיינים — בונה תנאים ויזואלי דרך
CAdminCalendar, טיימרים דרך agents (CAgent::AddAgent), אנליטיקה מקושרת למודול המכירות - מחשבון עלויות — ווידג'ט React בפרונטאנד, REST API במודול, נוסחאות מאוחסנות ב-Highload-block
- מערכת הזמנות — יומן בזמן אמת, נעילה דרך
$DB->StartTransaction()/$DB->Commit()על בקשות במקביל, אינטגרציה עם channel manager דרך webhook
רכיבים ומטמון Composite
התאמת רכיבים דרך result_modifier.php ו-component_epilog.php, לא על ידי עריכת template.php של התבנית הסטנדרטית. כך עדכוני ליבה עוברים ללא כאבים.
מטמון Composite (טכנולוגיית "Composite Site") — השרת שולח HTML מוכן, תוך עקיפת ניתוב PHP. אזורים דינמיים (עגלה, הרשאה) נטענים דרך CBitrixComponent::setFrameMode(true) ו-AJAX. TTFB יורד ל-30–50 אלפיות השנייה. אבל יש הסתייגויות: לא כל הרכיבים תואמים, $APPLICATION->ShowPanel() שובר composite, ונדרשת סימון קפדני של <div id="bx-composite-...">.
מה לבדוק לפני התקנת מודול מהמרקטפלייס?
לפני התקנת מודול מהמרקטפלייס, ביקורת היא חובה. אנחנו בודקים: שאילתות SQL ללא prepared statements (שלום, SQL injection), שימוש ישיר ב-$_REQUEST ללא סינון, שימוש ב-API מיושן של הליבה במקום D7, והתנגשויות עם מודול המטמון Composite. מודול ללא עדכונים מעל שנה ועם כמה עשרות התקנות הוא כנראה בעיה בעדכון PHP הבא. מקרה אופייני: מודול קורא ל-CIBlockElement::GetList ללא איפוס מטמון — האתר קורס עם 5000 פריטים.
מעבר ל-D7
בעת שדרוג PHP או מעבר למהדורה חדשה — רפקטור לקריאות מיושנות:
-
CIBlockElement::GetList()→Bitrix\Iblock\Elements\ElementTable::getList() -
CSaleOrder::GetList()→Bitrix\Sale\Order::getList() -
CModule::IncludeModule()→Bitrix\Main\Loader::includeModule()בדיקות ב-staging, rollback דרך git במקרה של בעיות.
לפי התיעוד הרשמי של 1C-Bitrix, D7 ORM הוא הכלי המומלץ לעבודה עם נתונים, המספק בטיחות טיפוסים ויצירת שאילתות אוטומטית.
השוואה: Init.php מול מודול
| קריטריון | Init.php | מודול עם D7 ORM |
|---|---|---|
| ביצועים | רץ בכל קריאה | רץ רק באירוע |
| יכולת בדיקה | אין טעינה אוטומטית, בדיקות בלתי אפשריות | תמיכה מלאה ב-PHPUnit |
| תחזוקה | הקוד גדל ללא שליטה | מבנה מבודד, versioning |
| Migrations | אין | טבלאות מותאמות אישית, ניהול דרך התקנה |
| מטמון | לא תומך באינוולידציה אוטומטית | מטמון מתויג, ניקוי מבוסס אירועים |
היקף פיתוח מודולים ועלות
מה כלול בפיתוח מודול?
- מפרט טכני ותוכנית ארכיטקטונית
- קוד לפי PSR-4 וסגנון הקוד של Bitrix
- בדיקות יחידה (PHPUnit) ללוגיקה עסקית
- בדיקות אינטגרציה לאירועים ו-REST API
- תיעוד התקנה, תצורה ו-API
- גישה לריפוזיטורי ולתיעוד
- הדרכת מנהלים לשימוש במודול
- אחריות תמיכה ל-6 חודשים
לוחות זמנים ומורכבות משוערים:
| מורכבות | דוגמאות | לוח זמנים |
|---|---|---|
| פשוט | ווידג'ט callback, מערכת באנרים, מחשבון פשוט | 3–5 ימים |
| בינוני | מערכת הזמנות, קונפיגורטור מוצרים, מודול ביקורות עם ניהול | 1–2 שבועות |
| מורכב | רב-אזוריות, תוכנית נאמנות מותאמת אישית, אינטגרציית ERP | 2–4 שבועות |
| ארגוני | פלטפורמת מרקטפלייס, תהליכים עסקיים מורכבים עם תפקידים מרובים | 1–3 חודשים |
העלות מחושבת באופן אישי — צרו קשר להערכת פרויקט.
בדיקות מודול
בדיקות יחידה דרך PHPUnit מכסות לוגיקה עסקית: חישוב הנחות, ולידציה, יצירת מסמכים. Mocks עבור Bitrix\Main\Application::getConnection() מאפשרים בדיקות בלתי תלויות ב-DB. בדיקות אינטגרציה בודקות handlers לאירועים על בסיס נתונים אמיתי — OnAfterIBlockElementAdd, OnSaleOrderSaved וכו'. נקודות קצה של REST API נבדקות דרך curl או לקוח HTTP של PHPUnit. קריטי עבור מודולים שעובדים עם b_sale_order, b_catalog_price — מקום שבו שגיאות עולות כסף.
תאימות נבדקת על PHP 7.4, 8.0, 8.1, 8.2 ומהדורות: Standard, Small Business, Business. אנחנו בודקים התנגשויות עם מודולים פופולריים מהמרקטפלייס — הם לעתים קרובות מיירטים את אותם אירועים. בדיקות עומס: מדידות על 10K, 100K, 1M רשומות, פרופיילינג דרך Xdebug לדליפות זיכרון ושאילתות N+1.
דוגמאות מעשיות
מודול קמפיינים לרשת אלקטרוניקה. ההנחות המובנות של מודול המכירות לא כיסו תרחישים כמו "2+1", מתנה ברכישה מעל סכום מסוים, או תנאים משולבים. בנינו בונה ויזואלי: משווקים יוצרים חוקים באמצעות גרירה ושחרור ללא טיקטים לפיתוח. יומן קמפיינים, השבתה אוטומטית דרך agents, אנליטיקה מקושרת ל-b_sale_order — המרה, סל ממוצע, מספר שימושים. הזמן להשקת קמפיין חדש ירד מיומיים לחצי שעה.
מחשבון לקבלנים. פרמטרים (שטח, חומרים, מספר קומות) → נוסחה → הערכת עלות ראשונית → ליד ל-CRM דרך CRest::call('crm.lead.add'). מקדמים אזוריים ותוספות עונתיות מ-Highload-block, מחירי חומרים מהחלפת 1C. מספר הלידים הממוקדים גדל בשליש: לקוחות רואים פירוט לפני שהם מתקשרים למנהל.
הזמנות לרשת מלונות. זמינות בזמן אמת דרך בקשות AJAX לטבלה מותאמת אישית vendor_booking_slots, חישוב תעריפים עונתיים, סנכרון עם Booking.com דרך API של channel manager. נעילת חדרים בהזמנות במקביל דרך SELECT ... FOR UPDATE בטרנזקציות. אזורי זמן מטופלים דרך \DateTimeZone — אורח מוולדיווסטוק ומנהל ממוסקבה רואים את אותה תמונה.
נעריך את הפרויקט שלכם תוך יום אחד. כתבו לנו — נספר לכם מה כלול בפיתוח turnkey. צרו קשר לייעוץ על הפרויקט שלכם. הזמינו פיתוח מודול מותאם אישית — קבלו פתרון מוכן עם תיעוד ותמיכה.