Praca z MediaWiki - Rozdział 15 - Administracja MediaWiki

1. Ustawienia konfiguracji
2. Debugowanie
3. Poprawa wydajności MediaWiki
4. Pamięć podręczna MediaWiki
5. Kolejka zadań
6. Linki administratora
7. Zastąp tekst
8. Uzyskiwanie informacji o IP użytkownika
9. Boty i API MediaWiki
10. Interfejs API MediaWiki
11. Optymalizacja wyszukiwarki
12. Prowadzenie farmy wiki
13. Wielojęzyczne wiki

Administrowanie wiki MediaWiki na ogół nie jest takie trudne, po wykonaniu wstępnej konfiguracji. Obejmuje zarówno działania wykonywane przez interfejs WWW, jak i akcje wykonywane na zapleczu, takie jak edycja LocalSettings.php i instalowanie rozszerzeń. Zazwyczaj jest tylko jedna lub kilka osób z dostępem do zaplecza i ta sama lub nieco większa grupa osób z dostępem administracyjnym na samej wiki.

Ta cała książka jest w dużej mierze skierowana do administratorów MediaWiki, więc w pewnym sensie większość tej książki mogłaby się zmieścić w temacie „Administracja MediaWiki”. Ale ten rozdział ma na celu przechowywanie niektórych narzędzi i działań, które są istotne tylko dla administratorów, które nie pasowały gdzie indziej.

Ustawienia konfiguracji

Istnieje wiele ustawień dla podstawowego MediaWiki, które można modyfikować w LocalSettings.php - w zasadzie wszystkie zmienne zaczynające się od „$ wg”. Niektóre są omówione w tej książce, choć jest to bardzo mały procent całego zestawu. Możesz zobaczyć pełną listę tutaj, pogrupowaną według typu funkcjonalności:

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

Oto przydatne, które nie zostało wymienione w innym miejscu książki:

• $ wgReadOnly - ustawia całą wiki jako tylko do odczytu, z podanym łańcuchem podanym jako powód; przydatne do tymczasowej konserwacji witryny

Debugowanie

MediaWiki to oprogramowanie, a oprogramowanie niestety może się nie udać. Jeśli napotkasz problem, problemem mogą być uprawnienia do katalogów plików, uprawnienia użytkowników bazy danych, brakujące pliki, brakujące tabele bazy danych, złe ustawienia w LocalSettings.php, niekompatybilne wersje lub nawet (zgubić myśl) błędy w kodzie. (Które, nawiasem mówiąc, są znacznie bardziej prawdopodobne w rozszerzeniach niż w podstawowym MediaWiki.)

Generalnie źródłem największego zamieszania w MediaWiki jest to, że użytkownicy widzą pustą stronę w przeglądarce w dowolnym momencie na wiki. Dzieje się tak, jeśli wystąpi błąd i jeśli PHP jest skonfigurowane do wyświetlania pustej strony, zamiast komunikatu o błędzie, gdy tak się stanie. Prawie zawsze lepiej jest zobaczyć błąd na ekranie; więc jeśli otrzymasz pustą stronę, najlepszym rozwiązaniem jest dodanie następującej linii, albo do LocalSettings.php, albo do własnego pliku php.ini PHP: ini_set ('display_errors', 1);

Jeśli jest dodawany do LocalSettings.php, powinien znajdować się w górnej części pliku, tuż pod linią „<? Php”.

Najłatwiejszym narzędziem do debugowania jest pasek narzędzi do debugowania MediaWiki. Umieszcza wszystkie niezbędne informacje (wywołania SQL, ostrzeżenia, ekrany debugowania) w jednym łatwo dostępnym miejscu na dole przeglądarki. Dla tych, którzy kiedyś używali debugowania MediaWiki w staromodny sposób, jest to niezwykle przydatne narzędzie. Możesz go włączyć, dodając następujące elementy do LocalSettings.php:

$ wgDebugToolbar = true;

Jednak możesz nie chcieć, aby wszyscy widzieli pasek narzędzi do debugowania, w czasie, gdy jest włączony (jeśli go włączysz, wszyscy go zobaczą). Na szczęście istnieją inne opcje. Jeśli widzisz komunikat o błędzie zawierający tekst „(ukryte zapytanie SQL)”, a chcesz zobaczyć wywołany SQL, możesz go zobaczyć, dodając następujący tekst do LocalSettings.php:

$ wgShowSQLErrors = true; A jeśli występujący błąd wydaje się być złożony, możesz włączyć rejestrację debugowania MediaWiki, a następnie sprawdzić zawartość tego pliku. Aby go włączyć, dodaj następujące polecenie do LocalSettings.php: $ wgDebugLogFile = "/ full / path / to / your / debug / log / file";

Ten plik musi być zapisywalny przez serwer WWW.

Często najprostszym rozwiązaniem, podobnie jak w przypadku wielu innych programów, jest po prostu wyszukiwanie w Internecie tekstu komunikatu o błędzie - może się zdarzyć, że inni natkną się na ten problem i być może zdiagnozowali go. Jeśli uważasz, że problem pochodzi z określonego rozszerzenia, dobrze jest sprawdzić stronę główną tego rozszerzenia lub jego stronę dyskusji, aby sprawdzić, czy jest o tym mowa.

Poprawa wydajności MediaWiki

To nie jest książka o wydajności internetowej, ale jeśli uważasz, że Twoja wiki jest zbyt wolna lub martwisz się o skutki zwiększonego ruchu w przyszłości, oto kilka przydatnych wskazówek:

• Upewnij się, że serwer WWW i PHP mają wystarczająco dużo pamięci.
• Istnieje wiele narzędzi buforujących, które mogą być używane w połączeniu z MediaWiki (i ze sobą), jak Squid, Varnish i memcached. Ze wszystkich dostępnych narzędzi najbardziej przydatne jest prawdopodobnie narzędzie do buforowania PHP, które często znacznie poprawia wydajność MediaWiki. Tutaj możesz zobaczyć wszystkie opcje buforowania:

• Użycie Nginx lub Lighttpd jako serwera WWW zamiast Apache może znacznie poprawić wydajność dla witryn o dużym natężeniu ruchu.
• MediaWiki może również współpracować z HipHop Virtual Machine lub HHVM, silnikiem wykonawczym PHP dla open source, opracowanym przez Facebooka. Wikipedia zaczęła korzystać z HHVM w grudniu 2014 r. I podwoiła prędkość witryny, zarówno do przeglądania, jak i edycji.

Pamięć podręczna MediaWiki

MediaWiki wykonuje obszerne buforowanie stron: po przejściu na stronę wiki istnieje prawdopodobieństwo, że nie została ona wygenerowana na miejscu, ale raczej jest to wersja z pamięci podręcznej, która została utworzona jakiś czas temu. (Nie dotyczy to stron w przestrzeni nazw „Specjalne”, które są generowane za każdym razem).

Użytkownicy mogą zawsze zobaczyć wersję „na żywo” dowolnej strony, dodając „action = purge” do adresu URL.

Rozszerzenie MagicNoCache pozwala oznaczyć niektóre strony jako nigdy nie buforowane, za pomocą przełącznika zachowania „__NOCACHE__”. Spójrz tutaj:

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

Buforowanie staje się problemem, gdy zainstalowane są Cargo lub Semantic MediaWiki, ponieważ buforowane strony nie pokazują automatycznie najnowszego zestawu wyników zapytań; może to powodować zamieszanie wśród użytkowników, jeśli dodają jakieś dane, a następnie nie pojawiają się w wynikach zapytania w innym miejscu. Najlepszym obejściem tego problemu jest zainstalowanie rozszerzenia MagicNoCache, używając go na każdej stronie zawierającej zapytanie.

Inną opcją jest użycie rozszerzenia Approved Revs ( Spójrz tutaj ) - chociaż nie jest to zamierzone, strony z zatwierdzoną wersją nie są buforowane. Może się to zmienić w przyszłości, ale w tej chwili należy mieć na uwadze efekt uboczny. Cargo i SMW udostępniają własną kartę / listę rozwijaną, którą widzą tylko administratorzy, zwaną „Purge cache” (Cargo) lub „Refresh” (lub SMW); oba wskazują na adres URL „action = purge”, który uniemożliwia administratorom ręczne wpisywanie.

Kolejka zadań

