Kontrola před spuštěním webu

květen 29 2019

Lukáš nám v Tritonu připravil checklist nejběžnějších chyb, které je překontrolovat před každým předáním nového webu. Protože se ale stále rozrůstáme a jednu větu v checklistu jde interpretovat různými způsoby, rozhodl jsem se vytvořit tento blogový zápisek, který to rozepisuje trochu podrobněji.

Nahrazuji starý web? Nastavil jsem přesměrování všech původních URL?

Důležitou součástí spuštění nového webu je bezproblémový přechod návštěvníků na novou verzi. Zejména v případech, kdy měníme platformu, tj. při přechodu na jiný CMS nebo u nové implementace webu, musíme ověřit, že ze všech původních URL se dostaneme na odpovídající sekci nového webu.

Nedodržení tohoto pravidla má dva zásadní dopady:

  • Oslabení vlivu zpětných odkazů, které nyní povedou na chybovou stránku.
  • Ztráta návštěvnosti a zákazníků. Stejně jako vyhledávače, i lidé neradi přicházejí na chybovou stránku - frustrace a zmatenost z neohlášené změny webu může poškodit značku. Například u e-shopů si zákaznící rádi ukládají záložky na produktové stránky.

Fungují všechny stránky webu? Fungují všechny formuláře? A co další funkce?

Před spuštěním je bezpodmínečně nutné projít každou stránku webu a ověřit, že skutečně funguje, stejně tak i interaktivní prvky, formuláře apod.

Není nic horšího, než zjistit, že nám týden nechodily objednávky od zákazníků, protože formulář byl špatně nastaven.

Je web optimalizovaný pro vyhledávače, tj. má dobré on-page SEO?

Základní meta informace

Každá stránka webu musí obsahovat tag title a description. Title stránky odpovídá skutečnému názvu, doplňujeme ho navíc také o název webu nebo nadřazené sekce za oddělovacím znakem. U titulní stránky obvykle dáváme název webu na první místo a za oddělovač přidáváme podtitulek nebo velmi krátký popis. Pokud stránka nemá vlastní popis, který by mělo smysl použít, pak description bude obsahovat alespoň obecný popis uvedený na titulní stránce webu.

Příklad:

<title>Rychlý networking | Net Forest</title>
<meta name="description" content="Děláme rychlý networking nejen pro start-upy. Na akcích Net Forest se seznamují lidé, kteří aktivně rozvíjejí své podnikání i profesní kariéru a těší se na nové příležitosti..">

Informační architektura stránek

Každá stránka musí dodržovat logický tok HTML elementů. Nevkládáme blokové (block) prvky dovnitř řádkových (inline), každá stránka má právě jeden nadpis úrovně h1, který je obvykle shodný s obsahem title tagu bez zmínění názvu webu. Jednotlivé obsahové sekce mají svůj vlastní příslušný nadpis nižší úrovně.

Každý obrázek vložený prostřednictvím img tagu by měl mít nastaven argument alt a v něm svůj krátký textový popis.

Příklad: https://www.netforest.cz/jak-to-funguje

URL stránek

Název stránky v URL by měl kopírovat název v title a h1. Jednotlivá slova oddělujeme pomlčkou, písmena měníme na malá a odstraňujeme interpunkci, háčky a čárky.

Příklad: https://www.hlinikova-strecha.info/vite-proc-je-plechova-strecha-lepsi-volbou-nez-tasky/

Sdílení odkazů na web

Většina webů přizpůsobených pro uživatelské sdílení odkazů dnes vytváří náhled odkazovaného webu. Protože vykreslovat celý skutečný snímek obrazovky je nepraktické, sestavovaly se podobné náhledy dříve pomocí triku - stáhl se title stránky a byl doplněn o první velký obrázek a souvislý text na stránce. Dnes si ale optimalizaci sdílení můžeme zjednodušit použitím OpenGraph meta tagů. U OpenGraph jde náhled sdílení dokonfigurovat vlastními informacemi. Každý web by měl obsahovat všechny meta tagy z příkladu. Náhledový obrázek by měl být alespoň jeden.

Pro testování náhledů lze využít Facebook sharing debugger: https://developers.facebook.com/tools/debug/sharing/

