Праца з MediaWiki - Кіраўнік 15 - Адміністрацыя MediaWiki

1. Налады канфігурацыі
2. Адладка
3. Паляпшэнне прадукцыйнасці MediaWiki
4. MediaWiki кэш
5. Чарга на працу
6. Спасылкі адміністратара
7. Замяніць тэкст
8. Атрыманне інфармацыі пра IP карыстальніка
9. Боты і API MediaWiki
10. MediaWiki API
11. Пошукавая аптымізацыя
12. Запуск вікі-фермы
13. Шматмоўны вікі

Адміністраванне вікі MediaWiki ў цэлым не так складана, як толькі вы зрабілі пачатковую ўстаноўку. Яна ўключае ў сябе як дзеянні, зробленыя праз вэб-інтэрфейс, так і дзеянні, зробленыя на заднім канцы, напрыклад, рэдагаванне LocalSettings.php і ўстаноўка пашырэнняў. Звычайна ёсць толькі адна або некалькі людзей, якія маюць доступ да задняга канца, і тую ж самую ці крыху большую групу людзей з адміністрацыйным доступам на самой вікі.

Уся гэтая кніга ў значнай ступені накіравана на адміністратараў MediaWiki, таму ў пэўным сэнсе вялікая частка гэтай кнігі можа адпавядаць тэме "Адміністрацыя MediaWiki". Але гэты раздзел прызначаны для захоўвання некаторых інструментаў і дзеянняў, якія маюць дачыненне толькі да адміністратараў, якія не падыходзяць у іншым месцы.

Налады канфігурацыі

Ёсць шмат налад для асноўнай MediaWiki, якія можна змяніць у LocalSettings.php - па сутнасці, усе зменныя, якія пачынаюцца з "$ wg". Некаторыя з іх апісаны ў гэтай кнізе, хоць гэта вельмі невялікі працэнт ад агульнага набору. Вы можаце ўбачыць поўны спіс тут, згрупаваны па тыпах функцыянальных магчымасцяў:

https://www.mediawiki.org/wiki/Manual:Configuration_settings

Вось карысны, які не згадваецца нідзе ў кнізе:

• $ wgReadOnly - усталёўвае ўвесь вікі толькі для чытання, пры гэтым указаная радок у якасці прычыны; карысна для часовага абслугоўвання сайта

Адладка

MediaWiki з'яўляецца праграмным забеспячэннем, і праграмнае забеспячэнне, на жаль, можа пайсці не так. У выпадку ўзнікнення праблемы могуць паўстаць правы доступу да каталога файлаў, правы карыстальнікаў у базе дадзеных, адсутнічаюць файлы, адсутнічаюць табліцы баз дадзеных, дрэнныя наладкі ў LocalSettings.php, несумяшчальныя версіі ці нават (загубленыя думкі) памылкі ў кодзе. (Што, дарэчы, значна больш верагодна, што адбываецца ў пашырэннях, чым у асноўнай MediaWiki.)

Як правіла, крыніца найбольш блытаніны ў MediaWiki, калі карыстальнікі бачаць пустую старонку ў браўзэры ў любы момант падчас вікі. Гэта адбудзецца, калі ёсць памылка, і калі PHP настроены паказваць пустую старонку, а не паведамленне пра памылку, калі гэта адбудзецца. Лёгка бачыць памылку на экране; так што калі вы атрымліваеце пустую старонку, лепшым рашэннем з'яўляецца даданне наступнай радка, альбо ў LocalSettings.php, альбо ў PHP уласны php.ini файл: ini_set ('display_errors', 1);

Калі ён дадаецца да LocalSettings.php, ён павінен знаходзіцца побач з верхняй часткай файла, прама пад радком "<? Php".

Самы просты інструмент для адладкі - гэта панэль адладкі MediaWiki. Ён змяшчае ўсю неабходную інфармацыю (SQL-званкі, папярэджанні, адладкавыя дысплеі) у адным лёгка даступным месцы ўнізе браўзэра. Для тых, хто з нас рабіў MediaWiki адладкі старамоднага спосабу, гэта дзіўна карысны інструмент. Вы можаце ўключыць яго, дадаўшы да LocalSettings.php наступнае:

