Redaktoři vedou boj na více frontách. Musejí ověřovat, jestli zdroje, z nichž čerpají, jsou seriózní, objektivní a aktuální. Musejí také kontrolovat sami sebe, protože nejsou neomylní a občas se spletou, dopouštějí se překlepů nebo mohou být něčím ovlivněni. Dnešní článek ale bude věnován boji s redakčním systémem, WordPress totiž umí být jak dobrý sluha, tak i zlý pán.

Učit se, učit se, učit se

Těm, kteří nemají zkušenosti s publikováním na Internetu, se celá věc může jevit prostě – článek se napíše, nahraje do systému a publikuje. V podstatě to tak opravdu je, v praxi však autor naráží na různá omezení redakčního systému, která ho nutí učit se, jak funguje, aby si ho dokázal přizpůsobit. S rostoucí sofistikovaností systému je to však čím dál náročnější. Pro lepší pochopení tohoto principu je potřeba vrátit se zpět v čase a podívat se, jak se weby dělaly dříve.

Základním jazykem World Wide Webu je HTML (Hypertext Markup Language), který umožňoval vpisovat do textu značky (tzv. tagy), podle nichž pak prohlížeč text formátoval. Těmito tagy mohli autoři vyznačit, co má být nadpis, co odstavec, co seznam, co odkaz, co citace atd. Nechyběly ani tagy pro tabulku, které se využívaly k rozčlenění stránky na záhlaví, zápatí, boční sloupce a hlavní obsah.

<H1>ElonX</H1>
<P>Novinky o projektech Elona Muska</P>

Autorovi tedy stačilo naučit se pár desítek tagů a jejich atributů (definovaných vlastností), a mohl začít tvořit. Tato jednoduchost však měla jednu velkou nevýhodu – redesign rozsáhlejšího webu zabral hodně času a energie. Změnu fontů, změnu rozměrů, změnu pozadí a další úpravy totiž bylo nutné provést zvlášť na každé stránce. Pokud se autor například rozhodl, že odkazy v textech přebarví na červeno, musel ke každému jednotlivě připsat <FONT COLOR="red"> (plus ještě uzavírací značku </FONT>). Naštěstí pro webdesignéry se k HTML brzy přidružil nový jazyk CSS (kaskádové styly), který umožnil oddělit vzhled od obsahu. Díky tomu bylo možné v jednom souboru CSS definovat jednotný styl pro celý web.

/* nadpisy 1. – 3. úrovně budou purpurové a zarovnané na střed */
H1, H2, H3 {color: purple; text-align: center}
/* odstavce budou mít větší výšku řádku a zarovnání do bloku */
P {line-height: 150%; text-align: justify}

Jenže aby autor mohl používat kaskádové styly, musel se naučit jejich syntaxi, selektory a názvy vlastností. Místo jednoho jazyka musel tedy už zvládat dva. A tím to teprve začínalo. Aby se web dal snadno udržovat, bylo potřeba zajistit, že k editaci společných částí webu jako záhlaví, zápatí, navigace apod. postačí stejně jako v CSS udělat změnu na jednom místě, a ta se projeví na všech stránkách webu. Nejschůdnější cestou, jak toho docílit, je preprocesor, který na straně serveru poskládá jednotlivé části kódu HTML do funkčního celku. K tomuto účelu se výborně hodí PHP, což je preprocesor a zároveň také skriptovací jazyk. Jednoduché řešení s využitím PHP vypadá následovně:

<!DOCTYPE HTML>
<HTML>
  <HEAD>
    <TITLE>Můj web</TITLE>
  </HEAD>
  <BODY>
    <DIV>
      <A HREF="index.php?page=1">Stránka 1</A>,
      <A HREF="index.php?page=2">Stránka 2</A>,
      <A HREF="index.php?page=3">Stránka 3</A>
    </DIV>
