Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Jump to content

Podręcznik:Architektura MediaWiki

From mediawiki.org
This page is a translated version of the page Manual:MediaWiki architecture and the translation is 100% complete.
Languages:
Niniejszy dokument jest wynikiem projektu MediaWiki architecture document , którego treść została opracowana w celu włączenia do książki Architecture of Open Source Applications. rozdział książki zawiera sekcję przeglądu historycznego, która odpowiada Historia MediaWiki, a ta strona wiki była wielokrotnie edytowana od czasu publikacji rozdziału w 2012 roku.

Od samego początku MediaWiki zostało stworzone specjalnie jako oprogramowanie dla Wikipedii. Deweloperzy pracowali nad ułatwieniem ponownego wykorzystania tego oprogramowania przez użytkowników zewnętrznych, ale wpływ i jednostronność Wikipedii kształtowały architekturę MediaWiki w całej historii.

Wikipedia jest jedną z dziesięciu największych stron internetowych na świecie, obecnie ma około 400 milionów unikatowych odwiedzających miesięcznie. Uzyskuje ponad 100 000 wywołań na sekundę. Wikipedia nie jest wspierana komercyjnie przez reklamy; jest całkowicie wspierana przez organizację non-profit, Fundację Wikimedia, która opiera się na darowiznach jako podstawowym modelu finansowania. Oznacza to, że MediaWiki musi nie tylko prowadzić stronę internetową z pierwszej dziesiątki, ale także robić to przy skromnym budżecie. Aby sprostać tym wymaganiom, MediaWiki kładzie silny nacisk na wydajność, buforowanie i optymalizację. Kosztowne funkcje, których nie można włączyć w Wikipedii, są wycofywane lub wyłączane za pomocą zmiennej konfiguracyjnej; Istnieje nieskończona równowaga między wydajnością a funkcjonalnościami.

Wpływ Wikipedii na architekturę MediaWiki nie ogranicza się do wydajności. W przeciwieństwie do ogólnych CMS-ów, MediaWiki zostało pierwotnie napisane w bardzo konkretnym celu: wspierania społeczności, która tworzy i opiekuje się swobodnie współużywalną wiedzą na otwartej platformie. Oznacza to na przykład, że MediaWiki nie zawiera standardowych funkcji dostępnych w korporacyjnych CMS-ach (takich jak łatwy przepływ pracy publikacji czy listy dostępu ACL), ale oferuje różnorodne narzędzia do radzenia sobie ze spamem i wandalizmem.

Od samego początku potrzeby i działania stale rozwijającej się społeczności uczestników Wikipedii wpłynęły na rozwój MediaWiki - i odwrotnie! Architektura MediaWiki była wielokrotnie inspirowana przez inicjatywy rozpoczęte lub wyproszone przez społeczność, takie jak utworzenie Wikimedia Commons lub funkcja Oflagowanych Wersji. Programiści dokonali poważnych zmian w architekturze, takich jak preprocesor MediaWiki 1.12, ponieważ sposób, w jaki Wikipedyści korzystali z MediaWiki, wymagał tego.

MediaWiki zyskało również solidną bazę użytkowników zewnętrznych dzięki temu, że jest oprogramowaniem open-source. Zewnętrzni użytkownicy wiedzą, że tak długo tak popularna strona internetowa jak Wikipedia korzysta z MediaWiki, oprogramowanie będzie utrzymywane i ulepszane. MediaWiki dotychczas koncentrowała się na witrynach Wikimedia, ale postanowiono uczynić ją bardziej ogólną i lepiej odpowiadać potrzebom użytkowników stron trzecich. Na przykład, MediaWiki jest dostarczane z doskonałym instalatorem internetowym, dzięki czemu proces instalacji jest znacznie mniej bolesny niż wtedy, gdy wszystko musiało być wykonane za pomocą wiersza poleceń, a oprogramowanie zawierało zakodowane na stałe ścieżki dla Wikipedii.

Mimo to, MediaWiki jest i pozostaje oprogramowaniem Wikipedii, co widać w całej jej historii i architekturze.

Baza kodu i najlepsze praktyki MediaWiki

Ogólna architektura
Warstwa użytkownika przeglądarka internetowa
Warstwa sieciowa Varnish
Serwer WWW Apache
Warstwa logiczna Skrypty PHP MediaWiki
PHP
Warstwa danych System plików Baza danych MySQL (program i zawartość) System buforowania

PHP

PHP został wybrany jako framework dla oprogramowania Wikipedii "Phase II" w 2001 roku; Od tego czasu MediaWiki rozrosła się organicznie i wciąż ewoluuje. Większość programistów MediaWiki to wolontariusze wnoszący swój wkład w swoim wolnym czasie, a we wczesnych latach było ich bardzo niewielu. Z perspektywy czasu niektóre decyzje lub pominięcia w projektowaniu oprogramowania mogą wydawać się błędne, ale trudno krytykować założycieli za to, że nie zaimplementowali jakiejś abstrakcji, która teraz okazuje się krytyczna, gdy początkowa baza kodu była tak mała, a czas potrzebny na jej opracowanie - tak krótki.

Na przykład, MediaWiki używa nazw klas bez prefiksu, co może powodować konflikty, gdy programiści PHP core i PECL dodają nowe klasy. W konsekwencji, klasa MediaWiki Namespace musiała zostać przemianowana na MWNamespace, aby była kompatybilna z PHP 5.3. Konsekwentne używanie prefiksu dla wszystkich klas (np. "MW") ułatwiłoby osadzanie MediaWiki w innej aplikacji lub bibliotece.

Poleganie na PHP prawdopodobnie nie było najlepszym wyborem pod względem wydajności, ponieważ nie skorzystało ono z ulepszeń, które otrzymały niektóre inne dynamiczne języki. Użycie języka Java byłoby znacznie lepsze pod względem wydajności i uproszczonego skalowania zadań konserwacji back-endu. Z drugiej strony PHP cieszy się dużą popularnością, co ułatwia rekrutację nowych programistów.

Nawet jeśli MediaWiki nadal zawiera "brzydki" przestarzały kod, na przestrzeni lat wprowadzono wiele ulepszeń, a nowe elementy architektury zostały wprowadzone do MediaWiki w całej jej historii. Należą do nich klasy Parser, SpecialPage i Database, klasa Image i hierarchia klas FileRepo, hierarchia ResourceLoader i Action. MediaWiki zaczynało bez żadnej z tych rzeczy, ale wszystkie z nich obsługują funkcje, które istnieją od samego początku. Wielu programistów jest zainteresowanych przede wszystkim rozwojem funkcjonalności, a architektura często pozostaje w tyle - tylko po to, by później nadrobić zaległości, kiedy koszt pracy w niedopasowanej architekturze staje się widoczny.

Bezpieczeństwo

Ponieważ MediaWiki jest oprogramowaniem obsługującym sławne witryny internetowe, takie jak Wikipedia - główni programiści i recenzenci kodu narzucili surowe zasady bezpieczeństwa. Aby ułatwić pisanie bezpiecznego kodu, MediaWiki daje programistom wrappery na temat wyszukiwania HTML i danych, aby poradzić sobie z ucieczką. Aby zdezyfekować dane wejściowe użytkownika, używa się klasy WebRequest, która analizuje dane przekazane w adresie URL lub za pośrednictwem formularza POSTed. Usuwa ukośniki z "magicznymi cudzysłowami", usuwa niedozwolone znaki wejściowe i normalizuje sekwencje napisów Unicode. Cross-site request forgery (CSRF) jest unikane za pomocą tokenów, a cross-site scripting (XSS) poprzez walidację danych wejściowych i ucieczki danych wyjściowych, zwykle za pomocą funkcji htmlspecialchars() PHP. MediaWiki zapewnia (i wykorzystuje) również dezyfekcję HTML przy pomocy klasy Sanitizer oraz funkcje bazy danych, które zapobiegają wstrzyknięciu SQL.

