פיתוח מערכת הפצת תוכן על 1C-Bitrix

פיתוח מערכת הפצת תוכן על 1C-Bitrix

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

מערכת הפצת תוכן הופכת את הפצת החומרים בין מקור לצרכנים לאוטומטית. אנו מתכננים את הארכיטקטורה, משתלבים עם התשתית הקיימת שלך, ומגדירים שליטה גמישה: מה, איפה, מתי, ועם אילו טרנספורמציות. לדוגמה, עבור רשת של 15 אתרים אזוריים, קיצרנו את זמן פרסום החדשות מ-3 שעות ל-5 דקות, וחסכנו ללקוח מעל $5.4k–7.8k בשנה.

מאמר זה מכסה את המרכיבים המרכזיים של מערכת כזו: ארכיטקטורת אתר ראשי ואתרי משנה, כללי הפצה, טרנספורמציות, טיפול בקונפליקטים, וניטור. למהנדסים שלנו יש ניסיון של 10+ שנים בפרויקטים של Bitrix, המבטיח סובלנות לתקלות וסקלביליות.

ארכיטקטורה: אתר ראשי ואתרי משנה

התכנית האופיינית היא אתר ראשי אחד (מקור תוכן) וכמה אתרי משנה (צרכנים). ב-Bitrix, ניתן ליישם זאת בכמה דרכים בהתאם לתשתית:

• Bitrix רב-אתרי — אם כל האתרים על התקנה אחת. לפי תיעוד 1C-Bitrix, רב-אתרי תומך בעד 50 אתרים לכל התקנה. רכיבי אינפובלוק מקושרים לאתרים דרך b_iblock_site. רכיב אחד יכול להיות פעיל במספר אתרים בו-זמנית. ניהול דרך שדה ACTIVE וקישור לאתרים.
• תכנית מבוזרת — התקנות Bitrix נפרדות. דורש שכבת API: האתר הראשי מפרסם תוכן דרך REST API או תור הודעות; אתרי המשנה נרשמים ומקבלים עדכונים.
• היברידית — CDN לקבצי מדיה, API לתוכן מובנה, שכפול ישיר של מסד נתונים לעדכונים דחופים (השהיה של עד 2 שניות).

איך עובד המפיץ של אינפובלוק?

כדי לעקוב אחר מה הופץ ולאן, יש צורך בטבלה מותאמת אישית:

CREATE TABLE content_distribution ( ID INT AUTO_INCREMENT PRIMARY KEY, SOURCE_ELEMENT_ID INT NOT NULL, SOURCE_IBLOCK_ID INT NOT NULL, TARGET_SITE_ID VARCHAR(8) NOT NULL, TARGET_ELEMENT_ID INT, STATUS ENUM('pending','published','failed','excluded') DEFAULT 'pending', PUBLISHED_AT DATETIME, ERROR TEXT, INDEX (SOURCE_ELEMENT_ID), INDEX (TARGET_SITE_ID, STATUS) ); 

כאשר רכיב מתפרסם באתר הראשי, אירוע CREATE TABLE content_distribution ( ID INT AUTO_INCREMENT PRIMARY KEY, SOURCE_ELEMENT_ID INT NOT NULL, SOURCE_IBLOCK_ID INT NOT NULL, TARGET_SITE_ID VARCHAR(8) NOT NULL, TARGET_ELEMENT_ID INT, STATUS ENUM('pending','published','failed','excluded') DEFAULT 'pending', PUBLISHED_AT DATETIME, ERROR TEXT, INDEX (SOURCE_ELEMENT_ID), INDEX (TARGET_SITE_ID, STATUS) ); מפעיל את ההפצה. ה-handler בודק את הכללים וכותב משימות לטבלה.

אילו כללי הפצה להגדיר?

מערכת כללים גמישה מגדירה איזה תוכן הולך לאן:

