Ultimate Multisite 101

Ultimate Multisite הוא תוסף WordPress Multisite שמאפשר לך להציע WaaS או "אתרים כשירות" ללקוחות. לפני שנצלול פנימה ונלמד איך Ultimate Multisite יכול לעזור לעסק שלך וללקוחותיך, יש קצת ידע בסיסי שעלינו לרכוש.

ה-WordPress Multisite

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

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

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

בליבת WordPress קיימת תכונה בשם פשוט 'Multisite' שמקורותיה חוזרים ל-2010 עם השקת WordPress 3.0. מאז היא עברה מספר גרסאות שנועדו להוסיף תכונות חדשות ולהדק אבטחה.

במהות, אפשר לחשוב על WordPress multisite כך: אוניברסיטה מחזיקה התקנת WordPress אחת, אבל כל פקולטה מנהלת את אתר ה-WordPress שלה.

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

הרשת

במונחי WordPress, רשת multisite היא מקום שבו ניתן לנהל מספר תתי-אתרים מלוח בקרה אחד. למרות שיצירת רשת multisite שונה בין ספקי אחסון, התוצאה הסופית היא בדרך כלל כמה הנחיות נוספות בקובץ wp-config.php שמודיעות ל-WordPress שהוא פועל במצב הספציפי הזה.

יש מספר הבדלים ברורים בין רשת multisite להתקנת WordPress עצמאית, שעליהם נדבר בקצרה.

Subdomain לעומת Subdirectory

אחת ההחלטות המיידיות ביותר שתצטרכו לקבל היא האם התקנת ה-multisite תפעל עם subdirectories או subdomains. Ultimate Multisite עובד באותה מידה טוב עם שתי האפשרויות, אבל יש כמה הבדלים ארכיטקטוניים בין שתי התצורות.

בתצורת subdirectory, אתרי הרשת יורשים נתיב המבוסס על שם הדומיין הראשי. לדוגמה, אתר רשת בשם 'site1' יקבל את הכתובת המלאה https://domain.com/site1. בתצורת subdomain, לאתר הרשת יהיה subdomain משלו הנגזר משם הדומיין הראשי. כך אתר בשם 'site1' יקבל את הכתובת המלאה https://site1.domain.com/.

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

מבחינת DNS, השימוש ב-subdirectories מציג אתגר פשוט יחסית. מכיוון שאתרי הרשת הם פשוט ילדים של הנתיב ההורה, צריך להיות רק רשומת דומיין אחת עבור שם הדומיין הראשי. עבור subdomains האתגר קצת יותר מורכב ודורש או רשומת CNAME נפרדת לכל אתר רשת או רשומת wildcard (*) ברשומות ה-DNS.

תחום נוסף לשיקול הוא SSL והנפקת ושימוש בתעודות SSL. בתצורת subdirectory ניתן להשתמש בתעודת דומיין בודדת מכיוון שאתרי הרשת הם פשוט נתיבים של שם הדומיין הראשי. כך תעודה עבור domain.com תספק SSL מתאים עבור https://domain.com/site1, https://domain.com/site2 וכן הלאה.

בתצורת subdomain השימוש בתעודת SSL מסוג wildcard הוא אחת האפשרויות הנפוצות ביותר. סוג זה של תעודת SSL מספק הצפנה לדומיין ול-subdomains שלו. לכן תעודת SSL מסוג wildcard תספק הצפנה עבור https://site1.domain.com, https://site2.domain.com ו-https://domain.com עצמו.

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

תוספים ותבניות

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

מסיבה זו, כאשר WordPress מוגדר כ-multisite, הוא מסיר ממנהלי האתרים את היכולת להתקין תוספים ותבניות ובמקום זאת מעביר יכולת זו לתפקיד חדש של מנהל רשת או 'super admin'. תפקיד מיוחס זה יכול אז להחליט האם לאפשר למנהלי אתרי רשת לראות או לגשת לתפריט התוספים בלוח הבקרה שלהם, ואם כן, האם הרשאות אלה מתרחבות ל_הפעלה_ או השבתה של תוספים.

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