$ wgDebugToolbar = true;

Аднак, магчыма, вы не жадаеце, каб усе бачылі панэль інструментаў адладкі, падчас яе ўключэння (калі вы ўключылі яе, усе ўбачаць). На шчасце, ёсць і іншыя варыянты. Калі вы ўбачыце паведамленне пра памылку, якое змяшчае тэкст "(запыт SQL схаваны)", і вы хочаце ўбачыць SQL, які быў выкліканы, вы можаце ўбачыць яго, дадаўшы да LocalSettings.php наступнае:

$ wgShowSQLErrors = true; І калі памылка, якая ўзнікае, можа быць складанай, вы можаце ўключыць у сябе самастойную рэгістрацыю часопіса адладкі MediaWiki, а потым вывучыць змесціва гэтага файла. Каб уключыць яго, дадайце да LocalSettings.php наступнае: $ wgDebugLogFile = "/ full / path / to / your / debug / log / file";

Гэты файл павінен быць запісаны на вэб-серверы.

Часта самае простае рашэнне, як і ў вялікай колькасці праграмнага забеспячэння, заключаецца ў правядзенні вэб-пошуку па тэксце паведамлення пра памылку - цалкам магчыма, што гэтыя праблемы сутыкнуліся і, магчыма, з дыягназам. Калі вы лічыце, што праблема звязана з пэўным пашырэннем, лепш праверыць галоўную старонку гэтага пашырэння або старонку размовы, каб даведацца пра яго згадванне.

Паляпшэнне прадукцыйнасці MediaWiki

Гэта не кніга пра прадукцыйнасць у Інтэрнэце, але калі вы адчуваеце, што ваша вікі занадта павольная, ці вы занепакоеныя вынікамі павелічэння трафіку ў будучыні, вось некалькі карысных саветаў:

• Пераканайцеся, што ваш вэб-сервер і PHP хапае памяці, прызначанай для іх.
• Існуе мноства інструментаў кэшавання, якія могуць быць выкарыстаны сумесна з MediaWiki (і адзін з адным), такімі як Squid, Varnish і memcached. З усіх наяўных інструментаў найбольш карысным з'яўляецца, верагодна, APC, утыліта кэшавання PHP, якая часта значна павышае прадукцыйнасць MediaWiki. Вы можаце ўбачыць усе варыянты кэшавання тут:

• Выкарыстанне Nginx або Lighttpd у якасці вэб-сервера, а не Apache, можа значна палепшыць прадукцыйнасць сайтаў з высокім трафікам.
• MediaWiki таксама можа працаваць з HipHop Virtual Machine, альбо з HHVM, рухавіком выканання з адкрытым зыходным кодам для PHP, распрацаваным Facebook. Вікіпедыя пачала выкарыстоўваць HHVM у снежні 2014 года, і гэта прыкладна ўдвая павялічыла хуткасць сайта для прагляду і рэдагавання.

MediaWiki кэш

MediaWiki вядзе шырокае кэшаванне старонак: калі вы ідзяце на вікі-старонку, ёсць верагоднасць таго, што яна не была створана на месцы, а хутчэй - гэта кэшаваная версія, створаная калі-небудзь у папярэдні дзень. (Гэта не адносіцца да старонак у "Спецыяльнай" прасторы імёнаў, якія ствараюцца кожны раз.)

Карыстальнікі заўсёды могуць бачыць "жывы" варыянт любой старонкі, дадаўшы "action = purge" да URL.

Пашырэнне MagicNoCache дазваляе пазначыць некаторыя старонкі як ніколі не кэшаваныя праз перамыкач паводзін "__NOCACHE__". Глядзіце тут:

https://www.mediawiki.org/wiki/Extension:MagicNoCache