Istnieją pewne zadania, które MediaWiki musi uruchamiać przez dłuższy czas, w tle. Najczęstszy przypadek pojawia się, gdy szablon jest modyfikowany. Powiedzmy, że ktoś dodaje znacznik kategorii do szablonu - oznacza to, że każda ze stron zawierających ten szablon musi zostać dodana do tej kategorii. Procesu tego nie można wykonać od razu, ponieważ znacznie spowolniłoby to działanie serwera, a nawet spowodowało jego awarię. Zamiast tego proces jest podzielony na „zadania”, które są umieszczane w „kolejce zadań” - a następnie zadania te są uruchamiane w uporządkowany sposób.

Za kulisami kolejka zadań jest tak naprawdę tylko tabelą bazy danych o nazwie „zadanie”, która przechowuje jeden wiersz dla każdego zadania. Zadania te są uruchamiane w kolejności sekwencyjnej, a po uruchomieniu zadania jego wiersz jest usuwany.

Zadania są uruchamiane za każdym razem, gdy wiki otrzymuje trafienie strony. Domyślnie jedno zadanie jest uruchamiane przy każdym trafieniu, ale ten numer można zmodyfikować, aby uruchomić zadania wolniej lub szybciej, zmieniając wartość $ wgJobRunRate. Aby na przykład uruchomić zadania dziesięć razy szybciej, dodaj do LocalSettings.php następujące elementy:

$ wgJobRunRate = 10;

I odwrotnie, aby uczynić go dziesięciokrotnie wolniejszym, ustaw wartość na 0,1. (W rzeczywistości nie można uruchomić ułamka zadania - zamiast tego ułamkowa wartość określa prawdopodobieństwo uruchomienia zadania w danym momencie).

Możesz również spowodować, że zadania będą uruchamiane w bardziej zautomatyzowany sposób, zamiast tylko czekać na ich uruchomienie (lub wielokrotnie naciskać „przeładuj” w przeglądarce, aby przyspieszyć działanie). Odbywa się to przez wywołanie skryptu runJobs.php w katalogu MediaWiki / maintenance. Możesz nawet utworzyć zadanie cron, aby regularnie uruchamiać runJobs.php - powiedzmy raz dziennie.

Istnieją różne parametry, które runJobs.php może przyjąć, takie jak ustawienie maksymalnej liczby zadań do uruchomienia lub, co ważniejsze, typu zadania do uruchomienia. Aby włączyć tę drugą, każdy typ zadania ma własną nazwę identyfikatora, którą można znaleźć w bazie danych. Możesz przeczytać o wszystkich parametrach runJobs.php tutaj:

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

Oprócz podstawowego MediaWiki, rozszerzenia mogą tworzyć własne zadania. Niektóre rozszerzenia to Transfer danych, UsuńBatch, Nuke i Zastąp tekst.

Linki administratora

Jedną z cech powszechnych w aplikacjach internetowych, której MediaWiki zawsze brakowało, jest obszar „pulpitu”, który umożliwia administratorom przeglądanie statystyk i wykonywanie zadań administracyjnych z jednego miejsca. W ograniczonym zakresie strona Special: SpecialPages już to robi; po prostu wyświetla większość dostępnych stron specjalnych, pogrupowanych według kategorii. To z pewnością lepsze niż nic, ale nie wszystkie strony wymienione w Special: Strony specjalne są szczególnie przydatne dla administratorów, i odwrotnie, nie wszystkie zadania administracyjne są wykonywane za pośrednictwem specjalnych stron (na przykład edycja paska bocznego nie jest).

Rozszerzenie Admin Links zapewnia coś bliższego rzeczywistemu pulpitowi administratora. Definiuje pojedynczą stronę Special: AdminLinks, która zawiera linki przydatne dla administratorów, oddzielone typem funkcjonalności. Inne rozszerzenia mogą dodawać własne linki do strony Linki administratora, jeśli zdecydują się, za pomocą haków i garści. Rysunek 15.1 pokazuje, jak wygląda strona, gdy zainstalowane są różne rozszerzenia opisane w tej książce, takie jak Ładunek, Formularze stron i Transfer danych.

Rysunek 15.1 Strona Łącza administratora, gdy zainstalowane są inne rozszerzenia (Zatwierdzone wersje, Zastąp tekst, Formularze stron, Ładunek itp.)

