Ultimate Multisite 101

Ultimate Multisite એવો વર્ડપ્રેસ મલ્ટીસાઇટ પ્લગઇન છે જે તમને ગ્રાહકોને WaaS અથવા વેબસાઇટ્સ as a Service ઓફર કરવાની સક્ષમ બનાવે છે. તેમાં ડૂબકી લગાવતા પહેલા અને Ultimate Multisite તમારા વ્યવસાય અને ગ્રાહકોને કેવી રીતે મદદ કરી શકે તે શીખવા માટે, આપણને કેટલીક મૂળભૂત જાણકારી મેળવવાની જરૂર છે.

વર્ડપ્રેસ મલ્ટીસાઇટ

આમાંથી મોટાભાગના લોકો સ્ટોક-સ્ટાન્ડર્ડ વર્ડપ્રેસ ઇન્સ્ટોલેશનથી પરિચિત હોય છે. તમે તેને તમારા હોસ્ટિંગ પ્રદાતાના કંટ્રોલ પેનલ દ્વારા બનાવી શકો છો અથવા, જો તમે સાહસિક હોવ, તો એક નવું વેબ સર્વર અને ડેટાબેઝ સેટ કરી શકો છો, કોર ફાઇલો ડાઉનલોડ કરી શકો છો અને ઇન્સ્ટોલેશન પ્રક્રિયા શરૂ કરી શકો છો.

આ વિશ્વભરમાં લાખો વર્ડપ્રેસ સાઇટ્સ માટે કામ કરે છે પરંતુ એક એજન્સી અથવા હોસ્ટિંગ પ્રદાતાના દૃષ્ટિકોણથી, ચાલો થોડી ક્ષણો વોલ્યુમ વિશે વાત કરીએ.

એક જ વર્ડપ્રેસ સાઇટ અથવા સો ઓગણી વેબસાઇટ્સ બનાવવા માટે સ્વચાલિત કંટ્રોલ પેનલ દ્વારા સિંક કરવું તે એક કામ છે, પરંતુ જ્યારે આ સાઇટ્સના સંચાલનનો ભાર તમારા પર આવે છે ત્યારે સમસ્યાઓ ટૂંક સમયમાં દેખાવા લાગે છે. જો તેનું સંચાલન ન થાય તો તમે मैલવેર માટે મુખ્ય લક્ષ્ય બની જશો. મેનેજ કરવા એટલે પ્રયત્ન અને સંસાધનોનો ઉપયોગ કરવો, અને ભલે વર્ડપ્રેસ સાઇટ્સના મેનેજમેન્ટ અને એડમિનિસ્ટ્રેશનને સરળ બનાવવા માટે બાહ્ય ટૂલ્સ અને પ્લગઇન્સ ઉપલબ્ધ હોય, ગ્રાહકો પાસે એડમિનિસ્ટ્રેટિવ એક્સેસ જાળવી રાખવાની હકીકત છે કે આ પ્રયત્નો સરળતાથી નિષ્ફળ થઈ શકે છે.

તેના કોરમાં, વર્ડપ્રેસ એક એવી સુવિધા પ્રદાન કરે છે જેનું નામ ફક્ત ‘Multisite’ છે, જેનો ઉદ્ભવ 2010 માં વર્ડપ્રેસ 3.0 ના લોન્ચ સાથે જોડાયેલો છે. ત્યારથી તેને નવી સુવિધાઓ રજૂ કરવા અને સુરક્ષાને મજબૂત કરવા માટે ઘણા સુધારા મળ્યા છે.

સારાંશમાં, એક વર્ડપ્રેસ મલ્ટીસાઇટને આ રીતે વિચારી શકાય: એક યુનિવર્સિટી વર્ડપ્રેસનું એક જ ઇન્સ્ટોલેશન જાળવી રાખે છે પરંતુ દરેક ફેકલ્ટી પોતાનો અલગ વર્ડપ્રેસ સાઇટ જાળવી રાખે છે.

ցանցը (The Network)

WordPress-ի համատեքստում, մուլտիսայթ ցանցը այն է, որտեղ կարելի է կառավարել մի քանի ենթասայթեր (subsites) մեկ վահանից (dashboard)։ Չնայած մուլտիսայթ ցանցի ստեղծումը տարբեր հոස්տինգային խմբերի միջև տարբերվում է, վերջնական արդյունքը սովորաբար ներառում է wp-config.php ֆայլում որոշ լրացուցիչ ցուցումներ՝ WordPress-ին ասելու համար, որ այն գործում է այս հատուկ ռեժիմով։

Մուլտիսայթ ցանցի և առանձին (stand-alone) WordPress տեղադրման միջև կա մի քանի հստակ տարբերություններ, որոնք մենք կարճ քննարկենք։

ենթադիր անունը (Subdomain) vs. ենթադիր թղթապանակը (Subdirectory)

Ամենահեշտ որոշումներից մեկը, որոնք պետք է կայացնել, այն է, թե արդյոք մուլտիսայթ տեղադրումը կաշխատի ենթաթղթապանակով (subdirectories) թե ենթադիր անուններով (subdomains)։ Ultimate Multisite-ը հարմար է երկու տարբերակների հետ, բայց դրանք ճարտարագիտական առումով որոշ տարբերություններ ունեն։

Ենթաթղթապանակային կոնֆիգուրացիայի դեպքում ցանցային սայթերը ժառանգում են ուղին՝ հիմնվելով հիմնական տիրույթի անվան վրա։ Օրինակ, «site1»-ի համար նշված ցանցային սայթը կունենա իր ամբողջ URL-ը որպես https://domain.com/site1։ Ենթադիր անունային կոնֆիգուրացիայի դեպքում ցանցային սայթը կունենա իր սեփական ենթադիր անունը (subdomain), որը վերածված է հիմնական տիրույթից։ Այսպիսով, «site1»-ի համար նշված սայթը կունենա իր ամբողջ URL-ը որպես https://site1.domain.com/։

