דפים מותאמים אישית ב-1C-Bitrix: בקרי D7 וניתוב

עמוד Bitrix מותאם אישית: היכן הלוגיקה הסטנדרטית נשברת

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

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

צוואר הבקבוק הראשון הוא הניתוב של Bitrix. הפלטפורמה מחפשת קובץ לפי נתיב הבקשה, ואם אין קובץ פיזי, היא מחזירה 404 או מציבה את המדור הקרוב ביותר.

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

עריכה של header.php ו-footer.php למען עמוד אחד שוברת את התצוגה בכל השאר, ו-result_modifier.php ו-component_epilog.php לא עוזרים כשצריך לשנות את מבנה התצוגה עצמו, ולא את הנתונים שבתוכו.

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

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

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

מה נותן הוצאת הלוגיקה אל בקרים ונתיבים

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

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

1C-Bitrix בענף העדכני מספק לכך מנגנונים מובנים — routes.php עם תיאור הנתיבים ובקרים היורשים ממחלקת הבסיס של הליבה. בעבר היה צריך להרכיב שכבה כזו ידנית מעל urlrewrite.php, והיא נותרה שברירית: הכללים התפצלו מהנתיבים האמיתיים, והמטפלים שכפלו את שליפת הנתונים.

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

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

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

אפשרויות מימוש לעמוד מותאם אישית: השוואת גישות

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

תבנית רכיב סטנדרטית

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

רכיב ובקר

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

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

כיצד בוחרים

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

כיצד אנו מתכננים ומיישמים ניתוב

ניתוב ב-Bitrix חי בשני מישורים: כללי urlrewrite.php לחלק הציבורי וראוטר D7 לבקרים. כל עוד מדובר בעשרה עמודים — זה לא מורגש, אך עם גדילת הקטלוג, המסננים וכתובות ה-SEO, הכללים מתחילים להתנגש, וחלק מהבקשות מגיעות ל-404 או להפניה מיותרת. לכן אנו מבצעים את העבודה לא כ"הוסף כלל", אלא כפרויקט עם שלבים מוגדרים.

1. ביקורת כללים קיימים. אנו ממפים את המסלולים הקיימים, משווים את urlrewrite.php לכתובות בפועל, מחפשים כפילויות, כללים מתים ושרשראות הפניות ארוכות מצעד אחד. מתעדים אילו כתובות מאונדקסות וחייבות להישמר.
2. תרשים מסלולים. מתכננים את המבנה הרצוי: אילו כתובות מוגשות על ידי בקר, אילו על ידי קומפוננטה, היכן נדרש SEO והיכן מספיק פרמטר. מאשרים את התרשים לפני הקוד — תיקונים בשלב זה זולים יותר מאשר כתיבה מחדש לאחר ההשקה.
3. הגדרת ראוטר ובקרים. רושמים מסלולים ב-D7, מתארים בקרים עם תלויות מפורשות, מוציאים לוגיקה מהתבניות. מביאים את כללי ה-SEO לצורה אחידה, כך שסדר הניתוח לא יהיה תלוי במיון מקרי.
4. טיפול בשגיאות ובהפניות. מגדירים התנהגות לכתובות לא קיימות: 404 במקום הגשת העמוד הראשי בשקט, 301 לשינוי מבנה, ניתוח נכון של פרמטרי עימוד ומסננים.
5. בדיקה. מריצים את המסלולים בבדיקות אוטומטיות ובידניות: קודי תגובה, הפניות, SEO, התנהגות תחת עומס. בודקים בנפרד שכתובות ישנות לא אבדו — אלו הפסדי תנועה ישירים.
6. מסירה. מוסרים את תרשים המסלולים, התצורה, רשימת הכללים והוראות להוספת עמודים חדשים, כדי שצוות הלקוח יוכל להרחיב את המבנה בלעדינו.

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

תוצרי פלט: תצורות ותקנונים

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

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

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

קייס: האצת השקת מדורים בנתיבים מותאמים אישית

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

מה עשינו

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

מדדים לפני ואחרי

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

במה שונה בקר D7 מרכיב סטנדרטי?

רכיב סטנדרטי הוא בלוק לוגיקה מוכן עם תבנית: מחברים אותו דרך $APPLICATION->IncludeComponent(), מעבירים פרמטרים, ומקבלים פלט. הוא חי בתוך העמוד, והניתוב נשאר באחריות מערכת הקבצים.

בקר D7 הוא חלק מהליבה: מחלקה עם מתודות-פעולות, המקושרת לנתיב דרך urlrewrite.php או קונפיגורציית ראוטר. הבקשה מגיעה לכתובת URL, הראוטר מזהה את הבקר והפעולה, לאחר מכן הקוד שלכם מבוצע והתגובה מרונדרת.

ההבדל מתבטא במי שולט בזרימה. אצל רכיב הלוגיקה קשורה לנקודת ההכללה בתבנית, וטיפול בבקשה, כותרות, קודי תגובה והפניות נותרים לשיקול דעתו של העמוד. אצל בקר D7 אתם שולטים בכל המחזור: ניתוח נתוני הקלט, בדיקת הרשאות, יצירת התגובה, מטמון, והחזרת JSON או HTML.

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

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

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

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

ספקות טכניים נפוצים בעת הרחבה

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

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

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

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

מה יקרה אם הקבלן שכתב את הקוד יעזוב?

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

האם ניתן לבטל עדכון שלא צלח?

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

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

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

נדון במשימה שלכם ונחזור עם תוכנית

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

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

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

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

בסעיף נפרד — סיכונים: התנגשויות עם עדכוני הפלטפורמה, תלויות במודולים של צד שלישי, אזורים עם עומס גבוה.

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