Кэшаванне становіцца праблемай пры ўсталёўцы Cargo ці Semantic MediaWiki, таму што кэшаваныя старонкі не аўтаматычна паказваюць найноўшы набор вынікаў запытаў; гэта можа прывесці да блытаніны для карыстальнікаў, калі яны дадаюць некаторыя дадзеныя, і тады яны не з'явяцца ў выніках запытаў у іншым месцы. Лепшы спосаб вырашэння гэтай праблемы - усталяваць пашырэнне MagicNoCache, выкарыстоўваючы яго на кожнай старонцы, якая змяшчае запыт.

Іншы варыянт - выкарыстоўваць пашыранае зацверджанае абнаўленне ( Глядзіце тут ) - Хоць гэта не наўмысна, старонкі, якія маюць зацверджаную версію, не кэшуюцца. Гэта можа змяніцца ў будучыні, але на дадзены момант гэта пабочны эфект, пра які трэба ведаць. Абодва Cargo і SMW забяспечваюць уласную ўкладку / выпадальны спіс, які бачаць толькі адміністратары, якія называюцца "Purge cache" (Cargo) або "Refresh" (або SMW); абодва паказваюць на адрас "action = purge", які не дазваляе адміністратарам уводзіць яго ўручную.

Чарга на працу

У фонавым рэжыме ёсць пэўныя задачы, якія MediaWiki павінна выконваць на працягу доўгага перыяду часу. Найбольш часта сустракаецца выпадак, калі шаблон змяняецца. Скажам, хтосьці дадае тэг катэгорыі да шаблона - гэта азначае, што кожную са старонак, якія ўключаюць гэты шаблон, трэба дадаваць у гэтую катэгорыю. Гэты працэс нельга зрабіць усё адразу, паколькі ён значна запаволіць сервер, ці нават часова яго збой. Замест гэтага працэс разбіваецца на "працоўныя месцы", якія змяшчаюцца ў "чарзе на працу" - а потым гэтыя заданні працуюць у парадку.

За кулісамі чарга заданняў на самай справе - гэта проста табліца базы дадзеных пад назвай "job", якая змяшчае адну радок для кожнага задання. Гэтыя заданні выконваюцца ў паслядоўным парадку, і пасля выканання задання яго радок будзе выдалены.

Праца выконваецца кожны раз, калі вікі атрымлівае старонку. Па змаўчанні, кожнае заданне выконваецца пры кожным ударе, але гэты лік можа быць зменены, каб зрабіць працу павольней або хутчэй, змяняючы значэнне $ wgJobRunRate. Для таго, каб запусціць працу ў дзесяць разоў хутчэй, напрыклад, у LocalSettings.php неабходна дадаць наступнае:

$ wgJobRunRate = 10;

І наадварот, каб зрабіць яго ў дзесяць разоў павольней, вы ўсталюеце значэнне ў 0,1. (Вы сапраўды не можаце запусціць частку задання - замест гэтага, калі дробнае значэнне вызначае верагоднасць таго, што заданне будзе выканана ў любы момант часу).

Вы таксама можаце прымусіць працу выконвацца больш аўтаматызаваным чынам, а не проста чакаць, пакуль яны будуць запушчаныя (альбо неаднаразова націснуўшы "перазагрузку" у браўзэры, каб паскорыць працу). Гэта робіцца шляхам выкліку сцэнарыя runJobs.php у каталог MediaWiki / maintenance. Вы нават можаце стварыць працу cron для рэгулярнага запуску runJobs.php - скажам, раз у дзень.

Існуюць розныя параметры, якія могуць запусціць runJobs.php, напрыклад, усталёўка максімальнай колькасці заданняў, якія могуць быць запушчаныя, ці, можа быць, што яшчэ больш важна, тыпу выкананага задання. Для таго, каб уключыць апошні, у кожнага тыпу задання ёсць сваё ідэнтыфікатарнае імя, якое можна знайсці ў базе дадзеных. Вы можаце прачытаць пра ўсе параметры для runJobs.php тут:

https://www.mediawiki.org/wiki/Manual:RunJobs.php

У дадатак да асноўнай MediaWiki, пашырэнні могуць ствараць і ўласныя працоўныя месцы. Некаторыя пашырэнні: Перадача дадзеных, DeleteBatch, Nuke і Replace Text.