<?php
$web_content = array('1' => 'Obsah první stránky', '2' => 'Obsah druhé stránky', '3' => 'Obsah třetí stránky');
if (isset($_GET['page'])) {
    $post = $_GET['page'];
    print('<ARTICLE>' . $web_content[$post] . '</ARTICLE>');
    }
?>
  </BODY>
</HTML>

Zde v osekaném zdrojovém kódu vidíme na prvním řádku deklaraci typu dokumentu (DOCTYPE), pak kořenový prvek HTML, v něm hlavičku kódu (HEAD), která se ale na stránce nezobrazuje, a „tělo“ kódu (BODY) s daty určenými k prezentaci – nejprve oddíl (DIVision) s odkazy (ty se poznají podle atributu HREF) a následně hlavní obsah. Klíčový je úsek mezi značkami <?php a ?>, to je kód PHP, ten přiřazuje každé stránce její hlavní obsah. Celý obsah webu existuje v jednom jediném souboru index.php, a uživateli se z něj posílá jen ta část, která náleží konkrétní stránce. Fakticky se tedy jedná o multistránku, ve které se pouze mění hlavní obsah podle toho, na jaký odkaz uživatel klikne. Pro autora je to splněný sen, jen se musí naučit ještě PHP. Ovšem s tím, jak se jeho web průběžně rozrůstá a stává se složitějším, přestává i toto pořád ještě poměrně triviální řešení dostačovat, protože ztrácí přehlednost – v takovém kódu se míchají databázové dotazy, řídící logika, tagy z HTML, a všechno to je do sebe zapletené jako špagety. „Špagetový“ kód se obtížně dál rozvíjí a vývojářské nástroje si s ním moc nevědí rady. Dalším krokem je tedy organizace kódu na bázi MVC (Model – View – Controller). MVC je vzor pro návrh aplikací, který je rozděluje do tří vrstev. Jedna (Model) pracuje s daty, druhá (View) má v gesci uživatelské rozhraní a třetí (Controller), která jednu s druhou propojuje, má řídící funkci. Jak to funguje: Controller podle vstupních parametrů pozná, co uživatel chce, zavolá Model, který požadované informace najde v databázi, a Controller je pak předá vrstvě View k zobrazení.

Z autora je v této fázi plnohodnotný programátor, ale i velmi dobrému programátorovi trvá měsíce, než naprogramuje všechny funkce, které by moderní blog měl mít: přizpůsobení pro různá zařízení, štítkování článků, zasílání oznámení o novinkách, počítání návštěvnosti, vyhledávání, hodnocení, registrace uživatelů, vkládání diskusních příspěvků, archív atd. Leč autor na programování nemá čas ani chuť. To však nevadí, existuje specializovaný software, s nímž lze tvořit webové stránky bez nějakého velkého programování – redakční systém. Ten obsahuje vše potřebné pro tvorbu a správu obsahu, dokonce lze instalovat i různé doplňky. Autor jenom vytvoří šablonu (kostru webové stránky, na kterou se bude nabalovat obsah; technicky se jedná o kolekci souborů určujících vzhled a chování stránek) a web je hotov.

Nyní už je snad zřejmé, že každý nástroj, který autorovi šetří práci a čas, představuje zároveň další úroveň složitosti. Redakční systém sice lze ovládat přes grafické uživatelské rozhraní bez znalosti programování, ale to se týká jenom administrace. Ke tvorbě šablon je nutné umět HTML, CSS, PHP, to je základ. Dále je zapotřebí si nastudovat strukturu šablon a API (programové rozhraní) redakčního systému.

Potíže

ElonX je postaven na WordPressu, tento redakční systém podporuje tři typy šablon. Klasický typ používá PHP soubory jako stavební bloky. Záhlaví, postranní panel, hlavní obsah a zápatí existují ve formě samostatných souborů, které se ve výstupu spojují do jediné stránky. Kód PHP komunikuje přímo s funkcemi WordPressu, což dává kodérovi detailní kontrolu nad každým výstupem. Novějším typem jsou blokové šablony, postavené na blokovém editoru Gutenberg a editoru webů. Používají soubory šablon založené na HTML a konfigurační soubor theme.json pro ovládání globálních stylů a nastavení. Blokové šablony mají méně PHP kódu a umožňují vizuálně upravovat záhlaví, zápatí a další části šablony prostřednictvím editoru webů. Nejlépe se hodí pro projekty, které vyžadují flexibilitu vizuálních úprav. Hybridní typ jsou klasické PHP šablony kompatibilní s blokovými editory.