Konfiguracja

MediaWiki oferuje setki ustawień konfiguracji, przechowywanych w globalnych zmiennych PHP. Ich domyślna wartość jest ustawiona na DefaultSettings.php, a administrator systemu może je odwrócić poprzez edycję LocalSettings.php.

MediaWiki było zbyt uzależnione od zmiennych globalnych, w tym w zakresie konfiguracji i przetwarzania kontekstu. Zmienne globalne powodują poważne konsekwencje bezpieczeństwa z funkcją PHP register_globals (której MediaWiki nie potrzebuje od wersji 1.2). System ten ogranicza również potencjalne abstrakcje konfiguracji i utrudnia optymalizację procesu uruchamiania. Co więcej, przestrzeń nazw konfiguracji jest współdzielona ze zmiennymi używanymi do rejestracji i kontekstu obiektu, co prowadzi do potencjalnych konfliktów. Z punktu widzenia użytkownika, globalne zmienne konfiguracji sprawiły, że MediaWiki wydawało się trudne do konfigurowania i utrzymania. Rozwój MediaWiki to historia powolnego przenoszenia kontekstu ze zmiennych globalnych do obiektów. Przechowywanie kontekstu przetwarzania w zmiennych składowych obiektu pozwala na bardziej elastyczne ponowne wykorzystanie tych obiektów.

Baza danych i przechowywanie tekstu

Schemat bazy danych rdzenia MediaWiki

MediaWiki korzysta z zaplecza relacyjnej bazy danych od czasu oprogramowania Fazy II. Domyślnym (i najlepiej obsługiwanym) systemem DBMS dla MediaWiki jest MySQL, z którego korzystają wszystkie strony Wikimedia. Jednak inne systemy DBMS (takie jak PostgreSQL, Oracle i SQLite) mają implementacje obsługiwane przez społeczność. Sysadmin może wybrać DBMS podczas instalacji MediaWiki, a MediaWiki zapewnia zarówno abstrakcję bazy danych, jak i warstwę abstrakcji zapytania, która ułatwia dostęp do bazy danych dla deweloperów.

bieżący układ zawiera dziesiątki tabel. Wiele z nich dotyczy treści wiki (np. page, revision, category, recentchanges). Inne tabele - między innymi- obejmują dane dotyczące użytkowników (user, user_groups), plików multimedialnych (image, filearchive), pamięci podręcznej (objectcache, l10n_cache, querycache) i narzędzi wewnętrznych (job dla kolejki zadań). Indeksy i tabele podsumowujące są szeroko stosowane w MediaWiki, ponieważ zapytania SQL, które skanują ogromną liczbę wierszy, mogą być kosztowne (zwłaszcza na stronach Wikimedia). Zapytania nieindeksowane są zwykle odradzane.

Baza danych przeszła dziesiątki zmian schematu na przestrzeni lat, z których najbardziej godną uwagi było rozdzielenie przechowywania tekstu i śledzenia wersji w MediaWiki 1.5.

Główne tabele zawartości w MediaWiki 1.4 i 1.5.

W modelu 1.4 treść była przechowywana w dwóch ważnych tabelach, cur (zawierających tekst i metadane aktualnej rewizji strony) i old (zawieranie poprzednich rewizji); usunięte strony były przechowywane w archive. Po wprowadzeniu zmian poprzednio bieżąca poprawka została skopiowana do tabeli old, a nowa edycja została zapisana do cur. Kiedy strona została przemianowana, tytuł strony musiał zostać zaktualizowany w metadatach wszystkich old wersji zmian, co mogłoby być długą operacją. Gdy strona była usuwana, jej wpisy w tabelach cur i old musiały zostać skopiowane do tabeli archive przed usunięciem; Oznaczało to przeniesienie tekstu wszystkich poprawek - które mogły być bardzo duże - a tym samym czasochłonne.

W modelu 1.5 metadane wersji i tekst wersji zostały podzielone: tabele cur i old zostały zastąpione przez page (metadane stron), revision (metadane dla wszystkich wersji, starych lub bieżących) i text (tekst wszystkich wersji, starych, bieżących lub usuniętych). Teraz, gdy wprowadzana jest edycja, metadane poprawki nie muszą być kopiowane miedzy tabelami. Wystarczy wstawić nowy wpis i zaktualizować wskaźnik page_latest. Ponadto, metadane wersji nie zawierają już tytułu strony, a jedynie jej identyfikator: eliminuje to potrzebę zmiany nazw wszystkich wersji, gdy nazwa strony jest zmieniana.

Tabela revision przechowuje metadane dla każdej wersji, ale nie ich tekst; zamiast tego zawierają identyfikator tekstowy wskazujący tabelę text, która zawiera rzeczywisty tekst. Gdy strona zostanie usunięta, tekst wszystkich wersji strony pozostaje na niej i nie trzeba go przenosić do innej tabeli. Tabela text składa się z mapowania identyfikatorów na tekstowe obiekty blob; Pole Flags wskazuje, czy tekstowy obiekt blob jest spakowany metodą Gzip (w celu zaoszczędzenia miejsca), czy też tekstowy obiekt blob jest tylko wskaźnikiem do zewnętrznego magazynu tekstu. Strony Wikimedia korzystają z zewnętrznego klastra pamięci masowej wspieranego przez MySQL, z polami binarnymi typu blob zawierającymi kilkadziesiąt wersji. Pierwsza wersja obiektu blob jest przechowywana w całości, a kolejne wersje tej samej strony są przechowywane jako różnice względem poprzedniej wersji; Obiekty blob są następnie spakowane w gzip. Ponieważ wersje są pogrupowane wg stron, to zwykle są podobne - więc różnice są stosunkowo małe i gzip działa dobrze. Współczynnik kompresji osiągnięty na witrynach Wikimedia jest bliski 98%.

MediaWiki ma również wbudowaną obsługę równoważenia obciążenia, dodaną już w 2004 roku w MediaWiki 1.2 (kiedy Wikipedia otrzymała swój drugi serwer - w tamtych czasach była to wielka sprawa). Load balancer (kod PHP MediaWiki, który decyduje, z którym serwerem się połączyć) jest teraz krytyczną częścią infrastruktury Wikimedia, co wyjaśnia jego wpływ na niektóre decyzje algorytmów w kodzie. Administrator systemu może określić w konfiguracji MediaWiki, że istnieje jeden główny serwer bazy danych i dowolna liczba podrzędnych serwerów baz danych; Do każdego serwera można przypisać wagę. Load balancer wyśle wszystkie zapisy do mastera i zrównoważy odczyty zgodnie z wagami. Śledzi również opóźnienie replikacji każdego urządzenia podrzędnego. Jeśli opóźnienie replikacji urządzenia podrzędnego przekroczy 30 sekund, nie otrzyma ono żadnych zapytań odczytu, które pozwoliłyby mu nadrobić zaległości; jeśli wszystkie urządzenia podrzędne są opóźnione o więcej niż 30 sekund, MediaWiki automatycznie przełączy się w tryb tylko do odczytu.

