מדוע עורך Quill המובנה ב-CMS שובר תוכן
עורך Quill המובנה ב-CMS נשבר באופן צפוי: מנהל התוכן מדביק טקסט מ-Word, שומר — ובעמוד נעלמות הכותרות, פסקאות נדבקות זו לזו, והטבלה הופכת לאוסף שורות. הסיבה אינה בעורך, אלא בכך שבין שדה הקלט לאחסון אין שכבה שמביאה את הסימון לצורה אחידה.
Quill מחזיר תוכן בפורמט Delta — רשימה שטוחה של פעולות הוספה ועיצוב — בעוד ה-CMS מצפה ל-HTML. אם ההמרה נעשית "בעין", כל מקרה לא סטנדרטי מאבד את העיצוב בעת השמירה.
היקר מכל הוא הדבקה מ-Word לעורך. Word מביא סגנונות inline, תגי <span> מקוננים, תווים בלתי נראים ומחלקות משלו. מטפל ההדבקה המובנה חותך חלק ומעביר חלק כפי שהוא — ולמסד הנתונים נכנס סימון שאי אפשר לאחר מכן לעבד באופן זהה בדפדפן ובאפליקציית המובייל. טבלאות נקרעות לפסקאות נפרדות, רשימות מאבדות קינון, קישורים נשארים עם פרמטרי מעקב.
סעיף נפרד של אובדן הוא סימון SEO. כותרות ברמות שונות מוחלפות בטקסט מודגש, <h2> ו-<h3> נעלמים מהמבנה, תמונות מגיעות בלי alt ועם שמות קבצים מקוריים. מנוע החיפוש רואה עמוד שטוח בלי היררכיה, ועורך התוכן לאתר הופך למקור של תיקון ידני אחרי כל פרסום. הבעיות של עורך מותאם אישית כאן אינן בממשק — אלא בהיעדר ולידציה בכניסה ונרמול ביציאה.
אנו מפרקים כיצד זה נסגר: סכמת אחסון, כללי המרה של Delta ל-HTML ובחזרה, העלאת מדיה והגנה מפני הדבקה "מלוכלכת".
מה נותנת אינטגרציה מותאמת אישית של עורך: פורמטים והעלאה
מבנה המסמך במקום HTML "גולמי"
הכנסת תמונות רגילה לעורך מחזירה <img> עם כתובת מוחלטת וסגנונות inline — בעת החלפת דומיין או CDN מחצית מהחומרים "מתעוורים", והפריסה נשברת בתבנית אחרת.
פורמטים מותאמים אישית של quill מוגדרים כצמתים נפרדים של מודל המסמך, ולכן כותרת, תיבה או טבלה נשארים בלוקים מטיפוסים ולא אוסף תגים. בתוצאה — פריסה צפויה בכל תבנית והעברה תקינה של החומר בין מדורים ב-CMS.
העלאת מדיה ללא דפים "כבדים"
העלאת תמונות לעורך עוברת דרך מטפל ייעודי: הקובץ נשלח לשרת, נבדק לפי סוג וגודל, נדחס ומקבל מספר גדלים עבור בלוקים שונים של הדף. העורך מכניס אובייקט מוכן עם סט וריאנטים, ולא את המקור במשקל של עשרה מגה-בייט.
הדף מגיש את הגודל הנדרש למקום הספציפי — זמן הטעינה ומשקל הדף מפסיקים להיות תלויים במי ואיך העלה את התמונה.
פורמט Delta כמקור יחיד
פורמט delta שומר את המסמך כרצף פעולות, ולא כסימון מוכן. זה נותן שני דברים: היסטוריית עריכות מלאה עם אפשרות שחזור ותוצאה זהה בעת פלט לאינטרנט, לדואר אלקטרוני או לאפליקציית מובייל. אחסון התוכן מצטמצם למבנה אחד — רינדור ל-HTML, plain text או PDF נבנה בצד השירות, ללא שכפול ידני.
אינטגרציה של העורך עם CMS
אינטגרציה של העורך עם CMS בנויה כך שהעורך הוא שדה קלט, וכל הלוגיקה של פורמטים, העלאה וולידציה חיה בשירות. החלפת תבנית או פריימוורק צד-לקוח אינה שוברת חומרים שכבר נשמרו: מבנה המסמך נשאר ללא שינוי.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| תוסף מוכן מהמרקטפלייס | טקסט פשוט, תבנית פלט אחת | לא ניתן להרחיב פורמטים ולוגיקת מדיה משל עצמך |
| עורך "כפי שהוא" + HTML ידני | לנדינגים חד-פעמיים | הפריסה נשברת בעת החלפת תבנית, עריכות לא מתועדות |
| אינטגרציה מותאמת אישית עם Delta | פלט מרובה-תבניות, היסטוריית עריכות, מדיה | דורשת שכבת שירות ותמיכה |
Quill נבחר כבסיס: מודל המסמך שלו ניתן להרחבה ללא כתיבה מחדש של הליבה, ופורמט האחסון אינו כבול לתבנית פלט מסוימת.
שלבי הטמעת עורך מותאם אישית ב-CMS
הטמעת עורך ב-CMS אינה החלפה של שדה אחד באחר, אלא עבודה עם פורמט אחסון התוכן, העלאת מדיה והרשאות גישה. להלן כיצד אנו מבצעים משימה כזו, כך שלאחר המסירה לא יהיה צורך לכתוב את העורך מחדש.
- ביקורת העורך. בוחנים מה קיים כיום, באיזה פורמט נשמר הסימון (HTML, Delta, פורמט עצמאי), אילו שדות ותבניות קוראים אותו. מתעדים היכן התוכן מאבד את המבנה בעת שמירה ופתיחה מחדש.
- תכנון הסכימה. מגדירים מה העורך מוציא החוצה ומה הוא מקבל בחזרה, כיצד מומרות רשומות ישנות, והיכן עובר הגבול בין הייצוג הנשמר לייצוג המוצג. הסכימה מאושרת לפני הקוד — אחרת המיגרציה הופכת לכתיבה מחדש.
- הגדרת פורמטים. בונים פאנל בהתאם למשימות בפועל: כותרות, רשימות, טבלאות, הוספת קוד, קישורים. מסירים כפתורים מיותרים — כל כפתור מיותר גורר אחריו כלל ניקוי בעת הדבקה ממקורות חיצוניים.
- הגדרת העלאת מדיה. תמונות וקבצים עוברים דרך מטפל ייעודי: בדיקת סוג וגודל, שינוי שם, קישור לרשומה. בנפרד בודקים הדבקה מהלוח וגרירה — אלו המקורות הנפוצים ביותר לנתיבים "שבורים".
- בדיקת פורמטים. מריצים את התוכן במעגל: יצירה, שמירה, פתיחה מחדש, עריכה, פרסום. מוודאים שהסימון אינו מצטבר פסולת לאחר מספר מחזורי עריכה.
- העברת רשומות ישנות. ממירים תוכן קיים ובודקים בדגימה: היכן שהמבנה לא שוחזר — מתקנים את הכללים, ולא רשומות בודדות באופן ידני.
- מסירת תיעוד. מוסרים תיאור הפורמט, סכימת ההמרה, הגדרות הטוען והוראות לעורכי התוכן. לאחר מכן צוות הלקוח מנהל את העורך בעצמו.
כל שלב מסתיים בתוצאה ניתנת לבדיקה: סכימה, טוען עובד, תוכן שנבדק. תארו את ה-CMS שלכם ואת העורך הנוכחי — נחזור עם הערכה ותוכנית לפי שלבים אלו.
במה שונה פורמט Delta מ-HTML באחסון תוכן?
פורמט Delta מאחסן את המסמך כרצף של פעולות: "הכנס טקסט", "שמור מאפיין", "מחק טווח". זה לא סימון (markup), אלא יומן שינויים — העורך וה-CMS עובדים עם אותה מבנה מסמך בדיוק, ולכן בעת טעינה ל-quill editor אין צורך לפרסר HTML בחזרה למודל.
אחסון תוכן ב-HTML בנוי אחרת: במסד הנתונים נמצאת הסימון המוכן, והעורך בעת פתיחה מפרסר אותו עם הפרסר שלו, ומאבד את מה שלא מתואר בסכימה שלו.
ההבדל מתגלה בפעולות שבהן חשובה הדיוק. Delta מתעד מיקום ואורך של ההכנסה, ולכן עריכה משותפת וביטול פעולות עובדים בצורה צפויה: שתי עריכות לא מתנגשות בגלל סדר תגים שונה.
באחסון תוכן ב-HTML התנגשויות כאלה יש לפתור על ידי השוואת עצים, ורשימות מקוננות, טבלאות ובלוקים מותאמים אישית לעתים קרובות משנים את המבנה לאחר סריאליזציה. השוואת הפורמטים כאן אינה על "טוב יותר או גרוע יותר", אלא על מי אחראי על שלמות — העורך או מסד הנתונים.
ל-Delta יש מחיר. הפורמט אינו קריא בעין: כדי לראות את הטקסט, יש צורך ברנדרר, וחיפוש בו במסד הנתונים דורש אינדקס נפרד. HTML ניתן למסור ישירות לתבנית, לסנן עם סניטייזר ולשים במטמון — עבור מערכת עריכה פשוטה זה זול יותר בתחזוקה.
לכן הבחירה תלויה בתרחיש: אם התוכן נערך על ידי מספר מחברים בו-זמנית או שנדרשים ביטולים מדויקים, מבנה המסמך ב-Delta משתלם; אם הפרסומים נדירים וחשובה מהירות ההגשה, HTML פשוט יותר.
בפועל, לעתים קרובות אנו עושים היברידי: Delta כמקור האמת עבור העורך וה-CMS, ו-HTML כשכבה נגזרת, שנבנית מחדש בעת השמירה ומוגשת למבקרים. כך העורך וה-CMS לא חלוקים בייצוג המסמך, והפרונטאנד מקבל סימון מוכן ללא רנדור בזמן אמת.
מקרה בוחן: כיצד סילקנו אובדן עיצוב בעורך
מערכת התוכן של הלקוח — חנות מקוונת עם קטלוג של כמה אלפי כרטיסים — עבדה בהתקנה סטנדרטית של העורך בתוך ה-CMS. בעת הדבקת טקסט מ-Word ומ-Google Docs אבדו רשימות, טבלאות וכותרות מקוננות: הסימון "קרס" לפסקה אחת, ושמירת מאמר גדול עם עשרה תמונות ארכה עד דקה ולעיתים נכשלה עם שגיאה. מנהלי התוכן בדקו מחדש כל פרסום ידנית, וחלק מהחומרים נשלחו לתיקון חוזר כבר לאחר העלייה לאתר.
מה שינינו
פירקנו את השרשרת מהקלט ועד הכתיבה למסד הנתונים ומצאנו שני צווארי בקבוק. הראשון — העורך החזיר סימון בפורמט פנימי משלו, וההמרה ל-HTML התרחשה בצד השרת "על הדרך", ולכן חלק מהצמתים אבדו. השני — התמונות הועלו באופן סינכרוני, וחסמו את הממשק עד לסיום כתיבת הקובץ.
העברנו את האחסון לפורמט הסימון הקנוני של העורך עצמו: הוא נשמר במסד הנתונים כפי שהוא, וה-HTML נבנה ממנו באופן דטרמיניסטי — אותו מסמך תמיד מניב אותה תוצאה. העלאת התמונות הועברה לתהליך נפרד עם תור ותצוגה מקדימה: הכותב רואה את התמונה מיד, והכתיבה מתבצעת ברקע.
בנוסף סגרנו את ההדבקה ממקורות חיצוניים — ניקוי הסימון כעת שומר על רשימות, טבלאות וכותרות, ומשליך רק סגנונות מיותרים.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| שיעור הפרסומים עם אובדן עיצוב | ~30% | פחות מ-1% |
| זמן שמירה ממוצע של מאמר עם תמונות | עד 60 שניות | 3-5 שניות |
| תיקונים ידניים לאחר פרסום | 2-3 לכל חומר | מקרים בודדים |
| הדבקה חוזרת של טקסט מ-Word | דרשה ניקוי ידני | מתבצעת אוטומטית |
נציין בנפרד את ההשפעה על מערכת התוכן: הזמן להכנת חומר הצטמצם בערך בחצי, משום שנעלמה ההגהה החובה של הסימון. מנהלי התוכן הפסיקו לשמור בראשם "כללי הדבקה בטוחה" — העורך עצמו מביא את הקטע המודבק לצורה תקינה.
Quill בחרנו כבסיס דווקא בגלל מודל המסמך הצפוי מראש: הסימון מתואר כעץ פעולות, ולא כמחרוזת HTML, ולכן ניתן להשוות אותו, לאחסן אותו ולשחזר אותו באופן אמין. זה בדיוק מה שנתן את שימור התוכן החסר בהתקנה הישנה.
ספקות לפני הטמעה: תאימות, מיגרציה, נסיגה
השאלה הטכנית הנפוצה ביותר היא מה יקרה לתוכן שכבר נצבר. Quill שומר את התגיות לא ב-HTML, אלא ב-Delta: רשימה שטוחה של פעולות הוספה ועיצוב.
בעת המיגרציה אנו ממירים חומרים ישנים ל-Delta ובחזרה, ומעבירים כל מסמך דרך בדיקה לאובדן עיצוב — טבלאות, רשימות מקוננות ובלוקים מותאמים אישית מועברים לפי כלל נפרד, ולא "בעין". תאימות העורך ל-CMS הנוכחי נבדקת על עותק של מסד הנתונים לפני שינויים בפרודקשן.
מה אם יידרש ביטול? תצורת העורך וכללי ההמרה נמצאים במערכת בקרת גרסאות, ולכן חזרה למצב קודם היא מעבר לגרסה קודמת, ולא עריכה ידנית. מה בנוגע להרשאות? תפקידי קריאה, עריכה ופרסום מופרדים ברמת ה-CMS: מחבר רואה רק את המסמכים שלו, עורך — תור לאישור, מנהל — היסטוריית שינויים.
האם הפריסה הנוכחית תישבר לאחר חיבור העורך?
לא. העורך מתחבר כמודול נפרד עם סגנונות מבודדים, ולכן ערכות הנושא והתבניות של האתר אינן נפגעות. אנו מריצים רגרסיה על עמודים טיפוסיים ומשווים את התגיות לפני ואחרי — פערים נראים לפני העלאה לפרודקשן.
לאחר ההטמעה הצוות מעביר לידיים:
- תצורת העורך עם תיאור סרגל הכלים וכללי העיצוב;
- סכמת המרה Delta ↔ HTML עם דוגמאות למסמכים מורכבים;
- מדיניות תפקידים והרשאות, המקושרת לקבוצות ב-CMS;
- סקריפטים למיגרציית תוכן ודוחות בדיקת ההעברה;
- נוהל נסיגה עם נקודות חזרה בכל שלב;
- תיעוד העורך: חיבור, הרחבה, שגיאות טיפוסיות.
תארו את המשימה שלכם — איזה תוכן כבר נצבר, איזה CMS בשימוש ואילו תפקידים נדרשים. נחזור עם הערכה ותוכנית הטמעה.
לוחות זמנים להטמעת עורך מותאם אישית: שלבים ואבני דרך
לוחות הזמנים אינם תלויים בעורך עצמו, אלא בכמה פורמטים, אינטגרציות ותרחישי הדבקה יש לכסות. להלן אבני דרך לפרויקט טיפוסי: עורך מותאם אישית מבוסס Quill, המשולב ב-CMS, עם העלאת קבצים ואחסון תוכן בפורמט Delta.
הטווח לפי שלבים — משלושה עד שבעה שבועות לעורך אחד. הפיזור נקבע לפי מספר התרחישים הלא-סטנדרטיים: הדבקה מטבלאות ומסמכים, עריכה משותפת, ניהול גרסאות, הגבלות לפי תפקידים. כל תרחיש כזה מוסיף ענף בדיקות נפרד ומזיז את לוח הזמנים באופן ניכר.
השלבים אינם מתקדמים בהכרח לפי הסדר. אב הטיפוס ועיבוד האחסון חופפים לעיתים קרובות: בזמן שהסכמות מוגדרות, כבר ברור באיזו צורה התוכן ייכנס לבסיס הנתונים. הדבר מקצר את לוח הזמנים הכולל, אך דורש שההחלטות לגבי פורמט האחסון יתקבלו בשבוע הראשון, ולא בסופו.
אבני הדרך לעיל מיועדות לצוות שכבר עבד עם פורמט Delta ועם בניות מותאמות אישית. אם התוכן מועבר מעורך ישן, מתווסף שלב העברה: ניתוח הסימון, המרה, ובדיקה על מדגם עמודים.