Inną ciekawą funkcją Admin Links jest to, że zawiera link do strony „Admin links” w linkach użytkownika u góry każdej strony, dzięki czemu pulpit nawigacyjny znajduje się zawsze w odległości jednego kliknięcia. Oto, jak góra strony wygląda w skórze Vector, z zainstalowanymi łączami administracyjnymi:

Zastąp tekst

MediaWiki nie ma wrodzonego sposobu na globalne wyszukiwanie i zastępowanie tekstu. Na Wikipedii i innych dużych wiki, boty są używane do tego celu, ale posiadanie sposobu na zrobienie tego z wiki jest dużo wygodniejsze. Na szczęście rozszerzenie Zamień tekst pozwala na zastąpienie tekstu w całej witrynie. Zastąp tekst może obsługiwać zarówno zawartość stron, jak i ich nazwy; jeśli treść tytułu strony zostanie zastąpiona, oznacza to, że strona zostanie „przeniesiona”.

Aby uruchomić zamiennik, przejdź do Special: ReplaceText. Ta akcja jest regulowana uprawnieniem „zastępuj”, które domyślnie jest udostępniane administratorom.

Rysunek 15.2 Góra specjalnej: Zastąp tekst

Możesz zobaczyć górę strony Special: ReplaceText na rysunku 15.2. Poniżej znajduje się lista przestrzeni nazw, z których użytkownik może wybrać; następnie poniżej znajdują się dodatkowe opcje wymiany, które pokazano na rysunku 15.3.

Rysunek 15.3 Dolna część specjalna: Zastąp tekst

Naciśnięcie przycisku „Kontynuuj” powoduje przejście użytkownika na drugą stronę z dokładnym dopasowaniem dla szukanego ciągu, dzięki czemu użytkownik może ręcznie wybrać, które strony będą miały zmodyfikowaną zawartość i / lub tytuły.

Każda zmiana dokonana przez Zastąp tekst pojawia się w historii stron, a użytkownik, który zainicjował wymianę, pojawia się jako autor tej edycji.

W przypadku bardziej złożonych transformacji prawdopodobnie będziesz musiał polegać na botach i interfejsie API MediaWiki, które przejdziemy do następnego.

Uzyskiwanie informacji o IP użytkownika

W rzadkich przypadkach przydatne może być uzyskanie informacji o adresie IP użytkowników, którzy są zalogowani - na przykład, jeśli hasło użytkownika zostało skradzione, a ktoś inny rozpocznie edycję wiki jako takiej; lub jeśli podejrzewasz, że pojedynczy użytkownik niszczy wiki z wielu kont; lub jeśli podejrzewasz, że pojedynczy użytkownik tworzy wiele kont, próbując dać złudzenie powszechnego porozumienia w pewnych kwestiach (jest to znane jako „sockpuppeting”). Adres IP jest faktycznie przechowywany dla każdej zmiany, która ma miejsce na wiki, ale nie jest widoczny gdziekolwiek na wiki. Jeśli masz dostęp do bazy danych, możesz wyświetlić te informacje w kolumnie „rc_ip” tabeli „recentchanges”. Rozszerzenie CheckUser pozwala administratorom przeglądać te informacje z samej wiki, aby ułatwić dostęp: https://www.mediawiki.org/wiki/Extension:CheckUser

I odwrotnie, jeśli nie chcesz, aby te informacje były przechowywane, ze względów prywatności możesz wyłączyć przechowywanie, dodając następujące informacje do LocalSettings.php:

$ wgPutIPinRC = false;

Boty i API MediaWiki

Istnieją różne narzędzia do automatycznych zmian zawartości wiki, takie jak rozszerzenie Zamień tekst. Ale w wielu przypadkach zestaw wymaganych zmian jest zbyt specyficzny, aby mógł być obsługiwany przez zautomatyzowane narzędzie. We wszystkich tych przypadkach są boty i API MediaWiki.

Bot w terminologii MediaWiki jest skryptem, który wykonuje jeden lub więcej określonych rodzajów edycji lub pobiera jedną lub więcej części danych. Bot może być napisany w dowolnym języku programowania: musi po prostu połączyć się z interfejsem API MediaWiki, który wykonuje rzeczywistą pracę polegającą na pisaniu i czytaniu danych. Większość głównych języków programowania ma jedną lub więcej bibliotek API MediaWiki napisanych dla nich, które dbają o szczegóły logowania do wiki i łączenia się z API. Ale nawet bez biblioteki trudno jest stworzyć bota MediaWiki - skrypt musi tylko trafić na niektóre adresy URL MediaWiki.

Jeśli bot dokonuje jakichkolwiek zmian na wiki, powinien być zalogowany jako użytkownik - najlepiej, aby był to osobne konto, które zostanie dodane do grupy „botów”. Możesz zobaczyć tego rodzaju konta w całej Wikipedii - są to te, które naprawiają uszkodzone znaczniki <ref>, zmieniają nazwy kategorii, dodają podpisy do niepodpisanych wiadomości na stronie rozmów itp. Na innych wiki są one nieco mniej popularne, ale niektóre mniejsze wiki wykorzystują je w znaczący sposób.

Ta strona zawiera pewne informacje i przydatne linki dotyczące tworzenia i uruchamiania botów:

Interfejs API MediaWiki

Interfejs API MediaWiki jest zasadniczo zbiorem adresów URL, do których można uzyskać dostęp w celu odczytu i zapisu na wiki. Wszystkie dotyczą różnych parametrów przekazywanych do pliku api.php. Ten plik znajduje się w tym samym katalogu co index.php; na przykład, jeśli twoja wiki ma adresy URL w postaci mywiki.com/w/index.php?title = ..., główny adres URL API można znaleźć pod adresem mywiki.com/w/api.php. (W przypadku nowszych wersji MediaWiki interfejs API jest połączony ze strony Special: Version).

Jeśli przejdziesz do tego głównego adresu URL, zobaczysz dość wyczerpujące (automatycznie wygenerowane) wyjaśnienie wszystkich dostępnych działań API. Akcje API są definiowane zarówno przez rdzeń MediaWiki, jak i szereg rozszerzeń. Zobaczysz również listę różnych formatów, w których wyniki mogą być wyświetlane, w tym JSON i XML. Na przykład dodanie „format = jsonfm” do adresu URL spowoduje wyświetlenie wyników w formacie pseudo-JSON, który użytkownicy mogą odczytać na ekranie, podczas gdy „format = json” spowoduje powstanie rzeczywistego surowego JSON.

Nie zapoznamy się ze szczegółami wszystkich funkcji API dostępnych tutaj, ale możesz je zobaczyć w api.php - możesz też przeczytać więcej na ten temat pod adresem:

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

Optymalizacja wyszukiwarki

Optymalizacja pod kątem wyszukiwarek lub SEO to praktyka polegająca na próbach wyświetlenia stron Twojej witryny tak wysoko, jak to możliwe, w wynikach wyszukiwania, zwłaszcza w Google. Jest to kontrowersyjna dziedzina: dla jej zwolenników jest to niezastąpiony sposób na ruch w sieci, podczas gdy dla jej przeciwników jest w najlepszym razie tandetny, aw najgorszym przypadku - hucksters, spamerów i oszustów. Niemniej jednak dla osób, które korzystają z publicznych wiki, wyświetlanie wysokich wyników wyszukiwania może być ważne.

Po pierwsze, MediaWiki jest już dobrze przygotowane do robienia dobrze wyników wyszukiwania na wiele sposobów. Wikipedia, która jest oczywiście oparta na MediaWiki, jest numerem jeden pod względem skuteczności wśród wyników wyszukiwania, pod względem metryki: zwykle znajduje się w pierwszej trójce, a często # 1, w przypadku wyszukiwania na dowolny temat, który obejmuje. Dzieje się tak głównie dlatego, że często łączy się z innymi stronami o tych konkretnych tematach, ale jest to również częściowo związane z własnym projektem MediaWiki.

W MediaWiki tematem każdej strony jest również: nazwa strony, część jej adresu URL, tekst w nagłówku najwyższego poziomu oraz tekst, który pojawia się w wewnętrznych linkach do tej strony. Taka spójność jest niezwykle ważna dla wyszukiwarek w powiązaniu tego słowa lub frazy z tym konkretnym adresem URL. W związku z tym zazwyczaj istnieje tylko jeden nagłówek najwyższego poziomu na stronie: nazwa strony jest zawarta w jedynym tagu <h1> na stronie, co jest kolejną rzeczą, która pomaga ustalić temat strony dla wyszukiwarek.

Istnieje co najmniej jedno aktywne rozszerzenie MediaWiki, które potencjalnie może pomóc dalej w rankingach wyszukiwarki: rozszerzenie WikiSEO, które dodaje do znaczników i kodu źródłowego kodu HTML strony wiki. Definiuje funkcję parsera o odpowiedniej nazwie „#seo”, którą można dodać w dowolnym miejscu strony, i która jest wywoływana w następujący sposób: {{#seo: title = ... | titlemode = ... | słowa kluczowe = ... | opis = ...}}

Parametr „title =” zastępuje, jest dołączany lub dołączany do zawartości znacznika HTML <title>, w zależności od wartości parametru „titlemode =”, który może być zastąpiony, dołączony lub poprzedzony. Parametry „keywords =” i „description =” są umieszczane odpowiednio jako atrybuty „name” i „content” znacznika HTML <meta>. Jeśli nie wiesz, jak najlepiej ustawić wszystkie te tagi, dobrym pomysłem jest sprawdzenie ich znaczenia i tego, w jaki sposób powinny być one najlepiej wykorzystywane do SEO.

Więcej informacji na temat WikiSEO znajdziesz tutaj:

Jeśli używasz szablonów typu infobox na większości stron, dobrą strategią jest umieszczenie tagu w szablonach, dzięki czemu nie musisz dodawać go ręcznie do każdej strony; a następnie wypełnij go określonymi parametrami z pola informacyjnego.

Prowadzenie farmy wiki

Nie jest niczym niezwykłym, że organizacje i korporacje chcą uruchamiać więcej niż jedną wiki; czasami o wiele więcej. Firma, która uruchamia publiczne wiki na różne tematy, dotyczące przychodów z reklam lub z jakiegokolwiek innego powodu, może skończyć z dużą ich liczbą. Wewnętrznie firmy mogą chcieć hostować więcej niż jedną wiki. Jak wspomniano, kontrola dostępu do danych jest jednym z powodów tutaj : najbezpieczniejszym sposobem na ograniczenie zbioru danych wiki do określonej grupy użytkowników jest przechowywanie ich w osobnej wiki. Różne działy w organizacji mogą chcieć mieć własne wiki, aby ograniczyć ich dane lub po prostu dlatego, że nie mają potrzeby udostępniania danych innym grupom. W bardzo dużej firmie lub innej organizacji liczba takich niezależnych oddziałów, które chciałyby, aby ich własne wiki mogły liczyć nawet w setkach.

Oczywiście każda grupa, która chciała mieć własną wiki, mogłaby je po prostu ustawić; jeśli wszyscy używają MediaWiki, instalacja jest bezpłatna i ogólnie nie jest zbyt trudna. (W rzeczywistości to właśnie historycznie zostały wprowadzone do organizacji wiki: małe grupy, które same je tworzą, w tak zwanych projektach „skunkworks”). Ale tego rodzaju konfiguracja może szybko stać się nieporęczna: jeśli inna osoba musi zostać ekspertem wiki, aby każda wiki była tworzona i utrzymywana, jest to zbyt dużo pracy. Nawet jeśli wszystkie wiki są zarządzane centralnie przez jedną osobę lub dział IT, może to być żmudna praca, gdy nadejdzie pora na aktualizację oprogramowania.

W takiej sytuacji to, co powinieneś używać, jest znane jako „farma wiki” lub czasami „rodzina wiki”: grupa wiki zarządzana z jednego miejsca, do której łatwo dodać dodatkowe wiki. W MediaWiki istnieje wiele sposobów tworzenia farmy wiki. Najlepsze odniesienie do czytania o różnych podejściach i sposobie konfiguracji każdego z nich znajduje się tutaj:

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

Na tej stronie znajduje się wiele podejść: pojedyncze i wielokrotne bazy kodu, pojedyncze i wiele baz danych, pojedyncze i wielokrotne instancje LocalSettings.php, itp. Jest jednak tylko jedno podejście, które naprawdę polecamy, czyli użycie pojedynczego baza kodu, wiele baz danych i wiele plików ustawień. Odpowiada to zasadniczo podejściu „strony w stylu Drupala” opisanemu na tej stronie.

Nie zajmiemy się tutaj pełnymi szczegółami technicznymi, ale podstawową ideą jest to, że masz oddzielną bazę danych dla każdej wiki, a także oddzielny plik ustawień. Każdy plik ustawień przypadający na wiki jest dołączany z poziomu LocalSettings.php. Poszczególne pliki ustawień określają nazwę bazy danych każdej wiki i pozwalają dostosować ustawienia wiki, w tym standardowe funkcje, takie jak nazwa wiki, logo, skóra i uprawnienia; oprócz zezwalania na rozszerzenia, które są dostępne tylko dla niektórych wiki.

Podręcznik „Rodzina Wiki” zawiera proste połączenie skryptu PHP i powłoki dla tego podejścia, które razem umożliwiają tworzenie i aktualizowanie bazy danych dla każdej wiki.

Musisz także wybrać strukturę adresów URL dla różnych wiki: dwa standardowe podejścia to użycie poddomen, takich jak „wiki1.mycompany.com” lub podkatalogi, np. „Mojafirma.com/wiki1”. Ta struktura musi być obsługiwana przez kombinację LocalSettings.php (która musi dowiedzieć się, którego pliku ustawień użyć, na podstawie adresu URL) oraz konfigurację serwera, która, jeśli używany jest Apache, jest zwykle plikiem httpd. conf. Szczegółowe ustawienia dla obu są zawarte w podręczniku „Rodzina Wiki”.

Jeśli z wyprzedzeniem wiesz, że będziesz mieć wiele wiki, może być pomocne posiadanie wspólnych kont użytkowników we wszystkich, aby użytkownicy nie musieli tworzyć nowego konta na każdej wiki, którą chcą edytować. Wikipedia robi to w skomplikowany sposób, używając rozszerzenia „CentralAuth”, ale w przypadku innych wiki można to zrobić w znacznie prostszy sposób, po prostu udostępniając różne bazy danych pojedynczy zestaw tabel dotyczących informacji o użytkowniku. Musisz tylko zdecydować, która baza danych będzie przechowywać informacje, a następnie dodać następujące informacje do LocalSettings.php: $ wgSharedDB = " main-database-name ";

Chociaż „udostępniona baza danych” brzmi jak wielka sprawa, domyślnie udostępniane są tylko tabele związane z informacjami o użytkowniku.

Wielojęzyczne wiki

Spośród wszystkich rzeczy, które administratorzy wiki zazwyczaj chcą robić, prawdopodobnie najbardziej koncepcyjnie trudna jest obsługa ich wiki w wielu językach. Dzieje się tak dlatego, że istnieje kompromis: chcesz, aby tekst, który każda osoba czyta w swoim języku, był jak najbardziej precyzyjny, ale jednocześnie chcesz uniknąć nadmiarowości, ponieważ nadmiarowość oznacza więcej pracy, aby zapewnić, że zawartość w różnych językach wszystkie pasują do siebie.

Po pierwsze, kilka dobrych wiadomości: tekst samego interfejsu - podobnie jak tekst w zakładkach „Edytuj” i „Wyświetl historię” lub tekst na specjalnych stronach - zazwyczaj nie stanowi problemu, ponieważ jeśli użytkownik ustawi swój język pod „Preferencje użytkownika”, są duże szanse, że cały ten tekst został przetłumaczony na ich język dzięki najwyższej klasy konfiguracji tłumaczenia MediaWiki.

To po prostu pozostawia zawartość wiki. W tym celu właściwe podejście zależy głównie od tego, czy treść ma być tworzona tylko przez użytkowników posługujących się jednym językiem, ale czytanych w wielu językach; lub czy treść ma być generowana przez użytkowników mówiących wieloma językami.

Istnieją zasadniczo trzy podejścia. W kolejności od najtrudniejszego do najmniej trudnego są:

Rysunek 15.4 Pasek z linkami do różnych tłumaczeń strony, udostępniany przez rozszerzenie Translate

• Tłumaczenie maszynowe treści. Dzięki takiemu podejściu zachowujesz całą zawartość w jednym języku, a następnie masz mechanizm umożliwiający ludziom tłumaczenie treści za pośrednictwem usługi tłumaczenia maszynowego. Zalecane jest rozszerzenie Live Translate: zapewnia łatwy w użyciu interfejs, kilka ciekawych dodatkowych funkcji i pozwala na korzystanie z usług tłumaczeniowych Google i Microsoft. Jest to zdecydowanie najłatwiejsze podejście do wielu języków. Możesz o tym przeczytać tutaj: