Veřejným spuštěním webu práce na něm nekončí. Stejně jako stroj potřebuje také web pravidelný servis a dohled. Bez něj jednou, v tu nejméně vhodnou chvíli, prostě zůstane stát. Aby se to nestalo, je důležité pravidelně aktualizovat a kontrolovat jeho funkčnost.
Proč provádět pravidelnou správu?
„Proč je nutné provádět aktualizace WordPressu? Nehrozí, že update WordPressu bude nekompatibilní s pluginy? Nejsme specialisti na váš obor, z našeho pohledu chceme mít klid a řešit svou práci a nezabývat se aktualizacemi.“ Tyhle otázky slýcháme pravidelně a jsou naprosto na místě. V tomhle článku si vysvětlíme, co se pod pojmem „správa webu“ doopravdy skrývá. Ne pro vývojáře, ale pro vás, majitele webu nebo e-shopu.
Web nikdy nezůstává tam, kde ho dodavatel předal. Pořád se s ním něco děje, ať chcete nebo ne. Aktualizuje se prostředí kolem něj: WordPress, pluginy, prohlížeče, požadavky Googlu nebo AI platforem. A stejně jako u auta, i tady platí, že první příznaky komplikací se nemají podceňovat.
Nejde přitom vždycky o jedno dramatické selhání, o nabouranou karoserii, která je vidět na první pohled. Mnohem častější je pomalejší varianta: roky drobných, nekoordinovaných zásahů bez jasné koncepce. To je spíš jako nevyměněný olej nebo uvolněná matice, nic, co byste na první pohled poznali, ale postupně to web opotřebovává.
Přesně tohle vídáme u klientů, kteří provozují web bez dlouhodobé koncepce rozvoje. Přichází pořád nové nápady na nové funkcionality, které se postupně zapracovávají, jeden vedle druhého, bez jasného plánu. Web se tím zpomaluje, aktualizace se stávají rizikovými a správa se komplikuje. Dlouhodobě nepromyšlené zásahy nakonec vyžadují vysoké náklady na opravy a celkovou údržbu.
Jednomu klientovi přestal fungovat produkční web i vývojová verze najednou, s chybou Cloudflare 522. Server byl podle poskytovatele hostingu uzamčený kvůli údržbě, později se ukázalo, že jde o hardwarový problém přímo u dodavatele serveru. Řešením byla noční offline migrace. Nešlo o chybu WordPressu ani pluginu, ale i takový výpadek je potřeba umět rozpoznat a dotáhnout do konce. To je jeden z mnoha úkolů správce webu – musí si umět poradit.
Přínos: Servisní prohlídka se dělá předtím, než auto přestane startovat, ne až potom. Se správou webu je to stejné.
„Však to funguje, tak proč platit za licence?“
WordPress, pluginy i šablony se vyvíjejí nezávisle na sobě, každé jiným tempem. Pluginy z oficiálního repozitáře wordpress.org procházejí alespoň základní bezpečnostní kontrolou. U placených pluginů a šablon z tržišť typu EnvatoMarket ale žádná taková záruka není – leží zcela na jejich autorech. Nemluvě o pluginech, které vznikají živelně vibecodingem, tedy rychloprogramováním za pomoc AI nástrojů.
Riziko vibecodingu spočívá v tom, že laik za pomocí AI nástroje vytvoří software, který obsahuje koncepční chyby a bezpečnostní díry. Autor úkoluje AU nástroj tak, aby dospěl k zamýšlenému výsledku, často ale vůbec neví, že aplikace má mít určitou strukturu a mechanismy, které zabrání její kompromitaci nebo neví, jak si ověřit, že tyto mechanismy fungují. Tyto části kódu jsou snadno napadnutelné a jedná se o aktivní hrozbu. Výjimkou je samozřejmě situace, kdy za pomoci AI vytvořil kód zkušený programátor.
Riziko přitom nehrozí jen z toho, že aktualizaci neuděláte. Někdy se to pokazí i v okamžiku, kdy ji uděláte. A tady narážíme na druhé, skryté riziko, tentokrát z opačné strany. Placené pluginy potřebují platný licenční klíč, aby vás upozornily na novou verzi. Licence se platí obvykle na rok. Když ji majitel webu neprodlouží, protože si říká „vždyť to funguje, tak proč platit“, plugin přestane hlásit aktualizace. Vypadá to neškodně. Ve skutečnosti si tím na webu tiše pěstujete bezpečnostní díru, o které nevíte, dokud přes ni nepřijde [úspěšný] útok.
Někdy je problém přesně opačný, aktualizovat nechcete, protože se vám současný stav hodí. Jeden náš klient provozoval e-shop na WooCommerce se starší šablonou. Obchodu se dařilo, systém táhla parta pluginů na podporu prodeje, remarketing, provizní systém, sledování nákupního chování a Google Tag Manager. Pak klient zavolal, že přestalo fungovat tlačítko na změnu množství v košíku. Jeho zákazníci nabyli dojmu, že je někdo schválně blokuje.
Jenže kde hledat příčinu, když šablona už aktualizace nedostává a nevíte, který z desítky pluginů za to může? Nakonec se ukázalo, že viníkem byl právě Google Tag Manager. Jeho předchozí aktualizace chování rozbila, další ji zase opravila. Stálo to přímo v poznámkách k vydání. Není to ničí vina, prostě se to stalo, a celý systém takhle funguje.
Přínos: Aktualizace nejsou jednorázový úkol k odškrtnutí. Je to průběžné hlídání toho, co je zaplacené, aktuální a podporované.
Pracovní verze webu je nezbytný nástroj
Pracovní kopie webu, devel, má být co nejvíc podobná produkční verzi. Nemusí mít stejný obsah, ale musí mít stejný technický základ. Tady se zkouší aktualizace a testují výsledky, dřív než se cokoliv dotkne ostrého webu. Založí se třeba přes plugin All-in-One WP Migration, obsah přenese z aktuální produkce, a než je devel hotový, zablokuje se přístup robotům z vyhledávačů, třeba pluginem Maintenance nebo jiným pluginem servisního režimu.
Když se při aktualizaci na develu něco pokazí, nic se neděje. V klidu najdeme a opravíme příčinu. Kdyby to nešlo, vytvoříme devel nový. Máme k dispozici soubory s chybami (debug.log, error.log webového serveru) a můžeme upravit chování přímo v kódu jen tak na zkoušku (což se na produkčním webu nedělá).
Pokud vytváříme nový web, pak se pracuje ještě s verzí, které říkáme stage nebo preproduction (předprodukční verze). Ta už mívá stejná data jako produkce a obvykle se z ní produkční verze stane přenesením na ostrou doménu nebo přepnutím DNS.
Přínos: Úpravy na produkčním webu musí projít filtrem develu nebo stage. Nejste pak překvapeni něčím, co bylo patrné předem.
Bezpečnost jako trvalá otevřená výzva
Zabezpečení webu není nikdy hotové a konečné, je to proces, který nekončí. Bohužel je přirovnání k válce poměrně trefné – jde o sérii bitev na několika frontách, někdy a někde vyhrajete, jindy zase nevyhrajete nebo dokonce prohrajete. Často lze ale uhrát remízu, tedy udržovat stav, kdy jsou síly vyrovnané. Bráníte se před útoky, které mohou přijít
- chybou nebo nedostatkem v kódu (vytvořili jste si vlastní kód s nějakým AI nástrojem a dali si ho na web?), třeba přes neošetřená vstupní políčka formulářů,
- záměrem v kódu (to už je aktivní malware),
- získáním přihlašovacích údajů uživatele,
- kompromitací dat včetně těch zálohovaných,
- útokem ze strany serveru nebo lokální sítě (typické pro levné multihostingy, kde jsou weby vedle sebe ve složkách)
Napadený web nemusí vypadat napadeně. Nejviditelnější projev bývá rozpadlý design, neznámé texty nebo přesměrování na nežádoucí obsah (a to třeba pouze na mobilní verzi). Mnohem častěji ale napadení zjistíte až ve chvíli, kdy vám to oznámí hostingová firma, protože se z webu odesílá nevyžádaná pošta. Napadení přitom mohlo proběhnout před mnoha měsíci.
Škodlivý kód se typicky maskuje a schovává tam, kam se návštěvník nikdy nepodívá. Na jednom webu jsme takhle našli infikovaný wp-includes/index.php, a zároveň i skript functions.php přímo v šabloně.
PŘÍKLAD. Ne každé hlášení je ale skutečný problém. Prověřovali jsme hlášení o trojanu, které se ukázalo jako falešný poplach: šlo o PDF s aktivními odkazy, které antivirus vyhodnotil jako phishing, přestože bezpečnostní nástroj Wordfence při skenování žádné riziko nenašel.
Antivirus označil PDF s aktivními odkazy za trojan, Wordfence na webu nic nenašel
Weby, o které se staráme, máme zabezpečené několika nástroji – primárně službou Cloudflare, volitelně pluginem Wordfence a sérií nastavení na hostingu, včetně např. dvoufázového ověření u administrátorů webu. Těch je omezený počet a mají originální jména (v žádném případě nesmí obsahovat slovo ‚admin‘ nebo název webu).
Přínos: Napadení je důsledek zanedbané péče, ne náhoda.
Monitorování dostupnosti webu, platnosti domény a certifikátu
Každý výpadek webu má negativní dopad na dostupnost služeb – počínaje informacemi ke kontaktování firmy přes nabídku informací, které někdo hledá, až po provedení požadované akce, třeba vyplnění formuláře nebo dokonce provedení objednávky. Všechno tohle musí být pořád k dispozici a použití nesmí bránit žádná bariéra. V praxi ale k výpadkům – incidentům – dochází, jedná se typicky o následující, řazeno od frekvence výskytu dle naší zkušenosti:
- významný výpadek konektivity nebo infrastruktury (překopnutý páteřní kabel při výstavbě dálnic nebo železnic, vyhořelé datové centrum v Praze, Frankfurtu, Mnichově…)
- nefunkční překlad adres nebo DNS (může souviset s předchozím bodem)
- výpadek hostingu (havárie serveru, výpadek proudu včetně záložních generátorů)
- propadlá doména (nezaplatili jste poplatek za prodloužení)
- propadlý certifikát pro https (chyba procesu na hostingu, protože certifikáty se obnovují automaticky)
- stránka se nevykreslí správně nebo celá (obvykle chyba po updatu v nějakém specifickém scénáři použití nebo jde o starou verzi z cache)
- stránka hlásí chybu 403, 404 nebo 50x místo svého obsahu (jde o o kombinaci různých příčin souvisejících se špatným nastavením redakčního systému nebo hostingu, patří sem i slabý výkon hostingu)
Tyto příčiny nemůže správce webu vždy ovlivnit, ale musí o nich vědět – ideálně dříve než majitel webu. K tomu se používají monitorovací nástroje, mohou být úplně jednoduché a bezplatné, ale také sofistikované a placené. Máme zkušenosti s následujícími (ale služeb je samozřejmě velmi mnoho):
- UptimeRobot.com – v bezplatném základu umožňuje sledovat až 50 webů s využitím pevných podmínek, např. 5minutový interval, max. 5 komunikačních kanálů (Discord, Google Chat, pushover a další méně populární způsoby), v placených verzích pak přibudou Slack, Telegram a další pokročilé vlastnosti včetně testování z více lokací na světě, více monitorů a více uživatelů
- Uptime Kuma – self hosted nástroj, který je s UR plně srovnatelný, samozřejmě není nutné platit jakékoliv licence, takže všechny vlastnosti jsou k dispozici hned; nástroj ovšem nemá podporu pro multilokační monitoring, tzn. dostupnost zjišťujete pouze z jednoho místa
- Icinga je pokročilý a trochu old-school nástroj pro linuxové adminy, kterým umožňuje sledovat infrastrukturu, a to včetně vytížení, kvót nebo různých typ nedostupností ve sledované síti
Naše monitorovací nástroje nás informují do chatu Nextcloud Talk, do Telegramu a mohly by i jinam (SMS, push notifikace). Vidíme a slyšíme ihned, pokud dojde k nedostupnosti nebo výpadku, navíc nám s předstihem hlásí blížící se termíny platnosti domény a certifikátu.
Přínos: Pomocí dobře vybraných nástrojů, jejich vhodnému nastavení a správně vyladěných procesů lze tak přesně a ihned vědět, co se s webem nebo serverem děje, jak dlouho to trvá a jakou měl incident příčinu.
Správné zálohování jako jistota, ne marketingový kec
Mnoho hostingových firem provádí pouze formální technickou zálohu vašeho webu pro případ, že na jejich straně dojde k technické chybě. Nejedná se tedy o zálohy, které mají za úkol pokrýt problémy způsobené na vaší straně – tedy nesprávnou nebo zanedbanou aktualizací, napadením webu nebo jinými průšvihy. Hostingy negarantují aktuálnost ani úplnost dat. Odpovědnost za zálohování je na vaší straně, resp. je to úkol pro správce webu.
Často se stává, že pokud je web napadený, vesele se zálohuje a zálohy jsou kontaminované, tedy nevhodné pro jeho případnou obnovu.
Mnoho firem, které se o weby starají, se chlubí tím, že dělají každodenní zálohu vašeho webu. Jako argument používají častou frekvenci záloh. To funguje u malých webů. Ale pokud má web 30 GB uživatelských dat a 8GB databázi, vzniká spousta okolností, které je potřeba zohlednit – každodenní komplexní zálohování není úplně realistický proces a ani nezvyšuje bezpečnost pro případ napadení. Chytřejší přístup je třeba následující (přečtěte si článek na Wikipedii o zálohování dat):
- Stanovit zálohovací schéma – tedy komplexní zálohy a inkrementální zálohy.
- Oddělit proces zálohování souborů, databáze a třeba konfigurace webu nebo souborů mimo redakční systém.
- Stanovit proces pro částečné a komplexní obnovení a pravidelně ho testovat.
- Pravidelně testovat funkčnost a celistvost záloh.
- A v neposlední řadě je nutné zohlednit bezpečnost a legislativní požadavky na proces zálohování (GDPR, NIS2, DORA, dostupnost v EU/mimo EU).
Takový přístup vidíme málokdy, pořád je dost majitelů i správců, kteří se spokojí se zálohou na stejný server, kde běží web, v lepším případě na Google Drive nebo Dropbox. Z dnešního pohledu už to může být porušení platné legislativy, protože umístění těchto cloudových serverů není vždy transparentní. Může se stát, že odesíláte [cizí] data mimo EU.
Přínos: Správně nastavené zálohování je nezbytná součást kvalitní péče o web. Práce s rizikem do náplně správce patří a je povinen je minimalizovat.
Nepřehlédněte naše případovky
Komunikace a koordinace se zákazníkem
Když náš klient očekává skokové navýšení návštěvnosti, protože pořádá větší akci nebo se prezentuje v médiích, potřebujeme o tom vědět předem. Jako externí tým nemáme automatický přístup k interním informacím klienta. Proto považujeme partnerskou komunikaci za důležitou součást spolupráce. Obvykle máme návrh, jak rizika u očekávaného náporu snížit.
Jeden náš klient akutně požadoval řešení zpomaleného webu, který najednou často padal. Právě probíhala konference a na stránky přišlo mnohem víc návštěvníků, než web unesl. Klient o akci dopředu věděl, ale nepodal nám žádnou informaci, a teprve v jejím průběhu žádal rychlé řešení. To už bylo pozdě.
Šlo o kombinaci zastaralého PHP 7.4 a nedostatečného paměťového limitu hostingu. Řešením bylo přejít na PHP 8.3, navýšit paměťový limit a doladit cache. To se špatně provádí v okamžiku, kdy akce probíhá a web má podávat výsledky.
Přínos: Informace o chystaných akcích a kampaních jsou stejně důležité jako samotná technika.
Jistotou jsou ověřené postupy a systém
Typická aktualizace webu a jeho komponent probíhá 2-3x měsíčně, protože každá součást má jinou frekvenci vydávání nových verzí. Sledujeme vývoj komponent a u kritických pluginů soubor se změnami v kódu (changelog) a vývojářské newslettery. Updaty webů nejprve provádíme na develu, obvykle automaticky nebo automatizovaně, pokud to jde. U složitějších webů je proces komplexnější, abychom minimalizovali rizika a nespadli do králičích, liščích nebo zaječích nor. 🙂
- Aktualizujeme pracovní verzi webu (devel).
- Provedeme technickou a vizuální kontrolu, opravíme chyby a popíšeme změny pro zákazníka.
- Domluvíme se zákazníkem servisní okno, informujeme ho o změnách.
- Provedeme výběrový a krokový update ostrého webu, od bezproblémových pluginů k rizikovějším.
- Opět provedeme kontrolu – funkční, vizuální, procesní:
- chování v administraci,
- vzhled a funkčnost mobilní verze,
- funkčnost formulářů, platebních bran, transkačních e-mailů apod.
- O všem si vedeme záznamy v informačním systému, abychom kdykoliv mohli dohledat provedené změny a informace k nim.
PŘÍKLAD. Přesně takhle probíhala rozsáhlejší revize e-shopu HSP Partners, který si za roky práce různých dodavatelů nasbíral řadu pluginů. Prošli jsme je jeden po druhém, zapsali, k čemu slouží, a jestli jeho funkci nedělá duplicitně i jiný plugin. Vznikl seznam s doporučením „ponechat“, „sloučit“ nebo „odstranit“, a teprve po odsouhlasení klientem jsme revizi pluginů reálně provedli. Upřímně – klienti obvykle důvěřují naší zkušenosti a pročištění pluginů nám svěří bez připomínek.
Obtížně se předem testují platební brány a jiné procesy závislé na skutečném provozu, stejně jako pluginy dodavatelů bez vývojářské licence. Tyto kontroly provádíme často řízeně na produkční verzi webu, často v nočních hodinách, aby případné výpadky nebo chyby zasáhly minimum návštěvníků/zákazníků.
Přínos: Postup vás provede procesem a máte plán i pro situaci, kdy se něco nepodaří.
WooCommerce vyžaduje ještě víc péče
U e-shopu platí všechno výše uvedené a ještě jedna věc navíc: každá minuta výpadku tu stojí reálné peníze. Problémy mohou vypadat jednoduše, ale příčiny bývají zapeklité, vyžadují komplexní přístup a výhodou jsou také letité zkušenosti. Mnoho e-shopů funguje ve více jazycích a měnách, což znamená, že pro tyto funkce potřebují mnoho dalších pluginů. Mezi nimi můžeme docházet ke konfliktům nebo nesouladu.
PŘÍKLAD. Na jednom e-shopu přestal být dostupný košík, pak celý web. Podpora hostingu našla dlouho běžící požadavky s marketingovými parametry jako utm_source nebo gclid, některé přes 1400 sekund. Takové URL mohou obcházet cache a nutit web zpracovat požadavek přes databázi znovu a znovu. Řešením bylo nastavit cache, aby query stringy ignorovala, a zkrátit časový limit pro zpracování požadavků.
Druhý typický problém e-shopu je doručitelnost. Na jednom webu bylo potřeba nastavit e-maily tak, aby registrace a objednávky nepadaly do spamu. Nastavili jsme SPF a DKIM záznamy a otestovali doručitelnost. Problém se ale později objevil znovu: nastavení SMTP pluginu se vrátilo k původnímu, nefunkčnímu stavu. Přenastavili jsme ho na Mailgun a znovu ověřili, že testovací zpráva skutečně dorazila.
Přínos: U e-shopu se chyba nezastaví na vzhledu. Proto platí stejná pravidla, jen přísněji.
Správce nesmí podporovat technický dluh
Technický dluh není jen stará verze WordPressu. Patří sem celý sloupec vzájemně závislých vrstev: staré PHP, zastaralá jQuery, opuštěné pluginy, duplicitní instalace, nebo staré knihovny uvnitř šablony, které vůbec nemusí být vidět.
Jeden web, který jsme přebírali do správy, běžel na WordPressu 4.7.26, přestože šlo o velkou a zavedenou firmu. Nikdo si nevšiml (nebo možná nebyl nikdo zodpovědný), že je potřeba aktualizovat, a technický dluh se roky nabaloval. Podobně dopadl i web z předchozí sekce: roky neřešená kombinace zastaralého PHP a nedostatečného hostingu se za běžného provozu neprojevila, ale nevydržela nápor jedné konference.
Někdy dluh nevzniká na vaší straně. Rok 2018 a 2019 bylo období, kdy se všichni přesouvali na zabezpečený protokol https. Konec roku 2023 přinesl jiný příklad: registr ARES tehdy změnil své API, a tahle změna se propsala i do aplikací, které na něj byly napojené. V roce 2025 a 2026 jsme řešili, jestli na weby pustit AI roboty a co z toho je vlastně plus a co mínus.
Někdy vzniká technický dluh nenápadně – nezodpovědný správce nebo někdo, kdo „nechtěl problémy“ nastavil plugin, který skryje všechny aktualizace. V administraci je pak roky všechno sluníčkové, aktuální a bez problémů.. dokud se plugin nevypne a nevyskočí desítky řetězených aktualizací a problémů.
Přínos: Platformu WordPress je potřeba udržovat. Technický dluh je drahý. Čím dřív ho odstraníte, tím to bude méně bolet.
Kolik to stojí a co se stane, když se to nedělá
Zanedbaný firemní web bude stát hodně peněz. Skutečná otázka nezní, kolik stojí správa, ale kolik by stálo, kdyby se neřešila vůbec. Oprava, obnova a zabezpečení dva roky zanedbaného webu vás mohou přijít až na desítky tisíc korun. Někdy je dokonce kvůli aktuálním požadavkům, které stará platforma nesplní, lepší vyrobit nový web:
- Starý web byl na staré verzi WP Bakery a marketér chce nyní dělat moderní landing pages pomocí AI nástrojů.
- Stránky jsou vytvořené v Elementoru před 5 lety a nové landing pages vypadají jinak než zbytek webu. Nebo naopak nové úpravy změní starý obsah. Ten je nutné celý přepracovat.
- Klíčový katalog produktů/služeb je vytvořený pomocí nějakého pluginu, který už roky nemá žádné updaty ani podporu. Web má datové struktury, ale už je nejde upravovat ani přidávat nové.
To je několik příkladů, které jsme řešili vytvořením nového webu a jeho komponenty „kolem existujících dat“. AI nám to dnes usnadňuje, ale pořád je to komplexní úkol.
Časté otázky a odpovědi
Jak často se má WordPress aktualizovat?
Záleží na typu webu. U firemní prezentace nebo blogu stačí kontrola jednou týdně. U e-shopu nebo webu s přihlašováním je lepší denně, bezpečnostní záplaty nasazujeme hned po vydání.
Co se stane, když web dlouho neaktualizuji?
Klidně nic, dokud někdo nenajde díru ve staré verzi. Pak přichází napadení a zhroucení webu, alternativně reklamy na kasína nebo sázky, někdy viditelné jen na mobilu. Samozřejmě se to vše objeví ve výsledcích vyhledávání pod vaším názvem a poškozuje to váš brand.
Můžeme si správu webu dělat sami?
U jednoduchého webu ano, pokud máte čas sledovat changelogy a testovat na develu. U e-shopu se profesionální hlídání vyplatí.
Jak poznáme, že je web napadený?
Nejčastěji to nepoznáte sami. Přijde na to hostingová firma, antivirus v prohlížeči, nebo si všimnete přesměrování na cizí stránky či neznámého uživatele v administraci.
Musíme mít testovací (vývojářskou) verzi webu?
Nemusíte, ale u WooCommerce to prakticky doporučujeme bez výjimky. Staging se hodí hlavně před aktualizací jádra, migrací na novou verzi PHP nebo před redesignem.
Čím se liší správa e-shopu od běžného webu?
Navíc se řeší e-mailové notifikace objednávek a výkon databáze. Chyba tu má přímý dopad na tržby.
Kolik stojí správa webu?
Podle rozsahu a typu webu se běžně pohybuje v řádu stovek až tisíců korun měsíčně, u e-shopů výš. Přesnou cenu vám spočítáme na základě konkrétního webu.
Předchozí dodavatel nám nepředal přístupy k webu. Poradíte si?
Ano, dohledání chybějících přístupů je běžná součást převzetí webu. Máme o tom i článek – co dělat, když správce odešel.
Web spuštěním nekončí, tam teprve začíná. Princip je stejný pro každý web: nejdřív pracovní verze, pak ostrá, žádná improvizace. U e-shopu platí totéž, jen přísněji.
Nebojte se na nás kdykoliv s důvěrou obrátit, společně se domluvíme a vyjasníme potřebné informace a podklady.
Pojďme si promluvit
Kliknutím na tlačítko si můžete v kalendáři bezplatně zarezervovat termín obchodní schůzky nebo bezplatné konzultace. Bude to hovor, kdy zjistíme vzájemná očekávání pro případnou spolupráci. Nejde o prodej.
Datum se uloží do kalendáře, e-mailem vám přijde potvrzení a odkaz na hovor. Hodinu před ním vám dorazí e-mailem připomínka. Budu na vás čekat.
Vlasta Ott
