Uživatel:Keny/ Aktualizace na MW 1.39

MediaWiki

Do mých 22 let mne počítače nezajímaly. Jejich možnosti mne zaujaly až po roce 1991, kdy jsem je začal využívat především pro DTP práce. S internetem jsem se setkal až coby student politologie a religionistiky na MU v Brně, počátkem roku 1998. A přes webové technologie jsem se dostal od MS Windows k Linuxu.

Roku 2003 jsem nastoupil jako adminitrátor MS Windows serveru a webu na ÚMOb Ostrava-Jih – do r. 2010 to byl největší obecní úřad v ČR, který na 90% pracovních stanic (cca 250 strojů) používal linuxový desktop. Tam jsem se dostal k virtualizaci a definitivně přestal používat MS Windows.

První setkání s Wikipedií

Na Wikipedii jsem prvně narazil počátkem srpna 2004, kdy za sebou neměla ještě ani 4 roky existence. V téže době jsme s mým kamarádem Tonym pracovali na intranetovém systému „OpenIntranet” na základě jeho řešení javascriptového WYSIWYG editoru. S vývojem jsme začali v květnu 2003, ihned poté co jsem nastoupil jako webmaster ÚMOb Ostrava - Jih. Původně se o údržbu – tehdy ještě víceméně statických stránek v PHP – staral „civilkář” a roce 2003 už byla údržba takového webu prostřednictvím jedince fyzicky neúnosná – hodně stránek, manuální editace, žádný verzovací systém. Bylo nutné stručně a jasně všem uživatelům natvrdo říkat:

1. Nic za vás nebudu dělat. Neznám vaši agendu. Nevím co se publikovat může a co ne.
2. Ale pracuji na systému, který vám umožňuje, abyste svoje informace mohli sdělovat sami.
3. A raději vám 100x vysvětlím jak na to, než abych to jednou udělal za vás.

Nezkušení a začínající uživatelé upřednostňují WYSIWYG editaci. Ta je ovšem u složitějších stránek problematická protože některé části kódu se interpretují až při náhledu či uložení. Možnost přepínání mezi wiki kódem a jeho interpretovaným zobrazením je tedy klíčová. OpenIntranet tohle umožňoval jako první CMS systém na světě již v roce 2003. MediaWiki umožňuje možnost používat WYSIWYG editor až od června 2013. Na wiki TheWoodcraft.org ovšem tuhle „vymoženost” uživatelé nemají, protože při využívání WYSIWYG editoru se uživatelé wiki nikdy nenaučí wiki kód – bohužel ani ty nejzákladnější věci, jako je kategorizace stránek, jednoduché formátování textu, zakládání sekcí (nadpisy), psaní odkazů či vkládání obrázků.

Wiki na adrese support.dce.felk.cvut.cz

Nová práce v univerzitním prostředí sebou přinesla novou výzvu – zdokumentovat kde co běží. Přemýšlel jsem, jaký systém pro takový účel použít. Chtěl jsem, aby to byl systém…

• co by umožnil z dílčích informací sestavit ucelenou dokumentaci,
• dostupný odkudkoliv,
• otevřený i vůči veřejnosti,
• který by ale zároveň mohl obsahovat také informace dostupné jen omezenému okruhu uživatelů.

Moje požadavky dokázal splnit pouze jediný systém – wiki, ale bylo nutné vyřešit otázku jak zajistit, aby mohla veřejně dostupná wiki obsahovat i články, neveřejné.

1. Chtěl jsem, aby se uživatel nemusel doprošovat nějakého administrátora, aby někomu udělil přístupová práva.
2. A rozhodnutí kdo si je bude moct nějakou stránku přečíst, či editovat, bylo jen na autorovi článku a ostatních členech jeho týmu.

Našel jsem rozšíření, které které splňovalo moje požadavky, ale mělo své nedostatky, takže mi nezbylo, než ho od základu přepsat. Výsledkem bylo rozšíření AccessControl, nasazené do ostrého provozu od srpna 2008, které je od května 2012 součástí GIT repozitáře oficiálních MediaWiki rozšíření.

MediaWiki a GIT

Provozujete-li pouze jednu wiki, představuje jakákoliv aktualizace krok do neznáma. Není totiž snadné vrátit ze zpět ke starší verzi, pokud něco neklapne. Proto je výhodné provozovat více než jednu wiki, neboť se mezi nimi vždy najde některá, co je méně sledovaná, se kterou můžete začít abyste se mohli připravit na případné problémy spojené s aktualizací těch ostatních.

Z vývojářského hlediska je totiž velmi důležité, zda-li je wiki „živá” nebo ne. Většina problémů totiž vyleze až v okamžiku reálného nasazení, kdy začne software zpracovávat uložená data.

