Nedávno jsem se dostal k webu, který se s přicmrndnutím Ruby generuje z Markdownu do statického HTML. Ta až surová jednoduchost mě nahlodala natolik, že jsem místní PHP parádu zkusmo převedl na Jekyll. A už u něho zůstal.
Přecijen… po více jak dekádě, kdy hrál WordPress prim, se člověku trochu přejí. Systém je to fajn, ne že ne. Obzvlášť pro klientský web na ověřeném základu.
Těžko si však vybrat mezi aktualizací automatickou, s nečekanými karamboly, nebo ruční, ale žeroucí čas. A to je jen jedno z mála „Systém je to fajn, ale“. Takže to sice dělám, ale kdybych nemusel…
A tady na ALES.NET nemusím, to je čistě moje území. 👑 Protože Markdown a Git nejsou překážkou, je Jekyll mnohem příjemnější volbou, i když už je to trochu old school. Ale ten je cool.
Předpoklady
Konkrétních návodů pro převod je net plný, to není třeba dokumentovat. Před utopením několika hodin jsem si ale sepsal pár abstraktnějších myšlenek a třeba se mi ještě budou hodit před případnými dalšími převody.
Když pominu vstupní časovou investici, protože „se to samo neudělá“, vychází mi to. On to čas ušetřený na budoucí správě stejně brzy srovná. Nebo jsem jen moc puntičkářský a měl bych WordPress nechat žít svůj život? Však je plnoletý (* 2003)!
Výhody
- Snadná údržba: Je prostě na palici mít něco v Gitu, něco v databázi a něco jen volně na FTP, protože si do souboru potřebuje WP sahat. Výsledkem Jekyllího buildu je statický web, takže i kdyby server shořel (ehm ehm, OVH?), stačí ho rychle nahrát na sebehloupější hosting a frčíme dál.
- Vestavěné zálohování: Všechno je pevně uchycené v repu. V podstatě odpadá nutnost promýšlet, jak zálohovat databázi a soubory, které nelze verzovat. Teď stačí Gitu přihodit kromě Blueboardu druhý remote na Githubu a „záloha“ vznikne automaticky s každým pushnutím.
- Známé prostředí: Už tak trávím většinu dne ve VSCode a mám ho nejvíc v ruce. Časem by navrch k tomu dávalo smysl
.mdzdrojáky článků i digizahradu zamíchat do jedné velké osobní wiki. - Předvídatelný zdroják: Markdown je transparentnější v tom, co z něj vypadne. U WP nikdy nevím, jestli není text obalen nějakým ostylovaným
<span>em navíc nebo nejeblo pluginu a třeba nejdřív plošně neupravil<title>, aby to po dvou měsících zase vrátil. A mezitím samozřejmě Google půlku stihl indexnout. Prkotina, ale radši bych s klienty řešil smysluplnější věci. - Jednodušší šablony: U WP je zvykem šablony a logiku hodně dělit napříč soubory. Jekyll je mnohem plošší by-design a v případě potřeby to zvládne taky zesložitit.
- Udržitelná optimalizace: Dostat web do vypiplaného stavu je díky statice mnohem snazší. A zároveň udržitelnější, protože:
- Na web se nebudou náhodně propisovat nevyžádaná WordPressí CSSka a skripty. Nebylo mi příjemné se prezentovat něčím, co si samo aktualizacemi mění vzhled. Jetpack byl častým viníkem, ale bohužel jde o dost zásadní plugin ekosystému.
- Debilní chytristika nad obrázky už nebude dělat problémy. Chci nad nimi ruční kontrolu a neřešit, že si WP zase usmyslel dogenerovat další velikost, která je rozměrově menší, ale datově větší. Navíc díky tomu zbytečně nebobtnají zálohy.
Neutrální
- Naplánované příspěvky: Dá se jich dosáhnout, ale ne v mém konkrétním setupu. Zároveň pro to ovšem nemám potřebu, žádný složitý publikační plán nedržím. Prostě to napíšu, nechám uzrát a zveřejnim, když to cejtim.
- Editace z mobilu: Všechny úpravy budou muset být z počítače. WordPress má pro iOS appku, nicméně s tou mám tolik negativních zkušeností (neustálá reautorizace účtů, zásek při publikaci příspěvku, přepsání dřívějších změn,…), že to v klidu oželím.
- Formuláře: Reálně jediná věc, která mě mrzí. Většina lidí si ale stejně raději našla mail a psala přímo, tak jsem tomu přizpůsobil CTA a kdyžtak to dořeším časem.
Nevýhody
- Nový devstack: I když snazší na údržbu, pořád je oproti všemu klientskému značně odlišný.
- Ztráta kontaktu: Když musím WP držet při životě pro sebe, nutí mě to víc sledovat best practices a ty pak rozhazovat i ke klientům.
Potenciál k rozvoji
- Zvýraznění syntaxe: Úryvky kódu tu mám často, ale nikdy jsem se nedostal k jejich obarvení. Teď to vypadá snadno.
- Přesun buildu na Github: Vyřešila by se hlavně nemožnost publikace z mobilu a přesunula závislost (za přidání další) z lokálního stroje do cloudu. Momentálně po tom neprahnu a ani historie nenasvědčuje potřebě to řešit.
- Hostování Amazonem: Mohl bych to taky celé hodit na AWS S3, se kterou jsem se paradoxně učil právě kvůli zálohování WordPressu. Spolu s tím bych se rád konečně koukl na CloudFlare. Zároveň se mi ale dost líbí současná strohost „co pushnu, to je online“, tak se možná vofukům s CDN radši vyhnu.