എന്താണ് WordPress Multisite?
WordPress-ന്റെ കോർ ഫീച്ചറുകളിൽ ഒന്നായ 'Multisite' 2010-ൽ WordPress 3.0-ന്റെ ലോഞ്ചിങ്ങോടെയാണ് ആരംഭിച്ചത്. അതിനുശേഷം പുതിയ ഫീച്ചറുകൾ ചേർക്കുന്നതിനും സെക്യൂരിറ്റി മെച്ചപ്പെടുത്തുന്നതിനുമായി നിരവധി അപ്ഡേറ്റുകൾ ഇതിന് ലഭിച്ചിട്ടുണ്ട്.
ലളിതമായി പറഞ്ഞാൽ, WordPress multisite ഇങ്ങനെ മനസ്സിലാക്കാം: ഒരു യൂണിവേഴ്സിറ്റി ഒരൊറ്റ WordPress ഇൻസ്റ്റാളേഷൻ മാത്രം മെയിന്റെയ്ൻ ചെയ്യുന്നു, എന്നാൽ ഓരോ ഫാക്കൽറ്റിയും അവരുടേതായ WordPress സൈറ്റ് നിലനിർത്തുന്നു.
എന്താണ് WordPress Multisite കൃത്യമായി?
ഒരൊറ്റ WordPress ഇൻസ്റ്റാളേഷനിൽ ഒന്നിലധികം സൈറ്റുകൾ ഷെയർ ചെയ്യാൻ അനുവദിക്കുന്ന WordPress-ന്റെ ഒരു ഫീച്ചറാണ് Multisite. Multisite ആക്ടിവേറ്റ് ചെയ്യുമ്പോൾ, ഒറിജിനൽ WordPress സൈറ്റ് സൈറ്റുകളുടെ നെറ്റ്വർക്ക് എന്ന് വിളിക്കുന്ന രൂപത്തിലേക്ക് മാറുന്നു.
ഈ നെറ്റ്വർക്ക് ഫയൽ സിസ്റ്റം (plugins-ഉം themes-ഉം ഷെയർ ചെയ്യുന്നു എന്നർത്ഥം), ഡാറ്റാബേസ്, WordPress കോർ ഫയലുകൾ, wp-config.php തുടങ്ങിയവ പങ്കിടുന്നു.
ഇതിനർത്ഥം WordPress, theme, plugin അപ്ഡേറ്റുകൾ നിങ്ങളുടെ എല്ലാ നെറ്റ്വർക്ക് സൈറ്റുകൾക്കും ഒരു തവണ മാത്രം ചെയ്താൽ മതി, കാരണം അവയെല്ലാം ഫയൽസിസ്റ്റത്തിൽ ഒരേ ഫയലുകൾ ഷെയർ ചെയ്യുന്നു.
ഇതാണ് multisite-ന്റെ പ്രധാന ഗുണങ്ങളിലൊന്ന്, കാരണം നിങ്ങളുടെ കസ്റ്റമേഴ്സിന്റെ സൈറ്റുകൾ മെയിന്റെയ്ൻ ചെയ്യാൻ വേണ്ട ജോലികളുടെ എണ്ണം അതേപടി നിലനിർത്തിക്കൊണ്ട് തന്നെ നിങ്ങൾ മാനേജ് ചെയ്യുന്ന സൈറ്റുകളുടെ എണ്ണം വർദ്ധിപ്പിക്കാൻ ഇത് സഹായിക്കുന്നു.
Subdomain അല്ലെങ്കിൽ Subdirectory?
WordPress multisite റൺ ചെയ്യുന്നതിന് രണ്ട് മോഡുകളുണ്ട് – നിങ്ങളുടെ സാധാരണ WordPress ഇൻസ്റ്റാളേഷനെ multisite ഇൻസ്റ്റാളേഷനാക്കി മാറ്റുമ്പോൾ ഇവയിലൊന്ന് തിരഞ്ഞെടുക്കേണ്ടതുണ്ട്:
Subdomain: ഉദാ.: site.domain.com
…അല്ലെങ്കിൽ
Subdirectory: ഉദാ.: yourdomain.com/site
ഓരോ മോഡിനും ഗുണദോഷങ്ങളുണ്ട്, ഈ തീരുമാനമെടുക്കുമ്പോൾ അവ പരിഗണിക്കേണ്ടതുണ്ട്.
ഒരു കാര്യം ശ്രദ്ധിക്കേണ്ടത്: നിങ്ങൾ തീരുമാനമെടുത്തുകഴിഞ്ഞാൽ, നിങ്ങളുടെ നെറ്റ്വർക്ക് subdirectory-ൽ നിന്ന് subdomain-ലേക്കോ തിരിച്ചോ മാറ്റുന്നത് വളരെ ബുദ്ധിമുട്ടാണ് – പ്രത്യേകിച്ച് നിങ്ങൾ ഇതിനകം കുറച്ച് സൈറ്റുകൾ ക്രിയേറ്റ് ചെയ്തിട്ടുണ്ടെങ്കിൽ.
ആ തീരുമാനമെടുക്കുന്നതിന് മുമ്പ്, ഇവിടെ ചില കാര്യങ്ങൾ മനസ്സിൽ വെക്കേണ്ടതുണ്ട്:
Subdirectory Mode സെറ്റപ്പും മെയിന്റനൻസും എളുപ്പമുള്ള മോഡാണ്. എല്ലാ സൈറ്റുകളും മെയിൻ ഡൊമെയ്നിലേക്ക് അറ്റാച്ച് ചെയ്ത പാത്തുകൾ മാത്രമായതിനാലാണ് ഇത് (ഉദാ. yourdomain.com/subsite). ഫലമായി, മെയിൻ ഡൊമെയ്നിന് ഒരൊറ്റ SSL certificate മാത്രം മതി, അത് മുഴുവൻ നെറ്റ്വർക്കിനെയും കവർ ചെയ്യും.
അതേസമയം, ഇതിന്റെ URL ഘടന കാരണം, Google-ഉം മറ്റ് മിക്ക സെർച്ച് എഞ്ചിനുകളും നിങ്ങളുടെ subdirectory-അടിസ്ഥാനമാക്കിയ നെറ്റ്വർക്കിലെ എല്ലാ subsites-നെയും ഒരു വലിയ സൈറ്റായി കണക്കാക്കും. ഫലമായി, നിങ്ങളുടെ എൻഡ്-കസ്റ്റമേഴ്സ് subsites-ൽ ചേർക്കുന്ന കണ്ടന്റ് നിങ്ങളുടെ ലാൻഡിംഗ് സൈറ്റിന്റെ SEO പെർഫോമൻസിനെ ബാധിച്ചേക്കാം. ഈ ആഘാതം എത്രമാത്രമെന്ന് ചർച്ചാവിഷയമാണ്, ഇത്തരം ഒരു ക്രമീകരണം SEO പെർഫോമൻസിന് ഗുണകരമാകുമെന്ന വാദവുമുണ്ട്.
Subdomain Mode സെറ്റപ്പ് ചെയ്യാൻ അൽപ്പം കൂടുതൽ സങ്കീർണ്ണമാണ്, പക്ഷേ ഇതിന്റെ URL ഘടന (ഉദാ. subsite.yournetwork.com) പൊതുവെ "കൂടുതൽ പ്രൊഫഷണൽ" ആയി കാണപ്പെടുന്നു.
Subdomain mode സെറ്റപ്പ് ചെയ്യുന്നതിലെ പ്രധാന വെല്ലുവിളികളിലൊന്ന് മുഴുവൻ നെറ്റ്വർക്കിനുമുള്ള SSL കവറേജ് (HTTPS) ആണ്. ബ്രൗസറുകൾ subdomains-നെ പ്രത്യേക എന്റിറ്റികളായി കണക്കാക്കുന്നു എന്നതാണ് കാരണം. ഫലമായി, നിങ്ങളുടെ നെറ്റ്വർക്കിലെ ഓരോ subdomain-നും വ്യത്യസ്ത SSL certificate വേണ്ടിവരും, അല്ലെങ്കിൽ Wildcard SSL certificate എന്ന പ്രത്യേക തരം certificate വേണ്ടിവരും. സമീപ വർഷങ്ങളിൽ, ഹോസ്റ്റിംഗ് പ്രൊവൈഡർമാരും പാനലുകളും SSL പ്രൊവിഷനിംഗിൽ മെച്ചപ്പെട്ടിട്ടുണ്ട്, ചിലർ ഒരു ബട്ടൺ ക്ലിക്കിൽ wildcard certificates നൽകുന്നു, ഇത് സെറ്റപ്പിന്റെ സങ്കീർണ്ണതയിൽ രണ്ട് മോഡുകൾ തമ്മിലുള്ള അന്തരം കുറയ്ക്കുന്നു.
Subdirectory mode-ൽ നിന്ന് വ്യത്യസ്തമായി, subdomain-അടിസ്ഥാനമാക്കിയ നെറ്റ്വർക്കിലെ subsites-നെ സെർച്ച് എഞ്ചിനുകൾ പ്രത്യേക വെബ്സൈറ്റുകളായി കണക്കാക്കുന്നു, അതിനാൽ ഒരു subsite-ലെ കണ്ടന്റ് മറ്റ് subsites-ന്റെ SEO പെർഫോമൻസിനെ ഒട്ടും ബാധിക്കില്ല.
The Super Admin
Single-site WordPress ഇൻസ്റ്റാളേഷനുകളിൽ അൺലിമിറ്റഡ് യൂസർമാരെ ചേർക്കാനും വ്യത്യസ്ത അനുമതികളുള്ള വ്യത്യസ്ത user roles നൽകാനും കഴിയും.
WordPress Multisite-ൽ, ഒരു പുതിയ തരം യൂസർ അൺലോക്ക് ആകുന്നു: super admin – കൂടാതെ ഒരു പുതിയ admin panel-ഉം അൺലോക്ക് ആകുന്നു: network admin panel.
പേര് സൂചിപ്പിക്കുന്നത് പോലെ, super admin-ന് നെറ്റ്വർക്കിൽ സൂപ്പർ പവറുകളുണ്ട്, എല്ലാ subsites, plugins, themes, എല്ലാം മാനേജ് ചെയ്യാൻ കഴിയും!
നിങ്ങളുടെ single-site WordPress ഇൻസ്റ്റാളേഷനെ multisite-ലേക്ക് മാറ്റിയാൽ, single site-ന്റെ ഒറിജിനൽ admin ഓട്ടോമാറ്റിക്കായി super admin ആയി അപ്ഗ്രേഡ് ചെയ്യപ്പെടും.
Plugins-ഉം themes-ഉം network admin panel-ൽ നിന്ന് super admins-ന് മാത്രമേ ഇൻസ്റ്റാൾ ചെയ്യാനോ അൺഇൻസ്റ്റാൾ ചെയ്യാനോ കഴിയൂ. Subsite admins-ന് ആ plugins-ഓ themes-ഓ ആക്ടിവേറ്റ് ചെയ്യാനോ ഡീആക്ടിവേറ്റ് ചെയ്യാനോ കഴിയും, super admin ഒരു plugin network activate ചെയ്യുന്നില്ലെങ്കിൽ – അങ്ങനെ ചെയ്താൽ അത് എല്ലാ subsites-ലും എപ്പോഴും ആക്ടീവ് ആയിരിക്കും.
കുറിപ്പ്: നിങ്ങൾ കാണുന്നത് പോലെ, ആരെയെങ്കിലും നിങ്ങളുടെ നെറ്റ്വർക്കിലേക്ക് ക്ഷണിച്ച് super admin സ്റ്റാറ്റസ് നൽകുന്നത് ആ യൂസർക്ക് നിങ്ങളുടെ നെറ്റ്വർക്കിൽ പൂർണ്ണ നിയന്ത്രണം നൽകുന്നു. ഉദാഹരണത്തിന്, മറ്റ് super admins-ന് നിങ്ങളുടെ super admin സ്റ്റാറ്റസ് നീക്കം ചെയ്യാനും, നിങ്ങളെ നിങ്ങളുടെ സ്വന്തം network admin panel-ൽ നിന്ന് ലോക്ക് ഔട്ട് ചെയ്യാനും കഴിയും. Ultimate Multisite കസ്റ്റമേഴ്സിന് അഡീഷണൽ super admins-ന് എന്തൊക്കെ ചെയ്യാൻ കഴിയുമെന്നതിൽ ഗ്രാന്യുലാർ കൺട്രോൾ നൽകാൻ, Support Agents എന്ന ഒരു add-on ഞങ്ങളുടെ പക്കലുണ്ട്. ഈ add-on നിങ്ങളെ മറ്റൊരു തരം യൂസർ – ഒരു agent – ക്രിയേറ്റ് ചെയ്യാൻ അനുവദിക്കുന്നു, നെറ്റ്വർക്കിൽ അവരുടെ ടാസ്ക്കുകൾ ചെയ്യാൻ ആവശ്യമായ അനുമതികൾ മാത്രം ഉള്ളതായി.
Subsites-ൽ എന്താണ് ഷെയർ ചെയ്യുന്നത്, എന്താണ് ഷെയർ ചെയ്യാത്തത്
നേരത്തെ സൂചിപ്പിച്ചത് പോലെ, WordPress multisite-ന്റെ പ്രധാന ഗുണങ്ങളിലൊന്ന് എല്ലാ subsites-ഉം ഒരേ configurations, core files, themes, plugins, WordPress core files തുടങ്ങിയവ ഷെയർ ചെയ്യുന്നു എന്നതാണ്.
എന്നിരുന്നാലും, ഓരോ subsite-നും പ്രത്യേകമായി സ്കോപ്പ് ചെയ്തിരിക്കുന്ന ഘടകങ്ങളുണ്ട്.
- ഉദാഹരണത്തിന്, ഓരോ subsite-നും അതിന്റേതായ uploads ഫോൾഡർ ലഭിക്കുന്നു. ഫലമായി, ഒരു പ്രത്യേക subsite-ന്റെ യൂസർമാർ അപ്ലോഡ് ചെയ്ത ഫയലുകൾ മറ്റൊരു subsite-ൽ ആക്സസ് ചെയ്യാൻ കഴിയില്ല.
- ഓരോ subsite-നും അതിന്റേതായ admin panel ഉ ണ്ട്, super admin network active ചെയ്തിട്ടില്ലെങ്കിൽ plugins-ഓ themes-ഓ ആക്ടിവേറ്റ് ചെയ്യാനോ ഡീആക്ടിവേറ്റ് ചെയ്യാനോ കഴിയും.
- മിക്ക database tables-ഉം ഓരോ subsite-നും വേണ്ടി ക്രിയേറ്റ് ചെയ്യുന്നു, അതായത് posts, comments, pages, settings, മറ്റുള്ളവ ഓരോ subsite-നും പ്രത്യേകമാണ്.
WordPress Multisite-ലെ User management
WordPress multisite-ലെ ഒരു സെൻസിറ്റീവ് വിഷയമാണ് user management. WordPress user table എല്ലാ subsites-ലും ഷെയർ ചെയ്യുന്ന ചുരുക്കം ചില tables-ൽ ഒന്നാണ്.
നിങ്ങളുടെ നെറ്റ്വർക്ക് കൊണ്ട് എന്താണ് നിർമ്മിക്കാൻ ഉദ്ദേശിക്കുന്നത് എന്നതിനെ ആശ്രയിച്ച് ഈ ക്രമീകരണം ചില പ്രശ്നങ്ങൾ സൃഷ്ടിച്ചേക്കാം. ഏറ്റവും പ്രധാനപ്പെട്ട പ്രശ്നം വ്യക്തമാക്കാൻ താഴെയുള്ള ഉദാഹരണം സഹായിക്കും.
ഈ സാഹചര്യം സങ്കൽപ്പിക്കുക:
നിങ്ങൾ ഒരു WordPress multisite നെറ്റ്വർക്ക് ക്രിയേറ്റ് ചെയ്യുകയും e-commerce സ്റ്റോർ വേണ്ട ആളുകൾക്ക് മാസവരിക്കായി subsites ഓഫർ ചെയ്യാൻ തുടങ്ങുകയും ചെയ്യുന്നു.
നിങ്ങളുടെ ആദ്യത്തെ പെയിംഗ് കസ്റ്റമർ ജോൺ ആണ്. നിങ്ങൾ ജോണിനായി നിങ്ങളുടെ നെറ്റ്വർക്കിൽ ഒരു സൈറ്റ് ക്രിയേറ്റ് ചെയ്യുകയും, ആവശ്യമായ എല്ലാ plugins ഇൻസ്റ്റാൾ ചെയ്യുകയും, ജോണിന് അവന്റെ സ്റ്റോർ മാനേജ് ചെയ്യാൻ ഒരു user ക്രിയേറ്റ് ചെയ്യുകയും ചെയ്യുന്നു.
പിന്നീട് രണ്ടാമത്തെ കസ്റ്റമർ ആലീസ് വരുന്നു. അവൾക്കും നിങ്ങൾ അതേ കാര്യം ചെയ്യുന്നു, ഇപ്പോൾ അവൾക്കും നിങ്ങളുടെ നെറ്റ്വർക്കിൽ ഒരു സ്റ്റോർ ഉണ്ട്.
ജോണും ആലീസും നിങ്ങളുടെ കസ്റ്റമേഴ്സ് ആണ്, പക്ഷേ അവർ പരസ്പരം അറിയില്ല. കൂടുതൽ പ്രധാനമായി, അവരിലൊരാൾ മറ്റേയാളുടെ സ്റ്റോർ വെബ്സൈറ്റ് സന്ദർശിച്ചാൽ, ഈ സ്റ്റോർ ഒരേ നെറ്റ്വർക്കിൽ ഹോസ്റ്റ് ചെയ്തതാണെന്ന് അറിയാൻ മാർഗമില്ല.
ഒരു ദിവസം, ജോണിന് ഒരു പുതിയ ജോഡി ഷൂസ് വാങ്ങേണ്ടതുണ്ട്, ആലീസിന്റെ സ്റ്റോറിൽ അവന് പെർഫെക്റ്റ് ആയവ കണ്ടെത്തുന്നു. പർച്ചേസ് പൂർത്തിയാക്കാൻ ശ്രമിക്കുമ്പോൾ, അവന് "email already in use" എന്ന എറർ മെസേജ് ലഭിക്കുന്നു, ഇത് വിചിത്രമാണ് കാരണം ഇത് ആലീസിന്റെ വെബ്സൈറ്റ് ആദ്യമായി സന്ദർശിക്കുന്നതാണെന്ന് ജോണിന് 100% ഉറപ്പാണ്.
ഇവിടെ എന്താണ് സംഭവിച്ചത് എന്നാൽ ജോണിന്റെ user മുഴുവൻ നെറ്റ്വർക്കിലും ഷെയർ ചെയ്യുന്നതാണ്, അതിനാൽ ആലീസിന്റെ സൈറ്റിൽ checkout ചെയ്യാൻ ഒരു അക്കൗണ്ട് ക്രിയേറ്റ് ചെയ്യാൻ ശ്രമിക്കുമ്പോൾ, ഒരേ email address ഉള്ള ഒരു user ഇതിനകം നിലവിലുണ്ടെന്ന് WordPress കണ്ടെത്തി എറർ കാണിക്കുന്നു.
കുറിപ്പ്: നിങ്ങളുടെ use-case അനുസരിച്ച് ഇത് എത്ര മോശമാകുമെന്ന് ഞങ്ങൾ മനസ്സിലാക്കുന്നു, അതിനാൽ Ultimate Multisite-ൽ നിലവിലുള്ള user-നുള്ള റെഗുലർ ചെക്കുകൾ ബൈപാസ് ചെയ്യുന്ന ഒരു ഓപ്ഷൻ ഉണ്ട്, ഒരേ email address ഉപയോഗിച്ച് ഒന്നിലധികം അക്കൗണ്ടുകൾ ക്രിയേറ്റ് ചെയ്യാൻ അനുവദിക്കുന്നു. ഓരോ അക്കൗണ്ടു ം ഒരു subsite-ലേക്ക് ബൗണ്ട് ആണ്, അതിനാൽ collision-ന്റെ റിസ്ക് മിനിമം ആയി നിലനിർത്തുന്നു. മുകളിലെ ഉദാഹരണത്തിൽ, ജോണിന് എറർ മെസേജ് ലഭിക്കില്ല, പ്രശ്നമില്ലാതെ ആ ഷൂസ് വാങ്ങാൻ കഴിയും. ഈ ഓപ്ഷനെ Enable Multiple Accounts എന്ന് വിളിക്കുന്നു, Ultimate Multisite → Settings → Login & Registration-ൽ ആക്ടിവേറ്റ് ചെയ്യാം.
User table ഷെയർ ചെയ്യുന്നുണ്ടെങ്കിലും, subsite admins-നോ super admin-നോ users-നെ subsites-ലേക്ക് ചേർക്കാനും നീക്കം ചെയ്യാനും കഴിയും, വ്യത്യസ്ത subsites-ൽ അവർക്ക് വ്യത്യസ്ത user roles പോലും നൽകാം.
Performance പരിഗണനകൾ
സപ്പോർട്ട് ചെയ്യാവുന്ന സൈറ്റുകളുടെ എണ്ണത്തിന്റെ കാര്യത്തിൽ WordPress multisite വളരെ ശക്തമാണ്. WordPress.com, Edublogs, Campuspress എന്നിവയെല്ലാം multisite-അടിസ്ഥാനമാക്കിയ സർവീസുകളാണെന്നും ഓരോന്നും ആയിരക്കണക്കിന് സൈറ്റുകൾ ഹോസ്റ ്റ് ചെയ്യുന്നുണ്ടെന്നും ഉള്ള വസ്തുത ഇത് തെളിയിക്കുന്നു.
ഒരൊറ്റ WordPress multisite ഇൻസ്റ്റാളേഷനിൽ ഹോസ്റ്റ് ചെയ്യാവുന്ന സൈറ്റുകളുടെ മാക്സിമം എണ്ണം തിയറിയിൽ ഇല്ലെങ്കിലും, പ്രാക്ടീസിൽ നിങ്ങൾക്ക് തൃപ്തികരമായി റൺ ചെയ്യാവുന്ന സൈറ്റുകളുടെ എണ്ണം നിരവധി ഘടകങ്ങളെ ആശ്രയിച്ച് വ്യത്യാസപ്പെടാം: സൈറ്റുകൾ എത്ര dynamic ആണ്, subsites-ന് ഏത് plugins ലഭ്യമാണ്, തുടങ്ങിയവ.
ഒരു thumb rule ആയി, നിങ്ങളുടെ നെറ്റ്വർക്ക് എത്ര സിമ്പിൾ ആണോ അത്രയും നല്ലത്. കണ്ടന്റ് യഥാർത്ഥത്തിൽ dynamic അല്ലാത്ത സൈറ്റുകൾക്ക് മുൻഗണന നൽകുന്നതും (അഗ്രസ്സീവ് caching strategies-ന് മികച്ച candidates ആക്കുന്നു) plugin stack കഴിയുന്നത്ര ലൈറ്റ് ആക്കി വെക്കുന്നതും (ആക്ടീവ് plugins-ന്റെ എണ്ണം കുറയുന്തോറും നല്ലത്) നിങ്ങൾക്ക് ഹോസ്റ്റ് ചെയ്യാവുന്ന subsites-ന്റെ എണ്ണം വളരെയധികം വർദ്ധിപ്പിക്കും.
ഏറ്റവും നല്ല കാര്യം, ഇതെല്ലാം WordPress ആയതിനാൽ, performance improvements-നായി നിങ്ങൾ ഇതിനകം അറിയു കയും ഇഷ്ടപ്പെടുകയും ചെയ്യുന്ന അതേ tools multisite നെറ്റ്വർക്കിനും പ്രവർത്തിക്കും.
Multisite-ന്റെ പ്രധാന bottleneck database ആണ്, പക്ഷേ മറ്റെല്ലാം ശരിയായി സെറ്റപ്പ് ചെയ്തിട്ടുണ്ടെങ്കിൽ, അതിനെക്കുറിച്ച് ആശങ്കപ്പെടേണ്ടി വരുന്നതിന് മുമ്പ് കുറച്ച് ആയിരം സൈറ്റുകൾ വരെ പോകാം. അപ്പോഴും, ആ സമയത്ത് ക്രമാനുഗതമായി ചേർക്കാവുന്ന solutions ഉണ്ട് (ഉദാഹരണത്തിന്, database sharding solutions പോലുള്ളവ).