Jenže v rámci projektů MediaWiki běží desítky instancí MediaWiki u kterých není možné si hrát s kódem a hledat chyby. Proto musel být vytvořen mechanismus, který jednotlivé instance postupně aktualizuje teprve ve chvíli, kdy je jisté že to proběhne bez problému.

Chyby totiž mohou být různé. S MediaWiki se pracuje na několika úrovních:

1. Uživatelská úroveň – je ta, kdy se tvoří obsah stránek, tedy data která MediaWiki a její rozšíření interpretuje.;
2. Administrátorská – na které se pohybují uživatelé co dohlížejí na chod MediaWiki a řeší problémy uživatelů. Proto mají k dispozici nejrůznější speciální stránky, které jim v tom pomáhají.
3. Vývojářská – při které se „hrabe” do kódu.
4. A ta nejmocnější – správce serveru.

Chyby způsobené při editaci wikitextu obvykle brzy odhalí a opraví jiný uživatel, ale chyba na úrovni kódu wiki vyžaduje zásah vývojáře.

Je-li wiki hojně navštěvovaná, je pravděpodobnost, že na chybu někdo narazí mnohem vyšší, než u wiki s nízkým počtem uživatelů. A je žádoucí, aby byla opravena co nejdříve. Proto Wikipedia a další projekty nadace WikiMedia nejedou na LTS verzích MediaWiki, nýbrž na hlavní vývojové větvi ve které se případné chyby ihned opravují.

Jenže nikdo není neomylný, proto se začal pro další vývoj MediaWiki od února roku 2012 používat GIT v kombinaci s Gerritem.

• git umožňuje snadno a rychle odhalit pravděpodobnou příčinu chyby a
• Gerrit je systém u kterého každý „patch”, prochází schvalovacím řízením než se dostane do produkčního kódu.

Byl to rozhodně krok správným směrem, bohužel úroveň komplexity stoupla nad rámec schopností většiny příležitostných vývojářů, což vedlo k tomu, že „svá” rozšíření začali postupně opouštět, jelikož nebyli schopni držet krok s vývojem hlavní větve MediaWiki.

Z těch, které se používají na wiki TheWoodcraft.org bych uvedl:

• EIMage – jeho autor umístil svůj kód, v naději že se jen někdo ujme již r. 2013
• ImageSizeInfoFunctions – neudržované od února 2019

O něco lepší osud měly ty, které se staly součástí repozitáře oficiálních MediaWiki rozšíření a rozšíření AccessControl bylo jedno prvních.

Jenže Gerrit měl své „dětské” nemoci, které se projevily v době, kdy začala probíhat integrace Gerritu a wiki na https://wikitech.wikimedia.org tím, že mi přestalo fungovat přihlášení do Gerritu (2016). Takže jsem sice mohl pushnout svůj patch do gitu, ale nebylo možné abych se mohl vyjádřit k patchům, které do gitu poslali jiní. Takže od MW verze 1.26 probíhal v hlavní větvi vývoj, který z mé strany nebylo možné nijak ovlivnit.

To se změnilo až v roce 2019, kdy mne kontaktoval Nicolas Nallet, s prosbou zda-li bych neimplementoval do rozšíření AccessControl podporu rozšíření PageForm. A protože napsal těsně předtím co se měl v Praze konat MediaWiki Hackaton 2019, domluvili jsme se, že se na to společně podíváme.

Strávili jsme spolu tři plnotučné dny. A po jeho odjezdu, jsem narychlo zbastlený kód kompletně přepracoval do verze 3.0 kterou však nebylo možné sloučit s hlavní vývojovou větví protože nová syntaxe nebyla řádně otestovaná a prověřená dlouhodobým provozem.

Až verzi 4.x bylo možné uznat za stabilní, protože za tři roky bylo nutné aplikovat pouze jednu změnu. Jenže mezi tím, vznikl fork hlavní větve, uváděný jako verze 5.0

Odkazy

• https://m.mediawiki.org/wiki/Version_lifecycle
• https://en.wikipedia.org/wiki/History_of_Wikipedia

---

Aktualizace na MW 1.39

Údržbářské skripty, s nimiž se pracuje během aktualizace:

runJobs.php

Skript, kterým si vynutíme zpracování fronty čekajících operací.

getConfiguration.php

Vypíše aktuální stav výchozích proměnných MediaWiki. Následujícím příkazem si lze výstup obarvit a poslat na less, tak aby byarvy zůstaly zachovány:

php maintenance/getConfiguration.php --format json | jq . -C | less -r

update.php

Hlavní aktualizační skript. S parametrem --skip-config-validation lze přeskočit kontrolu konfigurace.

php maintenance/update.php --skip-config-validation

Rozšíření Contributors

