הרחבת רכיבי Bitrix סטנדרטיים ללא העתקה

העתקת רכיבי Bitrix סטנדרטיים הופכת כל עדכון לסיכון וצוברת חוב טכני. אנו מרחיבים את לוגיקת הרכיבים באמצעות מנגנונים מקוריים—result_modifier, אירועים, מחלקות הרחבה ו-wrappers—ללא העתקה. הצוות שלנו מוסר את הפרויקט במפתח מלא, תוך הבטחת פעילות יציבה ותמיכה שוטפת לאחר היישום.
השירותים שאנו מציעים
מציג 1 מתוך 1כל 1626 השירותים
הרחבת רכיבי Bitrix סטנדרטיים ללא העתקה
בינוני
~1-2 שבועות

הכישורים שלנו:

שאלות נפוצות

לעתים קרובות אנו נתקלים בפרויקטים שבהם מפתחים מעתיקים רכיבי Bitrix סטנדרטיים. זה מוביל לבעיות במהלך עדכונים. דמיינו: חנות המסחר האלקטרוני שלכם פעילה כבר שנה. העתקתם את catalog.section, הוספתם שדות מותאמים אישית ודירוג. מגיע עדכון גדול — אתם מבזבזים יומיים על מיזוג שינויים. שישה חודשים לאחר מכן, עוד עדכון — ושוב כאב ראש. כל העתק של רכיב הופך לחוב טכני שמאט את הפיתוח ומגדיל את עלויות התחזוקה.

לפי הסטטיסטיקות שלנו, 80% מהפרויקטים עם העתקי רכיבים דורשים ריפקטורינג מלא בעת שדרוג לגרסה מרכזית חדשה. החלפת העתקים במנגנוני הרחבה מקוריים משתלמת תוך 4-6 חודשים: זמן העדכון מצטמצם פי 5 (טוב פי 5 מהעתקים), ובאגי תאימות נעלמים. החיסכון הממוצע לריפקטורינג של רכיב הוא $1,200 (בהתבסס על למעלה מ-40 פרויקטים). עבור חנות טיפוסית עם 15 העתקי רכיבים, החיסכון הכולל מגיע ל-$18,000 במשך שנתיים.

אנחנו צוות עם ניסיון של 8+ שנים בפיתוח Bitrix. השלמנו 40+ פרויקטים של ריפקטורינג ומודרניזציה, תוך ריפקטורינג של למעלה מ-200 העתקי רכיבים. אנו עוזרים לחברות לחסל העתקי רכיבים מבלי לאבד פונקציונליות. צרו קשר לייעוץ — נעריך את הפרויקט שלכם.

מנגנוני הרחבת רכיבי Bitrix: result_modifier, אירועים, הרחבות מחלקה

Bitrix מציעה ארבע דרכים להרחיב את הלוגיקה של רכיב סטנדרטי מבלי להעתיק אותו: result_modifier.php, אירועים, הרחבות מחלקה ורכיבי עטיפה. הרחבת רכיב Bitrix באמצעות הרחבת מחלקה היא השיטה היעילה ביותר.

result_modifier.php — השלמת נתונים מהירה

הקובץ result_modifier.php בתיקיית התבנית מבוצע לאחר הלוגיקה הראשית של הרכיב אך לפני פלט התבנית. אתם מקבלים הפניה ל-$arResult ויכולים להוסיף או לשנות נתונים. לדוגמה, טעינת דירוגי מוצרים משירות חיצוני:

<?php
// /local/templates/my_site/components/bitrix/catalog.section/.default/result_modifier.php
if (!defined('B_PROLOG_INCLUDED') || B_PROLOG_INCLUDED !== true) die();

$ids = array_column($arResult['ITEMS'], 'ID');
if ($ids) {
    $ratings = MyRatingService::getAverageForItems($ids);
    foreach ($arResult['ITEMS'] as &$item) {
        $item['MY_RATING'] = $ratings[$item['ID']] ?? 0;
    }
}

שיטה זו פשוטה אך אינה מאפשרת לשנות את שאילתת ה-SQL של הרכיב. לצורך התערבות בשאילתה, יש צורך באירועים.

אירועי רכיב — התערבות ברמת השאילתה

רוב הרכיבים הסטנדרטיים פולטים אירועים. לדוגמה, תיעוד Bitrix מתאר את <?php // /local/templates/my_site/components/bitrix/catalog.section/.default/result_modifier.php if (!defined('B_PROLOG_INCLUDED') || B_PROLOG_INCLUDED !== true) die(); $ids = array_column($arResult['ITEMS'], 'ID'); if ($ids) { $ratings = MyRatingService::getAverageForItems($ids); foreach ($arResult['ITEMS'] as &$item) { $item['MY_RATING'] = $ratings[$item['ID']] ?? 0; } } המאפשר לשנות את מסנן הבחירה. כך מסתירים מוצרים ללא מחיר:

// /local/php_interface/init.php
\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'iblock',
    'OnBeforeIBlockElementGetList',
    function (\Bitrix\Main\Event $event) {
        $filter = $event->getParameter('filter');
        $filter['!CATALOG_PRICE_1'] = false;
        $event->setParameter('filter', $filter);
        return $event;
    }
);

אירועים מספקים גמישות מבלי להעתיק את הרכיב. עם זאת, לוגיקה עסקית מורכבת עדיף למקם בהרחבת מחלקה.

הרחבת מחלקה — גמישות מרבית