Příklad: https://www.netforest.cz/

    <meta property="og:url" content="https://www.netforest.cz">
    <meta property="og:type" content="website">
    <meta property="og:title" content="Rychlý networking | Net Forest">
    <meta property="og:description" content="Děláme rychlý networking nejen pro start-upy. Na akcích Net Forest se seznamují lidé, kteří aktivně rozvíjejí své podnikání i profesní kariéru a těší se na nové příležitosti..">
    <meta property="og:image" content="https://www.netforest.cz/images/netforest-photo1.jpg">
    <meta property="og:image" content="https://www.netforest.cz/images/netforest-photo2.jpg">
    <meta property="og:image" content="https://www.netforest.cz/images/netforest-photo3.jpg">
    <meta property="og:image" content="https://www.netforest.cz/images/netforest-photo4.jpg">
    <meta property="og:image" content="https://www.netforest.cz/images/netforest-photo5.jpg">

Nastavení pro roboty, vyhledávače a odkazy vedoucí ven z webu

U každého webu jde nastavit doporučení, jak by se měly chovat programy, které jej automatizovaně procházejí. Tato pravidla fungují pouze jako přání - nejde jimi vynutit dodržování. Pravidla pro roboty jde nastavit na třech základních místech:

  • Soubor robots.txt, který je uložen ve web root složce - povolení a zákaz přístupu k dalším souborům.
  • Meta tag robots HTML dokumentu: nastavení ukládání odkazů a indexování webů.
  • Atribut rel u odkazů uvnitř HTML dokumentu: chová se stejně jako u meta tagu, ale platí jen pro tento konkrétní odkaz.

Nastavení u odkazů se týkají cílové URL ve vztahu k současné stránce, nastavení uvnitř meta tagu robots se vztahuje ke všem odkazům na současné stránce. Nastavení v robots.txt umožňuje vytvářet pravidla pro celý web nebo jeho části.

Po finálním spuštění webu je potřeba ověřit, že na žádné veřejně dostupné stránce není nastaven zákaz indexování nebo crawlingu.

Příklad meta tagu - zákaz indexování stránky a následování jejích odkazů:

<meta name="“robots“" content="“noindex,nofollow“">

Příklad robots.txt - povolení crawlingu všem robotům na celém webu s vyjímkou složky admin a jejího obsahu:

User-agent: *
Disallow: /admin

Rychlost načítání

Od moderního webu, který se zobrazuje ve vyhledávačích, se o čekává rychlé a pohodlné načítání. Všechny obrázky na webu minifikujeme tak, aby zabíraly co nejméně místa a při jejich stahování se tak přenášelo co nejméně dat. Stejně jako obrázky, minifikujeme také CSS a JS odstraněním funkčně zbytečného formátování a zkrácením názvu proměnných.

Pro minifikaci jpg, png a gif obrázků lze využít web TinyPNG: https://tinypng.com/, v CMS systémech jsou dostupné minifikační pluginy.

Pro minifikaci skriptů a grafických stylů lze použít https://www.minifier.org/, lepší je ale nastavit si automatickou minifikaci ve vývojovém prostředí.

Pro testování rychlosti lze využít Google PageSpeed Insights: https://developers.google.com/speed/pagespeed/insights/?hl=cs

Je web zabezpečený? Chrání před spamem?

Nastavení HTTPS

Všechny weby, které spouštíme pro klienty, musí mít na finální doméně nastaven přístup přes HTTPS na portu 443. Verze bez šifrování na portu 80 musí na šifrovanou verzi přesměrovávat a to tak, že mění protokol a zachová zbytek původní URL.

Na našem serveru nastavujeme přesměrování pomocí konfigurace web serveru NGINX. Na externím hostingu většinou běží Apache HTTP server, který můžeme dokonfigurovat souborem .htaccess ve web root složce webu (tečka na začátku značí skrytý soubor v Linux / Unix systémech).

Příklad - pravidlo pro vynucení www a https před názvem domény:

RewriteEngine On

RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]

RewriteCond %{ENV:HTTPS} !^.*on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

HTTPS certifikát u webů citlivých na utajení dat nakupujeme a nebo používáme certifikáty vystavené certifikační autoritou Let's Encrypt. K nasazení certifikátů od Let's encrypt používáme automatizační nástroj certbot a jeho plugin pro webový server NGINX python-certbot-nginx.

Pokud nasazujeme Let's encrypt certifikát někam, kde nejde použít certbot, musíme ručně sestavit žádost (CSR) a odeslat ji na servery Let's encrypt, ručně provést ověření domén a pak hotový certifikát nasadit. Proces jde usnadnit použítím webové aplikace jako jako zerossl.com.

Obfuskace e-mailů

Všechny veřejně viditelné emailové adresy na webu musí být upraveny, aby je spamboti nemohli jednodušše přečíst Nejjednodušší metoda, jak toho docílit, je sestavení finálního textového řetězce (klikatelného) emailu pomocí javascriptu. Nejběžnější webové scrapery neumí javascript interpretovat.