"Zabezpieczenie chronologii" MediaWiki zapewnia, że opóźnienie replikacji nigdy nie spowoduje, że użytkownik zobaczy stronę, która twierdzi, że akcja, którą właśnie wykonał, jeszcze się nie wydarzyła. Odbywa się to poprzez zapisanie pozycji wzorca w sesji użytkownika, jeśli wysłane przez niego żądanie spowodowało zapytanie zapisu. Następnym razem, gdy użytkownik zażąda odczytu, moduł równoważenia obciążenia odczytuje tę pozycję z sesji i próbuje wybrać urządzenie podrzędne, które dogoniło tę pozycję replikacji, aby obsłużyć żądanie. Jeśli żaden z nich nie jest dostępny, zaczeka, aż będzie. Inni użytkownicy mogą postrzegać akcję jako jeszcze nie dokonaną, ale chronologia pozostaje spójna dla każdego użytkownika.


Zapytania, buforowanie i dostarczanie

Przepływ pracy wykonywania żądania internetowego

index.php jest głównym punktem dostępowym dla MediaWiki i obsługuje większość żądań przetwarzanych przez serwery aplikacji (tj. żądań, które nie były obsługiwane przez infrastrukturę buforowania; patrz niżej). Kod wykonywany od index.php przeprowadza kontrole bezpieczeństwa, ładuje domyślne ustawienia konfiguracji od includes/DefaultSettings.php, odgaduje konfigurację z includes/Setup.php, a następnie aplikuje ustawienia witryny zawarte w LocalSettings.php. Następnie tworzy instancję obiektu o wartości MediaWiki ($mediawiki) i tworzy obiekt Title ($wgTitle) w zależności od tytułu i parametrów akcji z zapytania.

index.php może przyjmować różne parametry akcji w żądaniu adresu URL; Domyślna akcja to view, która pokazuje zwykły widok zawartości artykułu. Na przykład, żądanie https://en.wikipedia.org/w/index.php?title=Apple&action=view wyświetla treść artykułu "Apple" w angielskiej Wikipedii[1]. Inne częste działania to edit (aby otworzyć artykuł do edycji), submit (aby wyświetlić podgląd lub zapisać artykuł), history (aby wyświetlić historię artykułu) i watch (aby dodać artykuł do listy obserwowanych użytkownika). Działania administracyjne obejmują delete (w celu usunięcia artykułu) i protect (w celu zablokowania edycji artykułu).

MediaWiki::performRequest() jest następnie wywoływany w celu obsłużenia większości żądań adresu URL. Sprawdza, czy nie ma złych tytułów, ograniczeń odczytu, lokalnych przekierowań interwiki i pętli przekierowań, a także określa, czy zapytanie dotyczy normalnej czy specjalnej strony.

Normalne zapytania stron są przekazywane do MediaWiki::initializeArticle(), aby utworzyć obiekt Article dla strony ($wgArticle), a następnie do MediaWiki::performAction(), który obsługuje "standardowe" akcje. Po zakończeniu akcji MediaWiki::doPostOutputShutdown() finalizuje żądanie, zatwierdzając transakcje bazy danych, wyprowadzając kod HTML i uruchamiając odroczone aktualizacje za pośrednictwem kolejki zadań. MediaWiki::restInPeace() zatwierdza odroczone aktualizacje i bezpiecznie zamyka zadanie.

Jeśli żądana strona jest stroną specjalną (tj. nie jest to zwykła strona wiki, ale specjalna strona związana z oprogramowaniem, taka jak Statistics), wywoływane jest SpecialPageFactory::executePath zamiast initializeArticle(); następnie wywoływany jest odpowiedni skrypt PHP. Strony specjalne mogą robić różnego rodzaju magiczne rzeczy, a każda z nich ma określony cel, zwykle niezależnie od pojedynczego artykułu lub jego treści. Specjalne strony zawierają między innymi różnego rodzaju raporty (ostatnie zmiany, logi, strony bez kategorii) i narzędzia do administrowania wiki (m.in. blokady użytkowników, zmiany uprawnień użytkowników). Ich przepływ pracy zależy od ich funkcji.

Wiele funkcji zawiera kod profilowania, który umożliwia śledzenie przepływu pracy wykonywania w celu debugowania - jeśli profilowanie jest włączone. Profilowanie odbywa się przez wywołanie funkcji wfProfileIn i wfProfileOut w celu odpowiedniego rozpoczęcia i zakończenia profilowania funkcji; Obie funkcje przyjmują nazwę funkcji jako parametr. Na stronach Wikimedia profilowanie jest ograniczone dla pewnej części wszystkich żądań - aby zachować wydajność. MediaWiki wysyła pakiety UDP na centralny serwer, który zbiera je i produkuje dane profilowe.

Montaż strony niebuforowanej

Podczas przeglądania strony kod HTML może zostać pobrany z pamięci podręcznej (patrz poniżej); Jeśli nie, najpierw rozwijane są szablony, funkcje parsera i zmienne. Daje to wikikod rozwinięty, wynik pośredni, który można zobaczyć za pomocą Special:ExpandTemplates, i zależy on od:

  • wikikodu;
  • szablonów bezpośrednio lub pośrednio odnoszących się do nich;
  • Funkcji parsera powoływanych bezpośrednio lub pośrednio;
  • Wartości zmiennych odnoszących się bezpośrednio lub pośrednio.

W nastęnym kroku ten rozszerzony wikikod jest konwertowany na kod HTML; Jest on wysyłany do użytkownika i zawiera odwołania do plików CSS, JavaScript i plików obrazów. Użytkownik może zobaczyć ten pośredni wynik, stosując opcję "wyświetl źródło" przeglądarki. Kod HTML danej strony zależy od:

  • rozwiniętego wikitekstu;
  • trybu, takiego jak przeglądanie lub edycja (patrz poniżej);
  • istnienia stron wewnętrznie powiązanych (zwróci widok lub edycję linka);
  • skórka i inne preferencje użytkownika;
  • nazwę użytkownika;
  • statusu użytkownika (więcej linków, jeśli jest administratorem itp.);
  • przestrzeń nazw (określa link do strony dyskusji lub, w przypadku strony dyskusji, do danej strony);
  • czy strona jest obserwowana przez użytkownika (podaje link obserwuj lub przestań obserwować);
  • czy strona dyskusji użytkownika była ostatnio edytowana (wyświetla komunikat).

Na koniec przeglądarka renderuje kod HTML przy użyciu plików, do których się odwołuje. Wynik, który użytkownik widzi na ekranie, zależy od:

  • kod HTML;
  • plików, o których mowa w kodzie HTML, takich jak obrazy osadzone, pliku CSS z serwera i pliki JavaScript;
  • przeglądarki i ustawień przeglądarki, w tym ewentualnie lokalnego pliku CSS, oraz rozdzielczości ekranu.

Jeśli JavaScript reaguje na zdarzenie, takie jak kliknięcie myszą, strona na ekranie zależy również od tych zdarzeń. Dotyczy to na przykład tabeli sortowalnej.

Gdy użytkownik wybierze zakładkę edytuj, wysyłany jest do niego sam wikikod, obejmujący całą stronę lub tylko jedną sekcję. Gdy użytkownik naciśnie Pokaż podgląd, jego nowa wersja wikikodu jest wysyłana na serwer, który wysyła odpowiednią nową wersję kodu HTML, która jest ponownie renderowana i wyświetlana powyżej lub poniżej nowej wersji wikikodu użytkownika (którą serwer również zwrócił). Po możliwie większej liczbie zmian i podglądów, użytkownik naciska Zapisz stronę, wysyłając "ostateczną" wersję użytkownika na serwer, który teraz rejestruje edycję i wysyła HTML nowej wersji (ponownie). W niektórych przypadkach automatyczna konwersja wikitekstu również ma miejsce na tym etapie.