Спасылкі адміністратара

Адной з асаблівасцяў, распаўсюджаных у вэб-прыкладаннях, якіх у MediaWiki заўсёды хапала, з'яўляецца вобласць "прыборная панэль", якая дазваляе адміністратару праглядаць статыстыку і выконваць адміністрацыйныя задачы з аднаго месца. У абмежаванай ступені старонка Special: SpecialPages робіць гэта ўжо; ён проста пералічвае большасць даступных спецыяльных старонак, згрупаваныя па катэгорыях. Гэта, безумоўна, лепш, чым нічога, але не ўсе старонкі, пералічаныя ў Special: SpecialPages, адмыслова карысныя адміністратарам, і, наадварот, не ўсе задачы адміністрацыі выконваюцца праз адмысловыя старонкі (напрыклад, рэдагаванне бакавой панэлі не з'яўляецца).

Пашырэнне Admin Links дае нешта бліжэй да сапраўднай панэлі адміністратараў. Ён вызначае адну старонку, Special: AdminLinks, якая змяшчае спасылкі, карысныя для адміністратараў, падзеленыя тыпам функцыянальных магчымасцяў. Іншыя пашырэнні могуць дадаваць свае ўласныя спасылкі на старонку Спасылкі адміністратара, калі яны захочуць, праз гаплікі і некалькі. На малюнку 15.1 паказана, як выглядае старонка, калі ўсталяваны розныя пашырэнні, апісаныя ў гэтай кнізе, такія як Cargo, Page Forms і Transfer Data.

Малюнак 15.1 старонка адміністрацыйных спасылак, калі ўсталёўваюцца розныя іншыя пашырэнні (зацверджаныя змены, замена тэксту, формы старонак, груз і г.д.)

Іншая добрая асаблівасць спасылак адміністратара заключаецца ў тым, што ён змяшчае спасылку на старонку "Спасылкі адміністратара" у спасылках карыстальнікаў у верхняй частцы кожнай старонкі, так што прыборная панэль заўсёды знаходзіцца ў адным пстрычцы мышы. Вось як выглядае верхняя частка старонкі ў скуры Вектар, з усталяванымі адміністрацыйнымі спасылкамі:

Замяніць тэкст

MediaWiki адсутнічае прыродны спосаб зрабіць глабальны пошук і замену тэксту. У Вікіпедыі і некаторых іншых маштабных вікі-ботах выкарыстоўваюцца для гэтай мэты, але спосаб здзейсніць гэта з-за вікі значна зручней. На шчасце, пашырэнне Replace Text дазваляе рабіць замену тэксту на ўсім сайце. Замяніць тэкст можа апрацоўваць як змест старонак, так і іх імёны; калі змест у загалоўку старонкі замяняецца, гэта азначае, што старонка "перамяшчаецца".

Каб запусціць замену, перайдзіце ў Спецыяльны: ReplaceText. Гэта дзеянне рэгулюецца дазволам 'replacetext', які па змаўчанні даецца адміністратарам.

Малюнак 15.2 Наверх Спецыяльнага: ReplaceText

У верхняй частцы старонкі Special: ReplaceText вы можаце ўбачыць на малюнку 15.2. Ніжэй прыведзены спіс прастор імёнаў, якія карыстальнік можа выбраць; потым ніжэй прадстаўлены некаторыя дадатковыя опцыі для замены, якія паказаны на малюнку 15.3.

Малюнак 15.3 Унізе спецыяльнага: ReplaceText

Пры націску на кнопку "Працягваць" прыводзіць карыстальніка да другой старонкі, у якім утрымліваюцца дакладныя супадзенні для радка пошуку, так што карыстальнік можа ўручную выбіраць, на якіх старонках будуць змяшчацца змесціва і / або загалоўкі.

Кожнае змяненне, зробленае Replace Text, адлюстроўваецца ў гісторыях старонак, прычым карыстальнік, які ініцыяваў замену, з'яўляецца аўтарам гэтага рэдагавання.