משתמשים ומנהלים

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

בהתחשב בהבנה זו, יכול להיות לא רצוי לאפשר יצירת משתמשים ומסיבה זו WordPress Multisite מסיר יכולת זו ממנהלי האתרים ומעביר אותה למנהל הרשת. בתורו, מנהל הרשת יכול להאציל את ההרשאות הנדרשות למנהל אתר כדי לאפשר לו ליצור חשבונות משתמש עבור האתר שלו.

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

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

מדיה

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

המיקום הסטנדרטי של WordPress (wp-content/uploads) נשאר; עם זאת, הנתיב שלו משתנה כדי לשקף את המזהה הייחודי של אתר הרשת. כתוצאה מכך קבצי מדיה עבור אתר רשת מופיעים כ-wp-contents/uploads/site/[id].

קישורים קבועים

הזכרנו קודם שיש יתרונות ברורים ל-subdomain על פני תצורת subdirectory והנה זה: נתיבים.

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

עבור פוסטים, נתיב /blog/ חובה מתווסף לאתר הראשי כדי למנוע התנגשויות עם אתרי רשת. משמעות הדבר היא שקישורים קבועים יפים כמו 'שם פוסט' יוצגו כ-domain.name/blog/post-name/

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

דפים סטטיים

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

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

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

הרשמה

בתוך הגדרות הרשת של WordPress Multisite זמינות מספר אפשרויות הרשמת משתמשים חדשות, המאפשרות למשתמשים חדשים וקיימים ליצור אתרים.

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

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

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

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

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

דומיין ו-SSL

בואו נדבר על התקנת WordPress Multisite שכמעט חומקת מתשומת הלב שלנו - WordPress.com. זוהי ללא ספק הדוגמה המקיפה ביותר ל-WordPress multisite ומדגימה את יכולותיו הנרחבות להתאמה אישית ועיצוב למילוי מטרה.

בימינו באינטרנט המודרני השימוש ב-SSL הוא כמעט חובה ומנהלי רשתות של WordPress multisites נתקלים במהרה באתגרים אלה.

בתצורת subdomain אתרים נוצרים על בסיס שם הדומיין השורש. כך אתר בשם 'site1' ייווצר כ-'site1.domain.com'. באמצעות תעודת SSL מסוג wildcard, מנהל רשת יכול להתמודד בהצלחה עם אתגר זה ולספק יכולות הצפנת SSL לרשת.

WordPress Multisite מכיל פונקציית מיפוי דומיינים המאפשרת לאתרי רשת להיות משויכים לשמות דומיין מותאמים אישית או שמות דומיין שונים מדומיין השורש של הרשת.

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

במידה זו בעוד WordPress Multisite מספק אמצעי לאפשר ל-www.anotherdomain.com להיות ממופה ל-'site1', מנהל הרשת נשאר עם האתגר של ניהול חיצוני של רשומות ה-DNS ויישום תעודות SSL.

Ultimate Multisite

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

מבוא

Ultimate Multisite הוא האולר השוויצרי שלכם כשמדובר ביצירת אתר כשירות (WaaS). חשבו על Wix.com, Squarespace, WordPress.com ואז חשבו על להחזיק בשירות משלכם.

מתחת למכסה המנוע Ultimate Multisite משתמש ב-WordPress Multisite אבל הוא עושה זאת באופן שלא רק פותר את אינספור האתגרים שמנהלי רשת מתמודדים איתם בהתקנות multisite אלא משפר את היכולות ומאפשר תמיכה במגוון רחב של מקרי שימוש.

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

מקרי שימוש

מקרה 1: סוכנות

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

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

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

סביר להניח שרצוי להשתמש בתצורה ולמרבה המזל Ultimate Multisite מקל מאוד על הנחיית מיפוי דומיינים ותעודות SSL עם האינטגרציות שלו למספר ספקי אחסון פופולריים וכן לשירותים כמו Cloudflare ו-cPanel.

