בלוק המוצרים החדשים של 1C-Bitrix: צוואר בקבוק בהצגת הקטלוג
בלוק המוצרים החדשים הוא חלון הראווה של קטלוג החנות המקוונת, שלפיו הקונה שופט אם המבחר עדכני. כל עוד הוא נבנה בבחירה סטנדרטית לפי תאריך היצירה והפעילות, הכול נשען על הנחה אחת: שהמיון לפי שדה זה זול.
בקטלוג עם עשרות אלפי פריטים ההנחה מפסיקה לעבוד — הבחירה מתבצעת על טבלאות של אלמנטים בלי אינדקס מורכב מתאים, וכל הצגה של הבלוק גוררת חיבורים מיותרים עם מאפיינים ומחירים.
הדבר פוגע בעיקר במהירות עדכון המבחר. בזמן שהמנהל עורך ומייצא מוצרים, המטמון של הבלוק והמדורים מתאפס כולו, והבקשה הבאה אוספת אותו מחדש מכל מסד הנתונים. ככל שהאספקות תכופות יותר, כך לעתים קרובות יותר הדפים מחזירים בלוק ריק או מיושן: פורמלית המוצר נוצר, בפועל הקונה אינו רואה אותו.
צוואר הבקבוק השני של הקטלוג הוא כפילויות בהצגת הקטלוג. המוצר נכנס גם לבלוק וגם לבחירה הראשית של המדור, ובקשירה לכמה קטגוריות הוא משוכפל ברשימה. תאריכים ממערכת החשבונות נדרסים בכל סנכרון, לכן «החדש» או יורד למטה או נעלם כליל. חלון הראווה מתפצל מהחשבונאות, המנהלים מפסיקים לסמוך עליו ומכריזים על מוצרים חדשים ידנית.
הסיבה אינה בתבנית או בעיצוב, אלא בשכבת הנתונים: לבלוק אין קריטריון חדשנות משלו, נפרד מתאריך יצירת הכרטיס. אנו מנתחים כיצד זה נסגר.
בלוק המוצרים החדשים: מה משתנה במהירות ההצגה ובעומס
בלוק חדשים טיפוסי ב-1C-Bitrix נבנה בשאילתה כבדה: בחירה לפי תאריך הפעילות, מיון, משיכת מאפיינים והצעות מסחריות, ואז בדיקת הרשאות.
כל עוד חלון הראווה נבנה מחדש בכל רינדור, כל ייצוא קטלוג מכפיל את העומס — כרטיס המוצר והעמוד הראשי מתחילים להתחרות על אותן טבלאות, וזמן התגובה עולה בדיוק ברגע הפרסום.
אנו מפרידים בין שני תהליכים: עדכון נתונים ורינדור. מוצרים חדשים נכנסים לייצוג נפרד, שמתעדכן לפי אירועי שינוי של המוצר, ולא בחישוב מלא לפי לוח זמנים. מטמון מנוהל מקבל תגיות של אינפובלוק ושל אלמנטים ספציפיים, לכן האיפוס מתבצע ממוקד — לפי פריט שהשתנה, ולא לפי כל המדור.
האפקט ניכר בשלושה מדדים. זמן עדכון חלון הראווה מצטמצם מדקות לשניות לאחר הפרסום: האורח רואה את החדש מיד, ולא אחרי חישוב לילי. מספר השאילתות לרינדור הרשימה יורד לאחת-שתיים במקום עשרות — מאפיינים ומלאי נלקחים מייצוג מוכן, ולא נאספים אחד-אחד.
השלישי — נעלם סוג של כשלים בייצוא חלקי, כאשר הבלוק מציג תערובת של פריטים ישנים וחדשים או נתקע על נתונים חסרים. תדירות עדכון החדשים הופכת לניתנת לניהול: היא נקבעת לפי סף תאריך, איפוס ידני של מטמון ההצגה או אירוע מהספק, ולא לפי לוח זמנים נוקשה.
אפשרויות הצגת מוצרים חדשים: השוואה
ב-1C-Bitrix «חדש» הוא לא שדה נפרד, אלא שיטת בחירה. אותו קטלוג יכול להיות מוצג לפי תאריך הוספה, לפי מאפיין-דגל, דרך מדור נפרד או כרשימה ידנית מפורשת — וכל אפשרות מתנהגת אחרת בזמן גידול הקטלוג, עדכון מלאי ואיפוס מטמון.
להלן אפשרויות הצגת חדשים, שביניהן באמת בוחרים. בנפרד אנו מביאים בחשבון את מגבלות התבנית: סימון קטלוג מוכן לא תמיד תומך במיון הנדרש, והצגת בלוק מחוץ לתבנית הראשית דורשת עריכת תבנית של רכיב מורכב.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| בחירה אוטומטית של מוצרים לפי תאריך הוספה | הקטלוג מתעדכן באופן קבוע, ואין מי שינהל את הרשימה | למעלה עולה הכול: פריטים שירותיים, כרטיסים שהועלו מחדש, מוצרים בלי מלאי |
| בחירה לפי מאפיין «חדש» | נדרשת בחירה ידנית של חדשים על ידי מנהל התוכן | דורש נוהל: שוכחים להסיר את הדגל, והבלוק מציג אותו דבר במשך חודשים |
| מדור נפרד או אינפובלוק לחדשים | נדרשת רשימה מנוהלת עם סדר מוגדר | שכפול מוצרים, אי-סנכרון מחירים ומלאי עם הקטלוג הראשי |
| רשימה ידנית של פריטים בהגדרות הרכיב | הצגה בעמוד הראשי, שליטה נוקשה בסדר | לא מתרחב: עריכות רק דרך מפתח, ובשינוי המבחר נשבר |
בפועל לרוב ניקח היברידי: בחירה אוטומטית של מוצרים לפי תאריך פעילות עם סינון לפי מלאי ומאפיין-דגל. האלגוריתם ממלא את הבלוק בעצמו, והמנהל מתערב רק כדי להסיר סימון מפריט מיושן.
שלבי העבודה: מביקורת הקטלוג ועד המסירה
בלוק החדשים אינו חלון ראווה סטטי, אלא בחירה מקטלוג 1C-Bitrix לפי תנאים: תאריך אספקה, סימון חדש, מלאי, פעילות המדור. אם מפרים את סדר העבודה, הבלוק נבנה «בעין» ומתפרק כבר בייצוא הראשון מהספק. לכן אנו הולכים לפי שרשרת קבועה.
- ביקורת הקטלוג. מנתחים אינפובלוקים והצעות מסחריות, מילוי מאפיינים, כפילויות וכרטיסים ריקים. בפלט — רשימת שדות שחסרים לבחירה, והחלטה: לתקן נתונים או לוגיקה.
- תכנון ההצגה. קובעים את תקופת החדשנות, עדיפות מדורים, מספר פריטים וכלל רוטציה, כדי שהבלוק לא ייתקע על מוצרים ישנים.
- הגדרת הבחירה. בונים סינון בהתחשב במחסנים, מחירים ופעילות אלמנטים, מגדירים מטמון ואיפוס שלו בעת עדכון הקטלוג. בנפרד בודקים תוצאה ריקה — מציין מקום במקום חור בעימוד.
- בדיקה תחת עומס. מריצים את הדף עם מטמון קר וחם, מודדים את זמן התגובה ומספר השאילתות למסד הנתונים. משווים את ההצגה לרשימה ידנית: אי-התאמה לפחות בפריט אחד — חזרה לתכנון.
- קבלת הפיתוח. מתאמים תרחישי בדיקה, מציגים עבודה על נתונים אמיתיים וקובעים סדר חזרה לבלוק הקודם.
- מסירת תיעוד. מוסרים סכימה של הבחירה, הוראות לעריכת תנאים ותזכיר למנהל התוכן: כיצד להוסיף מאפיין בלי לשבור את המיון.
מה אנו מוסרים לפרויקט: קבצים, סכימות, נהלים
אחרי מסירת הבלוק בפרויקט נשארים לא רק דפים עובדים, אלא גם סט ארטיפקטים, שלפיהם אפשר לפתח את הקטלוג בלעדינו. אנו מוסרים אותם למאגר ובצורה שמתאימה למפתח שיפתח את הפרויקט בפעם הראשונה.
- תצורה עובדת של בלוק החדשים — רכיב, תבניות הצגה, הגדרות בחירה ומטמון, קישור לאינפובלוק של הקטלוג.
- סכימת זרימת נתונים — מייצוא מ-1С ועד כרטיס באתר: אילו מאפיינים ממופים, היכן נחתכים פריטים בלי מלאי וכיצד נקבע תאריך האספקה.
- סכימת עדכון החדשים — לוח זמנים לסנכרון, סימן «חדש», כללים להסרת סימון לאחר תום התקופה והתנהגות הבלוק אם הסנכרון לא עבר.
- נוהל פרסום — סדר פעולות: מי מוסיף מוצר, אילו שדות חובה לפני הצגה בבלוק, כיצד מתבצעת הסרה מפרסום.
- הרשאות גישה למדורים — מטריצת תפקידים: מנהל תוכן, מנהל קטלוג, מנהל מערכת. רואים מה כל אחד יכול לשנות בלי סיכון לשבור את הבחירה.
- תיעוד הקטלוג — תיאור מאפייני האינפובלוק, קשרים להצעות מסחריות ונקודות הרחבה למשימות עתידיות.
- רשימת תיוג לקבלה ותמיכה — כיצד לבדוק את הבלוק אחרי עדכון הקטלוג, היכן לראות יומני סנכרון ומה לעשות בעת אי-סנכרון עם 1С.
כל מסמך אנו כותבים לפעולה קונקרטית, ולא «לצורך סימון וי»: לפי נוהל הפרסום עובד חדש מציג מוצר בלי לפנות למפתח, ולפי סכימת העדכון מהנדס תורן מבין באיזה שלב הסנכרון נתקע.
דוגמה מהפרקטיקה: עדכון חלון הראווה בלי השהיות
פרויקט — חנות מקוונת על 1C-Bitrix עם קטלוג של כמה אלפי פריטים ולוגיקת בחירה משלו לחדשים. את חלון הראווה «חדשים» המנהלים הרכיבו ידנית: פעם בשבוע עברו על האספקות, סימנו פריטים ידנית וקבעו סדר.
כל עוד הקטלוג היה קטן, זה עבד — בהיקפים גדולים הרשימה התיישנה מהר יותר משהספיקו לעדכן אותה, וחלק מהפריטים בכלל לא הגיעו לחלון הראווה.
מה היה לפני הפיתוח
ייצוא האספקות התבצע בחבילה אחת ולא היה מחולק למנות. בקטלוג עם מבצעים פעילים וחישוב מחדש של מחירים הוא לא הושלם: התהליך נעצר באמצע, חלק מהפריטים נשארו עם סימני חדש ישנים, והחנות הציגה מוצר שכבר אינו במלאי. טיפלו בכך ידנית — המנהל השווה את הדוח למה שבאמת באתר.
מה שינו
את בחירת החדשים העבירו לכללים: תאריך אספקה ראשון, סימון פעילות, קישור למדור, זמן חיים בחלון הראווה. את הייצוא פיצלו למנות עם שמירת נקודת בקרה — בעת קטיעה הוא ממשיך מהפריט האחרון שעובד, ולא מאפס. את הסדר הידני החליפו במיון לפי תאריך אספקה עם עדיפות לפריטים עם מלאי במחסן.
מה קרה בסוף
זמן בחירת החדשים הצטמצם מכמה שעות של עבודה ידנית לחישוב אוטומטי לפי לוח זמנים. כשלי ייצוא, שקודם קרו כמעט בכל הפעלה, נעלמו: לא תועדו הרצות לא מושלמות בתקופת הניטור.
חלקם של פריטים שנכנסים לחלון הראווה ביממה הראשונה לאחר האספקה עלה מכ-שני שלישים לכיסוי מלא — ובמקביל הבלוק הפסיק להחזיק מוצר שאזל.
מה לעשות אם הקטלוג כבר בנוי באמצעים סטנדרטיים?
ברוב המקרים קטלוג שנבנה באמצעים סטנדרטיים אינו מבוי סתום, אלא נקודת התחלה עובדת. ההצגה הסטנדרטית נשענת על רכיבים, תבנית ופרמטרי בחירה, לכן אין צורך לשבור אותה כולה: די להגדיר מחדש קטע מסוים — מיון, סט שדות, תנאי בחירה, מראה הכרטיס.
טכנית זה נעשה באמצעות תבנית רכיב משלנו בתבנית האתר או רכיב יורש. הליבה נשארת ללא שינוי, ולכן עדכונים מותקנים באופן סטנדרטי, בלי קונפליקטים והשוואת קבצים ידנית אחרי כל גרסה.
גם את הנתונים איננו נוגעים. מבנה המדורים, מאפיינים, קישור הצעות מסחריות, מחירים ומלאי נשארים כפי שהם — משתנה רק שכבת ההצגה. מקור האמת נשאר אחד, לא נוצרות כפילויות של הקטלוג ואי-סנכרון בין מדורים.
החלפת ההצגה בלי לכתוב מחדש את הקטלוג היא סקציה נפרדת בתבנית, שמחוברת במקום הסטנדרטית או לצידה. את ההצגה הישנה משאירים עובדת: אם הבלוק החדש יתנהג אחרת תחת עומס אמיתי, החזרה מתבצעת בהחלפת תבנית אחת.
אין צורך לעצור את האתר לצורך פיתוח כזה. העריכות מתבצעות על עותק, הפרסום — בהחלפת תבנית בזמן פעילות נמוכה, והחזרה — באותה פעולה בשלב אחד. פיתוח חלקי הוא כמעט תמיד מהיר ובטוח יותר מבנייה מחדש מלאה של הקטלוג, ונקודות ההרחבה שהוטמעו סוגרות עריכות הצגה עתידיות בלי התערבות חוזרת.
שאלות טכניות נפוצות על שדרוג ההצגה
מדור החדשים כמעט תמיד נבנה מישויות קיימות של הקטלוג — מאפיינים, מדורים, הצעות מסחריות. לכן לפני תחילת העבודה אנו קובעים היכן מחושבת הבחירה, מה נכנס למטמון וכיצד הנתונים מגיעים ממערכת החשבונות: מהחלטות אלה תלויים גם מהירות תגובת הדף וגם העומס על השרת בשיא התעבורה.
האם הבלוק לא ישבור מטמון ואינדוקס?
בחירת החדשים מוגדרת כרכיב נפרד עם מפתח מטמון משלו, שקשור לתאריך תחילת המכירה ולסימן הפעילות של המוצר. בעת שינוי שדות אלה המטמון מתאפס ממוקד, ולא כולו לפי הקטלוג.
למערכות חיפוש המדור מוצג בקישורים רגילים עם ניווט עמודים ומטא-תגים תקינים, בלי טעינה רק באמצעות סקריפט — אחרת דפי החדשים נופלים מהסריקה.
כיצד החדשים מגיעים ממערכת החשבונות?
איננו יוצרים מקור אמת שני: הסימנים «מוצר חדש» ו«תאריך הופעה» מגיעים לקטלוג יחד עם שאר השדות בסנכרון. אם מערכת החשבונות אינה מוסרת סימנים כאלה, נוסיף אותם לכללי הייצוא או נחשב אותם בצד האתר לפי תאריך האספקה הראשון. העדכון מתבצע במנות, כדי שהסנכרון לא ייקח לעצמו את כל המשאבים.
מה יקרה כשמספר המוצרים יגדל?
העימוד והשאילתות מתוכננים לגידול עם מרווח: מספר הפריטים בעמוד מוגבל, השאר עובר להצגה בעמודים נפרדים, והבחירה מתבצעת תוך התחשבות באינדקסים לפי תאריכים ופעילות. הוספת מוצרים אינה דורשת עימוד מחדש — רק מספר העמודים במדור גדל.
האם צריך לעצור את האתר בזמן העבודה?
לא. העריכות מתבצעות בעותק נפרד, נבדקות על נתוני בדיקה, ואז מועברות לסביבת העבודה. ההחלפה אורכת שניות ואינה מפסיקה ביצוע הזמנות; במידת הצורך אנו עובדים בחלון לילה.
נדון במשימה: מה נדרש להערכת ההצגה שלכם
הערכת שדרוג הקטלוג נשענת על עובדות, ולא על הנחות, לכן אנו מתחילים בנתוני פתיחה. אספו את המפורט להלן — לפי נתונים אלה נחשב את עומס העבודה ונחזור עם תוכנית עבודה לקטלוג.
- גישה לסביבת בדיקה או לעותק של אתר הפרודקשן עם קטלוג אמיתי — בהתקנת דמו בחירת החדשים אינה משוחזרת.
- מבנה המבחר: מספר מוצרים והצעות מסחריות, מאפיינים לבחירה, מחירים אזוריים ומחסנים.
- מקור הסימן «חדש»: תאריך הופעה בקטלוג, מאפיין כרטיס או ייצוא ממערכת החשבונות — נדרש מקור אמת אחד.
- דרישות לתדירות עדכון: פעם ביום לפי לוח זמנים, לפי אירוע בעת שינוי כרטיס או בעת סנכרון עם מערכת החשבונות.
- מקומות הצגה והיקף: עמוד ראשי, עמודי קטגוריות, גרסת מובייל, מספר פריטים והתנהגות הבלוק כשאין חדשים.
- קריטריוני קבלה: תרחישים ניתנים לבדיקה, מי מאשר את התוצאה ומה נחשב מוכנות.
- שדרוגים שכבר בוצעו: תבנית משלכם, עריכות ברכיבים, הרחבות — ההערכה תביא בחשבון קונפליקטים בעדכון.
- גישות ותפקידים: מנהל האתר, מאגר, ייצוא ממערכת החשבונות, מי מקבל את העבודה.
לפי נתונים אלה נחשב את היקף העריכות, סדר העלאה לפרודקשן וסט בדיקות בעת הקבלה — ונחזור עם הערכה ותוכנית עבודה.