תוסף MODX מותאם אישית: היכן נשברת הלוגיקה של האתר
תוסף MODX מותאם אישית כמעט תמיד מתחיל מאירוע אחד — ומתרחב במהירות לעשרה. תוסף על שמירת מסמך מחשב מחדש מחירים, תוסף סמוך על אותו אירוע מנקה מטמון, ושלישי שולח נתונים למערכת חיצונית.
כל עוד כל אחד נכתב בנפרד, הכול עובד; לאחר העריכה הראשונה של סדר החיבור האתר מתחיל לשמור עמודים בלי חישוב מחדש.
קונפליקט בין מטפלים (handlers) — הסיבה הנפוצה ביותר. התוצאה תלויה בעדיפות ובסדר הטעינה: שני תוספים על אותו אירוע מוחקים זה את הפלט של זה, וזה אינו נראה לא ביומן ולא בממשק. כמה שמירות כושלות — ובקטלוג נשארים פריטים במחיר אפס, שאיש לא ישים לב אליהם עד התלונה הראשונה של הלקוח.
שגיאות חילופי נתונים נראות אחרת: התשובה מהמערכת החיצונית מגיעה בחלקים, והתוסף כותב לבסיס הנתונים לפני בדיקת השלמות. הרצה חוזרת לפי לוח זמנים מכפילה רשומות, והפער מצטבר בשקט. סוג נפרד — שגיאות שקטות בניהול, כאשר החריגה נבלעת, ליומן נשלחה שורה אחת, והמפעיל רואה «נשמר» עליז.
ניפוי באגים של לוגיקה עצמאית מתחיל מתרחיש שניתן לשחזר ומסדר חיבור מפורש — ואז הקונפליקט בין המטפלים מפסיק להיות מקרי. בהמשך נפרט כיצד זה נסגר: ממפת האירועים ותקנון העריכות ועד לבדיקות לפני העלאה לפרודקשן.
מה משתנה לאחר ההטמעה: האפקט במספרים
התוסף נרשם לאירועי הליבה של MODX — שמירת משאב, פרסום, ביצוע הזמנה — ופועל ברגע הפעולה, ולא לפי תזכורת של המנהל. זה משנה בו-זמנית את שיעור הפעולות הידניות, את העומס על ממשק הניהול ואת התנהגות המערכת בעת תקלה.
האוטומציה נוטלת פעולות חוזרות: חישוב מלאי מחדש, מילוי שדות מקושרים, יצירת כתובות עמודים, ייצוא למערכות משיקות. העריכות הידניות בזרימה טיפוסית פוחתות ב-80–90%, ובמקום שבו נדרש בעבר גישה לעריכה, נותר רק פיקוח על התוצאה.
ממשק הניהול מתפנה לאו דווקא במספר הפעולות, אלא במשקל שלהן. שאילתות כבדות ופניות לשירותים חיצוניים עוברות לעיבוד נדחה: הממשק מגיב בזמן הקודם, ותור המשימות נפתר ברקע. אי-זמינות של מערכת משיקה אינה חוסמת עוד את השמירה — העריכה נקלטת, וההרצה החוזרת מופעלת אוטומטית.
אפקט נפרד — סוג תקלות שנעלם בעת שמירה וסנכרון. בעבר פער בין הקטלוג למערכת המשיקה התגלה רק מתלונת לקוח, וזמן התגובה לתקלה נמדד בשעות. כעת התוסף משווה את התוצאה מיד לאחר האירוע וכותב את הפער ליומן: זמן התגובה מצטמצם לדקות, וחלק מהתקלות נסגרות ללא מעורבות אדם.
את האפקט של ההטמעה אנו מודדים לפני ואחרי על זרימת נתונים אמיתית — לפי יומן האירועים, ולא לפי תחושות הצוות. המדדים ניתנים לבדיקה בסביבת הבדיקות, ולכן את התוצאה אין צורך לקבל כמובנת מאליה.
אפשרויות מימוש: תוסף, סניפט, עריכת הליבה
MODX מאפשר לבצע כמעט כל התאמה בכמה דרכים, והבחירה כאן אינה בשאלה «איך לכתוב מהר יותר». מודל האירועים מספק נקודות התערבות בתהליכים מערכתיים, סניפטים מטפלים בלוגיקת הפלט, והליבה פתוחה פורמלית לעריכות — אך כל ענף משאיר חותם שונה בתחזוקה.
אנו מתחילים בשאלה: האם קיים אירוע מתאים, או שהמשימה מצטמצמת לפלט בתבנית — מהתשובה תלוי אם ההתאמה תשרוד עדכון של הפלטפורמה וכמה תעלה התחזוקה שלה בעוד שנה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| תוסף על אירוע | יש צורך להתערב בתהליך מערכתי: שמירת משאב, שינוי סטטוס הזמנה, אימות | סדר הפעולה נקבע לפי עדיפות; שגיאה במטפל מפילה את כל הבקשה כולה |
| סניפט | פלט או חישוב במקום מסוים בתבנית, לוגיקה חד-פעמית ללא תגובה לפעולות | אינו מופעל על אירועים, והתוצאה נשמרת במטמון יחד עם העמוד |
| תוסף טיפוסי | פונקציונליות חוזרת: אזור אישי, חילופי ספריות עזר, ישויות עצמאיות | נדרשים ממשק ניהול ומבנה טבלאות עצמאי, ורף הכניסה גבוה יותר |
| עריכת הליבה | אמצעי קיצון, כאשר פשוט אין אירוע מתאים להוק | עדכונים מוחקים את השינויים, וחזרה לאחור אפשרית רק מגיבוי |
| שירות חיצוני | הלוגיקה חיה מחוץ למערכת: חישובים כבדים, חילופים עם מערך הנהלת החשבונות | דורש מערך אמינות נפרד — זמן המתנה, ניסיונות חוזרים, טיפול בקונפליקטים |
עריכת הליבה והשירות החיצוני — נקודות הקיצון. הראשונה זולה יותר בהתחלה, אך כל עדכון הופך למיזוג ידני; השנייה מוציאה את האמינות אל מחוץ לאפליקציה. תוסף על אירוע ותוסף טיפוסי מספקים לרוב איזון עובד: הקוד חי בנפרד מהליבה, מתעדכן כסדרו ומועבר בין פרויקטים.
שלבי הפיתוח: מתרשים האירועים ועד ההעלאה
תוסף ב-MODX הוא רישום לאירועי הליבה: הקוד פועל כאשר המערכת שומרת מסמך, בונה עמוד או משנה הגדרות. שלבי פיתוח התוסף כפופים לכלל אחד — תחילה להבין את נקודות ההתערבות, אחר כך לכתוב קוד.
לכן העבודה מתחילה בביקורת: יש להבין אילו מטפלים כבר תלויים על האירועים הנדרשים ובאיזה סדר הם פועלים, אחרת התוסף החדש ידרוס לוגיקה שעבדה שנים.
- ביקורת האתר — ספירת מלאי של נקודות ההתערבות: תוספים פעילים, סניפטים, הגדרות הקשר, תבניות. הפלט הוא מפה: מה נעשה בו שימוש חוזר, מה נדרוס מחדש, ומה אסור לגעת בו.
- תרשים האירועים והנתונים — רשימת אירועים, עדיפויות המטפלים, הטבלאות והשדות המושפעים, ההתנהגות בעת תקלה חלקית. מתואם לפני שורת הקוד הראשונה.
- אב טיפוס — תוסף מינימלי עם מטפל אחד על העתק בדיקה: בודקים שהאירוע מתרחש ברגע הנכון, שהנתונים מגיעים מלאים, ושממשק הניהול והחלק הציבורי אינם נסוגים.
- בדיקה על העתק האתר — פורסים העתק עם נפח נתונים דומה ומריצים תרחישים: פרסום, עריכה, מחיקה, הרשאות גישה, פעולות מרוכזות.
- בדיקת תקלות — אי-זמינות של שירות חיצוני, הפעלה חוזרת של אירוע, ייבוא המוני. התוסף לא אמור לחסום את שמירת המסמך.
- העלאה לאתר הפעיל — שלב אחר שלב: גיבוי, איפוס מטמון ותבניות מקומפלות, הפעלת התוסף, מעקב אחר יומן השגיאות ביממה הראשונה.
- מסירה — מאגר קוד, תיאור האירועים וההגדרות, הוראות לחזרה לגרסה הקודמת.
הרכב האספקה: קוד, תרשימים, תקנונים, תיעוד
התוסף חי יותר זמן מכל קבלן: בעוד שנה מישהו מהצוות שלכם יצטרך לפתוח את הקוד, להבין לאילו אירועים הוא נרשם, ולבצע עריכה בבטחה. לכן את הרכב האספקה אנו קובעים לפני תחילת העבודה — לא כפורמליות, אלא כדרך להסיר את התלות בנו.
- מסירת קוד — מאגר עם היסטוריה מלאה, ההרשאות רשומות על שם המזמין, והפריסה במערך נקי משוחזרת לפי ההוראות.
- תרשים האירועים והתלויות — אילו אירועי MODX התוסף מיירט, באיזה סדר פועלים המטפלים, ומה ישתנה בעת ניתוק כל אחד מהם.
- תיעוד לתוסף — ייעוד, הגדרות, נקודות הרחבה, מגבלות ידועות; נקרא בלי התכתבות איתנו.
- תקנון עדכונים — סדר העבודה בעת עדכון הליבה או תוספים סמוכים: מה בודקים, באיזו סביבה, וכיצד חוזרים לגרסה הקודמת.
- יומן שינויים — מה ולשם מה השתנה בכל מהדורה, ואילו עריכות השפיעו על ההתנהגות במערך הפעיל.
- הוראות לצוות — הפעלה וניתוק של התוסף, היכן לראות לוגים, ומה לעשות בתקלות טיפוסיות.
- מערך בדיקות — סט בדיקות ורשימת תיוג לקבלה, שלפיהם הצד המקבל מאשר בעצמו את התקינות לאחר העדכון.
המסירה היא דיון, לא ארכיון: עוברים על כל ארטיפקט יחד עם המהנדסים שלכם, עונים על שאלות ומתעדים את הסיכונים שנותרו. תארו את המשימה — נחזור עם הערכה ותוכנית.
מקרה בוחן: סנכרון הקטלוג עם מערכת חיצונית
מה היה לפני ההטמעה
הקטלוג של הלקוח — 12,400 פריטים, ומחירון הספק הגיע כקובץ פעמיים ביום. המנהל העביר אותו ביד: השוואה מלאה נמשכה 3-4 שעות, ופריטים שלא היו בייצוא החדש נותרו מההרצה הקודמת. המחירים באתר פיגרו עד 20 שעות, המלאי לא תאם — לפי מדידות פנימיות 6-7% מהמוצרים הוצגו כזמינים כשהמחסן ריק. מדי שבוע זה הניב ביטול אחד או שניים של הזמנות שכבר שולמו, ובירור עם הלקוח.
מה שינו ומה יצא
תוסף על MODX נרשם לאירועי שמירת פריטים ולבקשות הקטלוג: עריכות יוצאות למערכת החיצונית בתור, והתשובה מיושמת על משאבי הקטלוג ללא מעורבות אדם. החילוף מתבצע במנות של 500 רשומות, עם ניסיון חוזר בעת תקלה, יומן פעולות ודוח נפרד על פערים — במקום דילוג שקט על פריטים. ליבת הפלטפורמה אינה נגעת, ולכן העדכונים עוברים כסדרם ואינם שוברים את האינטגרציה.
המדדים לפני ואחרי נבדלו באופן ניכר: מעבר מלא על הקטלוג נמשך 40 שניות, החילוף מופעל כל 15 דקות ומעביר רק שינויים. שיעור הפעולות הידניות ירד מ-100% לאפס, פערי המלאי — מתחת ל-0.5%, המחיר באתר מתעדכן בתוך עשר דקות לאחר העריכה אצל הספק.
הביטולים מסיבת «אין במלאי» פסקו, ויומן החילוף עונה על השאלה מה ומתי השתנה: במצב שנוי במחלוקת רואים את מקור הנתונים ואת זמן הרשומה.
במה נבדל מטפל על אירוע מקריאה בתבנית?
מטפל אירוע הוא תוסף שנרשם לאירוע מערכתי ונקרא על ידי הליבה עצמה ברגע שהאירוע התרחש. קריאה בתבנית היא סניפט המוכנס למקום מסוים בתבנית או בצ'אנק: הלוגיקה מתבצעת במקום שבו הציב אותה מעצב התבניות, ורק בעמודים שבהם התבנית הזו מיושמת.
מכאן ההבדל העיקרי באמינות. המטפל חי ברמת מודל הנתונים: שמרתם משאב מפאנל הניהול, העליתם מנה דרך ייבוא, תיקנתם ערך בסקריפט — התגובה תפעל באותו אופן, כי נקודת ההתערבות היא אחת לכל המסלולים.
קריאה בתבנית מכסה רק את המסלול שבו היא רשומה: החליפו תבנית או מסרו את הנתונים בדרך אחרת — והלוגיקה לא תפעל בשקט, והפער יתגלה כבר על נתוני הייצור.
סדר הפעולה בתרשים האירועים נשלט על ידי עדיפות המטפלים. כמה תוספים על אירוע אחד מסתדרים לשרשרת, ואפשר להבטיח שהבדיקה והנרמול יעברו לפני הכתיבה, ולא אחריה. בתבנית הסדר נקבע על ידי הסימון: הוא נשען על סדר הפלט ונשבר בעריכה הראשונה של הקידוד.
גם במהירות המטפל מנצח. לוגיקה בתבנית מתבצעת בכל בנייה של עמוד, כלומר אצל כל מבקר, ומשפיעה ישירות על זמן התגובה. העבודה על אירוע מתבצעת פעם אחת — ברגע השינוי, ובהגשה נותרת רק קריאה של נתונים שכבר הוכנו. פעולות כבדות מועברות למשימות נדחות, כדי שהעורך לא ימתין לסיום השמירה.
לכן את נקודות ההתערבות בוחרים לפי השאלה «היכן הנתונים משתנים», ולא «היכן נוח להציג אותם». קריאה בתבנית נשארת למשימות תצוגה — להציג ערך מוכן, להרכיב בלוק מהמטמון.
ספקות טכניים: מה מבהירים לפני ההתחלה
לפני ההתחלה אנו מסנכרנים ציפיות עם הצוות הטכני של המזמין — בשלב זה מוסרים רוב סיכוני התחזוקה. להלן השאלות שאנו שואלים ואלה שנשאלות אצלנו לרוב.
האם התוסף יעמוד בעדכון ה-CMS?
את הרישום לאירועי הליבה אנו עורכים כחבילה נפרדת, את הליבה איננו נוגעים — העדכון אינו מוחק את הלוגיקה. לפני המהדורה אנו מריצים תרחישים על הענף העדכני ועל ה-LTS: שינויים בסדר הפעלת המטפלים לא יצופו כבר באתר החי.
מי אחראי לתחזוקת הקוד המותאם אישית?
את קוד המקור אנו מוסרים למאגר שלכם, ומתארים אירועים, מטפלים ונקודות הרחבה. מכאן את התחזוקה מנהלת הקבוצה שלכם לפי התיעוד, או שאנחנו — לפי תקנון הוצאת הגרסאות.
אילו הרשאות נדרשות בהתחלה?
מערך בדיקות, העתק של בסיס הנתונים, גישה לממשק הניהול, למבנה הקבצים וללוגים. הכול משוחזרים על העתק: אם תרחיש נשבר, האתר החי נותר ללא פגע.
כיצד נבדקת הלוגיקה של התוסף?
את המטפלים אנו מכסים בבדיקות לאירועים ולנתוני גבול: ערכים ריקים, כפילויות, אי-זמינות של שירותים חיצוניים. את הרגרסיה אנו מריצים לפי רשימת האירועים המושפעים, כדי שהלוגיקה החדשה לא תשבור תרחישים סמוכים.
תיקחו על עצמכם לשפר תוסף של אחר?
תחילה ביקורת: מתעדים תלויות בגרסת ה-CMS ובתוספי צד שלישי, ואחר כך מבצעים עריכות תוך שמירה על ההתנהגות הנוכחית. קטעים מסוכנים אנו כותבים מחדש בהדרגה, ולא בשינוי אחד.
נדון במשימה: מה להבהיר לפני ההערכה
כדי שהערכת המשימה תישען על עובדות ולא על הנחות, אנו זקוקים לנתוני פתיחה על המערכת ועל ההתנהגות הצפויה של התוסף. הם בדיוק אלה שקובעים את היקף העבודה ואת התוכנית — באותו תיאור «צריך תוסף» ההיקף עשוי להיות שונה פי כמה.
- נקודות הרחבה: לאילו אירועים נרשם התוסף, באיזה סדר הם פועלים ביחס ללוגיקה הקבועה, ומה קורה בעת ביטול פעולה.
- התנהגות צפויה: מה בדיוק התוסף משנה בפלט או בנתונים, אילו תרחישים נחשבים תקינים ואילו — לשגיאה.
- מצב הפרויקט: הענף העדכני של MODX, מערך הסניפטים, הצ'אנקים, התבניות והתוספים שכבר מותקנים — כדי לא להיכנס לקונפליקט עם הלוגיקה הקיימת.
- אינטגרציות: שירותים חיצוניים, כיווני חילוף, פורמטי נתונים ותדירות הקריאות.
- עומס: נפח התוכן, מספר הפעולות בו-זמנית, והיכן נדרשים מטמון ועיבוד נדחה.
- הרשאות: מערך בדיקות, מאגר קוד, הרשאות להעלאה ולקריאת תצורות.
- קריטריוני קבלה: אילו בדיקות חייבות לעבור במערך הבדיקות לפני ההעברה למערך הפעיל.
את הדיון במשימה אנו מתחילים בניתוח נתוני הפתיחה הללו יחד עם המהנדס שיוביל את הפיתוח: מבהירים נקודות שנויות במחלוקת, מסמנים סיכוני הגירה, ורק לאחר מכן חוזרים עם הערכה ותוכנית עבודה לפי שלבים.