כך על ידי מינוף אחד מהספקים האלה או על ידי הצבת Ultimate Multisite מאחורי Cloudflare, היבטים כמו ניהול דומיינים ותעודות SSL הופכים לטריוויאליים למדי.

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

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

תבניות מספקות פונקציונליות דומה, המאפשרת להפעיל או להסתיר תבניות מסוימות ביצירת אתר.

סוכנויות ימצאו שקט נפשי עם Ultimate Multisite שמאפשר להן לעשות מה שהן עושות הכי טוב - לעצב אתרים יוצאי דופן.

מקרה 2: ספק נישה

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

אולי אתם שחקני גולף נלהבים שמקדמים אתרים למועדונים או שאתם גיימרים נלהבים של esports שמספקים אתרים לקלנים. אולי יחיד שמקדם שירות הזמנות למסעדות?

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

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

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

בהתאם לדרישות גם תצורת subdirectory וגם subdomain עשויות להתאים, ובמקרה כזה בחירות הארכיטקטורה יהיו בין תעודת SSL פשוטה ל-subdirectories או תעודת SSL מסוג wildcard ל-subdomains.

מקרה 3: אחסון אתרי WordPress

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

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

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

עבור מפתחים שרוצים להשתלב עם Ultimate Multisite, הפתרון מציע גם API RESTful מקיף ו-Webhooks להתראות על אירועים.

ללא הסתמכות על אינספור תוספים חיצוניים ורישיונות, Ultimate Multisite מספק פתרון עשיר בתכונות והשוואתי לזה של Wix, Squarespace, WordPress.com ואחרים.

שיקולי ארכיטקטורה

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

אחסון משותף לעומת אחסון ייעודי

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

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

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

בקיצור, זול לא אומר טוב.

Ultimate Multisite ידוע כעובד עם מספר ספקי אחסון טובים ומשתלב היטב בסביבה שלהם כדי לספק פונקציות כמו מיפוי דומיינים ו-SSL אוטומטי. ספקים אלה מעריכים ביצועים ומספקים שירות ברמה גבוהה יותר מאחסון משותף.

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

שיקולי ביצועים

Ultimate Multisite אינו אפליקציה איטית, למעשה, הוא מהיר להפליא. עם זאת, הוא מבצע רק כמו האפליקציה והתשתית הבסיסיות ויכול לנצל רק את מה שיש לו גישה אליו.

שקלו זאת: אתם מנהלי הרשת של התקנת Ultimate Multisite עם 100 אתרים. חלק מהאתרים האלה מצליחים ומושכים מספר מבקרים מדי יום.

תרחיש זה יהיה שונה בקנה מידה קטן יותר של נאמר אחד עד חמישה אתרים אבל במהרה בעיות של קנה מידה יהיו ברורות.

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

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

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

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

Ultimate Multisite כולל תוסף Cloudflare מתוחכם המאפשר למנהלי רשת להציב את ההתקנות שלהם מאחורי Cloudflare ולהשתמש לא רק ביכולות ה-caching שלו אלא גם באחסון DNS, תעודות SSL ומנגנוני אבטחה.

גיבויים

אפשר לשאול 50 אנשים לעצה על גיבויים ולקבל 50 דעות שונות על אסטרטגיות גיבוי. התשובה היא, תלוי.

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

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

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

Snapshots

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

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

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

סקריפטים חיצוניים

נראה שאין מחסור בסקריפטים חיצוניים ופתרונות לגיבוי משאבי WordPress ו-MySQL ואלה יעבדו היטב עבור Ultimate Multisite מכיוון שהוא תוסף WordPress שמשתמש במערכת הקבצים ובמסד הנתונים של WordPress. כך פתרון שמגבה אתרי WordPress יכסה באופן הולם את הצרכים של Ultimate Multisite.

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

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

תוספים

כמעט אין בעיה ב-WordPress שלא ניתן לפתור עם תוסף ואם ניהול סקריפטים חיצוניים הוא לא הכוס שלכם אז אולי תוסף הוא האפשרות הבאה הטובה ביותר.

