לעתים קרובות נתקלנו בתרחיש הבא: לקוח משיק חנות שנייה (או שלישית) על אותה התקנת ביטריקס, אך משתמש בתבנית אחת. העיצוב נשבר, וההתאמה האישית הופכת לסיוט. הטעות היא שכל אתר מקבל עיצוב משלו, אך הירושה אינה מוגדרת. שימוש בתבניות נפרדות לכל אתר הוא המפתח למניעת קונפליקטים. בואו נפרק כיצד לארגן כראוי תבניות בסביבה מרובת אתרים מבלי לבזבז זמן על שכפול. לדוגמה, בפרויקט אחד, בגלל תבנית משותפת, עריכות לאתר הסיטונאי שברו את כרטיס המוצר הקמעונאי, מה שהוביל לזמן השבתה של 3 ימים ולאובדן של כ-15% מההזמנות. תבניות נפרדות בסביבה מרובת אתרים מפחיתות את זמן העריכות פי 4 בהשוואה לתבנית אחת. גישה זו יעילה ב-75% יותר מגישת תבנית אחת.
מדוע חשוב להפריד תבניות?
אם מספר אתרים חיים בעותק ביטריקס אחד אך משתמשים בתבנית אחת, במוקדם או במאוחר תיתקלו בקונפליקטים של סגנונות ועריכות לאתר אחד שוברות את השני. תבניות נפרדות מספקות גמישות: האתר הקמעונאי יכול לקבל כרטיס מוצר משלו, האתר הסיטונאי אחר, והגרסה הניידת שלישית. הלוגיקה המשותפת מבודדת אז בתבנית בסיס. למעלה מ-90% מהפרויקטים שלנו נהנים ממבנה זה, וזה חוסך עד 30 שעות בחודש על תחזוקה.
מבנה תבניות בסביבה מרובת אתרים
ביטריקס מאחסנת תבניות ב-/bitrix/templates/ (מערכת) ו-/local/templates/ (משתמש). עבור כל אתר, מגדירים את התבנית ברירת המחדל בלוח הניהול: הגדרות → אתרים → רשימת אתרים → {אתר} → תבנית אתר.
מבנה מומלץ למספר אתרים:
/local/templates/
base/ # Общий базовый шаблон (layout, хедер, футер)
site_retail/ # Шаблон розничного сайта
site_wholesale/ # Шаблон оптового сайта
site_mobile/ # Мобильная версия (если не адаптив)
ירושת תבניות. ביטריקס אינה תומכת בירושת תבניות באופן טבעי, אך ניתן לדמות זאת באמצעות כוללים או קישורים סימבוליים:
// /local/templates/site_retail/header.php
// Подключаем общий хедер и переопределяем только нужное
define('TEMPLATE_BASE_PATH', $_SERVER['DOCUMENT_ROOT'] . '/local/templates/base/');
include TEMPLATE_BASE_PATH . 'header.php';כיצד הגדרנו תבניות: מקרה אמיתי
לאחרונה הגדרנו סביבה מרובת אתרים ללקוח: חנות קמעונאית (תבנית /local/templates/ base/ # Общий базовый шаблон (layout, хедер, футер) site_retail/ # Шаблон розничного сайта site_wholesale/ # Шаблон оптового сайта site_mobile/ # Мобильная версия (если не адаптив) ) ופלטפורמה סיטונאית (// /local/templates/site_retail/header.php // Подключаем общий хедер и переопределяем только нужное define('TEMPLATE_BASE_PATH', $_SERVER['DOCUMENT_ROOT'] . '/local/templates/base/'); include TEMPLATE_BASE_PATH . 'header.php'; ) על אותה מסד נתונים. העברנו את הכותרת המשותפת, התחתית וסקריפטים של אנליטיקה ל-retail. עבור wholesale, התאמנו אישית את כרטיס המוצר על ידי החלפת תבנית base בתיקייה משלה. עבור retail, הסרנו מחירים והוספנו כפתור "בקשת הצעת מחיר". הכל עבד ללא העתקת קוד מיותר. לפי תיעוד 1C-Bitrix, התצורה מרובת האתרים תומכת בתבניות נפרדות דרך ההגדרות של כל אתר.
כיצד להקצות תבניות רכיב לאתרים שונים?
עבור כל רכיב, ניתן להגדיר תבנית שונה באתרים שונים. תבניות רכיב נבדקות בסדר זה:
-
catalog.element -
wholesale -
/local/templates/{site_template}/components/{namespace}/{component}/{template}/ -
/local/components/{namespace}/{component}/templates/{template}/
משמעות הדבר: כדי לתת לאתר הקמעונאי כרטיס מוצר משלו, פשוט צרו /bitrix/templates/{site_template}/components/....
ניואנסים מעשיים
משאבי CSS ו-JS. לכל תבנית יש /bitrix/components/{namespace}/{component}/templates/{template}/ ו-/local/templates/site_retail/components/bitrix/catalog.element/.default/template.php משלה בשורש. ביטריקס כוללת אותם אוטומטית. עבור בנייה עם Vite או Webpack, הגדירו style.css לכל תבנית.
בדיקת האתר הנוכחי בקוד:
// Получить ID текущего сайта
$siteId = \Bitrix\Main\Context::getCurrent()->getSite(); // 's1', 's2', etc.
// В компонентах и шаблонах — глобальная константа
define('SITE_ID', $siteId);
// Условный рендеринг в шаблоне
if (SITE_ID === 's2') {
// Логика для оптового сайта
}קבצי שפה: תרגומים ספציפיים לתבנית מאוחסנים ב-script.js. ביטריקס טוענת אותם אוטומטית בעת שימוש ב-publicPath.
השוואת גישות: תבניות משותפות לעומת נפרדות
| קריטריון | תבנית אחת לכולם | תבניות נפרדות (הגישה שלנו) |
|---|---|---|
| גמישות עיצובית | מוגבלת, קונפליקטים של סגנונות | מקסימלית, כל אתר ייחודי |
| מורכבות תחזוקה | גבוהה, עריכות שוברות אתרים אחרים | נמוכה, שינויים מבודדים |
| שכפול קוד | לא מפורש, אך תנאים רבים | מינימלי הודות לתבנית בסיס |
| מהירות פיתוח לאתרים חדשים | איטית, עריכות לקוד משותף | מהירה, הבסיס עובר בירושה |
דוגמה מפורטת למבנה
עבור פרויקט עם שלושה אתרים (קמעונאי, סיטונאי, נייד), המבנה האופטימלי:
/local/templates/
base/
header.php
footer.php
style.css
retail/
header.php (include base/header.php с доработками)
components/bitrix/catalog.element/.default/template.php
wholesale/
header.php (include base/header.php, убрана корзина)
components/bitrix/catalog.element/.default/template.php (без цен)
mobile/
header.php (адаптивный)
style.cssמה כלול בעבודה
- ניתוח ארכיטקטורת התבניות הנוכחית ומפת האתר
- עיצוב מבנה
// Получить ID текущего сайта $siteId = \Bitrix\Main\Context::getCurrent()->getSite(); // 's1', 's2', etc. // В компонентах и шаблонах — глобальная константа define('SITE_ID', $siteId); // Условный рендеринг в шаблоне if (SITE_ID === 's2') { // Логика для оптового сайта }עם תבניות בסיס ובנות - העברת עיצוב קיים למבנה החדש
- הגדרת ירושה והחלפות רכיבים
- בדיקת תאימות דפדפנים והתאמה לנייד
- תיעוד המבנה לתחזוקה עתידית
- מסירת גישה והדרכה לצוות הלקוח
כיצד אנו עובדים: תהליך
- ניתוח — הערכת מספר האתרים והאלמנטים המשותפים/ייחודיים שלהם.
- עיצוב — יצירת תוכנית מבנה התבניות.
- יישום — פריסת תבנית הבסיס ותבניות הבנות.
- בדיקות — אימות שכל אתר פועל כראוי.
- פריסה — העלאה לשרת הייצור.
לוחות זמנים משוערים
| תצורה | לוח זמנים |
|---|---|
| הגדרת 2 תבניות (מבנה בסיסי) | 1–2 ימים |
| העברת עיצוב קיים למבנה מרובה אתרים | 2–4 ימים |
| פיתוח תבניות מאפס עבור 2–3 אתרים | 5–10 ימים |
המחיר מתחיל ב-$550 עבור הגדרה בסיסית של שתי תבניות. אנו מטפלים בפרויקטים בכל רמת מורכבות — קבלו ייעוץ לפרויקט שלכם, ונספק לוחות זמנים והערכות מדויקות. הזמינו ביקורת על מבנה התבניות הנוכחי שלכם כדי לחשוף בעיות נסתרות.
הניסיון והערבויות שלנו
אנו מפתחים על 1C-Bitrix מזה למעלה מחמש שנים והשלמנו יותר מ-40 פרויקטים מרובי אתרים. אנו מבטיחים פעולה תקינה של התבניות ותאימותן לעדכוני המערכת. כתבו לנו, ונעריך את הפרויקט שלכם ונספק לוחות זמנים מדויקים.