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

סיכום

רוב הסוכנויות בונות כל אתר וורדפרס מתוך תמה ריקה, גם כשבסיס משותף היה חוסך שבועות מהלו"ז. מאמר זה טוען ש-theme.json, תבניות בלוקים ובלוקים דינמיים מאפשרים לך לתקנן את השכבה המבנית תוך שמירה על העיצוב הייחודי של כל לקוח. הוא נוגע ישירות בחמש ההתנגדויות שמונעות מצוותים לשנות: 'יש לנו לקוחות שונים', 'בלוקים מותאמים אישית יקרים', 'העורך מבלבל', 'נאבד את ה-hooks וה-filters שלנו' ו-'FSE אינו מוכן לייצור'. כל התנגדות מקבלת טיעון נגדי מעשי ודפוס קונקרטי שאתה יכול לאמץ בהדרגה. התמורה היא תהליך בנייה שניתן לחזור עליו שעדיין מכבד עבודה ייחודית במקום שמגיע לה. אזהרה: אין כפתור איפוס בלחיצה אחת.

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

ההתנגדות 'אבל כל לקוח שונה'

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

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

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

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

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

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

ההתנגדות 'בלוקים מותאמים אישית מפוצצים את התקציב'

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

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

תרחיש ערמומי יותר: הלקוח מבקש 'קרוסלת מקרי בוחן'. האינסטינקט הראשון הוא לחשוב 'אני צריך בלוק קרוסלה'. אבל האם הם צריכים קרוסלה? אולי הם צריכים קבוצה של פוסטים הניתנים לגלילה אופקית, שבלוקי ליבה יכולים לטפל בה עם בלוק 'קבוצה' וקצת CSS. או אולי הם צריכים רשימה דינמית של מקרי בוחן אחרונים, שזה בלוק דינמי שמבצע שאילתה על ה-CPT. השאלה היא לא 'איזו תכונה הלקוח רוצה?' אלא 'על איזה נתונים היא תלויה?' אם הנתונים סטטיים וניתנים לעריכה על ידי הלקוח, תבנית תספיק. אם הנתונים מגיעים משאילתת מסד נתונים, בלוק דינמי מוצדק. אם הנתונים צריכים להתעדכן בזמן אמת מ-API, ייתכן שאתה מסתכל על אינטגרציית REST API במקום—זה נכנס לסוג אחר של בנייה.

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

לפני שאתה בונה משהו, העבר את ההחלטה דרך הטבלה הזו:

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

כדאי גם לחשוב על שמות בלוקים מהיום הראשון. שם בלוק הוא בעצם חוזה עם התוכן שלך. אם תקרא לו wagent/team-grid ולאחר מכן תשנה את שמו ל-wagent/team-carousel, תשבור תוכן קיים אלא אם תספק נתיב התיישנות. בחר שמות גנריים המבוססים על מטרה, שלא יהפכו לפרסום מטעה ככל שהבלוק מתפתח. זהו סוג של משמעת שמות שכולנו למדנו מקידומות תוספים, וזה חל לא פחות על שמות בלוקים.

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

ההתנגדות 'לקוחות ישברו את העורך'

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

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

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

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

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

ההתנגדות 'כבר יש לנו hooks ו-filters'

העיקרון כאן הוא: אתה לא זורק את ה-hooks; אתה מוסיף שכבה מעל. בלוקים הם גבול ההצגה; hooks הם עדיין הדרך שבה אתה מזריק לוגיקה. פונקציית הקריאה החוזרת (render callback) של בלוק דינמי רצה ב-PHP, מה שאומר שאתה יכול לקרוא לאותן פונקציות ולהחיל את אותם filters שכבר אתה סומך עליהם.

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

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

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

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

ההתנגדות 'FSE אינו מוכן לייצור'

בסדר, אבל שאל מה 'מסוכן' אומר בפועל. עריכת אתר מלאה (Full Site Editing) עברה מספר מהדורות, ו-theme.json התייצב לסכמה יציבה. הסיכון אינו שהעורך 'פתאום נשבר'—הסיכון הוא שהקוד המותאם אישית של הצוות שלך עשוי להסתמך על תבניות PHP בסגנון ישן שמתקיימות במקביל בצורה מביכה עם תבניות בלוקים. בנוסף, חלק מהתוספים של צד שלישי עדיין מניחים עורך קלאסי או Customizer. זו החלטת תאימות, לא סיבה לזרוק את כל המודל.

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

לפני שאתה מציע תמת בלוקים ללקוח, עבר על רשימת בדיקה מהירה:

• האם ללקוח יש תמה מותאמת אישית בכבדות שתדרוש העברה?
• האם התוספים החיוניים תומכים בעורך האתר וב-REST API?
• האם סביבת האירוח מאפשרת את גישת הקבצים שתמת הבלוקים מצפה לה?
• האם הקדשת זמן לעיצוב תבניות, לא רק לרישום בלוקים?
• האם הצוות של הלקוח יסבול את שינויי העורך, או שהם צריכים תבנית נעולה?

אם התשובה לאחת מהשאלות היא לא, התאם את ההיקף או השתמש בגישה היברידית. זו לא פשרה; זה שיקול דעת הנדסי. ואם אתה בונה היברידי, זכור את סיפור ה-hooks וה-filters למעלה—אתה עדיין יכול לעטוף לוגיקה ישנה בבלוקים דינמיים בעוד theme.json מתמודד עם המראה הגלובלי.

בקרת גרסאות ל-theme.json שלך היא לא רק דאגה תיאורטית. ראיתי ספריית בלוקים מותאמת אישית של סוכנות נשברת כשהלקוח עדכן את וורדפרס וקובץ ה-style של הבלוק נרשם עם wp_register_style() תחת מזהה (handle) ששונה. התיקון היה קל, אבל הפאניקה הייתה אמיתית. תהליך בדיקה פשוט—הרץ את העדכון על עותק סטייג'ינג של האתר, לחץ על הדפים המרכזיים, ואז שחרר—פותר את רוב ההפתעות האלה.

ההתנגדות שלא העלית לעצמך

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

הנה 30 הימים הראשונים בקירוב:

1. ערוך ביקורת על חמשת בניות הלקוח האחרונות שלך ורשום את עשרת חלקי הפריסה החוזרים ביותר.
2. הפוך את עשרת החלקים האלה לתבניות בלוקים, עם קבוצה קטנה של מחלקות CSS.
3. בנה תוסף משותף (או mu-plugin) שרושם את התבניות האלה. אם לא חשבת על ארגון תוספים עבור זה, עיין תחילה בהמדריך הזה לבניית תוספים חזקים.
4. צור theme.json אחד שתואם לעיצוב הבסיס שלך; הוסף ערכים ספציפיים ללקוח כשאתה מקים פרויקטים.
5. בחר פרויקט פנימי קטן אחד או לקוח ידידותי והעבר אותו לסט הטכנולוגי.
6. תעד סיפור גבורה אחד של לקוח שערך את דף הבית שלו בלי להתקשר אליך.

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

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

החזרתיות נובעת מהחלקים המשעממים: סכמת theme.json מוצקה, ספריית תבניות ברורה, והמשמעת לשמור על השכבה המשותפת רזה. זה לא הגרסה הנוצצת ששומעים בוובינרים. זו זו שמנצחת את הבלוז של יום שני בבוקר של תמה ריקה.