Для больш складаных пераўтварэнняў, верагодна, вам прыйдзецца спадзявацца на боты і на API MediaWiki, які мы пяройдзем да наступнага.

Атрыманне інфармацыі пра IP карыстальніка

У рэдкіх выпадках можа быць карысна атрымаць інфармацыю пра IP-адрас пра карыстальнікаў, якія ўвайшлі ў сістэму - напрыклад, калі крадзяжу пароля карыстальніка і хтосьці пачынае рэдагаваць вікі як іх; альбо калі вы падазраеце, што адзін карыстальнік вандалізуе вікі з некалькіх уліковых запісаў; альбо калі вы падазраеце, што адзін карыстальнік стварае некалькі уліковых запісаў, каб паспрабаваць зрабіць ілюзію шырокага кансенсусу па нейкай праблеме (гэта вядома як "sockpuppeting"). IP-адрас фактычна захоўваецца для кожнага змены, якое адбываецца ў вікі, але нідзе ў вікі не відаць. Калі ў вас ёсць доступ да базы дадзеных, вы можаце праглядзець гэтую інфармацыю ў слупку "rc_ip" табліцы "recentchanges". Пашырэнне CheckUser дазваляе адміністратарам праглядаць гэтую інфармацыю з самой вікі, для палягчэння доступу: https://www.mediawiki.org/wiki/Extension:CheckUser

І наадварот, калі вы не хочаце, каб гэтая інфармацыя захоўвалася, па меркаваннях прыватнасці вы можаце адключыць захоўванне, дадаўшы да LocalSettings.php наступнае:

$ wgPutIPinRC = false;

Боты і API MediaWiki

Існуюць розныя прылады для ўнясення аўтаматычных змяненняў у змест вікі, напрыклад, пашырэнне Замяніць тэкст. Але ў многіх выпадках неабходны набор правак занадта спецыфічны, каб кіравацца аўтаматызаваным інструментам. Для ўсіх гэтых выпадкаў ёсць боты і API MediaWiki.

Бот, у тэрміналогіі MediaWiki, - гэта сцэнар, які робіць адзін або некалькі канкрэтных відаў правак альбо атрымлівае адзін або некалькі частак дадзеных. Бот можа быць напісаны на любой мове праграмавання: ён проста падключаецца да API MediaWiki, які выконвае фактычную працу па напісанні і чытанні дадзеных. Большасць асноўных моў праграмавання маюць адну або некалькі бібліятэк API API, якія прадугледжваюць ўваход у вікі і падключэнне да API. Але нават без бібліятэкі стварыць бібліятэкі MediaWiki не так складана - скрыпту трэба ўдарыць толькі некаторыя URL-адрасы MediaWiki.

Калі бот уносіць змены ў вікі, то ў ідэале яго трэба ўвайсці ў сістэму як карыстальнік - а ў ідэале - асобны ўліковы запіс, які дадаецца ў групу "ботаў". Гэтыя ўліковыя запісы можна ўбачыць па ўсёй Вікіпедыі - яны фіксуюць пашкоджаныя тэгі <ref>, перайменоўваюць катэгорыі, дадаюць подпісы да непадпісаных паведамленняў размовы і г.д. На іншых вікі яны даволі радзей, але некаторыя больш дробныя вікі істотна іх выкарыстоўваюць.

Гэтая старонка змяшчае інфармацыю і карысныя спасылкі на стварэнне і запуск робатаў:

MediaWiki API

MediaWiki API, па сутнасці, ўяўляе сабой набор URL-адрасоў, з якімі можна атрымаць доступ, каб чытаць і пісаць у вікі. Усе яны звязаны з рознымі параметрамі, перададзенымі ў файл api.php. Гэты файл знаходзіцца ў тым жа каталогу, што і index.php; Так, напрыклад, калі ў вашай вікі ёсць URL-адрасы формы mywiki.com/w/index.php?title = ..., галоўны URL-адрас API можна знайсці на mywiki.com/w/api.php. (Для больш апошніх версій MediaWiki, API звязаны са старонкі Special: Version).

