הפסקת תמיכה בבלוקים של גוטנברג: עדכון מבלי לשבור תוכן

סיכום

עדכון בלוק גוטנברג לעיתים שובר פוסטים קיימים המשתמשים בגרסה הישנה. מאמר זה מראה לך כיצד להשתמש במאפיין deprecated ב-block.json כדי לשמור על תאימות לאחור. תלמד את השלבים המדויקים ללכידת הסימון הנוכחי של הבלוק, הגדרת גרסה אחת או יותר מיושנות, ומיפוי תכונות בצורה נכונה. נסקור גם בלוקים סטטיים וגם דינמיים, עם דוגמאות מעשיות. המאמר גם מטיל ספק בהנחה שהפסקת תמיכה היא תמיד הגישה הטובה ביותר, ודן מתי הפסקה נקייה עשויה להיות טובה יותר. בסוף, תוכל לעדכן את הבלוקים שלך בביטחון מבלי לשבור את התוכן של המשתמשים שלך.

תרחיש השינוי השובר

השקת בלוק המלצות מותאם אישית לפני שישה חודשים. הוא פלט <div> פשוט עם ציטוט ושם מחבר. כעת הלקוח שלך רוצה עיצוב חדש: המחבר צריך להופיע מעל הציטוט, עם מחלקת CSS שונה. אתה מעדכן את פונקציית ה-save וה-render_callback של הבלוק. אתה בודק בפוסט חדש — זה נראה נהדר. אז אתה נווט לפוסט ישן שמשתמש בבלוק. אסון: טקסט הציטוט נעלם, המחבר במקום הלא נכון, והעיצוב משובש. זה עתה שברת כל עמוד שמשתמש בבלוק.

זוהי הבעיה הקלאסית של "שינוי שובר" בפיתוח בלוקי גוטנברג. בלוקים הם למעשה מבני נתונים המשולבים בסימון. כאשר אתה משנה את הסימון, העורך לא יכול למפות אוטומטית תוכן ישן למבנה החדש. התוצאה היא שגיאת אימות (הבלוק הופך לבלתי חוקי) או — גרוע מכך — השחתה שקטה שבה הבלוק מוצג בצורה לא נכונה.

מהי הפסקת תמיכה בבלוק?

הפסקת תמיכה בבלוק היא המנגנון המובנה של גוטנברג לטיפול בשינויי גרסאות. על ידי הגדרת מערך deprecated ב-block.json של הבלוק שלך, אתה אומר לעורך: "אם נתקלת בבלוק התואם לאחת מהגרסאות הישנות הללו, המר אותו לגרסה הנוכחית." כל ערך מיושן מציין את ה-attributes, ה-supports ופונקציית ה-save (או render_callback) הקודמים. כאשר העורך טוען בלוק ישן, הוא עובר על מערך המיושנים לפי הסדר ומחיל את ההתאמה הראשונה.

תכונה זו אינה מנוצלת לעיתים קרובות כי מפתחים מניחים שלעולם לא יצטרכו לשנות את הסימון של בלוק. אבל בפרויקטים אמיתיים, הדרישות מתפתחות. אם תדלג על הפסקת תמיכה, תאלץ משתמשים למחוק ולהכניס מחדש בלוקים (חוויה גרועה) או לתחזק שתי גרסאות נפרדות של הבלוק (מבולגן). מדריך המפתחים הרשמי של וורדפרס מכסה זאת במדריך עורך הבלוקים, אך חסרים הדרכות מעשיות.

שלב 1: לכוד את המצב הנוכחי

לפני ביצוע שינויים, תעד את הפלט המדויק של save (או render_callback עבור בלוקים דינמיים) ואת ה-attributes שהבלוק שלך משתמש בהם כעת. חשוב על זה כעל צילום מסך. עבור בלוקים סטטיים, שמור את ה-JSX שמוחזר על ידי פונקציית ה-save. עבור בלוקים דינמיים, שמור את סימון ה-PHP שנוצר על ידי render_callback.

צור קובץ חדש בתוסף שלך בשם deprecated.js (או דומה) ואחסן שם את פונקציית ה-save הישנה. לחלופין, שמור את הגרסאות המיושנות ישירות בקובץ ה-JavaScript הראשי של הבלוק. המפתח הוא לשמור קוד זה בדיוק כפי שהיה כאשר הבלוק נפרס לראשונה.

שלב 2: הגדר את הגרסאות המיושנות שלך

ב-block.json שלך, הוסף מערך deprecated. כל ערך הוא אובייקט שיכול לכלול:

• attributes (אובייקט): הגדרות התכונות הקודמות.
• supports (אובייקט): כל הגדרות תמיכה קודמות שהשתנו.
• save (פונקציה או מחרוזת): פונקציית ה-save הקודמת. עבור בלוקים מבוססי JavaScript בלבד, תייבא את הפונקציה הישנה. עבור בלוקים דינמיים המבוססים על PHP, תוכל להשתמש ב-migrate ו-render_callback במקום.
• migrate (פונקציה): פונקציה שממפה תכונות ישנות לחדשות (אופציונלי).

דוגמה:

"deprecated": [
  {
    "attributes": {
      "quote": { "type": "string", "source": "html", "selector": ".quote" },
      "author": { "type": "string", "source": "html", "selector": ".author" }
    },
    "supports": {},
    "save": "() => <div className=\"testimonial-legacy\"><p className=\"quote\">{attributes.quote}</p><p className=\"author\">{attributes.author}</p></div>"
  }
]

שימו לב: פונקציית ה-save ב-block.json מוגדרת בדרך כלל ב-JavaScript. אם אתה משתמש בסקריפט חיצוני, תצטרך לטעון אותו ולהפנות לשם הפונקציה. לחלופין, תוכל להטמיע את הפונקציה כמחרוזת (אם כי זה לא מומלץ עבור בלוקים מורכבים).