Buforowanie

Samo MediaWiki zostało ulepszone pod kątem wydajności, ponieważ odgrywa centralną rolę na stronach Wikimedia, ale jest również częścią większego ekosystemu operacyjnego, który wpłynął na jej architekturę. Infrastruktura buforowania Wikimedia nałożyła ograniczenia na MediaWiki; Programiści obeszli te problemy, nie próbując kształtować szeroko zoptymalizowanej infrastruktury buforowania Wikimedia wokół MediaWiki, ale raczej czyniąc MediaWiki bardziej elastycznym, aby mogło działać w ramach tej infrastruktury, bez uszczerbku dla wydajności i potrzeb buforowania.

Na stronach Wikimedia większość zapytań jest obsługiwana przez serwery proxy buforowania wstecznego (Squids) i nigdy nie dociera do serwerów aplikacji MediaWiki. Squids zawierają statyczne wersje całych renderowanych stron, dostarczane do prostych odczytów użytkownikom, którzy nie są zalogowani w witrynie. MediaWiki natywnie obsługuje Squid oraz Varnish i integruje się z tą warstwą buforowania, na przykład powiadamiając je o konieczności usunięcia strony z pamięci podręcznej, gdy ta została zmieniona. W przypadku zalogowanych użytkowników oraz innych zapytań, które nie mogą być obsłużone przez Squids, Squid przekazuje żądania do serwera WWW (Apache).

Drugi poziom buforowania ma miejsce, gdy MediaWiki renderuje i składa stronę z wielu obiektów, z których wiele może być buforowanych, aby zminimalizować przyszłe wywołania. Do takich obiektów należą interfejs strony (pasek boczny, menu, tekst interfejsu użytkownika) oraz właściwa zawartość, przetworzona z wikikodu. Pamięć podręczna obiektów przechowywanych w pamięci jest dostępna w MediaWiki od wczesnej wersji 1.1 (2003) i jest szczególnie ważna, aby uniknąć ponownego analizowania długich i złożonych stron.

Dane sesji logowania mogą być również przechowywane w memcached, co pozwala sesjom działać w sposób przezroczysty na wielu serwerach front-end w konfiguracji równoważenia obciążenia (Wikimedia w dużym stopniu polega na równoważeniu obciążenia, używając LVS razem z PyBal).

Od wersji 1.16, MediaWiki używa dedykowanego bufora obiektów dla zlokalizowanego językowo tekstu interfejsu użytkownika; Zostało to dodane po zauważeniu, że duża część obiektów buforowanych w memcached składała się z komunikatów interfejsu użytkownika zlokalizowanych w języku użytkownika. System opiera się na szybkim pobieraniu pojedynczych wiadomości z baz danych stałych (CDB), czyli plików z parami klucz-wartość. W typowym przypadku CDB minimalizują obciążenie pamięci i czas uruchamiania; Są one również używane w pamięci podręcznej interwiki.

Ostatnia warstwa buforowania składa się z pamięci podręcznej kodu operacyjnego PHP (ang. opcode), zwykle włączanej w celu przyspieszenia aplikacji PHP. Kompilacja może być długotrwałym procesem; Aby uniknąć kompilowania skryptów PHP do kodu pośredniego za każdym razem, gdy są wywoływane, akcelerator PHP może być użyty do przechowywania skompilowanego kodu operacji i wykonywania go bezpośrednio bez kompilowania. MediaWiki będzie "po prostu działać" z wieloma akceleratorami, takimi jak APC - akcelerator PHP.

Ze względu na swoje dopasowanie specjalnie do Wikimedii, MediaWiki jest optymalizowane dla tej kompletnej, wielowarstwowej, rozproszonej infrastruktury pamięci pamięci zapasowej. Niemniej jednak natywnie obsługuje również alternatywne konfiguracje dla mniejszych witryn. Na przykład oferuje opcjonalny uproszczony system buforowania plików, który przechowuje postacie wyjśiowe w pełni przetworzonych stron, tak jak robi to Squid. Ponadto, warstwa buforowania abstrakcyjnych obiektów MediaWiki pozwala na przechowywanie obiektów w pamięci podręcznej w kilku miejscach, w tym w systemie plików, bazie danych lub pamięci podręcznej opcode.

ResourceLoader

Podobnie jak wiele innych aplikacji internetowych, interfejs MediaWiki stał się z biegiem lat bardziej interaktywny i responsywny, głównie dzięki użyciu JavaScript. Działania na rzecz użyteczności zainicjowane w 2008 r., a także zaawansowana obsługa multimediów (np. edycja plików wideo online) wymagały dedykowanej poprawy wydajności front-endu.

Aby zoptymalizować dostarczanie zasobów JavaScript i CSS, opracowano moduł ResourceLoader. Została zapoczątkowany w 2009 roku, ukończony w roku 2011 i jest podstawową funkcją MediaWiki od wersji 1.17. ResourceLoader działa poprzez ładowanie zasobów JS i CSS na żądanie, skracając w ten sposób czas ładowania i parsowania nieużywanych funkcji, na przykład w starszych przeglądarkach. Minimalizuje również kod, grupuje zasoby w celu zapisywania żądań i może osadzać obrazy jako identyfikatory URI.

Języki

Strona główna: Manual:Language

Kontekst i uzasadnienie

Najistotniejszą cześcią skutecznego przyczyniania się i rozpowszechniania wolnej wiedzy dla wszystkich jest dostarczanie jej w jak największej liczbie języków. Wikipedia jest dostępna w ponad 280 językach, a artykuły encyklopedii w języku angielskim stanowią mniej niż 20% wszystkich artykułów. Ponieważ Wikipedia i jej siostrzane strony istnieją w tak wielu językach, ważne jest nie tylko dostarczanie treści w języku ojczystym czytelników, ale także zapewnienie dopasowanego jezykowo interfejsu oraz skutecznych narzędzi do wprowadzania i konwersji treści, aby uczestnicy mogli bezproblemowo dopisywać wkład.

Z tego powodu, lokalizacja i internacjonalizacja (l10n i i18n) są centralnym komponentem MediaWiki. System i18n jest wszechobecny i wpływa na wiele części oprogramowania; Jest również jednym z najbardziej elastycznych i bogatych w funkcje. Wygoda tłumacza jest zwykle ceniona bardziej niż wygoda programisty - jednak uważa się, że jest to akceptowalny koszt.

MediaWiki jest obecnie zlokalizowane w ponad 350 językach, w tym w językach nie związanych z łacińskim oraz z zapisem od prawej do lewej (RTL), o różnym stopniu kompletności. Interfejs i zawartość mogą być w różnych językach i mogą mieć mieszaną kierunkowość pisma.

Język treści

MediaWiki pierwotnie używało kodowania według języka, co prowadziło do wielu problemów; Na przykład w tytułach stron nie można było używać obcych skryptów. Zamiast tego przyjęto UTF-8. Wsparcie dla zestawów znaków innych niż UTF-8 zostało porzucone w 2005 roku, wraz z dużą zmianą schematu bazy danych w MediaWiki 1.5; Treść musi być teraz zakodowana w UTF-8.

