אפתח בגילוי נאות, חברתינו מציעה את שני השירותים – גם תכנות של WordPress Custom Theme וגם בניה ע"ג אלמנטור.
ההבדל בניסוח בין תכנות לבניה הוא לא אקראי. ישנם פרוייקטים שמצריכים פיתוח, וישנם פרוייקטים שיכולים להסתפק בבניה. כשפונה אלינו גנן שכונתי, ההמלצה הברורה היא לפרוייקט אלמנטור. במקרה כזה תספיק לו הרכבה של עיצוב on the go תוך כדי בניה, בלי שלבי אסטרטגיה ובלי שלבי UX/UI, הוא בסך הכל צריך להציג את מרכולתו בצורה אסטטית ואוניברסלית. אין צרכים מיוחדים, אין התממשקויות, אין סטיילגייד, אין צורך עקרוני בכלי אינטראקטיבי כזה או אחר, אין תיכנון אנימציות שתואם את הסטיילגייד והמסר השיווקי, אין ביצוע פיקסל פרפקט לפי חזון גרפי מדוייק.
אך במקרים בהם פרוייקט שמלווה ע"י סטודיואים מהשורה הראשונה, ישנם כמה חסרונות מובהקים לשימוש ב-Page builder (להלן: PB). ההתייחסות היא באופן כללי לכל סוגי ה-PB, לא נמנה חסרונות נקודתיים של אלמנטור אלא חסרונות מובנים בשיטה:
- אבטחה: וורדפרס עצמה היא תוכנה שמתוחזקת ע"י חברה בסדר גודל עולמי (Automatic), מריצה מאות מיליוני אתרים, ומשחררת עדכוני אבטחה כמעט על בסיס שבועי. אך כשמתגלה באג או פרצת אבטחה ב-PB שבחרתם, אתם תלויים בחסדי החברה המפיצה, שלעיתים עושה זאת בהתנדבות ללא SLA מסודר. להסיר ספק, יש לא מעט כאלה, לאלמנטור לבד היו 6 דיווחי אבטחה השנה, אחת קריטית מלפני כמה ימים.
- יציבות: הישענות על פלאגין שהאתר לא יכול לרוץ בלעדיו, במקום בניה רזה ונקיה על-גבי וורדפרס, יוצרת תלות בעדכוני התוכנה שהחברה המתחזקת של ה-PB תשחרר, תלות ביציבות הפלאגין עצמו, ותקווה שהעדכון לא יצור התנגשות שתביא לנפילת האתר.
- ביצועים: מטבע הדברים PB מנסים לענות לקשת רחבה של צרכים, ולא נותנים מענה רזה וממוקד לאתר שלכם. לכן הם טוענים הרבה פונקציות ומודולים, וכן מריצים הרבה שאילתות מיותרות, שמעמיסות דרמטית על הביצועים של האתר, דבר שמשפיע גם על התפעול השוטף וגם על הדירוג ב-Google Speed Test.
- קושי תפעולי: לאדם שאינו טכני ומיומן, התפעול השוטף של פיתרון ג'נרי הרבה יותר מורכב מאשר פיתרון מותאם. בפיתרון Custom מנהל התוכן מקבל טופס אליו הוא יוצק נתונים יבשים, והם מסתדרים אוטומטית ע"ג התבנית הויזואלית באתר. ב-PB מנהל התוכן מקבל עורך ויזואלי (לצורך ההמחשה – כמו PowerPoint) שמאפשר לו גמישות יתרה, דבר המצריך מכל מנהל תוכן גם חוש טכני וגם חוש עיצובי (לצד העבודה עצמה שאותה הוא נשכר לבצע..).
- פלאגינים נלווים: מטבע הדברים כשעובדים בתצורה של בניה ולא תכנות, נאלצים להוסיף פלאגינים נלווים כדי להצליח ליישם פעולות שאינן מובנות ב-PB. זה מראה דיי נפוץ לראות שבאתר המבוסס על PB ישנם עשרות רבות של פלאגינים, חלקם אחראים לתפקוד משמעותי של האתר. הישענות על אותם פלאגינים מייצרת שוב את אותה תלותיות ביציבות הפלאגין, באבטחה שלו, ובשחרור עדכונים מצד המפתחת שלו.
- עדכוני גירסא: בעת עדכון גירסת וורדפרס, המשך התפקוד הרצוף של אתר המבוסס על PB כפוף לכך שלא יחולו התנגשויות בין הגירסא החדשה של וורדפרס ל-PB שלכם. כשאתם בוחרים להתבסס על PB מסויים, אתם נכנסים איתו למערכת יחסים ארוכה ומחייבת, ומביעים בו אמון מלא שיתעדכן פונקציונאלית ואבטחתית לכל אורך חיי האתר שלכם, וכמובן שיעשה זאת בזריזות המתבקשת.
- תמיכה טכנית: רוב ה-PB מפותחים ע"י חברות בינלאומיות המציעות שירותי תמיכה שאינן בהכרח בשעות לוקאליות, ובהכרח לא בכלים זמינים. אפילו אלמנטור שהינה חברה ישראלית, מציעה תמיכה באמצעות קבוצת פייסבוק בלבד. בעת תקלה קריטית עליכם פשוט לחכות למענה וולונטרי.
- פיקסל פרפקט: יישום של עיצוב שנוצר ב-Figma כמעט בלתי אפשר לבצע על PB ברמת Pixel Perfect. שלא לדבר על חוסר היכולת הטוטאלית להטמיע Styleguide אחיד ומחייב. לכל PB יש את הכלים והסטנדרטים שלו, וחוסר האחידות והמחויבות ל-Styleguide זה חלק מהגדרת המוצר. כל ניסיון לשים פלסטר עלול להישבר בעדכון הגירסא הבא.
- תזוזות עיצוביות: המציאות מראה שגם כאשר עידכוני גירסא ל-PB עוברים תקין, כמעט בכל עדכון שכזה – תחול תזוזה ויזואלית כזו או אחרת באתר. זה פחות מהותי אצל ידידינו הגנן השכונתי, אבל כשעובדים מול סטיילגייד מדוייק וחווייה שנוצרה ע"י סטודיו ששילמתם לו עשרות או מאות אלפי שקלים כדי לייצר אותה – היא נפגמת בוודאות מוחלטת.
- הגמישות-יתר הויזואלית שה-PB מציעים, מביאים פרוייקטים שלמים להיראות כמו סלט עגבניות (ולא כמו זה של שף ידוע) לאחר כמה סבבי עדכון תוכן, בעיקר כשהעדכון לא מתבצע ע"י אותו מנהל תוכן בחברה.
- רספונסיב: דיוק חוויית הרספונסיב לא מתאפשר באופן מלא ב-PB. אפילו באלמנטור איתרנו לאחרונה כמה באגים שהוגשו לתיקון, אינני יודע מה קרה איתם מאז. חווייה מדוייקת מיוצרת ע"י קוד מדוייק.
- קומפוננטות מיוחדות: גם שליפות מיוחדות כמו "תשלוף בסקשן הזה את הפוסטים האחרונים בשילוב עם האירועים האחרונים וסדר לי אותם לפי העתידיים בנפרד ואירועי-העבר בנפרד" לא מתאפשר ב-PB. הדוגמא אולי נשמעת קצת דימיונית, המציאות היא שבכל אתר שיש בו יותר מ-10 תבניות מגיעים לצורך לבצע אוטומציה ברמה כזו או אחרת, שב-PB תצטרכו לבצע אותה ידנית. וכל פעולה ידנית דינה להיתפספס או להיתבצע בצורה לא אחידה לאורך הזמן ובעת התחלפות בעלי תפקידים בחברה.
- שאיבת מידע (API): הטמעת מידע ממקורות חיצוניים, כמו יבוא נתוני מניה, יבוא Sec Filings, יבוא משרות מ-Comeet וחבריה, כל האלמנטים הללו לא נתמכים באופן מובנה ב-PB. הרעיון ב-PB הוא מתן מענה לצרכים הנפוצים הרחבים, אך ברגע שנרצה לעשות משהו מעט מיוחד, ניתקל בצורך לפתח במיוחד, או בחלק מהמקרים להשתמש בפלאגינים נוספים – על כל המשתמע מכך.
- דחיפת מידע (API): גם דחיפת מידע למקורות חיצוניים, כמו CRM או במקרים של שילוב הדוק של מערכת מלאי והזמנות וכד' – יהיה מאתגר כשהאתר משתמש ב-PB. וכשאני מציין מאתגר המשמעות היא שיתכן שנפתור את זה כעת, אבל תצטרכו להתפלל טוב טוב לפני כל עדכון גירסא שכלום לא ישבר בוקר אחד לפני שהתערוכה או המהלך השיווקי הגדול יוצא לדרך.
- היברידי: אם נרצה להשתמש ב-PB רק בחלק מהדפים ואת יתר הדפים לבצע כ-Custom – מעבר לכפילות הפיתוחית שתידרש, הדבר בלתי אפשרי לאור כך שה-PB בעצם מזריקים את הקוד של עצמם לכל עמודי האתר ללא אבחנה. הם לא מצטרפים לפרוייקט בפרופיל נמוך.
בפרוייקטים בהם היה צורך להעמיד דפי נחיתה עם גמישות עיצובית משמעותית שלא היה ניתן לאפיין מראש, יישמנו פיתרון היברידי לפיו האתר הראשי פותח כ-Custom Theme, וישנו PB שיושב על סאב-דומיין נפרד המשמש לטובת דפי הנחיתה. בשיטה הזו נפילה של ה-PB לא מפילה את האתר כולו.
לסיכום, לכל פרוייקט יש את הפיתרון המתאים לו, ולא יהיה נכון לצאת בהצהרה גורפת של "רק זה נכון". צריך לבצע את הבחירה בצורך מושכלת, ולזכור ששינוי שיטה משמעו פיתוח מחדש של כל הפרוייקט, על הלו"ז והתקציב המשמע מכך.