סימני מים בביטריקס: מדוע ההגנה על תמונות נשברת
הצבה אוטומטית של לוגו על הקטלוג נשברת בשקט: כרטיסים נפתחים, תמונות נמסרות, אבל ההגנה עליהן כבר לא קיימת. לרוב הסיבה היא מטמון. ביטריקס שומרת במטמון עותקים מוקטנים של תמונות, וכאשר משנים את תבנית ההצבה או את קובץ הלוגו עצמו, התצוגות המקדימות הישנות נשארות על הדיסק עם התוכן הקודם. המבקר מקבל תמונה מהמטמון, תוך עקיפת המעבד, וסימני המים של ביטריקס בתשובה הזו פשוט חסרים.
הכשל השני — עקיפת ההגנה על תמונות דרך כתובות ישירות. המעבד מותקן על הפלט דרך רכיב, אבל קבצי המקור נמצאים ב-/upload/ ונפתחים בקישור ישיר. מספיק להסיר את סיומת הגודל בכתובת — ותקבלו את המקור הנקי ללא לוגו. הגנת התמונות של הקטלוג, הבנויה רק ברמת תבנית הפלט, נעקפת בתיקון אחד של הכתובת.
השלישי — איכות. הצבה מעל תצוגה מקדימה שכבר דחוסה יוצרת הרכבה כפולה: הלוגו מטשטש, קצוות הקטלוג של המוצר "מצלצלים", ובגנרציה חוזרת של גדלים הארטיפקטים מצטברים. אם הכרטיסים additionally נשלחים לפלטפורמות חיצוניות, הדגרדציה נראית מיד.
הרביעי — עיבוד ידני. קטלוג עם כמה אלפי פריטים עם כמה זוויות למוצר לא ניתן להרכיב מחדש בידיים: כל החלפה של מבחר או ספק משמעה מעבר חדש על הקבצים, ופריט שנשכח נשאר ללא סימון ומתגלה רק בדיעבד.
אנחנו מפרקים כיצד זה נסגר: היכן להציב את העיבוד כך שלא ייעקף, כיצד לבטל את תוקף המטמון של התצוגות המקדימות בעת החלפת הלוגו וכיצד להרכיב מחדש את הסימונים על כל הקטלוג ללא אובדן איכות.
מצבי מיזוג ופורמטים: מה לבחור לפי המשימה
היכן להטביע את הסימן: בזמן העלאה או בזמן הגשה
עיבוד בזמן העלאה — הסימן מוטבע בקובץ פעם אחת, ומכאן והלאה מוגשת תמונה מוכנה. החיסרון — יש לשמור את המקור ללא הסימן בנפרד, אחרת יצירה מחדש אינה אפשרית.
הטמעה בזמן הגשה משאירה את קבצי המקור ללא שינוי, אך כל בקשה עוברת דרך המעבד: ללא מטמון תמונות הדבר מוסיף השהיה מורגשת בגלריות עם מאות תמונות.
בפועל — שילוב היברידי: הסימן מוטבע בזמן ההעלאה, והתוצאה נשמרת בספרייה נפרדת עם סיומת גודל. יצירה מחדש בעת החלפת לוגו מתבצעת באופן מרוכז על קבצי המקור, ללא העלאה חוזרת של קבצים על ידי העורכים.
מצב מיזוג ואטימות
מצב המיזוג של סימן המים קובע כיצד הלוגו מונח על הרקע. Multiply ו-Darken קריאים על רקע בהיר, אך נעלמים באזורים כהים; Screen ו-Lighten פועלים להפך. Normal עם שקיפות למחצה — האפשרות הצפויה ביותר: שקיפות הלוגו בטווח 40–60% שומרת על קריאות הסימן ואינה הורגת את פרטי התמונה שמתחתיו.
עבור PNG עם ערוץ אלפא השקיפות מוגדרת בקובץ עצמו, עבור JPEG — בפרמטר המיזוג. אין לערבב: JPEG אינו שומר אלפא, והסימן יקבל מלבן לבן בשוליים.
פורמט אחסון הסימן
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| PNG עם אלפא | לוגו בעל צורה מורכבת, צל, קצוות מחודדים | משקל הקובץ גבוה מזה של JPEG |
| SVG | סימן וקטורי, נדרש גודל שונה ללא אובדן חדות | לא כל ספריות העיבוד קוראות SVG ישירות |
| JPEG | סימן צפוף ללא אזורים שקופים | אין ערוץ אלפא, מסגרת נראית לעין על רקע צבעוני |
| WebP עם אלפא | נדרש גם משקל קטן וגם שקיפות | דורש בדיקת תמיכה בצד ההגשה |
מטמון ויצירה מחדש
מטמון תמונות נבנה על מפתח: קובץ המקור בתוספת האש של פרמטרי הסימן — מיקום, שקיפות, מצב. החלפת לוגו משנה את ההאש, התצוגות המקדימות הישנות מתבטלות אוטומטית, ולא נשארות תלויות בספרייה.
הדבר פותר את הבעיה הקלאסית "עדכנו את הסימן, אבל באתר מופיע הישן": הבנייה מחדש מתבצעת לפי לוח זמנים, ללא מעבר ידני על גלריות.
1C-Bitrix מגיש תצוגות מקדימות מוכנות דרך מנגנון שינוי הגודל שלו — חשוב שהסימן יוטבע לפני הכתיבה למטמון, אחרת הוא או שלא יופיע, או יוטבע שוב בכל פנייה.
הטמעה בשלבים: מביקורת הקטלוג ועד למסירה
הטמעת הצבת סימנים אוטומטית מתחילה בביקורת תמונות הקטלוג: סופרים את הנפח הכולל, את שיעור המוצרים ללא תמונה ראשית, את פיזור הגדלים והפורמטים, ואת קיומם של כפילויות וקבצים שכבר סומנו ידנית.
בשלב זה ניכר היכן הסכמה תיכשל — למשל בתמונות עם שקיפות או בכרטיסים צרים, שבהם הסימן יסתיר את המוצר עצמו. ללא ספירת מלאי, כל הגדרת עיבוד נתקלת בסינון ידני ובהעלאה חוזרת.
לאחר מכן מתכננים את סכמת הנחת הסימן: מיקום, מרווח מהקצה, שינוי קנה מידה ביחס לרוחב התמונה, שקיפות והתנהגות על רקע בהיר וכהה. את הסכמה מקבעים לפני הקוד — אחרת תיקונים "בעין" לאחר ההרצה שוברים כרטיסים שכבר עובדו.
- ביקורת תמונות הקטלוג — ייצוא רשימת קבצים, מדידת גדלים ופורמטים, איתור כפילויות וקבצים שכבר סומנו ידנית.
- תיאום סכמת ההנחה — מיקום, מרווח, קנה מידה, שקיפות, כללים נפרדים לרקעים בהירים וכהים.
- הגדרת העיבוד — קישור לאירועי העלאה ועדכון מוצר, כך שהסימן יוצב אוטומטית ולא בהרצה גורפת.
- הרצת ניסיון על מדגם — 50–100 כרטיסים אמיתיים מקטגוריות שונות, כולל בעייתיים: שקיפות, פנורמות, תמונות קטנות.
- בדיקת התוצאה — השוואת הפלט למופת, בקרה שהסימן אינו מסתיר את המוצר ואינו משוכפל בהעלאה חוזרת.
- עיבוד גורפי של היתרה — הרצה על כל הקטלוג עם לוג של קבצים שעובדו ושל קבצים שדולגו.
- מסירה עם תיעוד — תיאור הסכמה, נקודות הקישור וסדר הנסיגה, כדי שתיקונים יבוצעו בלעדינו.
בדיקה על כרטיסים אמיתיים היא שלב חובה: דווקא בה עולות קטגוריות שבהן הסכמה הסטנדרטית אינה עובדת, ועבורן נקבעים כללים נפרדים. לאחר המסירה הלקוח מקבל מנגנון עובד ותיעוד שלפיו ניתן לפתח אותו. תארו את המשימה — נחזור עם הערכה ותוכנית.
במה שונה הטלת סימן בעת העלאה מעיבוד אצווה?
הטלת סימן בעת העלאה פועלת ברגע שהקובץ נכנס לספריית המדיה או משויך לרכיב באינפובלוק. המטפל מקבל את המקור, מטיל את הסימן במיקום ובשקיפות שהוגדרו, ולאחר מכן התמונה המסומנת נשמרת באחסון.
משם נחתכות התצוגות המקדימות — כלומר, כל הגדלים הנגזרים כבר מכילים את הסימן, ואין צורך לגעת בהם בנפרד. מסלול זה סוגר את הנושא עבור תוכן חדש: העורך העלה תמונה — היא כבר מוגנת, בלי פעולות ידניות ובלי סיכון שמישהו ישכח לסמן תיבה.
עיבוד אצווה של תמונות עובד אחרת: הוא עובר על קבצים שכבר נמצאים במערכת ומטיל את הסימן מעל תמונות מוכנות. זוהי הדרך היחידה לסגור קטלוג קיים, שבו הצטברו אלפי תמונות ללא הגנה.
ההרצה מתבצעת במנות, כדי לא ל�consum את משאבי השרת ולא לחסום את האתר למבקרים; לאחר העיבוד חובה לבנות מחדש את התצוגות המקדימות — אחרת בכרטיסי המוצרים ובפידים יישארו עותקים ישנים ללא סימן, וההגנה תיראה כפועלת רק בממשק הניהול.
המגבלה המרכזית של מסלול האצווה — אי-הפיכות. הסימן נצרב בפיקסלים, ואת המקור ניתן להחזיר רק מגיבוי, אם זה נוצר לפני ההרצה. לכן הסדר הוא כזה: תחילה עותק של האחסון, אחר כך הרצה על סביבת בדיקה, ורק אחר כך הרצה בסביבת הייצור.
הטלת סימן בעת העלאה נטולת חסרון זה — גם שם המקור נדרס, אך היקף השינויים מוגבל לקובץ אחד, והחזרה לאחור אינה מחייבת שחזור של כל הקטלוג.
ההבדל השני — ההתנהגות בעת שינוי תבנית הסימן. אם שינו את הלוגו, המיקום או השקיפות, בעת העלאה זה יחול רק על קבצים חדשים, והישנים יישארו עם הסימן הישן. הרצת אצווה במצב כזה היא הכלי הסטנדרטי: היא מכסה את כל המערך בתבנית אחידה.
בפועל שני המסלולים אינם מתחרים זה בזה, אלא משלימים זה את זה: אצווה מיישרת את מה שהצטבר, וההעלאה שומרת על הרף לכל מה שמגיע לאחר מכן.
הנקודה השלישית — ביצועים. הרצת אצווה על קטלוג גדול אורכת שעות ודורשת חלון תחזוקה, בעוד שהטלת סימן בעת העלאה מוסיפה לשאילתה שברירי שנייה ובלי מורגש לעורך. מכאן סכמת העבודה: מעבר אצווה חד-פעמי על הארכיון, ולאחריו עיבוד קבוע בכניסה.
מקרה בוחן: כיצד הקטלוג הפסיק לאבד תמונות בעת העתקה
הלקוח — רשת חנויות עם קטלוג של כמה אלפי פריטים — הגיע עם כאב קונקרטי: מתחרים לקחו באופן קבוע כרטיסי מוצר יחד עם התמונות. לחלק מהמוצרים לא היו צילומים משלהם, והמקורות היו נגישים באופן פתוח בשרת — די היה לפתוח את כתובת התמונה ולשמור את הקובץ.
ברבעון תועדו 40+ התאמות של תמונות באתרים חיצוניים, ובמקביל לא ניתן היה לעבד את הקטלוג באופן ידני: המנהלים הספיקו להגן על לא יותר מ-15% מהפריטים החדשים.
מה שינו
העברנו את הטלת סימני המים לצינור ההעלאה: ברגע שמוצר נשמר בקטלוג המידע, התמונה עוברת עיבוד אוטומטי — הלוגו מוטל במיקום מוגדר עם שקיפות ניתנת להגדרה, והקובץ המקורי עובר לאחסון סגור. באופן פומבי מוצגת רק הגרסה המוגנת, ולכן הורדה בקישור ישיר כבר אינה מספקת תמונה נקייה.
את העיבוד הוצאנו למשימות רקע עם תור: אצווה של 500 תמונות עוברת ב-6-8 דקות, מבלי לחסום את עבודת המנהלים. עבור כל כרטיס נשמר הקשר "מקור — עותק מוגן", כך שבעת החלפת לוגו או מיקומו ההרכבה מחדש מתבצעת מהמקורות הקיימים, ללא העלאה חוזרת.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| שיעור הכרטיסים המוגנים | ~15%, באופן ידני | 100% באופן אוטומטי |
| זמן עיבוד אצווה של 500 תמונות | כמה ימי עבודה ידנית | 6-8 דקות בתור |
| אירועים עם מקורות פתוחים | 40+ ברבעון | הכיתה נסגרה: אין מקורות פומביים |
| הרכבה מחדש בעת החלפת לוגו | העלאה חוזרת של כל התמונות | מהמקורות השמורים |
בנפרד סגרנו את השלמות: אם העיבוד נכשל באמצע האצווה, המשימה מופעלת מחדש מהתמונה האחרונה שהצליחה, וכרטיס ללא עותק מוגן אינו מפורסם — המבקר לא יראה מוצר עם "חור" במקום תמונה.
את הצינור הרכבנו על כלי עיבוד התמונות הסטנדרטיים שמגיעים עם הפלטפורמה — ללא שירותים חיצוניים וללא העברת קבצים החוצה. הלוגיקה של ההטלה מתוארת באופן הצהרתי, ולכן הוספת סוג חדש של סימן (למשל, עבור מדור מבצעים) מחייבת עריכת קונפיגורציה, ולא כתיבה מחדש של קוד.
1C-Bitrix בתרחיש זה מספק נקודות הרחבה מוכנות על אירועי הקטלוג — זה הספיק כדי לשלב את העיבוד בתהליך ההעלאה הקיים, מבלי לגעת בממשק הניהול.
ספקות לפני ההתחלה: תאימות, חזרה לאחור, הרשאות גישה
לפני הפעלת ההגדרה האוטומטית של סימני מים ב-Bitrix, השאלה הנפוצה ביותר היא לגבי תאימות לתבנית הנוכחית: האם הפריסה תישבר, האם תצוגת הקטלוג תיפגע. עיבוד התמונות נתלה באירועי העלאה ו-resize, ולא בתבנית, ולכן הסימון והקומפוננטות נשארים ללא שינוי — רק תוכן הקובץ בדיסק משתנה.
אם בפרויקט קיימים מטפלי resize מותאמים אישית, אנו בודקים תחילה את סדרי העדיפויות שלהם, כדי למנוע החלה כפולה.
מה אם נידרש לחזור לאחור? כל השינויים מיושמים כמודול נפרד ומופעלים באמצעות הגדרה, ולא על ידי עריכת הליבה. השבתה מחזירה את התנהגות ההעלאה המקורית בצעד אחד, ללא צורך לפרק עריכות זרות בקוד. לפני העלייה לאוויר אנו מבצעים גיבוי של מסד הנתונים ואחסון הקבצים — חזרה לאחור אפשרית בכל נקודה.
אילו הרשאות גישה נדרשות? די בגישה לאזור הניהול ולשרת למשך העבודה: מערכת הקבצים, מתזמן המשימות, גישה לאחסון התמונות. אם לא ניתן לספק גישה ישירה, נעבוד בחלונות מוסכמים ונעביר פקודות למנהל המערכת שלכם.
מה יקרה לתמונות שכבר הועלו?
קבצים קיימים מעובדים במעבר נפרד על פני האחסון עם הגבלת עומס — ניתן להריץ במנות בשעות שאינן שעות עבודה. העלאות חדשות מיישמות את הכלל מיד, ולכן לא נוצר מצב מעורב בקטלוג.
הלקוח מקבל לידיו:
- תצורת המודול עם תיאור כל הפרמטרים;
- תרשים מעבר התמונה מההעלאה ועד ההצגה;
- מדיניות ההחלה: מיקום, שקיפות, התנהגות בתצוגה מקדימה;
- הוראות לחזרה לאחור ולהפעלה מחדש;
- נוהל גיבוי לפני שינויים;
- תיאור הרשאות הגישה הנדרשות לעבודה ולתמיכה.
תארו את המשימה ואת התבנית הנוכחית — נחזור עם הערכה ותוכנית עבודה, כולל סדר העלייה לאוויר ונקודות חזרה לאחור.