Znaki niedostępne na klawiaturze edytora mogą być dostosowywane i wstawiane za pomocą Edittools w interfejsie MediaWiki, komunikatu wyświetlanego pod oknem edycji; jego wersja JavaScript automatycznie wstawia kliknięty znak do okna edycji. Rozszerzenie WikiEditor dla MediaWiki, opracowane w ramach prac w zakresie poprawy użyteczności, łączy specjalne znaki z paskiem narzędzi edycji. Inne rozszerzenie, zwane UniversalLanguageSelector , zapewnia dodatkowe metody wejścia i funkcje mapowania kluczowych znaków poza ASCII.

Niedawne i przyszłe ulepszenia obejmują lepszą obsługę tekstu pisanego od prawej do lewej, tekst dwukierunkowy (tekst LTR i RTL na tej samej stronie) oraz UniversalLanguageSelector .

Język interfejsu użytkownika

Komunikaty interfejsu są przechowywane w tablicach PHP w parach klucz-wartość od czasu stworzenia oprogramowania Phase III. Każdy komunikat jest identyfikowany za pomocą unikalnego klucza, który ma przypisane różne wartości w różnych językach. Klucze są określane przez deweloperów, którzy są zachęcani do używania prefiksów dla rozszerzeń; Na przykład, klucze wiadomości dla rozszerzenia UploadWizard będą zaczynać się od mwe-upwiz-, gdzie mwe oznacza MediaWiki extension.

Komunikaty MediaWiki mogą zawierać parametry dostarczone przez oprogramowanie, które często wpływają na gramatykę wiadomości. Aby zapewnić obsługę praktycznie każdego możliwego języka, system lokalizacji MediaWiki został z czasem ulepszony i złożony, aby dostosować się do ich specyficznych cech i wyjątków - często uważanych za kuriozum przez użytkowników języka angielskiego.

Na przykład przymiotniki są niezmiennąmi słowami w języku angielskim, ale języki takie jak francuski wymagają zgodności przymiotników z rzeczownikami. Jeśli profil użytkownika ma ustawione preferencje płci, przełącznik {{GENDER:}} może być używany w wiadomościach interfejsu, aby odpowiednio się do nich zwrócić (więcej informacji). Inne przełączniki to {{PLURAL:}} dla "prostych" liczb mnogich i języków takich jak arabski z liczbą podwójną, próbną lub liczbę paucalną (drobnoliczną), oraz {{GRAMMAR:}}, która zapewnia funkcje transformacji gramatycznej dla języków takich jak fiński, których przypadki gramatyczne powodują zmiany lub fleksje.

Rozróżnienie płci może być również używane w nazwach przestrzeni nazw użytkowników zależnych od płci, tak aby tytuł strony i adres URL poprawnie odnosiły się do użytkownika. Warianty płci w standardowych przestrzeniach nazw MediaWiki są definiowane za pomocą $namespaceGenderAliases w MessagesXx.php każdego języka, podczas gdy $wgExtraGenderNamespaces może być używane dla przestrzeni nazw specyficznych dla wiki. Od r107559 - 13 języków domyślnie korzysta z tej funkcji:

  • Arabic
  • Czech
  • German
  • Lower Sorbian
  • Spanish
  • Galician
  • Hebrew
  • Upper Sorbian
  • Polish
  • Brazilian Portuguese
  • Portuguese
  • Russian
  • Saterland Frisian

Lokalizacja komunikatów

Zobacz też: [[:Help:Komunikaty systemowe ]]

Zlokalizowane komunikaty interfejsu dla MediaWiki znajdują się w plikach MessagesXx.php, gdzie Xx to kod języka ISO-639 (np. MessagesFr.php dla francuskiego); domyślne komunikaty są w języku angielskim i przechowywane w MessagesEn.php. Rozszerzenia MediaWiki korzystają z podobnego systemu lub przechowują wszystkie zlokalizowane wiadomości w [Nazwa-rozszerzenia].i18n.php plik. Oprócz tłumaczeń pliki komunikatów zawierają również informacje zależne od języka, takie jak formaty dat.

Tłumaczenia były kiedyś wykonywane poprzez przesyłanie poprawek za PHP dla plików za MessagesXx.php. W grudniu 2003 roku MediaWiki 1.1 wprowadziło "komunikaty bazy danych": podzbiór stron wiki w przestrzeni nazw MediaWiki zawierający komunikaty interfejsu. Zawartość strony wiki MediaWiki:[Message-key] jest tekstem wiadomości i nadpisuje jej wartość w pliku PHP. Zlokalizowane wersje komunikatów znajdują się pod adresem MediaWiki:[Message-key]/[kod-języka], np. MediaWiki:Rollbacklink/de.

Ta funkcjonalność pozwoliła zaawansowanym użytkownikom tłumaczyć (i dostosowywać) komunikaty interfejsu lokalnie na swojej wiki, ale proces ten nie aktualizuje plików i18n dostarczanych z MediaWiki. W 2006 roku Niklas Laxström stworzył specjalną, mocno przetworzoną stronę MediaWiki (obecnie hostowaną na translatewiki.net), na której tłumacze mogą łatwo dopasowywać do lokalnych języków komunikaty interfejsu we wszystkich językach, po prostu edytując stronę wiki. Pliki MessagesXx.php są następnie aktualizowane w repozytorium kodu MediaWiki, skąd mogą być automatycznie pobrane przez dowolną wiki. Na stronach Wikimedia komunikaty z bazy danych są teraz używane tylko do dostosowywania, ale nie do lokalizacji. Rozszerzenia MediaWiki i niektóre powiązane programy, takie jak boty, są również lokalizowane na translatewiki.net.

Aby pomóc tłumaczom zrozumieć kontekst i znaczenie komunikatu interfejsu, dobrą praktyką w MediaWiki jest dostarczanie dokumentacji dla każdej wiadomości. Ta dokumentacja jest przechowywana w specjalnym pliku komunikatów z kodem języka qqq, który nie odpowiada prawdziwemu językowi. Dokumenty dla każdego wiadomości są następnie wyświetlane w interfejsie tłumaczenia na translatewiki.net. Innym pomocnym narzędziem jest kod języka qqx : gdy jest używany z parametrem &uselang do wyświetlenia strony wiki (np. en.wikipedia.org/wiki/Special:RecentChanges?uselang=qqx), MediaWiki wyświetli klucze wiadomości zamiast ich wartości w interfejsie użytkownika; Jest to bardzo przydatne do określenia, który komunikat należy przetłumaczyć lub zmienić.

Wykres języków awaryjnych

Zarejestrowani użytkownicy mogą ustawić własny język interfejsu w swoich preferencjach, w takim przypadku zastępuje on domyślny język interfejsu witryny. MediaWiki obsługuje również języki awaryjne: jeśli wiadomość nie jest dostępna w wybranym języku, zostanie wyświetlona w najbliższym możliwym języku - niekoniecznie w języku angielskim. Na przykład językiem zastępczym dla języka bretońskiego jest francuski.

Użytkownicy

Użytkownicy są reprezentowani w kodzie przy użyciu instancji z klasy User, która hermetyzuje wszystkie ustawienia specyficzne dla użytkownika (identyfikator użytkownika, nazwę, uprawnienia, hasło, adres e-mail itp.). Klasy klienta używają metod dostępu do uzyskiwania dostępu do tych pól; Wykonują one całą pracę polegającą na ustaleniu, czy użytkownik jest zalogowany i czy żądana opcja może zostać zrealizowana z plików cookie, czy też potrzebne jest zapytanie do bazy danych. Większość ustawień potrzebnych do renderowania normalnych stron jest ustawiana w pliku cookie, aby zminimalizować korzystanie z bazy danych.