Příklad obfuskace kontaktního emailu z webu tritonit.cz:

<script type="text/javascript"><!--
    var ivntlhw = ['t', 'i', 'e', 't', 'a', 'c', '"', 't', 's', '@', 't', ' ', '<', 'a', '"', '@', 'r', 'o', 'm', 't', 'i', ':', 'o', 'r', 'c', 'o', '<', ' ', 'i', 'i', '.', 'z', 't', 't', 'c', 'a', '=', 's', 'l', 'n', 'i', 'z', 'n', '/', 'o', 'f', 'f', 'e', '>', '>', 'n', 'm', 'i', 'o', 'n', 'h', 'l', 'a', 'i', 'l', 'i', '.', '=', 'f', '"', 'r', 'a', '"'];
    var schidlm = [60, 55, 41, 13, 36, 30, 8, 56, 37, 20, 53, 2, 64, 66, 40, 52, 4, 57, 42, 21, 16, 15, 14, 54, 34, 25, 0, 33, 23, 59, 29, 63, 28, 24, 62, 1, 39, 38, 12, 49, 48, 31, 17, 65, 19, 50, 18, 5, 47, 67, 26, 9, 11, 51, 58, 3, 35, 43, 27, 45, 44, 61, 7, 6, 32, 22, 10, 46];
    var bwmotom = new Array();
    for (var i = 0; i < schidlm.length; i++) {
        bwmotom[schidlm[i]] = ivntlhw[i];
    }
    for (var i = 0; i < bwmotom.length; i++) {
        document.write(bwmotom[i]);
    }
    // -->
</script>
<noscript>
  Pro zobrazení emailové adresy, prosíme, zapněte JavaScript.
</noscript>

Ochrana formulářů

Všechny veřejně dostupné formuláře potřebují antispamovou ochranu. V případě použití CMS systému (Wordpress) můžeme ochranu svěřit pluginu pro vytváření těchto formulářů. V případě tvorby webu od začátku je potřeba alespoň nějakou ochranu vytvořit ručně.

Nejjednodušší metoda ochrany je přidání skrytých polí do formuláře tak, že je robot nedovede rozeznat od zbytku.

Nastavil jsem měření návštěv?

Až na naprosté výjimky měříme u všech webů návštěvnost uživatelů. Tyto informace jsou v internetovém marketingu velmi důležité neboť nám umožňují přízpůsobit web na základě chování návštěvníků, analyzovat, co nám přináší nejvíce peněz, nebo zacílit na určitou skupinu podrobnější reklamu.

Google Tag Manager & Google Analytics

Na všech webech nasazujeme kód Google Tag Manager. Ten nám dovoluje spravovat kódy ostatních služeb přehledně z jednoho místa ve webovém prohlížeči, aniž bychom museli zasahovat do zdrojového kódu webu. Společně s Google Tag Managerem automaticky nasazujeme i základní měření Google Analytics, a to prostřednictvím tagu Universal Analytics s nastaveným měřením Page View.

Měření konverzí

Pokud vytváříme web, vždy tím sledujeme nějaký cíl nebo úkol, který bude web vykonávat. K ověřování plnění tohoto cíle slouží konverze. Rozplánování konverzí bychom měli řešit už při designové fázi webu. Během vývoje pak musíme zajistit, že jsou jednotlivé cíle měřitelné - tzn., že existuje způsob, kterým web dá vědět, že uživatel právě splnil vytyčený cíl.

Konverze si pomyslně dělíme na měkké a tvrdé. Tvrdou konverzí rozumíme úplné splnění úkolu webu - například dokončení prodeje zboží v e-shopu, odeslání poptávkového formuláře, nebo využití mzdové kalkulačky. Měkkou konverzí rozumíme buď splnění vedlejšího úkolu webu (přečtení celého článku, prohlédnutí kontaktních osob firmy), nebo dokončení významného kroku na cestě ke tvrdé konverzi, například ověření dostupnosti internetu, začátek vyplňování kontaktního formuláře, apod.

Měkké konverze obvykle využíváme k rozhodování, jak budeme s návštěvníkem nebo zákazníkem dále pracovat. Pokud někdo přidal zboží do košíku, mohl by nákup ještě dokončit, pokud si ověřil dostupnost služby, mohl by si ji ještě objednat.

Je všecho v pořádku s obsahem webu?

