טבלת ההגדרות הגלובלית של PrestaShop מאפשרת לשגרת הסרת ההתקנה (uninstall) של מודול למחוק בקלות הגדרות השייכות להרחבות אחרות שאינן קשורות אליה כלל. קריאה בודדת ל-Configuration::deleteByName('width') יכולה למחוק ערך רוחב מותאם אישית של חנות אחרת, מה שישאיר את בעל החנות מבולבל ואת המודול הבעייתי נראה תמים וחסר נזק.
למה טבלת ההגדרות המשותפת חשובה
PrestaShop שומרת את ההגדרות של כל מודול בטבלה אחת המכילה רק מפתח (key) וערך (value). בטבלה אין עמודה המתעדת איזה מודול יצר שורה מסוימת, והיא אינה אוכפת מוסכמת שמות (naming convention) כלשהי. כתוצאה מכך, שני מודולים במקרה שמשתמשים באותו מפתח — למשל "width" או "API_DATE_FROM" — יקראו ויכתבו לאותה שורה במסד הנתונים. הכתיבה האחרונה היא שקובעת, וכל מחיקה מאוחרת יותר תסיר את השורה עבור שני הצדדים.
מתי קוד הסרת התקנה הופך לכלי למחיקת נתונים
מתודת הסרת התקנה טיפוסית נראית כך:
public function uninstall()
{
return Configuration::deleteByName('width');
}
הכוונה היא לנקות את ההגדרות של המודול עצמו, אך מכיוון שהמפתח אינו מוגדר תחת מרחב שמות (namespace), הפקודה מסירה כל שורה בשם "width". לא נרשמת שום אזהרה ולא נזרקת שגיאה (exception); השורה פשוט נעלמת. מודול אחר של בעל החנות מאבד בשקט את ההגדרה שלו ועלול להתחיל להתנהג בצורה מוזרה.
הבעיה הופכת למפתה במיוחד במהלך שדרוג גרסה. מפתח שעובר מגרסה 1.0 ל-2.0 עשוי להתחיל לשמור ערכים תחת מפתח עם קידומת (prefix) כגון MY_MODULE_WIDTH. כדי "לנקות" את הרשומות הישנות ללא הקידומת, הם מוסיפים קריאה למחיקה בשגרת הסרת ההתקנה, מתוך אמונה שהם מסירים רק נתוני עבר (legacy data). במציאות, הם מוחקים גם כל הרחבה אחרת שאחסנה נתונים תחת אותו מפתח גנרי.
מה הביקורת חשפה
ביקורת של 57 מאגרי מודולים (repositories) ציבוריים חשפה דפוס חוזר:
- מודולים רבים משתמשים במפתחות גנריים כמו "width", "height" או "API_DATE_FROM" ללא קידומת הנגזרת משם המודול.
- מספר מתודות הסרת התקנה מכילות קריאות ל-
Configuration::deleteByNameהמכוונות למפתחות גנריים אלו. - הבעיה אינה מוגבלת למפתח בודד או לסוג מסוים של מודול; תכנון הטבלה המשותפת הופך אותה לסיכון מערכתי.
הביקורת לא מצאה לוגים או הודעות שגיאה שיזהירו את בעל החנות שהגדרות של מודול אחר נמחקו. הסימפטום היחיד הוא אובדן פתאומי של הגדרות, שבעל החנות עשוי לייחס לבעיית מטמון (cache) או לבאג בקוד שלו עצמו.
פרקטיקות בטוחות יותר למפתחי מודולים
- הגדרת מרחב שמות (Namespace) לכל מפתח – הוסיפו את השם הטכני של המודול לפני כל מפתח הגדרה (למשל,
my_module_width). זה יוצר מזהה ייחודי מבלי להסתמך על עמודת בעלות נפרדת. - הימנעו ממחיקת מפתחות ישנים ללא קידומת – השארת כמה שורות מיושנות בטבלה כמעט ואינה עולה דבר במקום אחסון ומבטלת את הסיכון לנזק נלווה.
- אמתו בעלות לפני מחיקה – אם מחיקה היא באמת נחוצה, בדקו תחילה שהערך של המפתח הוגדר על ידי הקוד שלכם (למשל, שמרו ערך סימון שרק המודול שלכם מכיר).
- בצעו ביקורת על מתודות הסרת התקנה – חפשו בבסיס הקוד קריאות ל-
deleteByName. יש לבחון כל מופע כדי לוודא שהמפתח מוגדר תחת מרחב שמות ייחודי. - תעדו את מוסכמת השמות – כללו הנחיה קצרה בקובץ ה-README של המודול, כדי שתורמים עתידיים יבינו את החשיבות של מפתחות עם קידומת.
בדיקה למניעת מחיקות מקריות בין מודולים
דרך מעשית לתפוס את הבאג לפני שהוא מגיע לחנות פעילה:
- הזנת טבלת ההגדרות (Seed) עם מפתח השייך למודול אחר (למשל,
other_module_setting=>test). - הרצת שגרת הסרת ההתקנה של המודול בסביבה מבוקרת.
- וידוא (Assert) שהמפתח שהוזן עדיין קיים לאחר סיום הסרת ההתקנה.
אוטומציה של בדיקה זו בערכת בדיקות היחידה (unit-test suite) של המודול מבטיחה שכל שינוי עתידי שיכניס קריאת deleteByName תועד, יגרום לכשל בבדיקה ויחייב בדיקה מחדש.
מה בעלי חנויות צריכים לשים לב אליו
בעלי חנויות כמעט ולא רואים את השורות הפנימיות במסד הנתונים, אך הם יכולים לזהות את הסימפטום: לאחר השבתה או הסרת התקנה של מודול, הרחבה אחרת חוזרת פתאום להגדרות ברירת המחדל שלה. אם זה קורה, בקשו מהמפתח לוודא שקוד הסרת ההתקנה של המודול מכבד את טבלת ההגדרות הגלובלית. בקשו רשימה של כל מפתחות ההגדרה שהמודול משתמש בהם; כל מפתח ללא קידומת ברורה הוא סימן אזהרה (red flag).
שורה תחתונה
העיצוב של PrestaShop הופך את טבלת ההגדרות למשאב משותף, ושגרת הסרה (uninstall) לא זהירה עלולה למחוק הגדרות של מודול אחר ללא עקבות. באמצעות שימוש ב-namespaces עבור מפתחות, הימנעות מניקוי אגרסיבי והוספת בדיקה פשוטה המגנה על רשומות זרות, מפתחים יכולים למנוע אובדן נתונים שקט ולשמור על יציבות החנויות של הסוחרים. המאמץ הנדרש הוא מינימלי, אך המחיר של הגדרה שאבדה — תלונות לקוחות, פניות לתמיכה ופגיעה במוניטין — יכול להיות גבוה בהרבה.