Oproti kódu pro verzi MW 1.35 už byla opravena chyba, která způsobovala, že funkce nevracela nic. Teď již jsou možné dva typy výstupů. Buď přes speciální stránku, Keny, Skarman a Jouza nebo přes funkci Keny, Skarman a Jouza

Změny u rozšíření Variables

Rozšíření Variables používalo háček InternalParseBeforeSanitize, který je pro MW 1.35+ označen jako deprecated a tudíž se na stránce generovana následující chyba:

Deprecated: Use of InternalParseBeforeSanitize hook (used in VariablesHooks::onInternalParseBeforeSanitize) was deprecated in MediaWiki 1.35. [Called from MediaWiki\HookContainer\HookContainer::run in /srv/main/wiki/includes/HookContainer/HookContainer.php at line 137] in /srv/main/wiki/includes/debug/MWDebug.php on line 381

InternalParseBeforeSanitize

Jako alternativu bylo možné použít mediawiki:ParserBeforeInternalParse nebo mediawiki:ParserAfterTidy. Volba nakonec padla na alternativu první, neboť se obešla bez editace kódu. Stačilo pouze upravit soubor extension.json

?

all to undefined function wfFindFile()

Lokální úprava rozšíření WhoIsWatching

Tohle rozšíření generuje by default na každé stránce wiki informaci o počtu sledujících, což je informace do které anonymním návštěvníkům této wiki nic není. Proto bylo nutné kóf rozšíření upravit tak, aby se zobrazoval počet sledujících hen přihlášeným uživatelům.