A co takhle použít nějakou už existující šablonu? Ano, to je nejrychlejší a nejpohodlnější řešení. Pro WordPress existuje spousta šablon – od placených až po ty úplně zdarma. Právě toto řešení Petr Melechin zvolil. Jak sami vidíte, bezvadně funguje. A co funguje, to plní účel. Takhle idylicky to však vypadá jen zvenčí. Ve skutečnosti se tu najde pár vad na kráse: bezpečnostní riziko, problematické aktualizace a špatná přizpůsobitelnost.

Bezpečnostní riziko

Tvůrci šablony mají v podstatě kontrolu nad webem, a mohou toho zneužít například k rozesílání spamu, DoS útokům na jiné servery nebo krádeži dat. Tento tzv. supply chain attack získává u útočníků na oblibě, protože nevyžaduje hledání technických chyb (místo toho se infiltrují do procesu vývoje nebo distribuce softwaru) a může zasáhnout tisíce webů najednou.

Problémy s aktualizacemi

Po aktualizaci může něco přestat fungovat. Neaktulizované šablony zase mohou představovat bezpečnostní riziko. WordPress je nejrozšířenější redakční systém, a proto nejčastější cíl útočníků. Ti používají automatizované skripty ke hledání právě takových starých šablon a pluginů.

Špatná přizpůsobitelnost

Většina moderních šablon nabízí vlastní nastavení v administraci, to se ale nedá srovnávat s možnostmi editace zdrojového kódu. Když však autor neví, do jakého souboru se podívat, a co přesně tam změnit, a jak, aby to následná aktualizace nepřepsala, pomůže si buď nějakým pluginem, který to udělá za něj, nebo se prostě smíří s tím, že něco není přesně tak, jak by chtěl. Jedna z věcí, které se bez pluginu nedají v administraci nastavit, je skloňování počtu komentářů. Proto na některých webech je na začátku diskuse informace ve tvaru: „0 komentáře“, „5 komentáře“ apod.

Když si to shrneme: ElonX je potenciálně zranitelný, některé věci nefungují a je komplikovanější něco měnit. Čtenářů to sice nijak neomezuje ani neohrožuje, ale pro redaktory je to někdy dost nepříjemné. Vlastní šablona, pokud se používá minimum cizího kódu a dodržují se bezpečnostní zásady (validace vstupů, escapování speciálních znaků), je z principu bezpečnější, lépe se s ní pracuje (protože kód je „čistější“) a její tvůrce má plnou kontrolu nad designem a funkčností webu.

Většinou první problém, na který autor narazí, je, že přednastavený styl není úplně ideální. V šabloně pro ElonX například bylo prvkům B, I, SMALL, BIG, TT a dalším nadefinováno, aby vlastnosti písma dědily od nadřazených prvků (font: inherit), což ale není vůbec žádoucí, protože jejich použití je pak bez efektu. Je potřeba dodat, že ani výchozí vzhled některých prvků (tj. objektů vyznačených tagy), definovaný na úrovni standardu HTML/CSS, není moc praktický, takže nutnosti úprav stylu by se autor nevyhnul ani s vlastní šablonou, naopak by jich bylo mnohem více.

