Čuňačíme v MediaWiki - responzivní obsah II.

7.1.2021 19:37 | Přečteno: 1585× | Jen tak na okraj | poslední úprava: 7.1.2021 19:43

Naposledy jsem psal o čuňačení v MediaWiki asi před půl rokem, kdy jsem chtěl upozornit na to, že jsem přepracoval svoji původní šablonu Images tak, aby bylo možné používat výřezy z obrázků a stránek generovaných z DjVu a PDF dokumentů. Blogpost nebyl nijak extra hodnocen, takže mě vcelku nepřekvapuje, jak se do hlavní vývojové větve MediaWiki dostávají čím dál větší prasečiny.

Přijde mi to šílené. Stejně jako je šílená současná doba. Bohužel se nemohu ubránit dojmu, že v průběhu loňského roku proběhl globální převrat – v duchu hesla "Buzeranti všech zemí spojte se!", proti němuž byla VŘSR lokální lapálií bez širšího dosahu a i Adolf Hitler zblednul závistí. Jenže před 100 lety ještě bylo možné buzerantům uniknout. Dnes již bohužel není kam. Stávající situace vynesla vzhůru tu nejhorší sortu psychopatů, co své pozice upevňují s využitím těch nejnižších lidských pudů – strachu, závisti a nenávisti.

Ale to vše už tady bylo. Každá revoluce požírá své děti, takže je pouze otázkou času, kdy dojde i na ně. Hodnocení současné situace ale není cílem mého blogpostu. Chci se pochlubit, tím co se dá v MediaWiki realizovat čistě prostřednictvím šablon, i bez pomocných skriptovacích berliček.

Pokud vás tedy zajímá, jak rychle se načítá stránka, která se generuje s využitím několik set šablon a zároveň si chcete něco zajímavého a poučného doma s dětmi přečíst, tak se koukněte na Seifertův překlad Setonovy knihy Z lesní říše. Pro fajnovky je tam k dispozici i anglický originál Woodland Tales, ale na jeho finalizaci teprve dojde.

Je to zvláštní náhoda, že originál vyšel přesně před 100 lety. V časech, kdy po světě řádila tzv. "španělská chřipka". Tenkrát neexistovaly ještě antibiotika, antivirotika, vakcíny proto chřipce, JIPky ani plicní pumpy. Nikdo neopruzoval s rouškama, nebyly žádné celoplošené buzerace. A vidíte. Lidstvo to bez větší újmy přežilo, jen pro to, aby se o necelých 20 let mohlo zřezat ještě s větší intenzitou, než kdy před tím.

Úprava Seifertova překladu té knížky ještě není ukončena. Je tam totiž víc jak stovka ilustrací a řada z nich je složena z několika výřezů, aby mohl být obsah stránky responzivní – mým cílem je udělat to tak, aby se to dalo v pohodě číst i na mobilu.

Doposud jsem řešil skládání několika výřezů do jednoho obrázků víceméně metodou pokus omyl. Vůbec první dokument, kde jsem tohle použil je série Setonových článků z roku 1902. Mimochodem, právě tuhle sérii článků Seton později prohlásil za první vydání The Birch bark roll. Ovšem tentokrát je těch obrázků opravdu hodně a zapojil se i kamarád, který se s jejich vkládáním teprve seznamuje, takže jsem vytvořil pomocnou šablonu I-size, aby nám to šlo rychleji a snáz od ruky.

Na téma MediaWiki zde ode mne v minulosti vyšlo…

1. (11.3.2015)MediaWiki - rozšíření Translate - kromě rozšíření Translate zde padla zmínka také o rozšíření AccessControl.
2. (12. 3.2015) Čuňačíme v MediaWiki - příklad využití rozšíření ExternalRedirect.
3. (14. 3.2015) Čuňačíme v MediaWiki dál - popisuje, jak v prostředí MediaWiki modifikovat textové zprávy k rozšíření ConfirmAccount.
4. (15. 3.2015) Od čuňáren ke korektnímu obsahu MediaWiki - popisuje jak u multijazyčné wiki využívat možnosti rozšíření ParserFunctions
5. ( 1. 4.2015) Čuňačíme v MediaWiki - opět - popisuje jak využít možností rozšíření ParserFunctions MyVariables k modifikaci nabízeného obsahu wiki na základě autentifikace.
6. ( 2. 4.2015) MediaWiki - dynamicky generované stánky - názorná ukázka využití rozšíření DynamicPageList (third-party) pro dynamicky generované stránky v MediaWiki. Kromě toho se zde objevila zmínka or rozšíření Loops a Variables, které umožňují v šablonách využívat smyčky a uživatelsky definované proměnné.
7. ( 3. 4.2015) Čuňačíme v MediaWiki - proč? seznámení s tím, jak a proč jsem se dostal k MediaWiki
8. (17. 8.2018) Čuňačíme v MediaWiki - responzivní obrázky blogpost o tom, jak donutit MediaWiki aby responzivně pracovala s obrázky. Součástí je šablona mé provenience, která využívá kromě již uvedených rozšíření navíc rozšíření ImageSizeInfoFunctions
9. ( 3. 4.2019) Čuňačíme v Mediawiki – RecentChanges bez javascriptu
10. (10. 4.2019) MediaWiki.org - překlad dokumentace
11. (20. 5.2019) Wikimedia Hackaton 2019
12. (12. 7.2020) Čuňačíme v MediaWiki - výřezy z obrázků

       

Komentáře

[Kol0brndaRulez]

No nádhera, jako blesk. Zavzpomínal jsem na dialup, díky.

[Aleš Kapica]

Zkus otevřít a na mobilu číst srovnatelně velký 245 stránkový PDF soubor

[_]

S dobrym pdf prohlizecem naprosto bez problemu a bez jakehokoliv uzivatelsky vnimatelneho lagu pri skrolovani.

[Aleš Kapica]

Neříkej, že ti ta html stránka po tom několikasekundovém načtení při procházení laguje. Mám 6 let staré BlackBerry Q10, načte se mi to cca během 8 sekund a procházení je zcela bezproblémové.

Abych řekl pravdu, kolikrát mi trvá mnohem déle načtení, z hlediska dat mnohem jednodušší, stránky z abclinuxu.cz

[Josef Kufner]

Však PDF je navržené tak, aby se dalo načítat postupně a jen to, co je na aktuální stránce potřeba. Problém může být jen pokud ta jedna stránka je příliš komplikovaná ci blbě udělaná.

[Aleš Kapica]

Je to smutné, ale většina PDF je udělaná blbě. Ale co hlavně, účelem PDF nebylo pohodlné a rychlé prohlížení elektronických dokumentů, ale jejich tisk. Až dodatečně do něj dobastlili další featury.

[marbu]

Ta wikistránka je pěkná ukázka (nebo spíš benchmark? šablon, ale pro čtení knížky na počítači bych spíš volil ten zdrojový DjVu/PDF soubor, a pro čtení na mobilu epub. Ne že by nebylo užitečné mít všechno na jedné html stránce, ale pro čtení samotné se to imho zrovna moc nehodí.

Btw je škoda, že na wikipedii nebo wikizdrojích funkci epub exportu nemají. Jednak příslušné MediaWiki rozšíření Extension:EPubExport zdá se umřelo, a druhak se správci zdá se rozhodli preferovat pdf export.

[Aleš Kapica]

Pche! Nic není nemožné Udělat něco podobného z té singlepage stránky je brnkačka.

Apropos, na to jsi přišel kde, že se to ke čtení na mobilu nehodí? Načteš to jen jednou a pak už skáčeš po libosti v rámci jedné stránky. Epub stejně není ve skutečnosti nic jiného než ořezané html.

[marbu]

Pche! Nic není nemožné Udělat něco podobného z té singlepage stránky je brnkačka. ... Epub stejně není ve skutečnosti nic jiného než ořezané html.

No právě. Jeden by řekl že díky tomu bude implementace takového exportu ve srovnání s ostatními exporty jednodušší, a tak nebude problém s nasazením na wikipedii.

[Aleš Kapica]

Jednodušší je načíst tu stránku do LibreOffice. Zatím akorát nevím, čím vším se ten import dá ovlivnit. Něco totiž akceptuje a něco ne. Abych byl konkrétní, blbě importuje ty postranní odkazy na stránky – valí to rovnou do textu. Přitom mají class="noprint" a při tisku se ignorují.

Importovaný dokument se ale stejně neobejde bez úpravy. Ten Libreoffice totiž nezachová proporce vložených obrázků (deformuje je), takže se to musí ručně změnit. Ovšem pak už to není problém uložit do čeho chceš, případně vyexportovat do toho PDF.

[marbu]

Apropos, na to jsi přišel kde, že se to ke čtení na mobilu nehodí? Načteš to jen jednou a pak už skáčeš po libosti v rámci jedné stránky.

Pro běžné lineární čtení mi přijde mnohem lepší nějaký program na čtení knih (např. fbreader), který zobrazuje text postupně po stránkách (místro scrolování), zobrazuje jen text a relevantní obrázky a pamatuje si naposledy otevřenou stránku. Z hlediska uživatelského pohodlí je to imho řádově lepší. Navíc jaksi explicitně funguje offline, protože pracuje s knížkami v epub souborech. Zatímco v prohlížeči na mobilu čtu spíše kratší texty, a pokud bych si chtěl takto nějaký dlouhý text uložit na později, abych se k tomu mohl nějakou dobu pravidelně vracet, nemám přímo jak (resp. řeším to přes pocket).

[Aleš Kapica]

Pro běžné lineární čtení mi přijde mnohem lepší nějaký program na čtení knih (např. fbreader), který zobrazuje text postupně po stránkách (místro scrolování)

Je to věc vkusu. Kupř. mi pro čtení víc vyhovuje klasický papírový list. Ovšem ne formát A4 ale cca A5. Ale tisknul bych to jedině v případě, že bych to pak chtěl někomu poslat dál.

Scrollování je pro mne přirozenější, než virtuální "listování". Pokud sis nevšiml, tak na té stránce jsou dva obsahy. Oba skáčou pouze v rámci jedné stránky, takže funguje i back. Alespoň tedy na mém mobilu. Čtu tak, že obrazovku při čtení posouvám palcem. A když se chci na něco kouknout blíž, tak si to zvětším.

Virtuální "listování" mne při čtení ruší a vykreslování stránek zdržuje, protože čtu rychleji, než to stíhají ty čtečky vykreslovat.

[Aleš Kapica]

Mimochodem, kdo neumí česky, ani anglicky, si může ty stránky prohnat přes translator. Není to sice bůhví co, ale s trochou imaginace to dá. S PDF či Epub na něco podobného můžeš rovnou zapomenout.

[Aleš Kapica]

Jo a ten zdrojový DjVu není problém stáhnout. Dostaneš se k němu přes libovolnou stránku. Skočíš na index a pak klikneš na obrázek titulní stránky. To tě hodí na soubor. A odtamtud si to můžeš stáhnout. Má to 6,3MB včetně textové vrstvy.

[Max]

Zajímalo by mně, co se děje na serveru. Pokud to tak dlouho čeká na data, tak to server, resp. db, asi nebude mít lehký?

Jinak mám nasazený parsoid jako backend pro klikaci WYSIWYG a pokud bych ten klikací ksicht měl použít na té stránce, tak asi umře vše :D, aspoň podle těch stránek s dokumentací, co v tom tvořím.
Zdar Max

[Aleš Kapica]

Co se děje? Jak už jsem napsal. Proběhne transkluze cca 245 stránek vygenerovaných přes rozšíření Proofread Page, cca stovky obrázků a řady dalších šablon, včetně kontroly - některé věci na té wiki jsou dostupné jen registrovaným uživatelům s povoleným přístupem.

Wysiwyg editor wiki je zlo. Kód té stránky je ve skutečnosti velmi jednoduchý. I jako anonym bys měl mít možnost si ho zobrazit.

Jinak jde o specifickou stránku. Jsou tam i rozsáhlejší. Generované z cca 600 stran.

[Ehm]

Nechutný, už chápu proč jsi v IT nesehnal nic pořádnýho

[Aleš Kapica]

A tak ne. Anonym si může zobrazit pouze kód z namespace Template. Ale nikomu nic nebrání v registraci. Ta je nezbytná ze tří důvodů. 1, ověřuje se při ní platnost mailové adresy. 2, je to účinná bariéra před škodiči a 3, na základě uživatelských jmen funguje ochrana stránek a nastavení práv k různým operacím a funkcionalitám. Anonym má u mé wiku kupř. jen velmi omezený přístup ke speciálním stránkám, jelikož se dají snadno zneužít k útoku na wiki.

[Aleš Kapica]

Pokud jde o vytížení serveru, není to nic hrozného. Výhodou šablon je mimo jiné to, že unifikují použitý kód. Mimochodem, i hlavní stránka té wiki je generována přes šablony. Ale o šabloně content jsem už tady asi v minulosti psal.

[Max]

Ano, v mém dotazu jsem myslel vytížení serveru.
Zdar Max

[Aleš Kapica]

99% času ten server jede na 2%. Přitom má relativně málo paměti a jen 2 procesorová jádra. Ovšem to se děje pouze při vkládání obrázku. Vtip je v tom, že ta šablona Image pracuje s již hotovým obrázkem, který se pouze procentuálně škáluje (šablona přepočítává parametry pro css) – to je rozdíl oproti tomu jak s obrázky nativně pracuje MediaWiki. Schválně si zkus jak rychle se načte tohle. To se renderuje složením 620 stránek, ale ještě to neprošlo korekturou, takže se nic nedělá s obrázky. Ty to zatěžují asi nejvíc a nejvíc jich má zatím právě ta knížka z Lesní říše.

[jiwopene]

2 % čeho? Pokud je to vytížení CPU během dotazu, tak bych předpokládal, že se čeká na disk.

[Aleš Kapica]

2% vytížení CPU. Ten maká nejvíc když se generují nové náhledy. Pak už se používá to co je vygenerované a změna velikosti se řeší přes css na straně klienta. U velkých stránek jako ta odkazovaná z blogpostu trvá nejdéle, přežvejkání toho co parser dostane z databáze.

Jinak jo, asi čeká na disk, protože ten stroj má poměrně málo RAM. Ale je to v pohodě viděl jsem už výrazně pomalejší servery.

P.S.:Vtipné je, jak se neustále různí boti pokoušejí atakovat Wordpress, který tam neexistuje. A Číňani se zas neustále pokoušejí zneužít mailserver.