$distributionRules = [ [ 'source_iblock_id' => 5, // Инфоблок «Новости» 'target_sites' => ['s2', 's3', 's4'], 'filter' => [ 'PROPERTY_CATEGORY' => [1, 2], ], 'transform' => 'NewsTransformer', 'delay' => 0, ], [ 'source_iblock_id' => 8, // «Акции» 'target_sites' => ['s2'], 'filter' => ['PROPERTY_REGION' => 'msk'], 'transform' => null, 'delay' => 3600, ], ]; 

טרנספורמציה של תוכן במהלך הפצה

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

// Адаптация ссылок $content = preg_replace( '|https://master-site\.ru/([^"\']+)|', 'https://regional-site.ru/$1', $sourceContent ); // Автоматический перевод через DeepL API $translated = $translationService->translate( $element['DETAIL_TEXT'], from: 'ru', to: $targetSite['LANGUAGE'] ); 

האתר הראשי מטפל בעד 50,000 רכיבים, עם השהיית הפצה שלא עולה על 5 דקות.

למה עיבוד אסינכרוני מהיר יותר?

עם אתרים רבים, הפצה סינכרונית ב-event handler היא רעיון רע: המשתמש יחכה מספר שניות לשמירה. עיבוד אסינכרוני דרך תור מהיר פי 3–5. ה-event handler יוצר משימה; worker של cron מבצע את ההפצה.

// Воркер обрабатывает 50 задач за один запуск $tasks = DistributionQueue::getPending(limit: 50); foreach ($tasks as $task) { $distributor->distribute($task); } 

איך לטפל בקונפליקטי עריכה?

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

• תמיד להחליף — פשוט אבל מאבד עריכות מקומיות.
• לא לגעת בעריכות ידניות — דגל OnAfterIBlockElementAdd/Update.
• מיזוג ברמת שדה — חלק מהשדות מסונכרנים, אחרים נשארים מקומיים.

יישום דרך מאפיין משתמש של רכיב האינפובלוק:

// При ручном сохранении на дочернем сайте CIBlockElement::SetPropertyValues($elementId, IBLOCK_ID, 'Y', 'LOCALLY_MODIFIED'); // При дистрибуции с мастера проверяем флаг $locallyModified = CIBlockElement::GetProperty(IBLOCK_ID, $elementId, [], ['CODE' => 'LOCALLY_MODIFIED'])->Fetch(); if ($locallyModified['VALUE'] === 'Y' && $rule['respect_local_edits']) { // Пропускаем обновление continue; } 

ניטור הפצה

איך להגדיר הפצה: שלב אחר שלב

1. הגדר את התכנית: בחר רב-אתרי, מבוזר, או היברידי.
2. צור את טבלת המשימות: הרץ את סקריפט ה-SQL למעלה.
3. כתוב event handlers: הירשם ל-$distributionRules = [ [ 'source_iblock_id' => 5, // Инфоблок «Новости» 'target_sites' => ['s2', 's3', 's4'], 'filter' => [ 'PROPERTY_CATEGORY' => [1, 2], ], 'transform' => 'NewsTransformer', 'delay' => 0, ], [ 'source_iblock_id' => 8, // «Акции» 'target_sites' => ['s2'], 'filter' => ['PROPERTY_REGION' => 'msk'], 'transform' => null, 'delay' => 3600, ], ]; .
4. הגדר כללים: קבע מסננים וטרנספורמרים לכל אינפובלוק.
5. עטוף ב-worker: הרץ עיבוד תור דרך cron.
6. הגדר ניטור: רשום סטטוסים ושגיאות.

מה כלול בפיתוח מערכת הפצה

• עיצוב תכנית וכללים
• הקמת ארכיטקטורה רב-אתרית או מבוזרת
• פיתוח שכבת API (REST / תור הודעות)
• יישום טרנספורמציות (קישורים, תרגום, נתונים אזוריים)
• שילוב ניטור ורישום
• הדרכת מנהלים ותיעוד
• תמיכה באחריות ל-3 חודשים

צור קשר כדי לדון בפרויקט שלך ולקבל ייעוץ.

שלבי פיתוח

סה"כ: 6–10 שבועות תלוי במספר האתרים ובמורכבות הטרנספורמציות.

קבל ייעוץ לפרויקט שלך — המהנדסים שלנו יעזרו לתכנן מערכת סוהר. בקש הערכה של המשימה שלך.