Dalším zdrojem mrzutostí jsou takzvané filtry, to jsou funkce, které mění vstupní nebo výstupní data ještě před tím, než se uloží do databáze nebo zobrazí. WordPress každý příspěvek automaticky autorovi upraví a zformátuje. Například filtr wpautop převádí dvojité odřadkování v textu příspěvku na odstavce. Ve starších instalacích WordPressu navíc formulářové prvky separuje do samostatných bloků. Vypnout se dá vložením řádku remove_filter('the_content', 'wpautop'); na začátek souboru single.php. Filtr wptexturize zase nahrazuje textové znaky jinými – viz tabulka. Aby k tomu nedocházelo, musí být určité znaky napsány jako HTML entita (např. entita " = "). Úpravě se nevyhnou ani textové smajlíky, příslušný filtr z nich udělá obrázkové. Zákeřnost filtrů je obecně v tom, že se změny neprojeví hned při psaní příspěvku v editoru, ale ukážou se až na výstupu.

Vedle formátovacích filtrů dokážou autora zle potrápit i filtry, které „ošetřují“ a opravují obsah příspěvku tak, aby byl bezpečný, měl korektní syntaxi a nenarušoval strukturu. Kvůli bezpečnosti WordPress maže tagy, atributy a pseudoprotokoly, které mohou spustit JavaScript, nebo být jakýmkoli jiným způsobem potenciálně zneužitelné či závadné. Tato opatrnost má dobrý důvod, co kdyby autor nevědomky použil například nějaký SVG obrázek obsahující škodlivý skript, který by kradl data, nebo přesměrovával na podvodné stránky. Nic to ale nemění na frustraci z takových omezení.

Velmi nepříjemnou věcí je také komentářový spam. Nejúčinnějším způsobem, jak se ho zbavit, je povolit psát komentáře pouze registrovaným uživatelům. Pro čtenáře by však bylo obtěžující se registrovat a přihlašovat. Jaké jsou tedy další možnosti? V administraci lze nastavit, že nové komentáře musí být před zveřejněním schváleny, což ale též není ideální volba. Byla by to zátěž pro redaktory a komentáře by se zveřejňovaly opožděně. Lepší je nainstalovat CAPTCHA (test, který rozlišuje člověka a robota) nebo antispamový filtr. ElonX využívá filtr Akismet, který funguje dobře, a jen zřídkakdy nějaký spam propustí.

Kam nás posune AI?

Již dnes lze využívat umělou inteligenci k opravě chyb a stylizaci textu, nebo ji dokonce i přímo zapojit do tvorby obsahu, zatím však tyto funkce nejsou běžnou součástí redakčních systémů. To se ale asi časem změní. Umělá inteligence se také může postarat o sémantické značení informací. Autoři totiž sémantiku obvykle zanedbávají, důležité pro ně totiž je, jak jsou informace zobrazeny, ne, jak jsou vyznačeny. S nesprávně vyznačenými informacemi se však špatně pracuje, příkladem může být třeba stylování tabulek. Tabulky mají určité části, které autoři většinou chtějí zvýraznit, a přitom je neumí řádně vyznačit, typicky popisek nebo hlavičkové buňky.

<p><em>Prodeje vozů Tesla v roce 2025</em></p>
<table>
  <tr>
    <td><strong>1. Q</strong></td>
    <td><strong>2. Q</strong></td>
    <td><strong>3. Q</strong></td>
    <td><strong>4. Q</strong></td>
  </tr>
  <tr>
    <td>336 681</td>
    <td>384 122</td>
    <td>497 099</td>
    <td>418 227</td>
  </tr>
</table>

Umělá inteligence by tedy byla při publikační činnosti neocenitelná, na druhou stranu, čím více toho na ní budeme nechávat, tím více kompetencí budeme ztrácet, a stávat se na ní závislejšími.

• About
• Latest Posts

Pavel Salvet

Autor není odborníkem na kosmonautiku, zajímá se o veřejné dění a politiku, ve volných chvílích se věnuje latině.

Latest posts by Pavel Salvet (see all)

• Zpověď redaktora ElonX – Trable s WordPressem - 27. 9. 2026
• Starlink je v bojích na Ukrajině obrovským přínosem, ale Rusko ruší signál - 14. 8. 2026
• Toxický vliv platformy X a dalších sociálních sítí na společnost - 11. 8. 2026