פיתוח פרמטרים מותאמים אישית לרכיבי 1C-Bitrix

פרמטרים מותאמים אישית של Битрикс: היכן נשבר התבנית הסטנדרטית

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

התגובה הראשונה של המפתח היא להוסיף תנאי ישירות בתבנית, השנייה — להיכנס ל-result_modifier.php או לרכיב עצמו. כך מתחילה התאמה אישית של תבנית הרכיב, שבתוך חצי שנה הופכת לסבך בלתי קריא.

בהמשך מופיעים כפילויות: עותק של התבנית עבור מדור, עוד אחד עבור דף נחיתה, שלישי עבור הגרסה הניידת — ותיקון במקום אחד כבר לא מגיע לאחרים. במקביל, מישהו מתקן את הליבה של Битрикс ישירות, כי "ככה יותר מהיר".

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

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

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

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

מה נותן הוצאת הלוגיקה לפרמטרים של הקומפוננטה

הוצאת הלוגיקה לפרמטרים של הקומפוננטה — זה ההפרדה בין "מה מציגים" ל"איך מציגים". התבנית מתארת את מבנה הפלט, וההגדרות — אילו מקטעים, שדות, מיון ומגבלות לוקח מופע מסוים. אותה קומפוננטה 1С-Битрикс משרתת את עמוד הבית, הקטלוג וכרטיס המוצר בלי לפצל את הקוד לכל עמוד.

עדכוני פלטפורמה בלי לאבד את השינויים

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

תבנית אחת במקום עותקים

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

מהירות התיקונים על ידי מנהל התוכן

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

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

דרכי התאמה אישית: השוואת גישות

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

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

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

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

אנו מתעדים את הגישה הנבחרת בתיעוד וב-.parameters.php, כדי שבעוד שנה מפתח חדש לא יתלבט מדוע הקוד עובד דווקא כך.

כיצד אנו מתכננים פרמטרים מותאמים אישית ב-Bitrix

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

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

1. ביקורת ההתאמה האישית הנוכחית: מיפוי מלאי של קריאות הרכיב, ערכים מוטבעים ושינויים בליבה.
2. סכמת פרמטרים: שמות, טיפוסים, ערכי ברירת מחדל, ותחומי אחריות של כל אחד.
3. מימוש: הוצאת הלוגיקה מהתבנית אל הפרמטרים, תאימות לאחור עם קריאות ישנות.
4. בדיקה בעת עדכון: הרצת עדכון המערכת והמודולים, תיעוד דריסות וקונפליקטים.
5. רגרסיה: השוואת הפלט לפני ואחרי בעמודים מרכזיים, בדיקת מטמון ו-SEO URLs.
6. מסירה: תיעוד לכל פרמטר עם דוגמאות קריאה.
7. הדרכה: מפגש קצר לעורכי תוכן ולמפתחים, ניתוח שגיאות נפוצות.

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

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

מה הלקוח מקבל לידיו

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

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

• קבצי פרמטרים של קומפוננטות — תיאורים ב-parameters.php (וקבצי .parameters.php משויכים עבור קומפוננטות מורכבות) עם טיפוסים, ערכי ברירת מחדל ורמזים. פרמטר בלי תיאור הוא פרמטר שעורך התוכן או שלא ייגע בו, או ישבור אותו.
• תבניות מעודכנות — template.php, .parameters.php של התבנית וקבצי הסגנון שבהם הפרמטרים החדשים באמת בשימוש. בנפרד מתעדים אילו פרמטרים משפיעים על הפלט ואילו רק על ההתנהגות.
• תרשים תלויות — מפה של "פרמטר → תבנית → קומפוננטה → עמוד": רואים מה ישתנה באתר אם משנים ערך מסוים. בלעדיה, שינוי של פרמטר אחד שובר באופן לא צפוי את הפלט במקום אחר.
• מדריך לעורך התוכן — מה אפשר לשנות באופן עצמאי, מה דורש מפתח, ואילו ערכים מותרים. כותבים בשפת העורך, לא בשפת הקוד.
• נוהל עדכונים — סדר התיקונים בפרמטרים, בדיקה בסביבת טסטים, ומה לעשות בעת עדכון הליבה והמודולים כדי שפרמטרים מותאמים אישית לא יימחקו.
• רשימת נקודות ההרחבה — היכן בדיוק התערבנו בלוגיקה הסטנדרטית, כדי שבפיתוח הבא לא נצטרך לחפש זאת בכל הפרויקט.
• היסטוריית שינויים — מה ולשם מה הוספנו בכל שלב: עוזר בניתוח תקלות ובהעברת הפרויקט לצוות אחר.

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

מקרה בוחן: קטלוג עם מסננים לא סטנדרטיים על Битрикс

הלקוח — ספק של ציוד תעשייתי — הגיע עם קטלוג על 1С-Битрикс, שבו המסנן לפי מאפיינים עבד רק על מדור אחד. שאר 40+ המדורים השתמשו בעותקים של תבנית קומפוננטה אחת: לוגיקת השליפה, רשימת המאפיינים וכללי המיון היו מקודדים ישירות בקוד.

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

מה היה לפני

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

מה שינו

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

מה נהיה

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

מספר התבניות הנתמכות הצטמצם פי 40, ושיעור המדורים שבהם המסנן עובד כשורה עלה מ-5% ל-100%.

במה שונה פרמטר של קומפוננטה מהגדרה של מודול?

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

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

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

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

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

ספקות טכניים לפני ההתחלה

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

האם זה תואם לתבנית ולסימון הנוכחיים?

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

כמה גדול היקף השינויים וכמה זמן זה לוקח?

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

מה עם התמיכה לאחר המסירה?

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

תארו את המשימה ואת התבנית הנוכחית — נחזור עם הערכת היקף השינויים ותוכנית העבודה.

בואו נדון במשימת ההתאמה האישית שלכם

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

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

מה עוזר לנו להגיע להערכה מהר יותר:

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

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

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

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

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