Թեև երկու տարբերակներն էլ հարմար ընտրություններ են, ենթադիր անունների (subdomains) օգտագործումը ունի մի շարք առավելություն, բայց պահանջում է նաև ավելի շատ մտածելու և ճարտարագիտական պլանավորման։

DNS-ի համատեքստում _subdirectories_ օգտագործելը համեմատաբար պարզ խնդիր է։ Քանի որ ցանցային կայքերը պարզապես հիմնական ուղու երեխաներ են, մայրական տիրույթի համար անհրաժեշտ է գոյություն ունենալ միայն մեկ դոմենային անուն։ _subdomains_ դեպքում խնդիրը մի փոքր բարդ է և պահանջում է կամ յուրաքանչյուր ցանցային կայքի համար առանձին CNAME մուտքագրում, կամ DNS գրանցումներում վայլդա (wildcard) (*) մուտք։

Ավելի շատ հաշվի առնելու ոլորտ է SSL-ի և SSL վկայականների տրամադրման ու օգտագործման համար։ subdirectory կոնֆիգուրացիայի դեպքում կարելի է օգտագործել մեկ դոմենային վկայական, քանի որ ցանցային կայքերը պարզապես հիմնական տիրույթի ուղիներ են։ Հետևաբար, domain.com-ի համար վկայականը բավարար SSL կտա https://domain.com/site1, https://domain.com/site2 և այլն-ի համար։

subdomain կոնֆիգուրացիայի դեպքում վայլդա SSL վկայականի օգտագործումը ամենատարածված տարբերակներից մեկն է։ Այս տեսակի SSL վկայականը ապահովում է կոդավորում (encryption) դոմենի և դրա subdomains-ի համար։ Հետևաբար, վայլդա SSL վկայականը կտա կոդավորում https://site1.domain.com, https://site2.domain.com և նույնիսկ https://domain.com-ի համար։

Չնայած գոյություն ունեն այլ տարբերակներ, դրանք հաճախ սահմանափակ են իրենց շրջանակներում և կիրառելիության մեջ, ինչպես նաև պահանջում են լրացուցիչ կոնֆիգուրացիա և համապատասխանության վերաբերյալ հաշվի առում։

Պլագիններ և թեմաներ (Plugins and Themes)

WordPress-ը տալիս է նույնպես բաներ, որոնք կարող են ձեռք բերվել՝ գոնե հաճախորդի տեսանկյունից։ Անկախ WordPress-ի կայքում, եթե կայքի ադմինիստրատորը տեղադրում է վատ պլագին կամ չի թարմացնում իր տեղադրումը, այս գործողության միակ զոհը և պատճառակետը նույնպես նա է։ Սակայն, եթե ադմինիստրատորը վատ պլագին է տեղադրում մուլտիսայտ կայքում, դա ստեղծում է ցանցի բոլոր կայքերի զոհ։

Այս պատճառով, երբ այն կազմաձևվում է որպես մուլտիսայթ WordPress, այն հեռացնում է սայթի ադմինների կարողությունը տեղադրել պլագիններ և թեմաներ, փոխարինելով այդ կարողությունը նոր ստեղծված ցանցային ադմինի կամ «սուպեր ադմին» դերին։ Այս հատուկ դերը կարող է որոշել, թե արդյոք թույլ տա ցանցային սայթերի ադմիններին տեսնել կամ մուտք գործել պլագինների մենյուին իրենց Dashboard-ում և եթե այո, թե արդյոք այդ թույլտվությունները տարածվում են պլագինները «ակտիվացնել» կամ «դեակտիվացնել»։

Այս չափով ցանցային ադմինը պատասխանատու է ցանցում պլագիններ և թեմաներ տեղադրելու համար և վերահանձնում է թույլտվությունները՝ այդ պլագիններն ու թեմաները օգտագործելու համար ցանցային սայթերի համար։ Սայթի ադմինները չեն կարող տեղադրել պլագիններ և թեմաներ կամ մուտք գործել իրենց սայթին չհատկացված պլագիններ և թեմաներ։

Օգտվողներ և ադմիններ (Users and Administrators)

WordPress Multisite-ում բոլոր ցանցային սայթերը կիսում են նույն տվյալների բազան, հետևաբար կիսում են նույն օգտվողները, դերերը և կարողությունները։ Ամենահարմար մտածելակերպը այն է, որ բոլոր օգտվողները ցանցի անդամներ են, այլ ոչ թե որևէ կոնկրետ սայթի։

Այս պատկերացման հիման վրա, օգտվողներ ստեղծելու թույլ տալը կարող է անցանկալի լինել, և դրա համար WordPress Multisite-ը այս կարողությունը հեռացնում է սայթի ադմիններիგან և փոխանցում այն ցանցային ադմինի վրա։ Փոխարենը, ցանցային ադմինը կարող է վերահանձնել անհրաժեշտ լիցենզավորումները սայթի ադմինի՝ թույլ տալու իրենք սեփական սայթի համար օգտվող հաշիվներ ստեղծել։

Վերընդրոշելով վերևում արված հայտարարությունը, թեև օգտվողները կարծես սայթի հետ կապված լինեն, իրականում դրանք հատկացված են ցանցին և հետևաբար պետք է եզակի լինեն ամբողջ ցանցում։ Հնարավոր է այնպիսի դեպքեր լինեն, երբ օգտվողների անունները հասանելի չեն գրանցման համար այս պատճառով։

Չնայած դա ընկերական հասկացություն է ձեռնադրում կորպորատիվ համակարգերում, այս մեկ միջոցով օգտատերերի գրանցումը և ինտենտիֆիկացիան (հաստատումը) հաճախ դժվար է հասկանալ նրանց համար, ովքեր ծանոթ են անկախ WordPress տեղադրություններին, որտեղ օգտատերերի վարչական գործողությունները մի փոքր ավելի հեշտ են։

Media (Մեդիա)

Երբ ցանցային կայքերը WordPress Multisite-ում ընդհանուր տվյալների բազայի օգտագործում են, դրանք պահպանում են տարբեր ուղիներ՝ էֆսիսիալ համակարգի վրա մեդիա ֆայլերի համար։