diff --git a/src/Hook.php b/src/Hook.php
index 9c2875e..8b2414a 100644
--- a/src/Hook.php
+++ b/src/Hook.php
@@ -120,17 +120,19 @@ class Hook {
         * @return bool
         */
        public static function renderWhoIsWatchingLink( Title $title ) {
-               $conf = new GlobalVarConfig( "whoiswatching_" );
-               $showIfZero = $conf->get( "showifzero" );
-               $count = self::getNumbersOfWhoIsWatching( $title, $conf );
-
-               if ( $count > 0 || ( $showIfZero && $count == 0 ) ) {
-                       $lang = RequestContext::getMain()->getLanguage();
-                       return Html::rawElement( "span", [ 'class' => 'plainlinks' ], wfMessage(
-                               'whoiswatching_users_pageview', $lang->formatNum( (int)$count ), $title
-                       )->parse() );
+               $user = RequestContext::getMain()->getUser();
+               if ( $user->isAllowed( 'seepagewatchers' ) ) {
+                       $conf = new GlobalVarConfig( "whoiswatching_" );
+                       $showIfZero = $conf->get( "showifzero" );
+                       $count = self::getNumbersOfWhoIsWatching( $title, $conf );
+
+                       if ( $count > 0 || ( $showIfZero && $count == 0 ) ) {
+                               $lang = RequestContext::getMain()->getLanguage();
+                               return Html::rawElement( "span", [ 'class' => 'plainlinks' ], wfMessage(
+                                       'whoiswatching_users_pageview', $lang->formatNum( (int)$count ), $title
+                               )->parse() );
+                       }
                }
-
                return false;
        }

Lokální úprava rozšíření Echo

Také tohle rozšíření bylo potřeba lokálně upravit. By default se totiž notifikace uživatele označí pouze jako přečtená, místo toho, aby se aby se odstranila. Tím pádem neustále „straší” v seznamu notifikací.

Proto bylo potřeba kód upravit následujícím způsobem:

index 6685a84d..ee7191ef 100644
--- a/includes/gateway/UserNotificationGateway.php
+++ b/includes/gateway/UserNotificationGateway.php
@@ -72,13 +72,10 @@ class EchoUserNotificationGateway {
                foreach (
                        array_chunk( $eventIDs, $this->config->get( 'UpdateRowsPerQuery' ) ) as $batch
                ) {
-                       $success = $dbw->update(
+                       $success = $dbw->delete(
                                self::$notificationTable,
-                               [ 'notification_read_timestamp' => $dbw->timestamp( wfTimestampNow() ) ],
-                               [
-                                       'notification_user' => $this->user->getId(),
+                               [ 'notification_user' => $this->user->getId(),
                                        'notification_event' => $batch,
-                                       'notification_read_timestamp' => null,
                                ],
                                __METHOD__
                        ) && $success;

Změny nezbytné pro ConfirmAccount

Captcha, aby boti nezneužívali registrační formulář

Úprava rozšíření ImageSizeInfoFunctions

Tohle rozšíření je kritické pro šablonu {{Images}}, protože s jeho pomocí zjišťuje informace o velikosti a cestě k uploadovanému obrázku.

$userGroupManager = MediaWikiServices::getInstance()->getUserGroupManager();

1, vytvořím instanci $soubor = MediaWikiServices::getInstance()->getRepoGroup()->findFile()

2, vyhledám $soubor->

$imagefile = MediaWikiServices::getInstance()->getRepoGroup(); $imagefile->findFile( $title );

$allowed = [ 'img' => array_merge( $common, [ 'alt', 'src', 'width', 'height', 'srcset' ] ),

Změny u rozšíření EImage

Tohle rozšíření je stejně jako některé šablony (např. šablona Images) závislé na interpretaci tagu img.

Proto je zatím nezbytně nutná aktivní proměnná $wgAllowImageTag, která je deprecated od MW 1.35, takže bude nutné vymyslet za ni náhradu.

https://www.mediawiki.org/wiki/Manual:$wgAllowImageTag

width = "5%"

width = "5%"

Změny v rozšíření AccessControl

Toto rozšíření je zcela zásadní.

userCan

Od MW 1.35 je tenhle háček deprecated, bylo ho nutné nahradit 'getUserPermissionsErrors'

https://www.mediawiki.org/wiki/Manual:Hooks/userCan

https://www.mediawiki.org/wiki/Manual:Hooks/getUserPermissionsErrors

https://doc.wikimedia.org/mediawiki-core/REL1_39/php/UserCanHook_8php_source.html#l00001

$wgUser

Rovněž je od MW 1.35 deprecated použití globální proměnné $wgUser.

Pro zavolání objektu uživatele se nově používá metoda …

RequestContext::getMain()->getUser()

https://www.mediawiki.org/wiki/Manual:$wgUser

Oprava vytvoření nové stránky

místo Title::makeTitle bylo potřeba požít Title::makeTitleSafe

Poprvé od... https://doc.wikimedia.org/mediawiki-core/REL1_27/php/classTitle.html#ab4f4092f04eb31b7d974742d8ded46c8

Změny v použití objektu Title

Od MW 1.37 je přístup k parametrům třídy Title možný jen přes metodu. Změna se týkala

• $mDbkeyform
• $mTextform
• $mNamespace

Oprava při zákazu speciálních stránek

Anonymní uživatel nemá žádnou skupinu práv, takže nastane problém pokud se volá speciální stránka. Bylo tedy nutné přidat testovací podmínku.

$gt === null

Oprava vytažení uživatelských skupin

Na stránce wiki.control.felk.cvut.cz kde se transkludují tabulky diplomových prací se projevila chyba, kterou způsobila odstraněná funkce 'getEffectiveGroups()', kterou od MW 1.37 nahrazuje 'getUserEffectiveGroups()'

Poprvé https://doc.wikimedia.org/mediawiki-core/REL1_27/php/classUser.html#a6e8c727238ad230eb888ea1fd9a90325

Naposledy https://doc.wikimedia.org/mediawiki-core/REL1_37/php/classUser.html#a6e8c727238ad230eb888ea1fd9a90325

Oprava indexu pro jmenné prostory

• alterSharedConstraints.php - MediaWiki 1.33

Na stránce Special:RecentChanges se pro změnu projevila chyba, která se zobrazovala přihlášenému uživateli, pokud se v seznamu nalezených stránek vyskytla stránka chráněná přes šablonu.

Pro její odstranění bylo potřeba nahradit původní třídu 'MWNamespace' která byla z kódu MW 1.39 odstraněna (deprecated od MW 1.34+), za třídu 'NamespaceInfo', která ji nahrazuje od MW 1.34+

Class 'MWNamespace' since MW 1.19 removed, from MW 1.34+ replace it class 'NamespaceInfo'.

Deprecated since 1.34, has been removed 1.39 rMWea1c106ea9a3

(T291389)

Oprava regulárního výrazu

Další problém, který se projevil byl způsoben chybným regulárním výrazem, který nerozlišoval šablonu či funkci v kódu wikitextu od názvu jmenného prostoru. Dvojtečka (colon), byla původně znakem, kterým se při použití původní syntaxe rozšíření identifikoval seznam uživatelů. Výraz bylo nutné upravit, aby akceptoval pouze řetězce, které začínají velkým písmenem, neboť všechny názvy jmenných prostorů začínají velkým písmenem. Zatím co dvojtečka se vyskytuje také v šablonách a funkcích.

Změny u rozšíření Widget - opravit?

Při vložení widgetu přes kombinaci rozšíření DynamicPageList3 a LabeledSectionTransclusion nedochází k jeho interpretaci. Je potřeba zjistit příčinu.

ToDo

ToDo Keny (diskuse), 28. 2. 2023, 11:17 (CET) – Pro „kouzelné slůvko” PAGEID – 38334 (je mezi Magic Words od MW 1.20+) bere i podstránky 0 vytvořit šablonu (nebo funkci?), která by na jeho základě vracela aktuální název stránky. Šablonu parametrizovat - plná cesta, jenom název stránky, jenom název kořenové stránky. Lze využít rozšíření SubpageFun?