MediaWiki zapewnia bardzo szczegółowy system uprawnień, z zasadniczo uprawnieniami użytkownika do każdej możliwej akcji. Na przykład, aby wykonać akcję "Wycofaj" (tj. "szybko wycofać edycje ostatniego użytkownika, który edytował daną stronę"), użytkownik potrzebuje uprawnienia rollback, które jest domyślnie zawarte w grupie użytkowników MediaWiki sysop. Ale może być również dodawany do innych grup użytkowników lub mieć dedykowaną grupę użytkowników tylko zapewniającą to uprawnienie (tak jest w przypadku angielskiej Wikipedii, z grupą Rollbackers). Dostosowywanie uprawnień użytkownika odbywa się poprzez edycję tablicy $wgGroupPermissions w LocalSettings.php; Na przykład $wgGroupPermissions['user']['movefile'] = true; pozwala wszystkim zarejestrowanym użytkownikom na zmianę nazw plików. Użytkownik może należeć do kilku grup i dziedziczy najwyższe prawa skojarzone z każdą z nich.

Jednak system uprawnień użytkowników MediaWiki został zaprojektowany z myślą o Wikipedii, tj. stronie, której zawartość jest dostępna dla wszystkich, a tylko niektóre działania są ograniczone do niektórych użytkowników. W MediaWiki brakuje ujednoliconej, wszechobecnej koncepcji uprawnień; nie zapewnia ona tradycyjnych funkcji CMS, takich jak ograniczanie dostępu do odczytu lub zapisu według przestrzeni nazw, kategorii itp. Kilka rozszerzeń MediaWiki zapewnia takie funkcje do pewnego stopnia.

Treści

Struktura treści

Koncepcja przestrzeni nazw była używana w erze UseModWiki Wikipedii, gdzie strony dyskusji były pod tytułem "[nazwa artykułu]/Talk". Przestrzenie nazw zostały formalnie wprowadzone w pierwszym "skrypcie PHP" Magnusa Manske. Na przestrzeni lat były one kilkakrotnie tworzone od nowa, ale zachowały tę samą funkcję: oddzielanie różnych rodzajów treści. Składają się z prefiksu, oddzielonego od tytułu strony dwukropkiem (np. Talk: lub File: i Template:); Główna przestrzeń nazw treści nie ma prefiksu. Użytkownicy Wikipedii szybko je zaadoptowali, a one zapewniły społeczności różne przestrzenie do rozwoju. Przestrzenie nazw okazały się być ważną cechą MediaWiki, ponieważ tworzą niezbędne warunki wstępne dla społeczności wiki i konfigurują dyskusje na poziomie meta, procesy społecznościowe, portale, profile użytkowników itp.

Domyślna konfiguracja dla głównej przestrzeni nazw treści MediaWiki ma być płaska (bez podstron), ponieważ tak działa Wikipedia - ale ich włączenie jest trywialne. Są one włączone w innych przestrzeniach nazw (np. User:, gdzie ludzie mogą na przykład pracować nad wersjami roboczymi artykułów) i wyświetlają "ścieżkę zwrotną".

Przestrzenie nazw rozdzielają zawartość według typu; w tej samej przestrzeni nazw, strony mogą być organizowane tematycznie za pomocą kategorii: pseudo-hierarchicznego schematu organizacyjnego wprowadzonego w MediaWiki 1.3.

Przetwarzanie treści: Język znaczników MediaWiki i Parser

Zawartość generowana przez użytkowników jest przechowywana przez MediaWiki nie w formacie HTML, ale w języku znaczników specyficznym dla MediaWiki, czasami nazywanym "wikitekstem". Pozwala to użytkownikom wprowadzać zmiany formatowania (np. pogrubienie, kursywa w cudzysłowie), dodawanie linków (za pomocą nawiasów kwadratowych), dołączanie szablonów, wstawianie treści zależnych od kontekstu (takich jak data lub podpis) i sprawiać, że dzieje się mnóstwo innych magicznych rzeczy.

Aby wyświetlić stronę, ta treść musi zostać przeanalizowana, złożona razem ze wszystkich zewnętrznych lub dynamicznych elementów, które wywołuje, oraz przekonwertowana na odpowiedni kod HTML. Parser jest jedną z najważniejszych części MediaWiki, co utrudnia jego zmianę lub ulepszenie. Ponieważ setki milionów stron wiki na całym świecie są zależne od parsera do generowania kodu HTML w sposób, w jaki zawsze był tworzony - musi on pozostać niezwykle stabilny.

Język znaczników nie był formalnie określony od samego początku; Zaczęło się od Znaczniki UseModWiki, a następnie przekształcały się i ewoluowały zgodnie z potrzebami. Na przykład użycie ThreadMode do dyskusji sprawił, że Magnus Manske zaimplementował 3 lub 4 tyldy (~~~~) jako skrót do podpisywania swoich postów nieustrukturyzowanym tekstem. Tyldy zostały wybrane, ponieważ przypominały odręczny podpis jego ojca.[2]

Z powodu braku formalnej specyfikacji, język znaczników MediaWiki stał się złożonym i specyficznym językiem, w zasadzie kompatybilnym tylko z parserem MediaWiki; Nie można go przedstawić jako gramatyki formalnej przy użyciu składni BNF, EBNF lub ANTLR. Obecna specyfikacja parsera jest żartobliwie określana jako "cokolwiek parser wypluwa z wikikodu, plus kilkaset przypadków testowych".

Było wiele prób alternatywnych parserów, ale jak dotąd żadna z nich się nie powiodła. W 2004 roku eksperymentalny tokenizrt został napisany przez Jens Frank do parsowania wikitekstu i włączony na Wikipedii; trzy dni później musiał zostać wyłączony z powodu słabej wydajności alokacji pamięci tablic PHP. Od tego czasu większość parsowania jest wykonywana za pomocą ogromnego stosu wyrażeń regularnych i mnóstwa funkcji pomocniczych. Znaczniki wiki i wszystkie specjalne przypadki, które parser musi obsługiwać, również stały się znacznie bardziej złożone, co sprawia, że przyszłe próby zbudowania nowego parsera będą jeszcze trudniejsze.

Zauważalnym ulepszeniem było przepisanie preprocesora przez Tima Starlinga w MediaWiki 1.12, którego główną motywacją była poprawa wydajności parsowania na stronach ze złożonymi szablonami. Preprocesor konwertuje wikikod na drzewo XML DOM reprezentujące części dokumentu (wywołania szablonów, funkcje parsera, zaczepy tagów, nagłówki sekcji i kilka innych struktur), ale może pominąć "martwe gałęzie" w rozwijaniu szablonu, takie jak nieobserwowane przypadki #switch i nieużywane wartości domyślne dla argumentów szablonu. Następnie parser iteruje po strukturze DOM i konwertuje jej zawartość na HTML.

Niedawne prace nad edytorem wizualnym dla MediaWiki spowodowały konieczność ulepszenia procesu parsowania (i przyspieszenia go), więc wznowiono prace nad parserem i warstwami pośrednimi między znacznikami MediaWiki a końcowym kodem HTML (zobacz Przyszłość, poniżej).

Magiczne słowa i szablony