Սովորական WordPress-ի դիրքը (wp-content/uploads) մնում է նույնը. սակայն այն փոխվում է՝ կախված ցանցային կայքի եզակի ID-ից։ Հետևաբար, ցանցային կայքի մեդիա ֆայլերը հայտնվում են որպես wp-contents/uploads/site/[id]։

Permalinks (Հղումների կառուցվածք)

Մենք նախկին նշել էին, որ subdomain-ի փոխարեն subdirectory կոնֆիգուրացիան ունի առանձնահատուկ առավելություններ և այստեղ են դրանք. ուղիները։

Subdirectory կոնֆիգուրացիայում, հիմնական կայքը (առաջին կայքը, որը ստեղծվում է ցանցի ստեղծման ժամանակ) և ցանցային ենթակայքերը պետք է կիսեն նույն ուղին՝ տիրույթից առաջ։ Սա հնարավորություն է տալիս շատ բազմաթիվ հակասություններ առաջացնելու համար։

Հոդվածների համար, հիմնական կայքում ավելացվում է պարտադիր /blog/ ուղին՝ ցանցային կայքերի հետ բախումներից խուսափելու համար։ Սա նշանակում է, որ «Հոդվածի անուն» նման գեղեցիկ permalink-երը կներկայացվեն որպես domain.name/blog/post-name/։

Subdomain կոնֆիգուրացիայում այս գործողությունը անհրաժեշտ չէ, քանի որ յուրաքանչյուր ցանցային կայք օգුajeանում է ամբողջ տիրույթի առանձնացումից և հետևաբար կարիք չունի հենվել մեկ ուղու վրա։ Նրանք փոխարեն պահպանում են իրենց յուրօրինակ ուղիները՝ հիմնված իրենց subdomain-ի վրա։

Static Pages (Սථատ էջեր)

subdirectory կոնֆիգուրացիայում անունների բախման հնարավորությունը ընդլայնվում է ստատիկ էջերի համար՝ որպես հիմնական կայք և ցանցային կայքերը օգտագործում են նույն ուղին։

Սա կանխելու համար WordPress-ը տրամադրում է մի մեխանիզմ, որով կարելի է անվանումների բացառություն (blacklist) սահմանել այնպես, որ դրանք չբախվեն առաջին կայքի անուններին։ Սովորաբար ցանցային ադմինիստրատորը մուտքագրում է հիմնական կայքի էջերի արմատային ուղիները։

subdomain կոնֆիգուրացիայի դեպքում անունների բախման հնարավորությունը մեղմվում է subdomain-ի շնորհիվ, քանի որ այն եզակի է ցանցային կայքի համար և ոչ մի կերպ կապված չէ հիմնական կայքի հետ։

Գրանցում (Registration)

WordPress Multisite-ի ցանցային կարգավորումներում առկա են նոր օգտվող գրանցման տարբերակներ, որոնք թույլ են տալիս նոր և գոյություն ունեցող օգտվողներին ստեղծել կայքեր։

Կենտրոնացած մեկ կայքում առանձին WordPress ներդրումների (stand-alone installations) հակառակը, ցանցային կայքերը չեն պահպանում այն հարմար գործիքները՝ օգտվողներ գրանցելու կամ այդ գրանցումները դասավորելու համար։

Երբ ստեղծվում են օգտվող հաշիվներ, այդ հաշիվները ստեղծվում են ցանցային մակարդակում։ Հետևաբար, դրանք որևէ կոնկրետ կայքին պատկանում չեն, այլ պատկանում են ամբողջ ցանցին։ Սա մի քանի առանձնահատուկ առավելություններ և թերություններ է ունի։

Օրինակ՝ ենթադրենք, ձեր WordPress Multisite-ը նորություններ և տեղեկատվական բնագավառում է։ Դուք կստեղծեք այս multisite-ը, ապա ֆինանսների, տեխնոլոգիաների, զվարճանքի և այլ հետաքրքրող ոլորտների համար ցանցային կայքեր (network sites) ստեղծեք՝ միևնույն ժամանակ պահպանելով ընդհանուր վերահսկողությունը plugin-ների և theme-երի վրա։ Յուրաքանչյուր ցանցային կայքում, հակառակ դեպքին custom post types-ի կամ սովորական գրառումների կատեգորիաների համեմատ, ավելի մեծ վերահսկողություն կունենա իր ցանցային կայքի տեսքի և օգտվողի փորձի վրա։

Այս չափով, երբ օգտվողը մուտք է գործում, նա մուտք է գործում ցանց և վերջնականապես մուտք է գործում բոլոր ցանցային կայքերը՝ անխափան փորձի համար։ Եթե ձեր նոր կայքը լիներ բաժանարար (subscription based), սա կլիներ օրդիդալ լուծումն ու արդյունքը։

Սակայն, եթե multisite-ի նախատեսված բնույթը և նպատակը առաջարկել այն ցանցային կայքերը, որոնք միմյանց հետ ոչ մի կապ չունեն, ապա գրեթե միշտ անհրաժեշտ է օգտագործել արտաքին կամ լրացուցիչ plugin-ներ՝ օգտվողների դերերը փոխելու համար։

Դոմեն և SSL

Եկեք խոսենք WordPress Multisite-ի տեղադրումից, որը գրեթե մեր ուշադրությունը չի գրավում՝ Wordpress.com-ի մասին։ Սա WordPress multisite-ի ամենամեծ օրինակն է և ցույց է տալիս դրա լայն հնարավորությունները, որոնք կարելի է հարմարեցնել և ձևավորել նպատակի բավարարման համար։

Այսօր մոդերն կայքում SSL-ի օգտագործումը գրեթե պարտադիր է, և WordPress multisite-ների адሚնիստրատորները շուտով դիմում են այս խնդիրներին։

subdomain կոնֆիգուրացիայում կայքերը ստեղծվում են արմատային տիրույթի (root domain name) հիման վրա։ Հետևաբար, «site1»-ի համար անվանված կայքը կստեղծվի որպես «site1.domain.com»։ Wildcard SSL վկայական օգտագործելով, ցանցային ադմինիստրատորը կարող է հաջողությամբ լուծել այս խնդիրը և ապահովել SSL-ի կոդավորման հնարավորությունները ցանցի համար։