שלב 3: מפה תכונות

לעיתים, אתה משנה לא רק את הסימון אלא גם את שמות התכונות או המקורות. לדוגמה, ייתכן שתעבור מאחסון המחבר כמחרוזת פשוטה לשדה טקסט עשיר. במקרים כאלה, השתמש במאפיין migrate כדי להפוך תכונות ישנות לחדשות.

migrate: (attributes) => {
  return {
    quote: attributes.quote,
    author: { content: attributes.author, level: 2 }
  };
}

אם לא תספק פונקציית migrate, העורך פשוט יעביר את התכונות הישנות ישירות לבלוק החדש. זה עלול לגרום לשגיאות אם שמות התכונות השתנו.

שלב 4: בדוק עם תוכן אמיתי

לאחר הגדרת הגרסה המיושנת, בדוק ביסודיות. צור פוסט חדש, הכנס את הבלוק הישן (אתה יכול לדמות על ידי הדבקת קוד הבלוק המסודר מפוסט קיים), וודא שהוא מומר לגרסה החדשה ללא שגיאות אימות. כמו כן, בדוק עריכה ושמירה של הבלוק שהומר. חזור על הפעולה עבור מספר גרסאות מיושנות אם יש לך כאלה.

עבור בלוקים דינמיים, התהליך דומה אך עם טוויסט: פונקציית ה-save עבור בלוק דינמי מחזירה בדרך כלל null (הבלוק מוצג באמצעות PHP). בערך המיושן, תוכל להגדיר save לסימון הסטטי הקודם שהיה בשימוש לפני שעברת להצגה דינמית, או להשתמש ב-render_callback ב-PHP המטפל במבני תכונות ישנים וחדשים כאחד. זה יותר מורכב אך אפשרי.

אזהרות והתפשרויות

הפסקת תמיכה היא חזקה, אך יש לה חסרונות. כל גרסה מיושנת מוסיפה קוד לתוסף שלך. עם הזמן, אתה עלול לסיים עם שרשרת של חמש או שש גרסאות מורשת שהן נדירות בשימוש אך חייבות להישמר. צוות הליבה של וורדפרס ממליץ לשמור לפחות שתי גרסאות אחורה, אך מעבר לכך, ייתכן שתשקול הפסקה נקייה אם מספר הפוסטים המושפעים קטן.

ניואנס נוסף: סדר הערכים המיושנים חשוב. העורך עובר על המערך מאינדקס 0 כלפי מעלה ומשתמש בהתאמה הראשונה. אם שתי גרסאות מיושנות דומות, ייתכן שהלא נכונה תוחל. תמיד רשום את הגרסה המיושנת העדכנית ביותר ראשונה (זו שקודמת ישירות לגרסה הנוכחית).

לבסוף, הפסקת תמיכה אינה מטפלת בתוכן שנערך באמצעות שינוי סגנון ברמת האתר (למשל, באמצעות theme.json). אם המראה של הבלוק שלך הסתמך על סגנונות גלובליים שהשתנו מאז, הפסקת התמיכה לא תתאים לכך. ייתכן שתצטרך להוסיף סקריפט הגירה שרץ בעת שמירה או באמצעות הוק עדכון תוסף.

כאשר הפסקת תמיכה אינה התשובה

רוב המדריכים מציגים הפסקת תמיכה כחובה. במציאות, ישנם מצבים שבהם הפסקה נקייה עדיפה. אם הבלוק שלך חדש ומשמש רק בכמה פוסטים, עדכון ידני של אותם מקרים בודדים עשוי להיות מהיר יותר מאשר כתיבה ובדיקה של קוד הפסקת תמיכה. באופן דומה, אם מודל הנתונים הבסיסי של הבלוק שונה מהותית (למשל, אתה ממזג שני בלוקים לאחד), הפסקת תמיכה עשויה לא להיות גמישה מספיק. במקרה זה, כתוב סקריפט הגירה חד-פעמי שרץ בעת עדכון התוסף, הממיר בלוקים ישנים לפורמט החדש.

נקודה מנוגדת נוספת: אין להשתמש בהפסקת תמיכה כתחליף לעיצוב טוב. אם אתה צופה שינויים תכופים, עצב את הבלוק שלך עם גירסון מלכתחילה — למשל, על ידי אחסון תכונת version ושימוש בהצגה מותנית. גישה זו, הנדונה במעבר לבלוקים בסיסיים, קלה יותר מהפסקת תמיכה אך דורשת ראייה קדימה.

סיכום

הפסקת תמיכה בבלוק היא כלי חיוני לכל מפתח גוטנברג רציני. היא מאפשרת לך לפתח את הבלוקים שלך מבלי לשבור את התוכן של המשתמשים. השלבים המרכזיים הם: לכידת המצב הנוכחי, הגדרת הגרסה המיושנת ב-block.json, מיפוי תכונות במידת הצורך, ובדיקה עם תוכן אמיתי. אך זכור שהפסקת תמיכה כרוכה בעלויות תחזוקה. לפעמים הפסקה נקייה או עיצוב בלוק עם גירסון היא יותר פרקטית. השתמש בהפסקת תמיכה בצורה אסטרטגית, לא אוטומטית, והבלוקים שלך יישארו חזקים דרך עדכונים רבים.

לפרספקטיבה רחבה יותר על בניית תוספים ניתנים לתחזוקה, ראה בניית תוספים חזקים לוורדפרס. ואם אתה חדש בפיתוח בלוקים, מעבר לבלוקים בסיסיים יעזור לך להתחיל.