Optistream איחדה שנים-עשר תוספי WordPress מותאמים אישית לקוד בסיס (codebase) יחיד מבלי לאבד SEO עבור אחת-אלף הדפים הציבוריים שלה.
למה המיזוג היה חשוב
אתר WordPress טיפוסי מסתיים עם קומץ תוספים; אתר גדול יותר נראה כמו סדנה מלאה בכבלים, שכל אחד מהם מזמזם אך אף אחד מהם אינו קל לניתוק. האתר של Optistream הריץ שנים-עשר תוספים מותאמים אישית שניהלו פרופילי סטרימרים, קבוצות esports ונתוני משחקים. התוספים הללו יצרו אלף דפים הניתנים לאינדקס. שמירה על כתובות ה-URL הללו ללא שינוי הייתה תנאי בלתי ניתן למשא ומתן — כל שינוי היה עלול להכשיל את המעבר.
איך המבנה הישן נראה
שנים-עשר התוספים חיו כל אחד בתיקייה משלו, רשמו סוג פוסט מותאם אישית (custom post type) משלהם, והתחברו (hooked) ל-WordPress בנקודות שונות. הבעיות הצטברו:
- ה-Hooks והנכסים (assets) היו מפוזרים, מה שהקשה על חיזוי איזה קוד רץ ומתי.
- לוגיקת הניתוב (routing) התקיימה בקבצים נפרדים רבים, כך שכתובת URL בודדת הייתה עלולה להיות מושפעת ממספר תוספים.
- קבצי CSS נטענו בסדר בלתי צפוי, מה שהוביל להתנגשויות עיצוב.
- ניפוי שגיאות (debugging) דרש פתיחה של שנים-עשר ספריות שונות, דבר שגזל זמן רב מכל מפתח.
המטרה לא הייתה לצמצם את מספר הקבצים; המטרה הייתה להעניק למערכת כולה מחזור חיים יחיד ומקום אחד לניהול תלויות (dependencies).
איך תוכנן המעבר
הצוות התייחס לממשק הציבורי — כתובות URL, תבניות (templates) ומטא-דאטה — כאל חוזה שלא ניתן להפר. כל שינוי בצד הלקוח (front end) ייחשב ככישלון. מתוך הבנה זו, הם ניסחו רשימת תיוג (checklist) שתופעל לאחר כל שלב.
1. רישום החוזים הציבוריים
כל נתיב URL נרשם יחד עם סוג הפוסט שלו, ה-rewrite slug, קובץ התבנית ומפתחות המטא (meta keys) עליהם הוא נשען. גיליון הנתונים הזה הפך לספר החוקים: אם כתובת URL השתנתה לאחר מעבר של מודול, המעבר בוטל (rolled back).
2. בניית loader פשוט
נוצר קובץ bootstrap קטן. כל תוסף לשעבר רושם כעת "content domain" יחיד באמצעות שם פונקציה צפוי. ה-loader אינו עושה דבר מתוחכם — רק מספיק כדי למשוך את המודול הנכון לתוך WordPress כשצריך. הפשטות הופכת כישלונות לברורים.
3. הגנה על הנתונים
שינוי שמות של מפתחות מטא היה הופך שינוי קוד למיגרציית נתונים, מה שהיה מוסיף סיכון מיותר. המפתחות הישנים נותרו ללא שינוי; פונקציות עזר חדשות עוטפות אותם, ושומרות על יציבות סכימת מסד הנתונים.
4. תיקון בעלות על CSS
התנגשויות עיצוב נפתרו באמצעות שלושה צעדים:
- קבצי ה-CSS של המודולים נכנסים לתור (enqueued) בעדיפות גבוהה כדי שייטענו אחרונים.
- כל הסלקטורים מוגדרים (scoped) תחת מחלקת עטיפה (wrapper class) ייחודית לכל מודול.
- נעשה שימוש ב-
filemtime()בעת ה-enqueuing כדי לנקות את זיכרון המטמון של הדפדפן (bust cache) אם גיליון עיצוב משתנה.
5. שימוש בלולאה בטוחה
המעבר התבצע מודול אחד בכל פעם. לאחר העברת מודול, הצוות אימת את רישום סוג הפוסט, הניתוב ופריסת המובייל לפני שעבר למודול הבא. התוספים המקוריים נותרו מותקנים אך לא פעילים, מה שסיפק אפשרות חזרה מיידית (rollback).
רשימת תיוג לסביבת ייצור
לאחר כל החלפת מודול, הצוות אימת:
- כל כתובת URL של סוג תוכן מחזירה סטטוס HTTP של 200.
- כותרת ה-canonical URL תואמת לכתובת ה-URL המקורית.
- כותרות הדפים ותיאורי המטא לא השתנו.
- כל התמונות נטענות ללא קישורים שבורים.
- לא מופיע גלישה אופקית (horizontal overflow) במסכי מובייל.
- קונסול הדפדפן מציג אפס שגיאות JavaScript או CSS.
רק לאחר שרשימת התיוג עברה בהצלחה, הצוות השבית את התוסף הישן לצמיתות.
מה התוסף החדש מספק
התוסף היחיד שנוצר אינו מצמצם את קוד הבסיס; הוא פשוט הופך את הגבולות לנראים. כל שנים-עשר התחומים הפונקציונליים חולקים כעת מחזור חיים אחד, סט אחד של hooks ומקום אחד לניהול תלויות. התוסף החדש לא הפך את המערכת לקטנה יותר. הוא הפך את הגבולות לנראים. זה התברר כשימושי יותר מאשר להחזיק פחות תוספים.
סיכונים וטיעוני נגד
המקרה של Optistream מראה שגישה ממושמעת של "חוזה תחילה" (contract-first) ופריסה מדורגת יכולות להחזיק את הסיכונים תחת שליטה.
מה כדאי לשים לב בהמשך
אם אתם שוקלים איחוד דומה, התחילו בשני עמודים אלו:
- יציבות URL – מיפו כל נתיב ציבורי לפני שאתם כותבים שורת קוד אחת.
- יציבות נתונים – הימנעו משינוי שמות של שדות במסד הנתונים אלא אם אתם מוכנים למיגרציה מלאה.
משם, בנו loader קטן, שמרו על CSS scoped, והעבירו מודולים אחד אחד תוך הרצת רשימת תיוג קפדנית לסביבת ייצור.