WordPress Multisite-ը պարունակում է տիրույթի քարտեզագրման (domain mapping) ֆունկցիա, որը թույլ է տալիս ցանցային կայքերը կապել հատուկ ադմիներային անունների հետ կամ այն անունների հետ, որոնք տարբերվում են ցանցի հիմնական տիրույթից։

Ցանցային ադմիների համար դա լրացուցիչ բարդություն է ներկայացնում ինչպես տիրույթի անունների կազմակերպման, այնպես էլ SSL վկայագրերի տրամադրման և պահպանման հարցերում։

Այս չափով, թեև WordPress Multisite-ը թույլ է տալիս www.anotherdomain.com-ը կապել «site1»-ի հետ, ցանցային ադմիները մնում են դժվարության մեջ՝ DNS գրանցումները արտաքին կերպով կառավարելու և SSL վկայագրերի իրականացման հարցում։

Ultimate Multisite

Եթե հասկանում եք առանձին WordPress ինստալացիայի և Multisite-ի տարբերությունները, եկեք դիտարկենք, թե ինչպես է Ultimate Multisite-ը կայքերը որպես ծառայություն (Website as a Service - WaaS) տրամադրելու համար գլխավոր զինատեղը։

Ներածություն

Ultimate Multisite-ը ձեր «Սվիսական արկղի»ն է՝ կայք որպես ծառայություն (WaaS) ստեղծելու հարցում։ Մտածեք Wix.com, Squarespace, WordPress.com-ի մասին և հետո մտածեք ձեր սեփական ծառայությունը սեփական անունով սեփականացնելու մասին։

Ներքին կառուցվածքում Ultimate Multisite-ը օգտագործում է WordPress Multisite-ը, բայց այն դա այնպես է անում, որ ոչ միայն լուծում է ցանցային ադմիների առջև ծայրահեղ խնդիրները multisite ինստալացիաների հետ, այլև ընդլայնում է հնարավորությունները՝ թույլ տալով աջակցել լայն տեսականությամբ օգտագործման դեպքեր։

Հաջորդ բաժիններում մենք կքննարկենք ընդհանուր օգտագործման դեպքերը և այդ դեպքերը աջակցելու համար անհրաժեշտ հաշվի առնելու պահանջները։

Օգտագործման դեպքեր (Use Cases)

Դեպք 1. Գործակալություն (An Agency)

Տարբերաբար, գործակալության հիմնական հմտությունները կայանում են կայքերի դիզայնում՝ ներառելով այնպիսի բաղադրիչներ, ինչպես ծառայության տեղադրումը կամ մարքեթինգի լիցքավորումը որպես լրացուցիչ ծառայություններ։

Գործակալությունների համար Ultimate Multisite-ը հրաշալի արժեք է առաջարկում՝ թույլ տալով միաժամանակ հյուրընկալել և կառավարել բազմաթիվ වෙබ්անայեր մեկ պլատֆորմի վրա։ Ավելին, այն գործակալությունների համար, որոնք ստանդարտացնում են իրենց դիզայնը որոշակի թեմաներով (օրինակ՝ GeneratePress, Astra, OceanWP կամ այլ), Ultimate Multisite-ի հնարավորություններով կարող են ավտոմատ կերպով ակտիվացնել այդ թեմաները յուրաքանչյուր նոր սայթի համար։

Նույնը վերաբերում է գործակալությունների գնային առաջարկներին՝ հայտնի և պոպուլյար plugin-երի համար. Ultimate Multisite-ի օգտագործումը թույլ է տալիս գործակալություններին օգտվել առկա ներդրումներից՝ ապահովելով ընդհանուր պլատֆորմ, որտեղ կարելի է տեղադրել, պահպանել և օգտագործել plugin-երը։

Ամենայն հավանականությամբ, կցուցումը (configuration) ցանկալի է, և բարի լույսով Ultimate Multisite-ը դարձնում է տիրապետող ադմինային գործողությունները՝ ծածկագրելու โดменներ (domain mapping) և SSL վկայականներ (SSL certificates), ինչպես նաև հ Popular hosting providers-ի համար Cloudflare և cPanel වැනි ծառայությունների հետ իր ինտեգրացիաներով։

Այսպիսով, մեկ այս պրովայդերից օգտվելով կամ Ultimate Multisite-ը տեղադրելով Cloudflare-ի հետ՝ ապահովելով โดเมնների և SSL վկայականների կառավարումը որոշ բան է դառնում շատ պարզ։

Այն գործակալությունները, ովքեր նախընտրում են խիստ վերահսկողություն սահմանել սայթերի ստեղծման վրա, կգնահատեն այն հեշտությունը, որով կարող են ստեղծել սայթեր և գործակալական պլաներ (plans) կապել դրանք հաճախորդների հետ Ultimate Multisite-ի մաքրված ինտերֆեյսի միջոցով։

Plugin-երի և թեմաների վրա խիստ վերահսկողություն է պահվում յուրաքանչյուր արտադրանքի համար Ultimate Multisite-ի ինտուիտիվ ինտերֆեյսների միջոցով, որոնք թույլ են տալիս plugin-երը և թեմաները հասանելի դարձնել կամ թաքցնել, ինչպես նաև դրանց ակտիվացման վիճակը՝ նոր սայթի համար ինստանցիացվելիս։

Թեմաները նույն տեսակի ֆունկցիոնալություն են ապահովում, ինչը թույլ է տալիս կայքի ստեղծման ժամանակ ընտրել որոշակի թեման՝ ակտիվացնել կամ թաքցնել։

Աгентները Ultimate Multisite-ի շնորհիվ կստանան հանգիստ, քանի որ այն թույլ է տալիս իրենց ամենաուժեղ բանը անել՝ եզակի վեբ սայթեր դիզայնել։

Դեպք 2. Խոսնակցական մատակարար (Niche Provider)