צרו מחלקה צאצאית ב-OnBeforeIBlockElementGetList. Bitrix משתמשת בה אוטומטית במקום המקורית. התבניות נשארות מ-// /local/php_interface/init.php \Bitrix\Main\EventManager::getInstance()->addEventHandler( 'iblock', 'OnBeforeIBlockElementGetList', function (\Bitrix\Main\Event $event) { $filter = $event->getParameter('filter'); $filter['!CATALOG_PRICE_1'] = false; $event->setParameter('filter', $filter); return $event; } ); . דוגמה — הוספת דגל "חדש" למוצרים שנוצרו לפני פחות מ-30 יום:

<?php // /local/components/bitrix/catalog.section/class.php
\Bitrix\Main\Loader::includeModule('iblock');
\Bitrix\Main\Loader::includeModule('catalog');

class MyCatalogSectionComponent extends \Bitrix\Iblock\Component\ElementList
{
    protected function getFilter(): array
    {
        $filter = parent::getFilter();
        $filter['!PREVIEW_PICTURE'] = false; // скрыть товары без изображения
        return $filter;
    }

    protected function prepareElementData(array $element): array
    {
        $element = parent::prepareElementData($element);
        $element['IS_NEW'] = (time() - strtotime($element['DATE_CREATE'])) < 86400 * 30;
        return $element;
    }
}

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

רכיב עטיפה — החלפת לוגיקה מלאה

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

טבלת סיכום של המנגנונים

משימה מנגנון מומלץ
הוספת שדה מחושב לתוצאה result_modifier.php
שינוי מסנן SQL אירוע OnBefore*
הרחבת לוגיקה עסקית הרחבת מחלקה ב-/local/
החלפה מלאה תוך שמירה על תבניות הרחבת מחלקה + עקיפת מתודות
שימוש חוזר ברכיב עם פרמטרים שונים רכיב עטיפה

כיצד להשיג הרחבת רכיב Bitrix מבלי לאבד עדכונים?

התשובה פשוטה: השתמשו בהרחבת מחלקה או באירועים. הם שומרים על תאימות לליבה ואינם דורשים מיזוג ידני במהלך עדכונים. התוצאה היא הפחתה של 80% בזמן העדכון וחיסכון של עד 40% בעלויות התחזוקה.

מדוע הרחבת רכיב Bitrix עדיפה לעסק שלכם

באמצעות שימוש בהרחבת רכיב Bitrix מקורית, אתם נמנעים מעלות של $500 עד $1,500 למיזוג חוזר בכל מחזור עדכון. עבור פרויקט טיפוסי עם 5 עדכונים בשנה, מדובר בחיסכון שנתי של $2,500 עד $7,500. בנוסף, האתר שלכם נשאר תואם לתכונות חדשות ותיקוני אבטחה.

כיצד לבחור את המנגנון המתאים?

אם אתם צריכים להוסיף שדה במהירות — result_modifier.php. אם אתם צריכים לשנות את השאילתה — אירועים. ללוגיקה עסקית רצינית — הרחבת מחלקה. רכיב עטיפה — למקרים שבהם אתם צריכים לשנות לחלוטין את ההתנהגות.

כיצד אנו מיישמים הרחבת רכיבים ללא העתקה?

הגישה שלנו היא שימוש במנגנוני Bitrix מקוריים תוך שמירה על יכולת השדרוג. התהליך כולל חמישה שלבים:

  1. ביקורת קוד — איתור כל העתקי הרכיבים, הערכת היקף ומורכבות.
  2. תכנון — בחירת המנגנון האופטימלי לכל מקרה.
  3. יישום — כתיבת הרחבות מחלקה, מטפלי אירועים, משנים.
  4. בדיקות — בדיקת תאימות לתבניות ולשינויים מותאמים אישית.
  5. תמיכה — מתן תיעוד, הדרכת הצוות שלכם ואחריות ל-12 חודשים.

מה כלול בעבודה

  • חיסול מוחלט של העתקי רכיבים (ריפקטורינג).
  • אופטימיזציה של שאילתות וקאשינג.
  • בדיקות על כל התרחישים הקנוניים.
  • הדרכת הצוות שלכם לעבודה עם הרחבות.
  • אחריות לתאימות לאחור.
  • תיעוד מפורט של כל השינויים ומדריכי הגירה.
  • גישה לפורטל התמיכה שלנו למשך 12 חודשים.

דוגמה מעשית: עבור חנות מסחר אלקטרוני עם קטלוג של 50,000 מוצרים, החלפנו 12 העתקי רכיבים בהרחבות מחלקה. זמן עדכון הליבה ירד מ-3 ימים ל-4 שעות. חיסכון בתחזוקה — 40% בשנה.

לוחות זמנים ומחירים

סוג עבודה משך זמן משוער
הרחבת רכיב אחד (result_modifier) 2–4 שעות
הרחבה באמצעות ירושת מחלקה 1–3 ימים
ריפקטורינג של כל העתקי הרכיבים 3–8 ימים (תלוי בכמות)

העלות המדויקת מחושבת באופן אישי לאחר ביקורת. עלות פרויקט טיפוסית נעה בין $1,500 ל-$5,000 בהתאם למורכבות. מוכנים להיפטר מהעתקי רכיבים? הזמינו ביקורת — המהנדסים שלנו יעריכו את הפרויקט ויציעו את הפתרון האופטימלי.