MediaWiki oferuje "Magiczne słowa", które modyfikują ogólne zachowanie strony lub włączają w niej dynamiczną treść. Składają się z: przełączników zachowań takich jak __NOTOC__ (dla ukrycia automatycznej tabeli treści) lub __NOINDEX__ (dla powiedzenia wyszukiwarkom, aby nie indeksować strony); zmiennych takich jak {{CURRENTTIME}} lub {{SITENAME}}; i funkcji parserów, tj. magicznych słów, które mogą przyjmować parametry, takich jak {{lc:[string]}} (do wyprowadzenia [string] w małych literach). Konstrukcje takie jak {{GENDER:}}, {{PLURAL:}} i {{GRAMMAR:}}, używane do lokalizacji interfejsu interfejsu, są funkcjami parsera.

Najczęstszym sposobem na włączenie treści z innych stron na stronie MediaWiki jest użycie szablonów. Szablony były tak naprawdę przeznaczone do umieszczania tych samych treści na różnych stronach, np. paneli nawigacyjnych lub banerów konserwacyjnych w artykułach Wikipedii; możliwość tworzenia częściowych układów stron i ponownego wykorzystywania ich w tysiącach artykułów z centralną obsługą wywarła ogromny wpływ na witryny takie jak Wikipedia.

Jednak szablony były również wykorzystywane (i nadużywane) przez użytkowników w zupełnie innym celu. MediaWiki 1.3 umożliwiła szablonom przyjmowanie parametrów, które zmieniają ich wynik; możliwość dodania domyślnego parametru (wprowadzona w MediaWiki 1.6) umożliwiła zbudowanie funkcjonalnego języka programowania zaimplementowanego na bazie PHP, co ostatecznie okazało się jedną z najbardziej kosztownych funkcji pod względem wydajności.

Tim Starling następnie opracował dodatkowe funkcje parsera (rozszerzenie ParserFunctions), jako tymczasowe rozwiązanie mające zapobiegać szalonym konstrukcjom stworzonym przez użytkowników Wikipedii za pomocą szablonów. Ten zestaw funkcji zawierał struktury logiczne, takie jak #if i #switch oraz inne funkcje, takie jak #expr (do obliczania wyrażeń matematycznych) i #time (do formatowania czasu).

Wkrótce użytkownicy Wikipedii zaczęli tworzyć jeszcze bardziej złożone szablony przy użyciu nowych funkcji, co znacznie pogorszyło wydajność parsowania na stronach z dużą ilością szablonów. nowy preprocesor wprowadzony w MediaWiki 1.12 (główna zmiana w architekturze) został zaimplementowany, aby częściowo rozwiązać ten problem. Później programiści MediaWiki dyskutowali o możliwości użycia rzeczywistego języka skryptowego w celu poprawy wydajności. Extension:Scribunto został dodany w lutym 2013 roku.

Pliki multimedialne

Użytkownicy przesyłają pliki za pośrednictwem strony Special:Upload; Administratorzy mogą konfigurować dozwolone typy plików za pomocą listy dozwolonych rozszerzeń. Po przesłaniu plików przechowywane są w folderze w systemie plików, a ich miniatury w dedykowanym katalogu thumb.

Ze względu na misję edukacyjną Wikimedia, MediaWiki obsługuje typy plików, które mogą być rzadkie w innych aplikacjach internetowych lub CMS-ach, takie jak obrazy wektorowe SVG oraz wielostronicowe pliki PDF i DjVus. Są one renderowane jako pliki PNG i mogą być przedstawione jako minatury oraz wyświetlane w tekście, podobnie jak bardziej popularne pliki graficzne, takie jak GIF, JPG i PNG.

Po przesłaniu pliku przypisywana jest do niego strona File: zawierająca informacje wprowadzone przez przesyłającego; Jest to dowolny tekst, który zwykle zawiera informacje o prawach autorskich (autor, licencja) oraz elementy opisujące lub klasyfikujące zawartość pliku (opis, lokalizacja, data, kategorie itp.). Podczas gdy prywatne wiki mogą nie dbać o te informacje - w bibliotekach medialnych takich jak Wikimedia Commons są one kluczowe w celu zorganizowania zbioru i zapewnienia legalności udostępniania tych plików. Argumentowano, że większość tych metadanych powinna być w rzeczywistości przechowywana w strukturze z możliwością zapytania o nie, takiej jak tabela bazy danych. Ułatwiłoby to znacznie wyszukiwanie, ale także przypisywanie i ponowne wykorzystywanie przez osoby trzecie – na przykład za pośrednictwem API.

Większość stron Wikimedia zezwala również na "lokalne" przesyłanie plików na każdą wiki, ale społeczność stara się przechowywać pliki multimedialne na wolnych licencjach w bibliotece wolnych multimediów Wikimedia, Wikimedia Commons. Każda strona Wikimedia może wyświetlić plik hostowany na Commons tak, jakby był hostowany lokalnie. Ten zwyczaj pozwala uniknąć konieczności przesyłania pliku na każdą wiki, aby go tam użyć.

W konsekwencji, MediaWiki natywnie wspiera zagraniczne repozytoria multimediów, tj. możliwość dostępu do plików multimedialnych hostowanych na innej wiki poprzez swoje API i system ForeignAPIRepo. Od wersji 1.16 każda strona internetowa MediaWiki może łatwo korzystać z plików z Wikimedia Commons za pomocą funkcjonalności InstantCommons. W przypadku korzystania z zagranicznego repozytorium miniatury są przechowywane lokalnie w celu zaoszczędzenia przepustowości. Jednakże nie jest możliwe (jeszcze) przesyłanie do zagranicznego repozytorium mediów z innego wiki.

Dostosowywanie i rozszerzanie MediaWiki

Poziomy

Architektura MediaWiki zapewnia różne sposoby dostosowywania i rozszerzania oprogramowania. Można to zrobić na różnych poziomach dostępu:

  • Administratorzy systemu mogą instalować rozszerzenia i skórki, a także konfigurować oddzielne programy pomocnicze wiki (np. do tworzenia miniatur obrazów i renderowania TeX-a) oraz ustawienia globalne (zobacz Konfiguracja powyżej).
  • Administratorzy wiki (czasami nazywani również "administratorami") mogą edytować gadżety dla całej witryny, ustawienia JavaScript i CSS.
  • Każdy zarejestrowany użytkownik może dostosować własne wrażenia i interfejs, korzystając ze swoich preferencji (dla istniejących ustawień, skórek i gadżetów) lub dokonać własnych modyfikacji (korzystając z osobistych stron JS i CSS). Zewnętrzne programy mogą również komunikować się z MediaWiki poprzez jego maszynowe API, jeśli jest ono włączone, zasadniczo udostępniając użytkownikowi dowolną funkcję i dane.

JavaScript i CSS

MediaWiki może odczytywać i stosować JavaScript i CSS dla całej witryny lub skóry przy użyciu niestandardowych stron wiki; Te strony znajdują się w przestrzeni nazw MediaWiki: i dlatego mogą być edytowane tylko przez administratorów; na przykład modyfikacje JavaScript od MediaWiki:Common.js mają zastosowanie do wszystkich skórek, CSS od MediaWiki:Common.css dotyczy wszystkich skórek, ale MediaWiki:Vector.css dotyczy tylko użytkowników ze skórką Vector.