Գոյություն ունի հին արտահայտություն, որը ասում է՝ «մեկ բան անիր և այն լավ անիր»։ Շատ մասնագետների համար դա նշանակում է մեկ հիմնական գաղափարի շուրջ ապրանք կամ ծառայություն ստեղծել։

Հնարավոր է, դուք լինեք ջերմ գոլֆբոլիստ՝ կլուբերի համար վեբ սայթեր առաջարկող, կամ հոգատար էսպորտային խաղացող՝ կլաների համար վեբ սայթեր տրամադրող։ Գու, դուք անհատ եք, որը բուքինգի ծառայություն առաջարկում եք ռեստորանների համար։

Շատ պատճառներով ցանկանում եք ապահովել ծառայություններ ընդունված շրջանակի և պլատֆորմի հիման վրա։ Հնարավոր է, որ դուք սեփական բոլոր անհրաժեշտ ֆունկցիոնալությունը տրամադրելու համար նախագծել եք կամ ներդրում կուտակել եք հատուկ plugin-ների մեջ, կամ կարող է լինի այն դեպքը, երբ արդյունաբերական լավագույն փորձերը պահանջում են դիզայնի որոշակի ստանդարտ մոտեցում։

Ultimate Multisite-ի նորարար հատկություններից մեկը տեխլատեր (template sites) օգտագործելն է։ Տեխլատեր կայքը այն կայքն է, որտեղ թեման արդեն տեղադրված և ակտիվացված է, անհրաժեշտ plugin-ները տեղադրված և ակտիվացված են, ինչպես նաև սэмպլական հոդվածներ կամ էջեր են ստեղծված։ Երբ հաճախորդը ստեղծում է նոր կայք տեխլատերի հիման վրա, թեմանի բովանդակությունը և կարգավորումները պատճենվում են նոր ստեղծված կայքում։

Սա ոչ միայն եզակի կայքեր և ծառայություններ մատուցողների համար աննախադեպ առավելություն է՝ թույլ տալով անմիջապես պատրաստ լինի կայք ստեղծել՝ հատուկ plugin-ներով և դիզայնով։ Հաճախորդը պարզապես պետք է տա ամենաքիչ մուտքային տվյալները՝ ծառայությունը ավարտելու համար։

Ըստ պահանջների՝ կարող լինել և՛ subdirectory կոնֆիգուրացիա, և՛ subdomain կոնֆիգուրացիա, որ դեպքում ճարտարապետական ընտրությունը կլինի պարզ SSL վկայագիր՝ subdirectories համար կամ վայագրերով (wildcard) SSL վկայագիր՝ subdomains համար։

3-րդ դեպք. WordPress වෙබ් հոստինգ

WordPress սайտեր հոստինգելու մի շարք տարբերակներ կան, բայց հազվադեպ է այն պարզ լինում՝ մատուցելով հաճախորդին WordPress-ի նախապես տեղադրված տարբերակը։ Սա այն պատճառով է, որ իմաստալից ծառայություն մատուցելու համար անհրաժեշտ է մի շարք որոշումներ և հաշվի առումներ համատեղել։

Ultimate Multisite-ը գերազանցում է այս ոլորտում՝ WordPress սайտերը հոստինգելու համար ամբողջական պատրաստի լուծում առաջարկելով։ Լուծման մեջ ներառված են բաժանարար ծառայությունների, վճարումների հավաքագրման, գնումների ձևաչափերի, զեղչային վաճառքի կոդերի և հաճախորդի հետ շփման համար անհրաժեշտ բոլոր հիմնական մեխանիզմները։

WordPress Multisite-ը ճիշտ տեղադրելու, կոնֆիգուրացնելու և պահպանելու համար անհրաժեշտ մեծ մասամբ կարևոր աշխատանքը հեշտանում է Ultimate Multisite-ի միջոցով այնքան, որ ցանցային ադմինիստրատորները պետք է հաշվի առնեն միայն այն կողմերը, որոնք վերաբերում են իրենց ծառայությանը կամ ոլորտին՝ օրինակ՝ արտադրանքի տիրույթներին, գնանշման և ծառայությունների առաջարկներին։

Ultimate Multisite-ի հետ ինտեգրվելուց ուզող մշակողների համար լուծումը նաև առաջարկում է ամբողջական RESTful API և Webhooks իրադարձությունների ծանուցման համար։

Արտաքին պլագիններից և լիցենզիաներից կախված չլինելով, Ultimate Multisite-ը առաջարկում է հնարավորություններով հարուստ և համեմատելի լուծում՝ Wix-, Squarespace-ի և WordPress.com-ի հետ։

Ճարտարապետական հաշվի առնելու հարցեր

Չնայած այն ամբողջական ուղեցույց չէ, հետևյալ կետերը պետք է օգնեն ճիշտ տեխնոլոգիաների ընտրության մեջ՝ Ultimate Multisite-ի տեղադրումը աջակցելու համար։

Ընդհանուր (Shared) vs. Տվյալների բաժանված (Dedicated) հոստինգ

Ցավոք, բոլոր հոස්թինգի պրովայդերները նույն չեն և որոշները գործում են շատ բարձր սերվերի խտությամբ։ Ցածր արժեքով պրովայդերը սովորաբար եկամուտներ են ստանում սերվերի խտությունը առավելագույնի հասցնելով։ Հետևաբար, ձեր Ultimate Multisite տեղադրումը կարող է միայն մեկ լինել մի քանի հարյուր կայքերից նույն սերվերի վրա։

Պրովայդରից համապատասխան պաշտպանական միջոցներ չկան, կիսված սերվերի վրա գտնվող կայքերը ենթարկվում են «աղմուկոտ հարևան» խնդրին։ Դա նշանակում է, որ նույն սերվերի վրա գտնվող մի կայքը այնքան ռեսուրսներ է օգտագործում, որ մյուս կայքերը պետք է մրցեն մնացած ռեսուրսների համար։ Հաճախ դա իրեն հայտնաբերում է որպես դանդաղ կամ ժամանակին պատասխան չచ్చే կայքեր։

Ինչպես վեբ հոස්թինգի պրովայդեր ինքներդ, ներդրված գործընթացը նշանակում է, որ ձեր հաճախորդները փորձում են ցածր արագություն, ցածր էջների կարգավորում և բարձր կոտրման (bounce rate) տոկոսներ, ինչը հաճախ հանգեցնում է հաճախորդների մեկ այլ վայրում ծառայություններ փնտրելու պատճառով հաճախորդների անհրաժեշտության։

Կարճ ասած, ցածրը նշանակում չէ լավը։

Ultimate Multisite-ը հայտնի է որպես աշխատող մի շարք լավ հոස්թինգի պրովայդեր հետ և լավ է ինտեգրվում դրանց միջավայրի հետ՝ տրամադրելով այնպիսի ֆունկցիաներ, ինչպես ատենքային քարտեզագրումը (domain mapping) և ավտոմատ SSL-ը։ Այս պրովայդերը գնահատում են արագությունը և տրամադրում են բաժանված հոස්թինգից ավելի բարձր մակարդակի ծառայություն։

Համապատասխան պրովայդերի ցուցակների և յուրաքանչյուրի համար ամբողջական սահմանման ինստրուկցիաների համար խնդրում ենք ստուգել Compatible Providers-ի փաստաթղթերը։

Արագության հաշվի առնելը (Performance Considerations)

Ultimate Multisite-ը դանդաղ կիրառություն չէ, այլ շատ արագ է։ Սակայն այն աշխատում է միայն ներքին կիրառման և ենթակառուցվածքի լավագույն մակարդակով և կարող է օգտվել միայն այն բաներից, որոնց հասանելի է։

Դիտարկեք հետևյալը. Դուք Ultimate Multisite տեղադրման ցանցային վարչություն եք՝ 100 կայքով։ Այդ կայքերի մի քանիսը լավ են աշխատում և ամեն օր գրեթե բազմաթիվ կայքերի այցելուներ են գրավում։

Սա տարբեր կլինի փոքր մասշտաբով՝ օրինակ մեկից հինգ սայթերի համար, բայց մեծ մասշտաբի խնդիրները շուտով կհայտնվեն։

Եթե չկանգնեցվի ուշադրություն, մեկ Ultimate Multisite սայթը պատասխանատու է բոլոր այցելուների հարցում աշխատանքներ կատարելու համար։ Այս հարցերը կարող են լինել դինամիկ PHP էջերի կամ ստատիկ ռեսուրսների՝ սթայլշեետների, JavaScript-ի կամ մեդիա ֆայլերի տեսքով։ Անկախ նրանից՝ մեկ սայթ լինի թե հարյուր, այս առաջադրանքները դառնում են կրկնվող, մշտական և անպետք։ PHP ֆայլը մշակելու համար CPU-ի ու հիշողության օգտագործումը անհրաժեշտ չէ, եթե արդյունքը բոլոր հարցում նույն ստատիկ տեղեկություն է։

Նույն կերպ, PHP կամ HTML էջի մեկ հարցը ինքնաբերաբար ստեղծում է մի քանի հետևող հարցեր՝ սկրիպտների, սթայլշեետների և պատկերային ֆայլերի համար։ Այս հարցերը ուղղված են ուղղակի ձեր Ultimate Multisite սերվերին։

Այս խնդիրը կարելի է հեշտությամբ լուծել սերվերը թարմացնելով, բայց դա երկրորդ խնդիր չի լուծում՝ աշխարհագրական հետաձգումները (geographic latencies)։ Միայն մի քանի սերվերներ տարբեր վայրերում կարող են պատշաճ կերպով հաղթահարել այս խնդիրը։

Այս պատճառով շատ ցանցային ադմինիստրատորները օգտագործում են առաջին էջի քեշավորման լուծումներ (front-end caching solutions) և բովանդակության բաշխման ցանցեր (CDN), որպեսզի կատարվեն ստատիկ էջերի հարցերը։ Այս հարցերը բավարարելը և ռեսուրսները սերվերին հասնելուց առաջ ռեսուրսներով տրամադրելը խնայում է մշակման ռեսուրսները, վերացնում է ուշացումները, խուսափում է անհրաժեշտ թարմացումներից և առավելագույնի հասցնում տեխնոլոգիական ներդրումները։

Ultimate Multisite-ը ներառում է բարդ Cloudflare add-on, որը թույլ է աշխատողներին կարողանում է իրենց ինստալացիան դնել Cloudflare-ի հետևում և օգտվելու ոչ միայն նրա քեշավորման հնարավորություններից, այլև DNS հոස්տինգից, SSL վկայագրերից և անվտանգության մեխանիզմներից։

Պահպանումներ (Backups)

Մեկը կարող է 50 մարդկանց խորհրդատվություն ուղղել պահպանման մասին և ստանալ 50 տարբեր կարծիքներ՝ պահպանման ռազմավարություններով։ պատասխանը հետևյալն է. դա կախված է իրավիճակից։

Ինչը չի վեճառվում, այն է, որ անհրաժեշտ է ապահովել բուկինգներ (backups) և գրեթե անհասկանելի է, որ դրանք չեն կառավարվում մատակարարի կողմից, հատկապես այն մատակարարի, ով առաջարկում է կառավարված ծառայություն (managed service)։ Հետևաբար, հաճախորդները կհամոզվեն ցանցային ադմինիստրատորից՝ այս ծառայությունը տրամադրելու և կառավարելու համար։ Ո՞ւմ է դիմում ցանցային ադմինիստրատորի, դա ամբողջապես այլ խնդիր է։

Այս բաժնի նպատակով եկեք համաձայնենք, որ բուկինգը (backup) սերտացված վիճակի պատկերն է՝ համակարգի վիճակի պատկերը այն պահին, երբ սկսվել է բուկինգը։ Պարզ ասած, ինչպես է համակարգի վիճակը բուկինգի ժամանակ, այդ վիճակը կերպով փաթempվում և ամրագրվում է բուկինգում։

Այս պատկերացմամբ, թե ինչպես իրականացնել բուկինգները և ինչն է լավագույն ձևը ձեր միջավայրի համար կկախված կլինի ձեր պահանջներից և հոස්տինգային մատակարարի կարողությունից այդ պահանջները բավարարելու։ Սակայն, ամենամեծ կարծիքով ունեցածից ամենաքիչ կարծիքով ըստ առաջադրության, ներկայացված տարբերակները պետք է որոշակի ուղեցույց տան։

Սնոպշոտներ (Snapshots)

Սնոպշոտները բուկինգների համար «սիլվեր գլուխ» են, քանի որ դրանք հեշտ են, չեն բարդացնում (մինչև վերականգնելը) և «աշխատում են»։ Սակայն, դրան պահանջում է ձեր մատակարարի օգնություն և գործում է հիմնականում միայն այն դեպքում, եթե ունեք VPS (Virtual Private Server) կամ նման համակարգ։ Մեր «Համապատասխանող Մատակարարներ» (Compatible Providers) փաստաթղթում թվարկված մի քանի մատակարարներ առաջարկում են բուկինգներ, որոնք չեն պահանջում ցանցային ադմինիստրատորի և այլ անձի հետ լրացուցիչ միջամտություն կամ հաշվի առում։

पारंपरिक બેકઅપ્સ ફાઇલો અને ડેટાબેઝને લક્ષ્ય બનાવે છે, જ્યારે સ્નેપશોટ આખા ડિસ્કને લક્ષ્ય બનાવે છે. આનો અર્થ એ છે કે માત્ર સાઇટના ડેટા જ સ્નેપશોટમાં કેપ્ચર થાય છે, પરંતુ ઓપરેટિંગ સિસ્ટમ અને કન્ફિગરેશન પણ થાય છે. ઘણા લોકો માટે આ એક અલગ ફાયદો છે કારણ કે સ્નેપશોટમાંથી લગભગ તરત જ એક નવો સિસ્ટમ શરૂ કરી શકાય છે અને તેને ખરાબ ચાલી રહેલા ઇન્સ્ટન્સને બદલવા માટે ઓપરેશનમાં લાવી શકાય છે. તેવી જ રીતે, ફાઇલો પુનઃપ્રાપ્ત કરવા માટેની પુનઃપ્રાપ્તિ પ્રક્રિયામાં ફક્ત સ્નેપશોટ ઇમેજને ડિસ્ક તરીકે હાલના ઇન્સ્ટન્સ સાથે જોડીને ફાઇલોને ઍક્સેસ અને કોપી કરી શકાય છે.

હોસ્ટિંગ પ્રોવાઇડર સાથે સ્નેપશોટ્સનો વધારાનો ખર્ચ થઈ શકે છે, પરંતુ તે અકસ્માતો સામે એક વીમા પોલિસી છે.

બાહ્ય સ્ક્રિપ્ટ્સ (External Scripts)

વર્ડપ્રેસ અને MySQL સંસાધનોનું બેકઅપ લેવા માટે બાહ્ય સ્ક્રિપ્ટ્સ અને સોલ્યુશન્સની કોઈ ખામી નથી, અને આ Ultimate Multisite માટે ખૂબ જ કામ કરશે કારણ કે તે WordPress ફાઇલ સિસ્ટમ અને ડેટાબેઝનો ઉપયોગ કરતું એક WordPress plugin છે. આમ, જે સાઇટ્સનું બેકઅપ લેવા માટે એક સોલ્યુશન હોય તે Ultimate Multisiteની જરૂરિયાતોને સંતોષશે.

આપણે એક સ્ક્રિપ્ટને બીજા પર ભલામણ કરી શકતા નથી, પરંતુ અમારી સામાન્ય સલાહ એ છે કે પરિણામો ઇચ્છિત છે તેની ખાતરી કરવા માટે ઘણા બેકઅપ અને પુનઃપ્રાપ્તિ પરીક્ષણો ચલાવવા જોઈએ અને ખાસ કરીને જ્યાં કોઈ પ્રકારની ડિફરન્શિયલ બેકઅપ વ્યૂહરચના લાગુ કરવામાં આવે ત્યાં સ્ક્રિપ્ટ અને તેની કાર્યક્ષમતાનું સતત મૂલ્યાંકન કરીને 'ખાતરી કરો કે તમે ખાતરી કરો છો'.

એ નોંધવું જોઈએ કે આ સ્ક્રિપ્ટ્સ ચાલતી વખતે સિસ્ટમ લોડ વધારશે, જેનો ધ્યાનમાં લેવો જોઈએ.

પ્લગઇન્સ (Plugins)

વર્ડપ્રેસમાં લગભગ કોઈ એવી સમસ્યા નથી જે plugin દ્વારા ઉકેલી ન શકાય, અને જો બાહ્ય સ્ક્રિપ્ટ્સનું સંચાલન તમારી શક્તિમાં ન હોય, તો કદાચ plugin શ્રેષ્ઠ વિકલ્પ છે.

Plugins տարբեր գործողություններով և հնարավորություններով են, բայց դրանք հիմնականում կատարում են նույն ֆունկցիան՝ WordPress-ի ֆայլերի և տվյալների բազայի պատճենում։ Այսուհետ ֆունկցիոնալությունները տարբերվում են. որոշ պլագիններ կարող են անցկացնել բեխարները արտաքին ծառայություններ, ինչպիսիք են Google Drive-ը կամ Dropbox-ը, կամ այլ համատեղելի օբյեկտային պահպանման ծառայություններ, ինչպիսիք են S3-ը, Wasabi-ն կամ մյուսները։ Ավելի համապարփակ պլագինները առաջարկում են տարբերական բեխարներ (differential backups) կամ որոշակի ռազմավարություն՝ արտաքին պահեստավորման ծախսերը խնայելու համար միայն փոփոխված տվյալները պահպանելու համար։

Ձեր պլագինը ընտրելիս ուշադրություն դարձրեք, որ այն multisite-ի հետ համատեղելի է (multisite aware) արդյոք։ Քանի որ գործողության ընթացքում բեխարը կատարվում է, կարող եք սպասել սերվերի ժամանակավոր բեռի այնքան ժամանակ, մինչև գործընթացը ավարտվի։

Դոմեն և SSL

