ערכת נושא מקצועית ל-Pico CMS ב-Twig — הזמנת פיתוח

ערכת Pico CMS מותאמת אישית: היכן נשברת הפריסה הטיפוסית

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

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

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

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

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

מה נותנת ערכה נפרדת: מהירות פרסום ועריכות

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

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

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

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

דרכים להתאמה: שכבת הרחבה, פורק לליבה, שכבה משלך

ערכה ב-Pico CMS היא סט תבניות Twig בתוספת קובץ הגדרות: הליבה מוסרת תוכן, והתבניות מחליטות איך הוא נראה. לכן התאמה היא שאלה לא של תחביר, אלא של מה יקרה לעריכות בעדכון המנוע הבא.

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

שלבי העבודה: סקר תבניות, סכמה, הרכבה, בדיקה

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

1. סקר תבניות. עוברים על תיקיית הערכה, אוספים את כל קבצי הסימון, מסמנים שרשראות ירושה, בלוקים כפולים וקטעים שאיש כבר לא מפנה אליהם. התוצאה — מפת תלויות ורשימת סיכונים.
2. השוואת תוכן וסכמת תבניות. משווים שדות במטא-נתונים של העמודים למה שהסימון באמת קורא. מוצאים שדות בלי פלט ומשתנים בלי מקור: זו הסיבה העיקרית לבלוקים ש"זזים" אחרי החלפת ערכה.
3. תכנון סכמה. מקבעים שלד בסיסי, קטעים לשימוש חוזר, סטים וסדר ירושה. הסכמה מסוכמת לפני שורת הסימון הראשונה — עריכות בשלב הזה זולות פי כמה.
4. הרכבה. הסימון נכתב לפי הסכמה, חזרות מוציאים לבלוקים משותפים, תבניות מטמון מכוונות כך שהעורך רואה שינויים מיד, והמבקר לא ממתין להרכבה מחדש.
5. בדיקת רגרסיה. מריצים עמודים טיפוסיים, פיד, חיפוש, עימוד, טפסים ומטא-נתונים לרשתות חברתיות. כל נתיב נבדק לפני ואחרי — פערים מתועדים בפרוטוקול.
6. מסירת הערכה. מוסרים מאגר עם היסטוריה, הערות בתבניות ותיאור הסכמה, ובנפרד מלמדים את העורכים: איך להוסיף עמוד, בלוק, תמונה בלי לשבור את הסימון.

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

מה נשאר אצל הלקוח: תבניות, סכמות ותקנונים

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

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

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

מקרה בוחן: עורכים מפרסמים בלי מעורבות מפתח

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

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

מה שינו

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

מה השתנה

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

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

ספקות טכניים לפני התחלה והתשובות להם

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

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

איך יעבור המעבר לשרת אחר?

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

האם כתובות העמודים יישמרו?

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

מי אחראי לתאימות התבניות?

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

במה שונה דריסת תבנית מתוסף?

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

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

הבחירה ביניהם מצטמצמת למה בדיוק משתנה:

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

מה לשלוח להערכה: הרכב נתוני המקור

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

• גישות לעותק האתר: סביבת בדיקה נפרדת עם אותו סט הרחבות כמו בפרודקשן, ובנוסף גישה לקבצי הערכה ולמסד הנתונים, אם התוכן מאוחסן לא רק בקבצי טקסט.
• הערכה הנוכחית במלואה — ארכיון או מאגר: תבניות Twig, חלקים, סגנונות, סקריפטים, הגדרות שירות. לא תמצית של «רק מה שאנחנו מתקנים»: קשרים בין תבניות נראים רק בעץ מלא.
• רשימת תוספים והטמעות צד שלישי עם סימון אילו קריטיים. זה מיד מראה אזורים שבהם יהיה צורך לכתוב מחדש את הלוגיקה עבור הסימון החדש.
• דוגמאות עמודים לפי סוגים: ראשי, רשימה, כרטיס, מאמר, טופס, עמוד שגיאה. מספיק 5–10 כתובות כדי להעריך את ירושת התבניות והבלוקים המשותפים.
• מגבלות הסביבה: גרסת PHP וסט ההרחבות, מגבלות זיכרון וזמן ריצה, סכימת מטמון, הגשת תוכן סטטי.
• פריסות ומקורות עיצוב, אם הערכה משתנה חזותית — עם רזולוציות מובייל ומצבי רכיבים.
• אינוריאנטים שאסור לאבד בעת המעבר: כתובות עמודים, תגי מטא, מיקרו-סימון, כללי הפניה.
• עדיפויות: אילו מקטעים נדרשים ראשונים, ומה יכול להמתין לשלב הבא.

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