Jump to content

Nie włamać się do MediaWiki

From mediawiki.org
This page is a translated version of the page Do not hack MediaWiki core and the translation is 100% complete.

Podczas gdy hakowanie rdzenia MediaWiki jest często proponowanym rozwiązaniem na innych forach wsparcia MediaWiki, nie jest to idealne rozwiązanie. Ogólnie rzecz biorąc, spowoduje to więcej problemów niż rozwiąże i tylko utrudni instalację przyszłych aktualizacji.

Do celów niniejszego artykułu "core" oznacza wszystkie pliki należące do oryginalnej instalacji MediaWiki. To znaczy wszystkie pliki z wyjątkiem LocalSettings.php, docker-compose.override.yml, te w folderze "rozszerzenia" lub "skins" lub innych folderów, które dodałeś od momentu instalacji.

Dlaczego nie należy modyfikować podstawowych plików

Bez względu na to, jak łatwo jest zmodyfikować podstawowe pliki, aby MediaWiki robiło to, co chcesz, oprzyj się pokusie.

  • W ten sposób będzie trudne lub niemal niemożliwe wdrażanie aktualizacji witryny, takich jak zabezpieczenia i naprawki błędów.
  • Utrudniasz utrzymanie strony dla następnych.
  • Możliwe, że możesz pozostawić swoją stronę podatną na wykorzystywanie.
  • Inni programiści nie są skłonni pomóc, jeśli wpadłeś w swoje serce - jeśli nie z innego powodu, niż trudno im wiedzieć, co zostało zrobione.

Rdzeń MediaWiki został zaprojektowany jako modułowy, więc nie powinno być powodu, by go hakować. Jeśli istnieje funkcja, której potrzebujesz i nie można jej osiągnąć poza modyfikacją rdzenia, rozważ opracowanie rozszerzenia lub przesłanie swojego hacka jako poprawki. Zgłoś błąd i poinformuj społeczność o funkcji, którą chcesz uzyskać. Zostanie ona następnie przetestowana i może stać się częścią rdzenia MediaWiki.

Problemy napotykane przez wiki, które hakują swój rdzeń

  • Czas aktualizacji MediaWiki wynosi od 30 minut do 6 godzin lub nawet 6 tygodni, jeśli diff pokazuje 13650 linii zmienionych.
  • Zwiększenie liczby spamów i innych niepożądanych ataków z powodu luk w zabezpieczeniach.
  • Brak nowych funkcji z powodu sprzecznych hackingów plików podstawowych.
  • Niezdolność do korzystania z dokumentacji MediaWiki.org - która została napisana przy założeniu, że nie zhakowałeś plików rdzenia (chyba że piszesz dokumentację dotyczącą obsługi MediaWiki, gdy używany jest ten konkretny hack).
  • Powtórzenie pierwotnego problemu - ponieważ raport błędów jest znacznie bardziej wiarygodnym sposobem rozwiązania problemu niż hak podstawowy - jeśli z żadnego innego powodu niż grupa programistów będzie badać problem i może odkryć niezbędne zmiany kodu, które przegapiłeś.
  • Skarżenie się przed programistami o niepracujące pliky podstawowe - i nie znalezienie zbytniego współczucia - jeśli włamiesz pliky główne - skuteczne wsparcie techniczne jest niemożliwe.

Wyjątki

Czy istnieją wyjątki od tej zasady?

Nie.

No dobrze, bardzo rzadko. Ale zazwyczaj dotyczy to konkretnych wiki lub implementacji przez osoby, które są bardzo dobrze zaznajomione z bazą kodu MediaWiki, praktykami programistycznymi i modelem bezpieczeństwa. Tych, którzy właściwie dokumentują swoje zmiany i stosują odpowiednią kontrolę wersji swojego kodu. Jeśli musisz pytać, prawdopodobnie nie powinieneś.

Rozszerzenia

Zauważ, że większość tej strony odnosi się również do ważnych rozszerzeń. Złym pomysłem jest bezpośrednie rozpoczęcie hakowania rozszerzeń Semantic MediaWiki lub któregokolwiek z rozszerzeń używanych w Wikipedii i innych witrynach Wikimedia.

Wyjątkiem może być sytuacja, w której rozszerzenie jest instalowane głównie poprzez kopiowanie jego kodu z tą wiki (zamiast pobierania go z repozytorium oprogramowania). Oznacza to, że nie jest ono zbyt poważnie utrzymywane.

Co zrobić zamiast tego

Zamiast hakerowania w serce MediaWiki, istnieje kilka alternatywnych rozwiązań, które należy rozważyć, mniej więcej w tej kolejności:

  1. MediaWiki jest potężną bestią po wyjęciu z pudełka, możesz zrobić wiele z interface messages MediaWiki, takimi jak MediaWiki:Sidebar i wiele innych, zobacz także inne strony na tej wiki dla np. dodatków i zmian JavaScript i CSS.
  2. Rozwiń rozszerzenie, aby osiągnąć to, co zamierzałeś zrobić, lub po prostu użyj jednego z istniejących haków.
  3. Prześlij raport o błędzie
  4. Prześlij swoje ulepszenie rdzenia do repozytorium kodu, aby inni mogli skorzystać z twojej poprawki.

Zobacz też