Na úplný závěr je potřeba sebekriticky znovu projít web. Skutečně vše vypadá dobře a na 100% funguje? Vypadá web tak, abych na něj mohl být hrdý? Nezapoměl jsem na žádnou funkci?

Odstranění testovacích dat

Odstranil jsem všechna testovací data a stránky? Co debugové výpisy do logu nebo konzole prohlížeče? Přepnul jsem web na produkční režim? Co databáze a číselníky v ní - jsou zde nahrána správná data?

Korektura textu

Jsou všechny texty gramaticky správně - bez hrubek a překlepů? Nezarovnává se někde podivně text na více řádků? Dávají všechny texty smysl? Kolik lidí si web pročetlo - můžu opravu věřit jen sobě nebo jedné další osobě? Odkazují se stránky na webu jedna na druhou v rozumné míře? Jsou odkazy vedeny z důležitých slov pro web - například běžných nákupních frází z vyhledávání?

Ošklivá grafika

Odpovídá grafika původnímu záměru designera? Skutečně se web zobrazuje správně na všech typech zařízení a v různých prohlížečích? Co dočasné fotografie a obrázky - vypadají dobře? Mám zajištěný termín dodání finálních fotografií od klienta?

Uživatelé, role a firmy na Facebooku

květen 10 2019

Administrace a oprávnění na Facebooku nejsou úplně triviální, zvlášť dokud si nesáhnete úplně na každou situaci a roli. Tento zápisek je pokusem o co nejstručnější vysvětlení principů.

Osobní účet a Firma:

Při registraci do Facebooku se automaticky vytvoří Osobní účet. Pro veškerou práci s Facebookem už není potřeba vytvářet žádné další přihlašovací údaje. Rozšíření na Firmy i Reklamní účty už jde zakládat prostřednictvím Vaší osoby.

Osobní účet (tj. Vy) může být součástí jedné nebo více Firem. Ve Firmě jsem buď admin nebo zaměstnanec. Admin nastavuje Firmu a přiděluje pravomoce uvnitř Firmy, zaměstnanec může Firmu jen opustit.

Firma buď vlastní nebo dostává přístupy ke Stránkám a Reklamním účtům. Administrátoři Firmy mohou libovolně přidělovat oprávnění zaměstnancům na všech stránkách a reklamních účtech, ke kterým se Firma dostane. Maximální úroveň oprávnění, které může admin přidělit závisí na tom, jaké přístupy dostala Firma. Z toho plyne, že pokud Firma stránku vlastní, může její admin přidělit maximální možný přístup.

Používání Firmy:

Pokud jsem členem Firmy a dostal jsem v jejím rámci oprávnění k nějaké Stránce, přibude mi tato Stránka na Facebooku a mohu ji upravovat. Na venek ale nikdo nepozná, že změny dělám konkrétně já. Dovnitř Firmy vidí jen její členové. To, jestli se můj účet právě chová jako Firma nebo jako Osobní účet, poznám podle domény, na které se nacházím. Na webu www.facebook.com jsem jen základní osoba. Na business.facebook.com se můj účet chová jako právě vybraná Firma a já mám administrativní možnosti podle mojí role v této Firmě. Pokud nejsem členem žádné Firmy, můžu ji vstupem na business.facebook.com založit.

Partnerské Firmy:

Firma A může nasdílet některé své účty a stránky Firmě B. Udělat to mohou administrátoři Firmy A tak, že přidají Firmu B jako partnera ve svém firemním Business Manageru, tj. administrační sekci Firmy.

Stránka a její vlastnictví:

Facebooková Stránka může být vlastněna buď Osobním účtem nebo Firmou. Vlastník je automaticky ten, kdo ji založil. Vlastnictví jde převést z Osobního účtu na Firmu ale ne obráceně. Převést jde také z Firmy A na Firmu B. Vlastník je vždy jen jeden.

Kromě vlastníka jde u Stránky přidělit role také dalším uživatelům. Jsou to:

  • Admin = práva na všechno kromě změny vlastnictví.
  • Editor = práva na úpravu nastavení informací o stránce a přidávání příspěvků, nemůže nastavovat uživatelské role.
  • Moderator = práva na mazání komentářů a moderování diskuzí.
  • Advertiser = Může ve jménu stránky dělat reklamu nebo boostovat příspěvky.
  • Analyst = Může číst statistiky o výkonu stránky.

Reklamní účet:

Ke tvorbě reklamy je potřeba vytvořit Reklamní účet. Jsou dva typy, podle toho, kdo ho založil: osobní a firemní. Osobní reklamní účet nejde sdílet na nikoho dalšího, jde u něj ale převést vlastnictví na Firmu, pokud jsem zároveň administrátorem této Firmy. Reklamu ale z Osobního reklamního účtu mohu dělat na libovolnou stránku, kde k tomu mám dostatečné oprávnění.