Użytkownicy mogą dokonywać tych samych typów zmian, które będą dotyczyły tylko ich własnego interfejsu, edytując podstrony swojej strony użytkownika (np. User:[Username]/common.js za JavaScript na wszystkich skórkach, User:[Username]/common.css za CSS na wszystkich skórkach lub User:[Username]/vector.css za modyfikacje CSS, które dotyczą tylko skórki Vector).

Jeśli zainstalowane jest rozszerzenie Gadgets, administratorzy mogą również edytować gadżety, tj. fragmenty kodu JavaScript udostępniające funkcje, które użytkownicy mogą włączać i wyłączać w swoich preferencjach. Nadchodzące zmiany w zakresie gadżetów umożliwią udostępnianie gadżetów na różnych wiki, unikając w ten sposób duplikacji.

Ten zestaw narzędzi miał ogromny wpływ i znacznie zwiększył demokratyzację rozwoju oprogramowania MediaWiki. Poszczególni użytkownicy mają prawo do dodawania funkcji dla siebie; Zaawansowani użytkownicy mogą udostępniać je innym, zarówno nieformalnie, jak i za pośrednictwem globalnie konfigurowalnych systemów kontrolowanych przez administratorów. Ten framework jest idealny do małych, samodzielnych modyfikacji i przedstawia niższą barierę wejścia niż cięższe modyfikacje kodu wykonywane za pomocą zaczepów i rozszerzeń.

Rozszerzenia i skórki

Gdy modyfikacje JavaScript i CSS nie wystarczają, MediaWiki dostarcza system hooków, który pozwala zewnętrznym programistom uruchamiać niestandardowy kod PHP przed, po lub zamiast kodu MediaWiki dla określonych zdarzeń. Rozszerzenia MediaWiki używają haków do podłączania do kodu.

Zanim hooki pojawiły się w MediaWiki, dodawanie niestandardowego kodu PHP oznaczało modyfikację kodu podstawowego, co nie było ani łatwe, ani zalecane. Pierwsze haki zostały zaproponowane i dodane w 2004 roku przez Evana Prodromou; Na przestrzeni lat dodawano o wiele więcej, gdy zaszła taka potrzeba. Korzystając z hooków, możliwe jest nawet rozszerzenie języka znaczników wiki MediaWiki o dodatkowe możliwości, za pomocą rozszerzeń tagów.

System rozszerzenia nie jest doskonały: rejestracja rozszerzenia opiera się na wykonywaniu kodu w momencie uruchomienia, a nie na danych przechowywanych w pamięci podręcznej, co ogranicza abstrakcję i optymalizację oraz szkodzi wydajności MediaWiki. Ale ogólnie rzecz biorąc, architektura rozszerzeń jest teraz dość elastyczną infrastrukturą, która pomogła uczynić specjalistyczny kod bardziej modułowy, powstrzymując podstawowe oprogramowanie przed (nadmierną) rozszerzeniem i ułatwiając użytkownikom zewnętrznym budowanie funkcjonalności na zamówienie MediaWiki.

Z drugiej strony, bardzo trudno jest napisać nową skórkę dla MediaWiki bez ponownego wynalezienia koła. W MediaWiki skórki to klasy PHP, z których każda rozszerza klasę Skin; zawierają funkcje, które zbierają informacje potrzebne do generowania HTML. Długotrwała skórka "MonoBook" była trudna do dostosowania, ponieważ zawierała wiele specyficznych dla przeglądarki CSS do obsługi starych przeglądarek; Edytowanie szablonu lub CSS wymagało wielu późniejszych zmian, aby odzwierciedlić zmianę we wszystkich przeglądarkach i platformach.

API

Innym głównym punktem dostępu dla MediaWiki, oprócz index.php, jest api.php, używany do uzyskania dostępu do czytelnego maszynowo API zapytań (Application Programming Interface).

Użytkownicy Wikipedii pierwotnie tworzyli "boty", które działały poprzez zbieranie ekranu treści HTML serwowanej przez MediaWiki; Ta metoda była bardzo zawodna i wiele razy się psuła. Aby poprawić tę sytuację, deweloperzy wprowadzili interfejs tylko do czytania (znajdujący się na query.php), który następnie rozwinął się w pełnoprawny API do czytania i pisania maszynowego, zapewniający bezpośredni, wysokopoziomowy dostęp do danych zawartych w bazie danych MediaWiki.

Programy klienta mogą używać API do logowania się, odczytania danych i publikowania zmian. Interfejs API obsługuje cienkich klientów JavaScript opartych na sieci Web i aplikacje użytkowników końcowych. Prawie wszystko, co można zrobić za pośrednictwem interfejsu przeglądarki WWW - można zrobić też za pomocą API. Biblioteki klienckie implementujące API MediaWiki są dostępne w wielu językach, w tym Pythonie i .NET.

Warstwy, domeny i wzorce

Strona główna: Architecture:MediaWiki

MediaWiki można podzielić na około 12 warstw technicznych , z których każda wywołuje klasy i kod w warstwie poniżej, ale nie powyżej. Przykładami są warstwa instalatora , warstwa punktu wejścia , warstwa okablowania i Warstwa API . Kod obejmujący wszystkie warstwy może być pogrupowany w około 21 modułów domeny , z przykładami takimi jak domena nawigacji (skórki), domena zarządzania użytkownikami (tworzenie, zmiana nazwy, logowanie) i domena internacjonalizacji . Wiele wzorców projektowych oprogramowania jest używanych w MediaWiki, w tym wzorzec fabryki , wzorzec uchwytu i wzorzec poleceń .

Plany na przyszłość

To, co zaczęło się jako letni projekt wykonany przez jednego wolontariusza programistę PHP, przerodziło się w MediaWiki: dojrzały, stabilny silnik wiki napędzający jedną z dziesięciu najlepszych stron internetowych z absurdalnie małą infrastrukturą operacyjną. Stało się to możliwe dzięki ciągłej optymalizacji wydajności, iteracyjnym zmianom architektury i zespołowi niesamowitych programistów.

Ewolucja technologii internetowych i rozwój Wikipedii wymagają ciągłych ulepszeń i nowych funkcji, z których niektóre wymagają poważnych zmian w architekturze MediaWiki. Tak jest na przykład w przypadku trwającego projektu edytora wizualnego, który skłonił do wznowienia prac nad parserem i językiem znaczników wiki, DOM i ostateczną konwersją HTML.

MediaWiki to narzędzie, które jest używane do różnych celów. W ramach projektów Wikimedia, na przykład, jest używany do tworzenia i opieki nad encyklopedią (Wikipedia), do zasilania ogromnej biblioteki multimediów (Wikimedia Commons) lub do transkrypcji zeskanowanych tekstów referencyjnych (Wikiźródła); i tak dalej. W innych kontekstach, MediaWiki jest używane jako korporacyjny CMS lub repozytorium danych, czasami w połączeniu z frameworkiem semantycznym. Te specjalistyczne zastosowania, które nie były planowane, prawdopodobnie będą nadal napędzać ciągłe korekty wewnętrznej struktury oprogramowania. W związku z tym, architektura MediaWiki jest wciąż żywa, podobnie jak ogromna społeczność użytkowników, których wspiera.

Uwagi i przypisy

  1. ↑ Żądania wyświetlenia są zwykle upiększane za pomocą ponownego nadpisywania adresów URL, w tym przykładzie na w:Apple.
  2. ↑ https://twitter.com/MagnusManske/status/1083507467802365952

Zobacz też

Zobacz też

Retrieved from "https://www.mediawiki.org/w/index.php?title=Manual:MediaWiki_architecture/pl&oldid=6884489"