העברת אתר וורדפרס מלחיצה מספיק כשהכל סטנדרטי. תוסיפו לזה כמה פלאגינים בבנייה מותאמת אישית ותבנית שנכתבה ידנית, ופתאום כל מדריך העברה שתמצאו באינטרנט מרגיש חסר. הם מכסים את מסד הנתונים, תיקיית ההעלאות, אולי את wp-config.php. הם כמעט אף פעם לא מתייחסים למה שקורה לאותו פלאגין מותאם אישית שהמפתח שלכם כתב לפני שלוש שנים ושאף אחד לא תיעד במלואו.
הנה החדשות הטובות: קוד מותאם אישית לא הופך את ההעברה לבלתי אפשרית. הוא רק משנה לאן צריך להפנות את תשומת הלב.
מה נשאר זהה בשירות העברת וורדפרס
בין אם האתר שלכם מריץ חמישה פלאגינים חינמיים מהמאגר או עשרה פלאגינים מותאמים אישית, המנגנון הבסיסי של שירות העברת וורדפרס לא משתנה. עדיין צריך להעביר שלושה דברים:
- מסד הנתונים (פוסטים, עמודים, הגדרות, חשבונות משתמשים)
- תיקיית wp-content (תבניות, פלאגינים, קבצים שהועלו)
- פרטי קונפיגורציה (wp-config.php, מבנה כתובות, כללי htaccess.)
תהליך העברה טוב מגבה את שלושת אלה, מעביר אותם לשרת החדש, מעדכן את כתובות ה-URL במסד הנתונים, ומוודא שהכל נטען כמו שצריך. שום דבר מהלוגיקה הזו לא משתנה רק בגלל שהפלאגינים שלכם מותאמים אישית. קובץ הוא עדיין קובץ. טבלה במסד נתונים היא עדיין טבלה במסד נתונים.
תאימות לסביבת השרת חשובה הרבה יותר
מה שכן משתנה זה כמה בקפידה צריך לבדוק תאימות לשרת. פלאגינים מוכנים מראש בדרך כלל נבנים לעבוד על מגוון רחב של גרסאות PHP והגדרות שרת, כי המפתחים רוצים שהם יעבדו אצל כמה שיותר לקוחות. פלאגינים מותאמים אישית לרוב לא נבדקו ככה. הם נבנו עבור שרת אחד, על ידי מפתח אחד, שחשב על הגדרות PHP מאוד ספציפיות.
לפני ההעברה, בדקו:
- גרסת PHP - קוד מותאם אישית שנכתב לפני חמש שנים אולי משתמש בפונקציות שהוצאו משימוש בגרסאות PHP חדשות יותר
- תוספי PHP - האם הפלאגין שלכם צריך GD, ImageMagick, cURL, או משהו פחות נפוץ כמו תוספי Redis או memcached?
- מגבלות זיכרון - פונקציונליות מותאמת אישית כבדה יותר לפעמים צריכה memory_limit גבוה יותר ממה שהתקנה ברירת מחדל מספקת
- תלויות Composer - אם הפלאגין שלכם נבנה עם חבילות Composer, גם הן צריכות לעבור, לא רק תיקיית הפלאגין עצמה
זה השלב שרוב רשימות הבדיקה להעברה מדלגות עליו, ובדיוק שם אתרים מותאמים אישית נשברים. כיסינו את הגרסה הרחבה יותר של התהליך הזה ברשימת הבדיקה שכל בעל אתר וורדפרס צריך להשלים לפני החלפת אחסון, אבל עם קוד מותאם אישית, התייחסו לכל פריט ברשימה הזו כאל חובה ולא כאל אופציה.
תבניות מותאמות אישית מביאות איתן קשיים משלהן
תבנית מותאמת אישית בדרך כלל אומרת נתיבי קבצים קבועים מראש, סוגי תוכן מותאמים שנרשמו ב-functions.php, ואולי כמה הפניות לקבצים שמניחות מבנה תיקיות מסוים. הנה למה כדאי לשים לב:
כתובות URL ונתיבים קבועים מראש
מפתחים לפעמים קובעים את הדומיין של האתר או נתיבי שרת מוחלטים ישירות בתוך קבצי התבנית, במקום להשתמש בפונקציות וורדפרס כמו get_template_directory_uri(). אם התבנית שלכם עושה את זה, חיפוש והחלפה פשוט במסד הנתונים עבור שם הדומיין לא יתפוס הכל. תצטרכו גם לבדוק את קבצי התבנית עצמם לאיתור הפניות לדומיין הישן או לנתיב השרת הישן.
כלי חיפוש והחלפה שעובד גם על קבצים וגם על מסד הנתונים חוסך הרבה חיפושים ידניים כאן, כי הוא מאפשר לתפוס הפניות בקבצי PHP, לא רק בשורות במסד הנתונים.
סוגי תוכן וטקסונומיות מותאמים אישית
אם התבנית שלכם או פלאגין מותאם אישית רושמים סוגי תוכן משלהם (כמו "תיק עבודות" או "המלצות"), הם חיים במסד הנתונים בדיוק כמו פוסטים רגילים. הם עוברים בלי בעיה כחלק מייצוא מסד הנתונים הרגיל. הסיכון הוא שאם הקוד שרושם את סוגי התוכן האלה לא עובר כמו שצריך, או מופעל בסדר הלא נכון, וורדפרס אולי לא יזהה את סוג התוכן באתר החדש עד שהפלאגין או התבנית ייטענו כמו שצריך.
בדיקת פונקציונליות מותאמת אישית לפני שעוברים סופית
עם פלאגינים סטנדרטיים, בדיקה חזותית מהירה אחרי ההעברה בדרך כלל תופסת בעיות. עם פונקציונליות מותאמת אישית, צריך לבדוק בפועל את התכונות שהקוד המותאם אישית מפעיל, כמו טופס יצירת קשר עם לוגיקת אימות מותאמת, שער גישה לחברים, או אינטגרציית API ששואבת נתונים משירות צד שלישי. דמיון חזותי לא אומר דמיון תפקודי.
כאן סביבת staging מוכיחה את עצמה. במקום לבדוק התנהגות פלאגין מותאם אישית על הדומיין החי ולקוות לטוב, אפשר להריץ את האתר המועבר קודם בעותק staging, לעבור על כל תכונה מותאמת אישית, ולוודא שחיבורי מסד הנתונים ומפתחות ה-API מצביעים למקומות הנכונים לפני שמישהו אחר רואה את זה. סביבות staging קיימות בדיוק בשביל הבדיקה היבשה הזו.
רשימת בדיקה מעשית
- התחברו ובדקו דפי ניהול או מסכי הגדרות מותאמים אישית
- שלחו טפסים מותאמים אישית וודאו שהנתונים נשמרים או נשלחים כראוי
- בדקו אינטגרציות API של צד שלישי (שערי תשלום, מערכות CRM, מחשבוני משלוח)
- בדקו תפקידי משתמש והרשאות מותאמים אישית אם הפלאגין שלכם יצר כאלה
- ודאו שמשימות מתוזמנות (cron jobs) שהפלאגין שלכם תלוי בהן עדיין פועלות
גיבויים הם רשת הביטחון שלכם, לא מחשבה שנייה
לפני שנוגעים בכלום, קחו גיבוי מלא של הקבצים ומסד הנתונים מהאתר המקורי. אם פלאגין מותאם אישית מתנהג בצורה לא צפויה בשרת החדש, ולא תיעדתם בדיוק איך הוא הוגדר קודם, גיבוי הוא הדרך המהירה ביותר לחזור למצב תקין ידוע. מערך גיבויים איכותי שמאפשר לשחזר קבצים ספציפיים או טבלאות מסוימות במסד הנתונים, במקום שחזור של הכל או כלום, שימושי במיוחד כאן. אם רק טבלאות מסד הנתונים של הפלאגין המותאם אישית נפגמו במהלך המעבר, תרצו לשחזר רק את הטבלאות האלה, לא להחזיר את כל האתר אחורה ולאבד שינויי תוכן שנעשו מאז.
בקרת גרסאות עוזרת יותר ממה שחשבתם
אם הפלאגינים והקבצים המותאמים אישית שלכם חיים במאגר Git, ההעברה נהיית הרבה פחות מסוכנת. אפשר למשוך בדיוק את אותו בסיס קוד לשרת החדש במקום להעתיק קבצים ולקוות ששום דבר לא נשמט או נפגם בדרך. זה גם נותן לכם נקודת חזרה נקייה אם משהו בסביבה החדשה גורם להתנהגות לא צפויה, כי אתם יכולים להשוות את מצב הקבצים לפני ואחרי המעבר.
אם לא השתמשתם בבקרת גרסאות לקוד המותאם אישית שלכם, ההעברה היא הזדמנות טובה להתחיל. לפרטים על העברת אתר גדול או מורכב במיוחד, ראו איך להעביר אתר וורדפרס גדול בלי לאבד אפילו פוסט אחד.
לסיכום
פלאגינים ותבניות מותאמים אישית לא משנים מהותית איך שירות העברת וורדפרס עובד. הקבצים ומסד הנתונים עדיין צריכים לעבור באותה דרך שתמיד עברו בה. מה שכן משתנה זו רמת הקפדנות הנדרשת: בדיקת תאימות לשרת מול קוד שנכתב עבור סביבה ספציפית אחת, איתור נתיבים קבועים מראש שחיפוש והחלפה במסד הנתונים עלול לפספס, ובדיקה אמיתית של הפונקציונליות המותאמת אישית במקום רק מבט חטוף על עמוד הבית. הקדישו זמן נוסף לכך, תעדו איך הקוד המותאם אישית שלכם מוגדר לפני שמתחילים, והישענו על staging וגיבויים מדויקים כדי לתפוס בעיות לפני שהן מגיעות למבקרים שלכם.
