מדוע התקנת Decap CMS נתקלת בעריכה ידנית של התוכן
האתר כבר נבנה מהמאגר (ריפוזיטורי): התוכן יושב לצד התבניות בקבצי סימון נפרדים, והפרסום מופעל באמצעות קומיט. כל עוד לא נוגעים בטקסטים, הסכימה עובדת — הבנייה משוחזרת, היסטוריית השינויים מלאה, וחזרה לכל גרסה אורכת דקות. אך די לשנות כותרת בדף הבית או לחדד ניסוח בכרטיס שירות, והעריכה עוברת לתור המשימות של המפתח.
מכאן מתחיל מחזור ידני: משימה במערכת המעקב, ענף, אישור, בנייה, בדיקה בסביבת הניסוי ורק אחר כך העלאה. על עריכה קטנה מתבזבזים יום-יומיים, ועל אישור ניסוחים — הרבה יותר.
בזמן הזה הטקסט נערך במקום נוסף, והתוכן במאגר ה-git מתרחק ממה שהמבקרים רואים בפועל; הפער צף כבר בפרודקשן, כשמישהו שולח צילום מסך עם שורה מיושנת.
התקנת Decap CMS סוגרת בדיוק את הפער הזה. לוח ניהול התוכן קורא את מבנה השדות מהקונפיגורציה ושומר את העריכות ישירות במאגר בקומיט נפרד — העורך עובד עם טפסים ולא עם קבצים, ואינו יכול לשבור את התבנית בטעות.
עריכות ללא מפתח אינן מבטלות את הסקירה: הענף, ההיסטוריה והחזרה נשארים במקומם, והפרסום הידני של עריכות הופך לשלב אחד במקום שרשרת אישורים.
נפרק כיצד זה נסגר בפועל — מתיאור הקולקציות והשדות ועד לבנייה שמופעלת אחרי כל קומיט.
מה נותן ה-Git-בקאנד: מהירות עריכות ובניות צפויות
Decap CMS שומר את התוכן לא במסד נתונים אלא במאגר: כל רשומה היא markdown או JSON עם front matter, עריכת העורך הופכת לקומיט, והפרסום — למיזוג ענף ולבנייה מחדש של האתר.
Git-בקאנד כזה ל-CMS מסיר את שכבת הביניים «מסד נתונים → API → רינדור», ולכן ה-HTML הסופי נשאר סטטי, וכל התוכן עובר את אותה סקירה ואותן בדיקות כמו הקוד. להלן שלושה אפקטים שנראים במטריקות.
זמן פרסום העריכה: דקות במקום שעות
מנהל התוכן עורך את הטקסט בעורך ויזואלי, העריכה עוברת לענף נפרד, ואחרי המיזוג מתחילה הבנייה אוטומטית. מטמון אינקרמנטלי בונה מחדש רק את הדפים שנגעו בהם, ולא את כל האתר, ולכן החציון מרגע הלחיצה על «שמור» ועד להופעת הטקסט בדומיין החי נמדד בדקות. במקומות שאין בהם סביבת טיוטה, את הענף מציגים בתצוגה מקדימה — האישור אינו חוסם את הפרסום.
היסטוריית גרסאות של התוכן ושיעור החזרות
כל עריכה היא קומיט עם מחבר, הודעה וההבדל המדויק. החזרה לניסוח הקודם נעשית ברוויזיה אחת, בלי שחזור גיבוי של מסד נתונים ובלי השבתה.
לפי מדידות ענפיות, בצוותים שהעבירו את העריכה למאגר, שיעור הפרסומים שיש להחזיר ביד יורד פי כמה — משום שהחזרה מפסיקה להיות פעולה על נתונים והופכת לפעולה בהיסטוריה.
בניית האתר אחרי העריכה: השגיאות נראות לפני היציאה לאוויר
הבנייה היא שער: בדיקת front matter, קישורים פנימיים שבורים, כפילויות כותרות והרכבת התפריט מתבצעת לפני ההעלאה. בנייה שנכשלה אינה מתפרסמת, הפרודקשן נשאר בגרסה הקודמת, והמחבר מקבל לוג עם ציון השורה.
כתוצאה מכך שיעור ההעלאות הכושלות שמגיעות למבקרים יורד, ומספר התקלות ה"שקטות" בניווט אחרי עריכות תוכן יורד למקרים בודדים.
אפשרויות חיבור: הרצה מקומית, שרת בנייה, ענן
הלוח עם git-בקאנד הוא אוסף של קבצים סטטיים שקוראים וכותבים תוכן ישירות למאגר: כל שמירה הופכת לקומיט בענף. לכן מצב החיבור קובע שלושה דברים בבת אחת — מי מקבל גישה לעריכות, כיצד נבדק השינוי ובאיזה רגע הוא מגיע לפרודקשן.
Decap CMS תומך בכל שלוש הסכימות בלי לשכתב את התוכן: משתנה מקטע הבקאנד בקונפיגורציה, וקבצי ה-markdown נשארים במקומם.
המצבים אינם מתחרים זה בזה אלא סוגרים שלבים שונים: הרצה מקומית — הגדרת סכימת הקולקציות, שרת בנייה — דומיין משלך וכללי פרסום פרטיים, ענן — עבודה משותפת של כמה עורכים. להלן השוואה לפי קריטריונים שברוב המקרים שוברים את הוצאת החומר.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| הרצה מקומית של הלוח | הגדרה ראשונית של שדות וקולקציות, דיבוג הסכימה, ייבוא חד-פעמי של תוכן ישן | דורש סביבה מותקנת והרשאות כתיבה למאגר; עורכים ללא גישה למאגר לא יוכלו לעבוד, ההזדהות אינה נבדקת |
| שרת בנייה של האתר | דומיין משלך, קונטור סגור, כללים משלך לבדיקת עריכות ותפקידי עורכים | יש להחזיק ולתחזק את השרת, להגדיר בעצמך כניסה, גיבויים והוקים לאירוע הקומיט |
| בנייה בענן של סטטיקה | כמה עורכים, תצוגה מקדימה של ענפים נפרדים, פרסום אוטומטי אחרי המיזוג | ההגדרות יושבות מחוץ למאגר, חלות מגבלות הפלטפורמה על הבנייה, הכניסה קשורה לספק שלה |
בפועל, המעבר בין המצבים הוא עריכת בלוק קונפיגורציה אחד והעברת כללי הגישה. התוכן, מבנה הקולקציות והיסטוריית הקומיטים נשמרים, ולכן בטוח להתחיל בהרצה מקומית ולעבור מאוחר יותר לשרת או לענן.
התקנה וחיבור של Git-בקאנד: שלבי העבודה
ב-Decap CMS ה-git-בקאנד הוא האפשרות הצפויה ביותר לאתר תוכן: העריכות עוברות למאגר בקומיטים רגילים, ולכן ההיסטוריה, האישור והחזרה פועלים באותם אמצעים כמו לקוד. את השלבים מסדרים כך שכל אחד יסתיים בבדיקה קונקרטית ולא בתקווה.
- ביקורת מבנה התוכן. מפרקים את הדפים וסוגי הרשומות הקיימים, מסמנים בלוקים חוזרים. בודקים: מה יהפוך לקולקציה ומה לקובץ בודד.
- הגדרת קולקציות התוכן. מתארים קולקציות, שדות ותיקייה לקבצי מדיה. בודקים: שדות חובה מסומנים, רשימות מקוננות אינן שוברות את הסכימה.
- חיבור ה-git-בקאנד. מציינים את ספק המאגר, ענף העבודה ותיקיית התוכן. בודקים: עריכת בדיקה יוצרת קומיט בענף הנכון ולא בענף הראשי.
- הרשאות גישה של המערכת. מגדירים תפקידים: המחבר עובד עם טיוטות, העורך הבכיר מאשר פרסום. בודקים: המחבר אינו יכול לכתוב ישירות לענף הראשי.
- בנייה ומדיה. מריצים בנייה עם עריכות אמיתיות ותמונות שהועלו. בודקים: הקובץ מגיע לתיקייה הנכונה, הנתיב בתוכן תקין, הבנייה לא נופלת.
- בדיקת הפרסום. מריצים מחזור מלא: טיוטה → אישור → בנייה → דף. בודקים: השינויים נראים באתר, והחזרת הקומיט מחזירה את הגרסה הקודמת.
- העברת הגישות למערכת. פותחים חשבונות והוראה קצרה על הממשק. בודקים: עורך חדש עובר את הדרך מהטיוטה ועד הפרסום בעצמו.
מה מועבר לידיים: קולקציות, תפקידים, נהלי עריכה
אחרי ההטמעה המערכת עורכת את האתר בעצמה, בלי לפנות אלינו. לכן לידיים עובר לא "גישה לאדמין" אלא אוסף קבצים במאגר: הקונפיגורציה של Decap CMS, מדיניות ההרשאות והוראות למחברים ולעורכים.
- סכימת הקולקציות — סוגי תוכן (דפים, חדשות, מחברים, מקטעי מידע) עם שדות: סוג, חובה, כלל בדיקה. רשומה עם כותרת ריקה או קישור תמונה שבור פשוט לא תישמר.
- תפקידי המחבר והעורך — המחבר רואה ועורך רק את הטיוטות שלו, העורך מאשר ומפרסם. ההפרדה נשענת על ענפים ועל הגנת הענף הראשי, ולא על הבנות בעל-פה.
- טיוטות ותצוגה מקדימה של עריכות — השמירה עוברת לענף נפרד, התצוגה המקדימה נבנית ממנו, ולכן דף לא גמור אינו מגיע לאתר החי.
- הוראה למערכת — כמה דפים עם צילומי מסך: כיצד להוסיף חומר, לצרף תמונה, לשלוח לבדיקה ומה לעשות אם שדה לא עבר בדיקה.
- נוהל החזרה — כיצד להחזיר את הגרסה הקודמת של החומר או להסיר תוכן מפורסם לחלוטין: דרך היסטוריית השינויים והחזרת הקומיט הנדרש.
- הסכם קבצי מדיה — היכן שוכנות התמונות, כיצד הן נקראות, איזה פורמט ומשקל מותרים.
- פירוק הקונפיגורציה עם המפתח שלכם — הגישות נרשמות על החשבונות שלכם, הסכימה והתפקידים מוסברים, ואת התמיכה אפשר לנהל בכוחות עצמכם.
בקבלה עוברים על כל סעיף במשימה חיה: פותחים חומר בדיקה, שולחים לבדיקה, מפרסמים ומחזירים. אם שלב דורש את השתתפותנו — זו אינה העברה אלא תלות.
מקרה בוחן: עריכות תוכן בלי מעורבות המפתח ובלי השבתות
מה היה לפני ההטמעה
האתר נבנה מקבצי markdown ב-Git, וכל עריכה עברה דרך המפתח: העורך שלח את הטקסט לרשימת המשימות המשותפת, המהנדס הכניס אותו לקובץ, ביצע קומיט והמתין לבנייה. הדבר הניב 10-12 פרסומים בשבוע ו-1-2 יממות מרגע אישור הטקסט ועד יציאתו באתר — חדשות דחופות איבדו את טעמן בזמן הזה.
גם היציבות נפגעה: בערך כל בנייה שלישית נפלה בגלל שגיאת הקלדה בשדות השירות של החומר או קישור לדף שאינו קיים, ועם הלוגים התעסק אותו מפתח.
מה שינו
פרסו Decap CMS עם Git-בקאנד ותיארו את הקולקציות בקונפיגורציה: אילו שדות יש לחומר, אילו חובה, באיזה פורמט התאריך והעטיפה. העורך עובד בממשק ווב — הטופס לא יאפשר לשמור חומר עם כותרת ריקה או קישור שבור, וכל שמירה הופכת לקומיט עם מחבר-עורך. הבנייה של ענף נפרד מספקת תצוגה מקדימה לפני המיזוג, ולכן השגיאה נראית בשלב העריכה ולא בענף הראשי.
מה קרה אחרי ההטמעה
המערכת עושה בעצמה למעלה מ-40 עריכות בשבוע בלי בקשות לפיתוח. היממה עד הפרסום הצטמצמה לדקות: החומר יוצא מיד אחרי הבדיקה, ולא אחרי חלון הזמן הקרוב של המהנדס. שיעור הבניות שנפלו ירד משליש למקרים בודדים, וכמעט כולם נתפסים בתצוגה המקדימה. המפתחים חזרו למשימות המוצר — ליווי התוכן חדל להיות העבודה שלהם.
במה שונה Git-בקאנד משירות חיצוני לאחסון תוכן?
Git-בקאנד משמעו ש-Decap CMS אינו שומר תוכן אצלו: כל עריכה היא קומיט למאגר, והקבצים יושבים ב-markdown/YAML לצד הקוד. שירות חיצוני בנוי ההפך — העורך כותב רשומה למסד הנתונים של הספק, והאתר מושך אותה דרך API. ההבדל מתבטא לא בנוחות העריכה אלא במי שולט בגרסאות ובאיזו מהירות מוחזרת שגיאה.
| קריטריון | Git-בקאנד | שירות חיצוני |
|---|---|---|
| היכן הנתונים | קבצים במאגר | רשומות במסד הנתונים של הספק |
| היסטוריית גרסאות | קומיטים, ענפים, שיוך למחבר | יומן בתוך השירות, לעיתים קרובות מצומצם |
| החזרת עריכה | revert של הקומיט הנדרש | שחזור מ-snapshot, העומק נקבע על ידי הספק |
| טיוטות | ענף + תצוגה מקדימה של הבנייה | טיוטות במסד הנתונים של הספק |
| פרסום | בנייה בצד שלנו | webhook של השירות, השהיה שאינה בשליטתנו |
| העברת תוכן | שכפול המאגר — תמונת מצב מלאה | ייצוא דרך API ובנייה מחדש של הקשרים |
| תלות | גישה למאגר | מפתחות, מכסות וכללי הספק |
האפקט המעשי — החזרה מפסיקה להיות פעולה של "צור קשר עם הספק". קלקלתם בלוק בדף הבית: revert של הקומיט, בנייה מחדש, העלאה — ובאתר הגרסה הקודמת. עריכות של כמה עורכים מתמזגות כמו קוד, והפער נראה בהשוואה שורה-מול-שורה במקום לצוף בפרודקשן.
הצד השני כן וכנה: Git-בקאנד דורש בנייה עובדת וגישה למאגר מצד אלה שעורכים את התוכן. שירות חיצוני מוצדק במערכת עריכה גדולה עם תפקידים והגבלה לפי שדות — אך אז התוכן חי במסד נתונים זר, ואתם יורשים תלות בתנאים וב-API שלו.
שאלות של מהנדסים: גישות, החזרת עריכות, הגירת תוכן
התוכן בסכימה כזו יושב לא במסד הנתונים של האפליקציה אלא בקבצים במאגר: כל עריכה הופכת לקומיט נפרד עם מחבר ותאריך. לכן שאלות של גישות, החזרה והעברה נפתרות לא בהרחבות של האדמין אלא ברמת מערכת בקרת הגרסאות — ועונים עליהן מראש.
היכן פיזית יושבים החומרים ומה יקרה בעת תקלה?
הטקסטים והתמונות נשמרים במאגר ולא במסד הנתונים של שרת אחד. בעת כשל של העורך או הבנייה התוכן אינו הולך לאיבוד: ניתן לבנות את הסטטיקה מהמאגר מחדש, ולכל מי שעובד עם הפרויקט יש עותק מלא.
כיצד להפריד את הרשאות הגישה בין העורכים?
התפקידים נבנים לפי מדורים: המחבר עורך רק את החומרים שלו, העורך מפרסם, המנהל שולט בסכימת השדות. ההגבלה נקבעת ברמת המאגר והענף — המחבר פיזית אינו יכול לגעת במדור של אחר או בענף הראשי.
מה לעשות עם תוכן שכבר נצבר בפורמט אחר?
מעבירים בסקריפט: דפים ורשומות מפורקים לקבצים תוך שמירת הכתובות, והתמונות עוברות לאחסון המדיה. אחרי ההרצה משווים את מפת הקישורים ומגדירים ניתובים מחדש כדי שתעבורת החיפוש שנצברה לא תאבד.
כיצד בנויים הטיוטות, הפרסום והחזרת עריכה כושלת?
המחבר עובד בענף נפרד, הטיוטה נראית בתצוגה המקדימה, והפרסום הוא מיזוג לענף הראשי. עריכה כושלת מוחזרת בקומיט הפוך: האתר חוזר למצבו הקודם תוך זמן של בנייה אחת, בלי שחזור ידני מגיבוי.
נדון במשימה: מה נדרש מהמערכת ומהמפתחים
כדי שהערכה של התקנת Decap CMS תהיה מדויקת ותוכנית ההטמעה ברת-ביצוע, אנו זקוקים להקשר מקדים על הפרויקט. מצד המערכת ומצד הפיתוח הוא שונה, וטוב לאסוף אותו לפני ההתחלה מאשר לברר אותו באמצע העבודה.
- היכן חי התוכן כיום: קבצים במאגר, סימון בצורת טקסט או נתונים באחסון אחר, מי וכיצד עורך אותם.
- המאגר ומודל ההסתעפות: אחסון Git, ענף העבודה, כללי מיזוג שינויים, למי יש הרשאת פרסום.
- מבנה הקולקציות: אילו ישויות נערכות, שדות חובה, רשימות מקוננות וקשרים בין מסמכים.
- תפקידים במערכת: מי כותב, מי מאשר, מי מפרסם; האם נדרש ענף נפרד לטיוטה ולבדיקה לפני הוצאה לאוויר.
- בנייה ופרסום: מחולל סטטיקה, קונפיגורציה של הבנייה, כיצד מועלית כעת הגרסה המוכנה וכיצד מוחזרת גרסה כושלת.
- גישות ואבטחה: סכימת ההזדהות של המחברים, הרשאות למאגר, גיבויים, מי אחראי על השחזור.
- דרישות מהספק: היקף העבודה, גבולות האחריות, סדר אישור העריכות ונוהל תגובה לתקלות.
- העברה למערכת: הוראה למחברים, פירוק שגיאות אופייניות וליווי אחרי ההשקה.
מכאן מתגבשים שלושה מסמכים: הערכת העבודה להטמעה, תוכנית הטמעה לפי שלבים ודרישות מהספק. תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית.