בעוד שתוספים משתנים באפשרויות ובתכונות הם בעיקר מבצעים את אותה פונקציה והיא ליצור עותק של קבצי WordPress ותכני מסד הנתונים. לאחר מכן הפונקציונליות משתנה כאשר חלק מהתוספים יכולים לשלוח את הגיבויים לשירותים חיצוניים כמו Google Drive או Dropbox או לסוג כלשהו של שירות אחסון אובייקטים תואם כמו S3, Wasabi או אחרים. התוספים המקיפים יותר מספקים גיבויים דיפרנציאליים או סוג כלשהו של אסטרטגיה לגיבוי רק נתונים שהשתנו כדי לחסוך בעלויות אחסון חיצוני.

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

דומיין ו-SSL

הרבה כבר נדון לגבי שמות דומיין במצב subdomain של multisite. פתרון כמעט אוניברסלי למנהלי רשת הוא להשתמש ברשומות DNS מסוג wildcard.

סוג זה של רשומת DNS יפתור בהצלחה subdomains כמו 'site1.domain.com' ו-'site2.domain.com' לכתובת IP של 1.2.3.4 וכך יתמוך ב-Ultimate Multisite ובמידה רבה יותר ב-WordPress Multisite במצב subdomain.

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

למרבה המזל יש אפשרויות קלות לתעודות SSL. במצב subdirectory ניתן להשתמש בתעודת דומיין רגילה. אלה זמינות בקלות ובחינם מספקי אחסון שעשויים להשתמש בשירות LetsEncrypt החינמי או ממקור אחר. אחרת אלה זמינות מסחרית מרשויות אם אתם מסוגלים ליצור את בקשת חתימת התעודה.

עבור מצב subdomain השימוש בתעודת SSL מסוג wildcard יזדווג בצורה מושלמת עם דומיין wildcard ויאפשר לתעודה להיות סמכותית עבור דומיין השורש וכל ה-subdomains ללא תצורה מיותרת.

עם זאת, יש לציין שתעודות SSL מסוג wildcard עשויות לא לעבוד עם שירותים כמו Cloudflare אלא אם אתם על תוכנית enterprise או מגדירים את הרשומה ל-DNS only ובמקרה כזה כל ה-caching והאופטימיזציה עוקפים.

מהקופסה Ultimate Multisite מספק פתרון לבעיה זו המדגים את הניסיון הנרחב שלנו עם הצרכים של WordPress multisites. הפעלת תוסף פשוט זה תגרום ל-Ultimate Multisite להשתמש בפרטי ההתחברות שלכם ל-Cloudflare כדי להוסיף אוטומטית רשומות DNS לאתרי רשת ב-Cloudflare ולהגדיר את המצב שלהם ל-'proxied'. באופן זה כל תת-אתר רשת, כאשר נוצר, יקבל את ההגנה והיתרונות המלאים של Cloudflare כולל SSL.

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

עבור רבים, השימוש ב-Cloudflare הוא אפשרות קלה. הלקוח רק צריך להציב את הדומיין שלו על Cloudflare, להפנות CNAME לדומיין השורש של Ultimate Multisite ולמפות את הדומיין שלו ב-Ultimate Multisite כדי להתחיל לנצל את שם הדומיין המותאם אישית שלו.

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

תוספים

סביר מאוד שתצטרכו תוספים נוספים כדי לספק פונקציונליות ללקוחות או לאתרי הרשת שלכם. האם כל התוספים עובדים עם WordPress Multisite ו-Ultimate Multisite? ובכן, תלוי.

בעוד שרוב התוספים ניתנים להתקנה ב-WordPress Multisite, ההפעלה והרישוי שלהם משתנים ממחבר למחבר.

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

לכן אולי כדאי לבדוק עם מחבר התוסף כיצד התוסף שלו יעבוד עם WordPress Multisite ודרישות מיוחדות או נהלים הנדרשים לרישוי שלו.