Калі вы ідзяце па гэтым галоўным URL-адрасе, вы ўбачыце даволі поўнае (аўтаматычна створанае) тлумачэнне ўсіх даступных дзеянняў API. Дзеянні API вызначаюцца як асноўнай MediaWiki, так і шэрагам пашырэнняў. Вы таксама ўбачыце спіс розных фарматаў, у якіх могуць быць адлюстраваны вынікі, у тым ліку JSON і XML. Напрыклад, даданне "format = jsonfm" у URL будзе адлюстроўваць вынікі ў фармаце псеўда-JSON, які карыстальнікі могуць чытаць на экране, а "format = json" атрымае фактычную сыравіну JSON.

Мы не будзем удавацца ў падрабязнасці ўсіх функцыянальных магчымасцяў API, даступных тут, але вы можаце ўбачыць яго на api.php - і вы таксама можаце прачытаць больш пра:

https://www.mediawiki.org/wiki/API:Main_page

Пошукавая аптымізацыя

Аптымізацыя пошукавых сістэм, альбо SEO, - гэта практыка спроб, каб старонкі старэйшага сайта былі як мага больш высокімі для вынікаў пошукавай сістэмы, асабліва ў Google. Гэта спрэчная сфера: для яго прыхільнікаў, гэта неад'емны спосаб атрымаць вэб-трафік, а для сваіх нядобразычліўцаў - гэта найлепшае рашэнне, а ў горшым выпадку - хакеры, спамеры і ашуканцы. Тым не менш, для людзей, якія працуюць у грамадскіх вікі, можа быць важным паказваць высокія вынікі пошуку.

Перш за ўсё, MediaWiki ўжо гатовая для таго, каб зрабіць вынікі пошуку рознымі спосабамі. Вікіпедыя, безумоўна, заснавана на MediaWiki, з'яўляецца найвялікшым сайтам нумар адзін для вынікаў пошуку па любой метрыцы: звычайна ў першай тройцы, і часта # 1, шукаюць любую тэму, якую яна ахоплівае. Гэта ў асноўным толькі таму, што ён часта звязваецца з іншымі сайтамі пра гэтыя канкрэтныя тэмы, але гэта таксама часткова звязана з уласным дызайнам MediaWiki.

У MediaWiki таксама тэма кожнай старонкі таксама: імя старонкі, частка яго URL, тэкст у загалоўку верхняга ўзроўню і тэкст, які з'яўляецца ва ўнутраных спасылках на гэтую старонку. Такая паслядоўнасць надзвычай важная для пошукавых сістэм, звязваючы гэтае слова або фразу з гэтым канкрэтным URL. Звязаныя з гэтым, як правіла, толькі адзін загаловак верхняга ўзроўню на старонку: імя старонкі змяшчаецца ў межах адзінага тэга <h1> на гэтай старонцы, што таксама дапамагае ўсталяваць тэму пошуку для пошукавых сістэм.

Існуе прынамсі адно актыўнае пашырэнне MediaWiki, якое патэнцыйна можа спрыяць пашырэнню пошукавых сістэм: пашырэнне WikiSEO, якое дадае і тэгі зыходнага кода HTML вікі-старонкі. Ён вызначае функцыю парсера, адпаведна з імем "#seo", якую можна дадаць у любым месцы на старонку, і якая выклікаецца наступным чынам: {{#seo: title = ... | titlemode = ... | ключавыя словы = ... | description = ...}}

Параметр "title =" альбо замяняе, дадаецца альбо дапаўняецца да змесціва тэга HTML <title>, у залежнасці ад значэння параметра "titlemode =", які можа быць альбо заменены, дапаўняць альбо дапаўняць. Параметры "keywords =" і "description =" змяшчаюцца ў якасці атрыбутаў "name" і "content" тэга HTML <meta>. Калі вы не ведаеце, як усталяваць усе гэтыя тэгі, лепш падумаць аб іх значэнні і як іх лепш за ўсё выкарыстоўваць для SEO.

Больш падрабязную інфармацыю пра WikiSEO можна знайсці тут:

Калі вы карыстаецеся шаблонамі ў стылі infobox на большасці старонак, добрая стратэгія заключаецца ў тым, каб змясціць тэг у шаблоны, так што вам не трэба дадаваць яго ўручную на кожную старонку; а затым запоўніце яго з канкрэтнымі параметрамі з інфобокса.

Запуск вікі-фермы

Гэта не рэдкасць для арганізацый і карпарацый, якія хочуць запусціць некалькі вікі; часам шмат. Кампанія, якая займаецца публічнымі вікі па розных тэмах, атрымлівае прыбытак ад рэкламы або па любой іншай прычыне, можа ў канчатковым выніку запусціць вялікую колькасць іх. Унутры кампаніі, магчыма, захочацца размясціць некалькі вікі. Як адзначаецца, кантроль доступу да дадзеных з'яўляецца адной з прычын тут : Самы бяспечны спосаб захаваць набор вікі дадзеных абмежаваны пэўнай групай карыстальнікаў - захаваць яго ў асобнай вікі. І розныя аддзелы ў арганізацыі маглі б захаваць сваю вікі альбо захаваць свае дадзеныя, альбо толькі таму, што ім мала неабходнасці абменьвацца дадзенымі з іншымі групамі. У вельмі вялікай кампаніі ці іншай арганізацыі колькасць такіх незалежных падраздзяленняў, якія хацелі б іх уласнай вікі, можа скласці нават у сотні.

Зразумела, кожная група, якая хацела ўласнай вікі, магла проста стварыць самі; калі ўсе яны выкарыстоўваюць MediaWiki, усталёўка бясплатная і звычайна не занадта складаная. (Гэта, па сутнасці, тое, што вікі гістарычна ўкараняюцца ў арганізацыі: невялікія групы, якія ствараюць іх, у праектах "skunkworks"). Але такая ўстаноўка можа хутка стаць брудным: калі іншаму чалавеку трэба стаць вікі-экспертам для стварэння і падтрымання кожнай вікі, гэта занадта шмат працы. Нават калі ўсе вікі кіруюцца цэнтралізаваным кіраўніцтвам адной ІТ-асобы або аддзела, гэта можа стаць стомнай працай, калі пара абнавіць праграмнае забеспячэнне.

У такой сітуацыі, што вы павінны выкарыстоўваць, гэта тое, што вядома як "вікі-ферма", ці часам "сям'я вікі": група вікі, якія кіруюцца з аднаго месца, і да якіх лёгка дадаць дадатковыя вікі. У MediaWiki, існуе мноства спосабаў стварэння вікі-фермы. Лепшая даведка для чытання пра розныя падыходы і пра тое, як наладзіць кожны з іх, тут:

https://www.mediawiki.org/wiki/Manual:Wiki_family

На гэтай старонцы пералічана шмат падыходаў: адзінкавыя і некалькі базавых кодаў, адзінкавыя супраць некалькіх баз дадзеных, адзінкавыя супраць некалькіх асобнікаў LocalSettings.php і т. Д. Тым не менш, існуе толькі адзін падыход, які мы рэкамендуем выкарыстоўваць, які заключаецца ў выкарыстанні адной. база кода, некалькі баз дадзеных і некалькі файлаў налад. Гэта па сутнасці адпавядае падыходу "сайты ў стылі Drupal", апісаным на гэтай старонцы.

Мы не будзем у поўнай меры ўводзіць тэхнічныя дадзеныя, але асноўная ідэя заключаецца ў тым: у вас ёсць асобная база дадзеных для кожнай вікі, а таксама асобны файл налад. Кожны файл налад на вікі будзе ўключаны з LocalSettings.php. У асобных файлах налад усталявана імя базы дадзеных для кожнай вікі і дазваляе наладзіць налады вікі, у тым ліку стандартныя функцыі, такія як імя вікі, лагатып, скура і дазвол; у дадатак да магчымасці пашырэння, якія ўключаны толькі для некаторых вікі.

Кіраўніцтва "Сямейства Wiki" ўключае ў сябе простую камбінацыю сцэнара PHP і абалонкі для гэтага падыходу, якая разам дазваляе ствараць і абнаўляць базу дадзеных для кожнай вікі.

Вам таксама трэба вызначыцца з структурай URL для розных вікі: два стандартных падыходу - выкарыстоўваць паддомены, такія як "wiki1.mycompany.com", або падкаталогі, такія як "mycompany.com/wiki1". Гэтая структура павінна быць апрацавана з дапамогай камбінацыі LocalSettings.php (якая павінна высветліць, якія параметры наладзіць на аснове URL) і канфігурацыю сервера, якая, калі выкарыстоўваецца Apache, звычайна ўяўляе сабой файл httpd. conf. Спецыфічныя налады для абодвух апісаны ў кіраўніцтве "Wiki family".

Калі вы загадзя ведаеце, што ў вас будзе некалькі вікі, можа быць карысна мець агульныя ўліковыя запісы карыстальнікаў, каб карыстальнікам не трэба ствараць новую ўліковы запіс на кожнай вікі, якую яны хочуць рэдагаваць. Вікіпедыя робіць гэта складаным спосабам, выкарыстоўваючы пашырэнне "CentralAuth", але для іншых вікі гэта можна зрабіць значна прасцей, проста калі розныя базы дадзеных падзяляюць адзін набор табліц з інфармацыяй пра карыстальніка. Вам проста трэба вырашыць, у якой базе дадзеных будзе захоўвацца інфармацыя, а затым дадаць да LocalSettings.php наступнае: $ wgSharedDB = " асноўная база дадзеных-імя ";

Хоць "агульная БД" гучыць як вялікая справа, па змаўчанні абменьваюцца толькі табліцы, якія маюць дачыненне да інфармацыі пра карыстальніка.

Шматмоўны вікі

З усіх рэчаў, якія звычайна хочуць рабіць адміністратарам вікі, магчыма, найбольш складана канцэптуальна, каб іх вікі падтрымлівалі некалькі моў. Гэта таму, што існуе кампраміс: вы хочаце, каб тэкст, які кожны чытае на сваёй мове, быў максімальна дакладным, але ў той жа час вы хочаце пазбегнуць залішніх дадзеных, таму што залішняя праца азначае больш працы, каб паспрабаваць забяспечыць змест на розных мовах усё адпавядаюць адзін аднаму.

Па-першае, некаторыя добрыя навіны: тэкст самога інтэрфейсу - напрыклад, тэкст на ўкладках "Змяніць" і "Прагляд гісторыі", альбо тэкст на адмысловых старонках - звычайна не з'яўляецца праблемай, таму што калі карыстальнік ўсталёўвае сваю ўласную мову пад "Налады карыстальнікаў", добрыя шанцы на тое, што ўвесь гэты тэкст быў перакладзены на сваю мову, дзякуючы наладжвальнай перакладзе MediaWiki.

Гэта проста пакідае змесціва вікі. Для гэтага правільны падыход у асноўным залежыць ад таго, ці будзе змест быць створаны толькі карыстальнікамі, якія размаўляюць на адной мове, але чытаюць на некалькіх мовах; ці прызначаны змест для стварэння карыстальнікаў, якія размаўляюць на некалькіх мовах.

Ёсць па сутнасці тры падыходы. Каб ад самага складанага да найменшага складанага яны былі:

Малюнак 15.4 Шкала са спасылкамі на розныя пераклады старонкі, якая прадастаўляецца пашырэннем перакладу

• Машынны пераклад змесціва. З дапамогай гэтага падыходу вы ўтрымліваеце ўсё змесціва на адной мове, а потым проста маеце механізм для таго, каб людзі перакладалі змесціва праз службу аўтаматычнага перакладу. Пашырэнне Live Translate - гэта рэкамендуемы падыход: ён забяспечвае просты ў выкарыстанні інтэрфейс, добрыя дадатковыя функцыі, а таксама дазваляе карыстацца службамі перакладу і Google і Microsoft. Гэта, безумоўна, самы просты падыход да некалькіх моў. Пра гэта вы можаце прачытаць тут: