Lekce 6 - Nový editor Gutenberg vs starý TinyMCE

V minulé lekci, Konflikty pluginů, šablon, WordPressu a jak je řešit, jsme si řekli něco málo ke konfliktům mezi pluginy a šablonami.

Dnes se blíže podíváme na slíbený editor Gutenberg a uděláme si takové menší srovnání.

Nový věk vyžaduje lepší technologie a pokrok je prakticky nevyhnutelný. Už velmi dlouho měl v sobě WordPress integrovaný TinyMCE editor. Ten v podstatě vypadá a funguje podobně jako Microsoft Word nebo Google Docs. Umí toho samozřejmě mnohem méně, ale je velmi obratný a použitelný i pro méně zdatné uživatele. Což byla a stále je jeho velká výhoda.

U Gutenbergu už se bavíme o robustním mini systému, který se skládá z bloků. Každý blok má svoje možnosti, atributy a už v administraci pak můžete vidět, jak bude výsledná grafika vypadat - máte totiž k dispozici tzv. preview mode (náhled).

TinyMCE

Výše vidíte, jak TinyMCE editor vypadal. Jedno velké textové pole, do nějž se narve vše, co je potřeba. A to je ten problém - absolutně vše by mělo být v něm.

Na druhou stranu - jako snadný textový editor slouží dobře a oproti Gutenbergu má mnoho výhod. Stačí si je vyzkoušet v praxi a uvidíte, že psaní je přirozenější a rychlejší. Do určité míry i přehlednější.

Nicméně budoucnost webů na WordPress (a v podstatě webů obecně) závisí na možnosti uživatelů si web přizpůsobit a ve chvíli, kdy textové pole je plné shortcodů, ztrácíte přehled.

Níže si všimněme právě shortcodu [google-map-v3] a nějakého [wpcol_1third] uvnitř nějž je nadpis a text.

Výstupem bude mapa a sloupec s nadpisem a textem. Což ale uživatel prakticky nemusí pochopit, když na to jen tak kouká. A teď si představte weby, kde prakticky vše je pouze v hranatých závorkách, někde se upíšete a chybu pak hledáte klidně i hodiny.

Problém je tedy jasný a jeho řešení se tvoří už pěkných pár let. Externí vývojáři totiž dodávají vizuální editory, které tento textový blok zakryjí a do něj nahrávají obrovské množství dat.

Své “přehledné” bloky pak ukazují místo toho, díky čemuž si můžete složit poměrně dobrý web. Ukázkou může být Elementor níže, viz:

Vlevo jsou bloky a do čárkovaného bloku je pak přenášíte, upravujete a dodáváte obsah. Což dává uživateli nové možnosti a především přehled/kontrolu. O něco podobného se právě snaží i Gutenberg.

Gutenberg

Nyní se podíváme, jak se web skládá s využitím Gutenbergu. Příklad uvedu na svém referenčním projektu.

Dostal jsem do rukou grafiku, kterou jsem si nakódoval. Jednotlivé bloky rozmístil do příslušných souborů - nadpis, text, carousel (slider), sloupce (možnost mít sloupce a v nich nadpis + text).

Náhled bloku a jeho nastavení pak následně vypadá takto:

A nyní vidíme ten znatelný rozdíl. Máme přehled o tom, jaký nadpis a jakého typu na stránce bude. Můžeme dodat menší text nad nadpisem, tlačítka a obrázky (blok byl vytvořen pomocí ACF pluginu, budeme rozebírat více v pozdějším článku).

Pokud si pak přepneme na náhled, vidíme, jak blok bude přibližně vypadat na stránce = rozmístění obsahu, velikost tlačítka, grafika tlačítka, textace, nadpisy atd.

Pomocí těchto bloků si můžeme následně skládat jakoukoliv stránku, protože bloky jsou dostupné kdekoliv po WordPressu (kde vývojář určí).

A to je obrovská výhoda. Vy totiž už jen nepíšete text na web, ale máte prakticky nekonečné možnosti, jak skládat web a jeho obsah.

Navíc nemusíte chodit mimo administraci, abyste měli přehled o tom, co na stránce bude. Samozřejmě náhled celé stránky je lepší, protože se ujistíte, co jak vypadá a jak to funguje. Nicméně si představte koukat na náhled stránky 20x kvůli nějakým opravám. Tento blokový systém tak v těchto případech značně urychluje práci.

Gutenberg má samozřejmě i nevýhody a není jich málo. Je to poměrně nové rozhraní, u něhož se tedy s nedokonalostí částečně počítá. Ale díky poměrně slušnému vývoji to za pár let bude velmi dobrý a propracovaný systém.

Můj pohled vývojáře

Pro tvorbu webových stránek a eshopu se mi blokový systém zamlouvá a u svých klientů jej rapidně rozšiřuji. Díky pluginu ACF jsem schopen tvořit robustní bloky a mít v šabloně pořádek a vývoj se tak urychluje.

Blokům by pak technicky vzato šli přiřazovat funkce, které umí novodobé prohlížeče. Mluvím konkrétně o načítání CSS a JS jen, když jsou potřeba v samotném HTML dokumentu (body).

Představte si mít na webu 40 unikátních bloků. Každý umí něco jiného. Teoreticky byste pak mohli mít 2 soubory - CSS a JS. Ty se budou načítat všude, ale třeba 80 % vůbec nemusí být použito.

Tím, že bychom měli soubory například header.css, footer.css, title.css, slider.css zařídíme to, že když uživatel tuto část uvidí, prohlížeč mu dané CSS načte. Pokud se ale uživatel nedostane ani blízko k patičce webu, proč načítat?

Co když máme robustní slider, kde jsou různé animace. Proč jeho soubory načítat i když na stránce není?

To vše jsou otázky, které si vývojář musí položit a následně na ně umět i odpovědět. Je totiž rozdíl jen tak vyplivnout web a nebo dodat klientovi produkt, jenž mu vydrží roky bez nutnosti větších zásahů.

A to je pro dnešek vše.

Kdo stojí za článkem?

Ahoj, jmenuji se Pavel Mareš a od roku 2012 pracuji v digitálním prostředí. Prošel jsem si kódováním, vývojem webů, grafikou a v tuto chvíli pomáhám svým klientům tvořit kvalitní stránky na míru.

Nabízím služby - UX, UI (grafika), kódování (Gulp, SASS, HTML5, CSS3, JS) a nasazení webu na WordPress (vlastní šablony). Můžete se podívat na mé reference.

Rychlý kontakt: +420 776 256 020 / info@mares-pavel.cz

Příště, v lekci Bezpečnost ve WordPressu, se blíže podíváme na téma bezpečnost.