Firemní reklamní účet je potřeba založit adminem Firmy. Mohu u něj sdílet oprávnění svým zaměstnancům a prostřednictvím Partnerství jej mohu sdílet i do ostatních Firem. Nemohu jej sdílet s Osobními účty. Také Firemní reklamní účet rozlišuje různé role:

  • Správa účtu = Právo na nastavování fakturace a platebních metod a všecho ostatní.
  • Správa kampaní = Právo na tvorbu reklamních kampaní a boostování příspěvků. Na tvorbu reklamy pro danou Stránku u ní musím mít navíc také alespoň roli Advertiser.
  • Čtení výsledků = právo na čtení výsledků reklamy.

Komplikace všeho s Instagramem:

Aby nic nebylo jednoduché, tak Facebook koupil Instagram a prapodivným způsobem propojil jejich administrace a účty.

Vlastníkem Facebook stránky tak může být nejen Osobní účet a Firma, ale také Instagramový profil. Instagramový profil se na přehledu rolí u stránky zobrazuje úplně stejně jako Firma, stejně tak také skrývá své uživatelské role uvnitř. Externí admin tak nepozná, co to je vlastně za typ účtu.

Jako u Firem i zde platí, že stránku ve vlastnictví Instagramového profilu už nejde převést zpátky na Osobní účet. Jde ji tak uvést do stavu, kdy se majitele už nejde zbavit, aniž by byla založena Firma a stránka navlastněna touto Firmou.

Certbot fails renewal with http-01 challenge on NGINX: Connection refused

dub 14 2019

The problem

This has been bothering me for more than half of a year. You might be unable to automatically renew certificates if the following conditions are true:

  • You're using the python-certbot-nginx plugin to install certificates and handle their renewal on your webserver.
  • You're using different location for acme-challenge than the actual folder inside installation root - this is most likely if you're using NGINX as a proxy for a different service.

During the renewal process you will most likely receive the following error:

Attempting to renew cert (example.com) from /etc/letsencrypt/renewal/example.com.conf produced an unexpected error: Failed authorization procedure. example.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://www.example.com/.well-known/acme-challenge/1hDMJJfjSOPJENxVmuXdDiphrVlEgRGXfHWB7Z8: Connection refused

However testing the connection with curl or wget from any location predictably gives just a 404 error. To fix it, I had to delete the old certificate configuration and reinstall it with the certbot-nginx plugin each time. This would allow http-01 challenge to pass successfully.

After pulling my hair for a while and playing with the --dry-run option, I've finally noticed the following message:

Plugins selected: Authenticator webroot, Installer nginx

This is wrong. It should be:

Plugins selected: Authenticator nginx, Installer nginx

The reason for the failure appears to be the alternate acme-challenge folder location. Webroot authenticator doesn't handle it and it will attempt to verify using regular sub-folder in webroot.

The solution

Open /etc/cron.d/certbot file and add --nginx option to the renew command, the python-certbot-nginx should be adding it automatically but it doesn't.

Přátelské upozornění od Facebook

dub 05 2019

S Facebookem obecně nerad sdílím jakékoliv informace v míře větší, než je minimum nutné pro fungování. Jednou z takových neposkytnutých informací bylo do nedávna moje telefonní číslo. Nicméně už objevili metodu, jak mě donutit prozradit jim ho:

Kamarád Facebook

A k čemu vlastně potřebuje Facebook tak přesně poznat, že jsem to skutečně já (a kde se nacházím)? To je vedlejší, je to prostě v zájmu veřejného blaha. Teď si určitě můžou být jisti, že mi nějaký hacker nezcizil účet :)

Cassandra Reaper

bře 18 2019

Do WebMedea jsme letos zapojili nové datacentrum. Udržovat Cassandru synchronizovanou pro nás ale s jeho přidáním znamená lineární nárůst práce. Kontroly logů, zda některá tabulka či schéma neprošly opravou, už nejsou časově únosné. Opravy databáze jsme se proto rozhodli automatizovat. Při rešerši možných řešení Pepa objevil aplikaci Cassandra Reaper, jejíž popis nádherně plní všechny naše potřeby:

  • periodické spouštění oprav
  • segmentované běhy oprav
  • historie a výsledek jednotlivých běhů.

Po menších obtížích s konfigurací webového UI jsme ji úspěšně nasadili k testování v následujících týdnech.