Շատ բան արդեն քննարկվել է multisite subdomain ռեժիմով դոմենների մասին։ Ցանցային ադմինիստրատորների համար գրեթե համընդհանուր լուծումը Wildcard DNS մուտքեր օգտագործելն է։

Այս տեսակի DNS մուտքը հաջողությամբ կհայտնի են subdomains-ին, ինչպիսիք են ‘site1.domain.com’ և ‘site2.domain.com’, 1.2.3.4 IP հասցեին՝ աջակցելով Ultimate Multisite-ին և ավելի մեծ չափով WordPress Multisite-ին subdomain_ռեժիմով։

Սա կարող լիովին աշխատել HTTP-ի համար, քանի որ թիրախային հոස්տը կարդացվում է HTTP հեդերներից, բայց այսօր ինտերնետում դրա համար շատ հազվադեպ է լինում՝ վեբը այդքան պարզ, որ HTTPS-ի անվտանգ գործարքները գրեթե անհրաժեշտ են։

Վերջապես, SSL վկայագրերի համար հեշտ տարբերակներ կան։ _subdirectory_ ռեժիմում կարելի է օգտագործել սովորական տիրույթի վկայագիր։ Այս վկայագրերը հեշտությամբ և անվճար են հասանելի хостинг պրովայդերից, որոնք կարող են օգտագործել უფასորդ LetsEncrypt ծառայությունը կամ այլ աղբյուր։ Հակառակ դեպքում դրանք առևտրային տեսքով հասանելի են մոտարմիններից, եթե կարողանում եք ստեղծել վկայագրի նշման խնդրի (certificate signing request)։

_subdomain_ ռեժիմում կլուիդոսի (wildcard) SSL վկայագրի օգտագործումը կհամապատասխանի կլուիդոսի տիրույթին և թույլ կտա վկայագրին լինել ավետող՝ արմատային տիրույթի համար և բոլոր _subdomains_ համար առանց անհրաժեշտ կարգավորումների։

Սակայն, պետք է նշել, որ կլուիդոսի SSL վկայագրերը չեն կարող աշխատել Cloudflare-ի հետ այնպիսի ծառայությունների հետ, ինչպես օրինակ՝ եթե դուք ընկերության պլանով չեք, կամ եթե մուտքը DNS-ի միայն որպես «proxied» (միջնորդված) սահմանեք, այս դեպքում բոլոր քեշավորումները և օպտիմալացումները անտեսվում են։

Out-of-the-box Ultimate Multisite-ը լուծում է այս խնդիրը՝ ցույց տալով մեր փորձը WordPress multisites-ի կարիքների հետ։ Այս պարզ add-on-ը ակտիվացնելիս Ultimate Multisite-ը կօգտագործի ձեր Cloudflare-ի հավաստագրումները՝ Cloudflare-ում ցանցային սайտերի համար DNS մուտքեր ավտոմատորեն ավելացնելու և դրանց ռեժիմը «proxied» (միջնորդված) սահմանելու համար։ Այսպես, ցանցային ենթասայթը ստեղծվող պահին կունենա Cloudflare-ի ամբողջ պաշտպանությունը և օգուտները, ներառյալ SSL-ը։

Ձեր Ultimate Multisite-ի տեղադրման բնույթի և նպատակի համաձայն կարող է անհրաժեշտ լինել հաճախորդների համար իրենց սեփական տիրույթները օգտագործել։ Այս դեպքում ցանցային ադմինիստրատորը պատասխանատու է երկու խնդրի լուծման համար. մեկը՝ տիրույթի անունը հոස්ելը և երկրորդը՝ այդ տիրույթի համար SSL վկայագրերը։

Շատերի համար Cloudflare-ի օգտագործումը հեշտ տարբերակ է։ Հաճախորդին բավական է իր ադոմենը տեղադրել Cloudflare-ում, CNAME-ը ուղղել Ultimate Multisite-ի արմատային ադոմենին և Ultimate Multisite-ում իր ադոմենը քարտեզագրել՝ սկսելու համար օգտվելու իր կոնստյումային ադոմենից։

Դրանից դուրս, անհրաժեշտ է փնտրել այլընտրանքային լուծումներ, ինչն է պատճառով, որ Ultimate Multisite-ը խորհուրդ է տալիս հայտնի Կ համատեղելի մատակարարների (Compatible Providers) ցանկ։ Սա այն պատճառով է, որ DNS և SSL-ի կարգավորման գործընթացը կարող է բարդ լինել։ Սակայն Ultimate Multisite-ի հետ այդ մատակարարների համատեղելիության շնորհիվ բարդությունը զգալի կերպով նվազում է, և ընթացակարգը ավտոմատացվում է։

Plugins (Պլագիններ)

Շատ հավանական է, որ ձեր հաճախորդների կամ ցանցային սайտերի համար անհրաժեշտ լինի լրացուցիչ պլագիններ՝ ֆունկցիոնալություն տրամադրելու համար։ Արդյո՞ք բոլորը 작동ում են WordPress Multisite-ի և Ultimate Multisite-ի հետ։ Դա կախված է դրանից։

Թեև շատ պլագինները կարելի է տեղադրել WordPress Multisite-ում, դրանց ակտիվացումը և լիցենզավորումը տարբերվում են մեկ մշակողից մյուսին։

Խնդիրը այն է, թե ինչպես է կիրառվում լիցենզավորումը որոշ պլագինների դեպքում, որոնք պահանջում են լիցենզավորում ադոմենի առանձին հիմի վրա։ Սա նշանակում է, որ որոշ պլագինների համար ցանցային ադմինիստրատորը պետք է ձեռքով ակտիվացնի լիցենզիան յուրաքանչյուր սайտի և յուրաքանչյուր նոր սайտի համար։

Հետևաբար, ամենահավանականը այն է, որ լավ կլինի ստուգել պլագինի մշակողի հետ, թե ինչպես է իր պլագինը աշխատում WordPress Multisite-ի հետ և արդյոք անհրաժեշտ հատուկ պահանջներ կամ ընթացակարգեր կան լիցենզավորման համար։