Digging the Digital

Vol Blogdrift!

Jekyll

De snelheid van mijn Jekyll site is met 80% verbeterd

door Leave a Comment

Dat zul je altijd zien. Heb ik eindelijk de knoop doorgehakt om deze site om te zetten van Jekyll naar WordPress, kom ik een nieuwe blogpost tegen die een van mijn bezwaren bij Jekyll wegneemt.

Snelheid

De hoeveelheid posts is toegenomen sinds ik een archief van oude blogs heb omgezet naar dit domein. Met Jekyll maak ik zogenaamde statische pagina’s. Dat betekent dat elke blogpost, elke pagina op deze site, een op zichzelf staande pagina is. Er komt niet uit een database, er wordt niets opgebouwd vanuit een server, zoals bijvoorbeeld bij WordPress. Dit heeft snelheidsvoordelen aan de kant van de lezer. Het Spartaanse uiterlijk van de site, weinig franjes, weinig toestanden, zorgt er voor dat de site enorm snel is volgens de Google PageSpeed Insights.

Om dit mogelijk te maken, wordt de site op de server in zijn totaliteit opgebouwd en als losse HTML bestanden gepubliceerd. Zo krijgt elke blogpost zijn eigen folder met een index pagina. Die index-pagina is wat je uiteindelijk als lezer ziet. Het blogplatform Jekyll maakt dit mogelijk. Een groot voordeel is dat je deze site op elke willekeurige webserver kunt serveren. Ik hoef er in theorie niets extra’s voor te installeren. It just works….

Er zijn echter wel wat nadelen. Met de groei van de site neemt de bouwtijd na elke wijziging behoorlijk toe. Jekyll is namelijk zo geprogrammeerd dat bij een wijziging in een blogpost, de complete site opnieuw wordt opgebouwd. Omdat elke pagina bestaat uit de inhoud en een template waar die inhoud in wordt getoond. Content en vormgeving.

Jekyll heeft wel wat slimmigheden om die bouwtijd te verkorten, zoals de zogenaamde incremental build. Hiermee wordt de bouwtijd al aanzienlijk verkort. Maar in mijn geval bleef het een frustratie, omdat de bouwtijd soms echt in de minuten liep. Dat vertraagt voor mij de flow van even wat schrijven en publiceren.

Versnel Jekyll

Ik kwam gisteren een blogpost tegen met een experiment om Jekyll te versnellen. De auteur maakt gebruik van functies die in een nieuwe versie van Jekyll zullen verschijnen, zoals caching en een snellere conversie van de Markdown opmaaktaal naar HTML webtaal. Met een paar kleine stappen wist hij de bouwtijd van zijn site met 61% te versnellen. Dat is indrukwekkend. Ik besloot lokaal het experiment uit te voeren om te zien wat er bij mij zou gebeuren. Dat was minstens zo indrukwekkend mag ik wel zeggen. De bouwtijd van mijn blog is met slechts de 3 eerste stappen al met 83% gereduceerd! Van 38,9 seconden naar 6,6 seconden.

De verbeteringen die de auteur doorvoert zijn nog niet goed te gebruiken op een live productiesite, zeker omdat hij gebruik maakt van een vroege versie van de nieuwe Jekyll. Deze stap alleen al versnelt het bouwproces met 55% en het lost één frustratie van het proces op. Het betekent wel dat ik deze site naar een andere hostingpartij moet brengen vanwege de plugins die er worden gebruikt in de vervolgstappen.

WordPress wint het toch

Maar het lost niet het grootste probleem voor me op, ik wil graag stappen zetten in het gebruik van de bouwstenen van het Indieweb. Ik word hier echter gehinderd in een gebrek aan kennis en inzicht hoe ik dit zelf kan doen. Zeker in een omgeving als Jekyll is dit wel nodig. Bij WordPress zijn er al betere plugins die goed werken als je ze installeert. Daarbij zijn er eveneens stappen in de WordPress community om een statische site te presenteren aan de voorkant in plaats van een volledig dynamische pagina, zoals nu gebeurt.

Maar gebruik je Jekyll en heb je een behoorlijk archief, dan is deze blogpost zeker de moeite waard om te leren hoe je de snelheid nog verder kunt verbeteren.

Verhuisupdate – we gaan naar WordPress

door Leave a Comment

Met wat korte tussenpozen ben ik bezig om deze site naar een volgend niveau te brengen. Wat ooit begon als een hobby-project om Jekyll en Github meer eigen te maken, is uitgegroeid tot een blogarchief van het verleden en heden.

Bouwstenen

Het was oorspronkelijk niet de bedoeling dat deze site een archief zou krijgen en ik had niet verwacht dat ik steeds specifiekere wensen zou krijgen rondom het beheer en de presentatie van de site. Nou ja, dat laatste misschien wel. Als je eenmaal bezig bent wil je altijd meer. Mijn interesse in het Indieweb en de bijbehorende bouwstenen maakte me eveneens nieuwsgierig. Wat zou ik zelf kunnen doen, wat is er al beschikbaar als een klik-en-klaar script?
Dat blijkt in de praktijk nog vies tegen te vallen. Er zijn zeker genoeg scripts en code op Github te vinden die je op weg kunnen helpen in de wereld van het indieweb. Denk aan webmentions en micropub, respectievelijk de mogelijkheid om reacties uit te wisselen met andere sites in plaats van reactieformulieren en de optie om met een groeiende verzameling van apps en extensies op je eigen site te posten.

Het werkt allemaal wel, maar net niet lekker genoeg. Net niet zoals ik het zou willen. Ik moet er zelf nog te veel aan sleutelen en echt diep onder de motorkap kijken wat er allemaal aan de hand is en wat ik moet verbeteren. Ik ben geen programmeur, maar ik ben niet bang om wat te leren. De laatste weken was ik meer tijd kwijt met het fixen van code-problemen dan met het schrijven op mijn blog en het plezier van het delen van toffe dingen hier. Zeker toen ik bezig was met de eerste stappen om mijn blog te verhuizen, kwam ik probleem op probleem tegen. Om een probleem op te lossen, moest ik eerst weer een andere hobbel over die voor een nieuw probleem zorgde. Zo ging het maar door. Ik was meer aan het programmeren dan aan het schrijven.

WordPress en Genesis

Dat was het definitieve teken dat er iets moest veranderen. De wijzer moest weer naar het schrijven en publiceren doorslaan. Ik vind het niet erg om zo nu en dan de mouwen op te stropen en wat code naar mijn eigen hand te zetten. Maar ik wil er vooral ook over kunnen schrijven en het kunnen delen. Na een weekend problemen oplossen had ik daar niet altijd meer zin in.

Wat is dan een goede oplossing? Eigenlijk had ik daar de afgelopen maanden al veel mee gewerkt bij Olisto. Samen met Patrick Loonstra heb ik de website een nieuw jasje gegeven, zowel aan de voorkant als in het WordPress beheer. We maakten gebruik van het Genesis framework met een zogenaamd child theme. De relatie tussen deze drie kan ik het beste uitleggen met een auto-analogie: WordPress is de motor van de auto, Genesis is de carrosserie en het eigen child theme is de lak, accessoires en het uiterlijk van de auto. Genesis geeft extra functionaliteiten boven op WordPress waardoor het aanpassen en eigen maken van een child theme weer eenvoudiger wordt. Genesis maakt van WordPress direct een meer flexibel CMS.

WordPress en Indieweb

Ik ben op dit moment bezig om de ongeveer 1000 blogposts lokaal te importeren in een WordPress blog en deze met Genesis en een child theme weer presentabel te maken. Dit is met een plugin en wat slimme Jekyll/Liquid code redelijk snel te doen.
Maar wat me écht blij maakt is de mogelijkheid om in WordPress diverse Indieweb bouwstenen weer te gebruiken. En vooralsnog werken ze na installatie prima. Ik ga bij Ton nog spieken hoe hij de webmentions met microformats voor elkaar heeft gekregen en ik zal nog wel iets zelf aan moeten passen in het child theme. Maar ik verwacht daar geen onoverkomelijke problemen. Ik begin met een child theme wat voor mij presentabel genoeg is, daarna ga ik dat verder tweaken naar mijn eigen wensen. Dat zit vooral in de presentatielaag. Daar ben ik beter in thuis dan de combinatie presentatie en beheercode. Belangrijke elementen voor een site ontwerp zijn voor mij hoe het mobiel werkt en hoe snel de site wordt getoond.

En Jekyll dan?

Betekent dit het einde van mijn avontuur met Jekyll? Voor dit blog wel. Ik merk dat ik de grenzen heb bereikt in wat ik kan en wil doen op technisch niveau. Jekyll en statische site generatoren zijn prima voor relatief kleine en eenvoudige blogs die weinig eisen hebben. Maar als je verder wilt professionaliseren heb je een goede programmeur naast je nodig, een diepere kennis van zowel Jekyll als Ruby, de onderliggende programmeertaal.
Ik zal Jekyll zeker blijven gebruiken voor kleinere projecten en aanbevelen waar nodig.

Adieu Jekyll, welkom WordPress!

Leesvoer: How does Jekyll work?

door Leave a Comment

De afgelopen maanden heb ik veel in WordPress gewerkt voor de nieuwe site van Olisto. Het bracht me wat aan het twijfelen of ik deze site tóch niet in WordPress moest omzetten. De kracht van het platform en de plugins zijn erg aanlokkelijk. Ik merkte dat ik met Jekyll soms de grenzen raakte, temeer omdat ik niet goed wist hoe de onderliggende engine van Jekyll in Ruby werkt.

De blogpost How Does Jekyll Work maakt me echter weer enthousiast over Jekyll als belangrijkste platform voor mijn moederschip. Dankzij de stapsgewijze uitleg over het mechanisme is me meer duidelijk hóe en waarom Jekyll bepaalde dingen doet en ik snap nu beter wat ik kan doen om bepaalde processen voor mezelf beter te maken.
Gelukkig is het bijna Kerstvakantie, dat geeft me weer de ruimte om wat te hobby-en hier!

Hoe ik mijn eigen templates update

door Leave a Comment

Een kleine irritatie kan soms ineens uitbarsten in de gedachte “Ik ga het nú oplossen”. Dat gebeurde me vanavond terwijl ik de voorpagina van deze site bekeek. De blogsoftware Jekyll die ik gebruik, maakt bij het genereren van de pagina’s verschillende versies van de blogpost aan.

Er is een versie genaamd ‘page.content’ die de volledige inhoud van de blogpost laat zien. En Jekyll maakt een versie ‘page.excerpt’ die, je raadt het al, een samenvatting van de blogpost laat zien. De voorpagina van mijn site laat standaard een korte samenvatting zien van de blogpost. Die samenvatting kan ik zelf schrijven in de header, maar dat gebeurt niet altijd. Dan valt Jekyll terug naar het weergeven van de eerste paragraaf op de voorpagina.

Soms zijn mijn blogposts erg kort. Misschien maar één paragraaf. Maar in de template voor de voorpagina werd wel altijd een “Lees verder ” tekst getoond, zelfs als de blogpost maar één paragraaf lang was. Je merkt, mijn kleine irritaties kunnen uit allerlei hoeken komen. Ik wilde dat oplossen en vanavond is het me gelukt.

Excerpt en content vergelijken

Je zou denken dat er een simpele oplossing is: vergelijk de lengtes van page.excerpt en page.content. Als de een korter is dan de ander, dan weet je dat er een “Lees verder” link moet komen.

Was het maar zo simpel…

Al snel kwam ik er achter dat bij het samenstellen van de voorpagina, de daadwerkelijke content per blogpost nog niet is gerenderd. Omdat ik alles in de Markdown opmaaktaal schrijf, is de lengte van page.content dus vrijwel altijd langer dan page.excerpt, tenzij ik geen Markdown in de post gebruik en die kans is klein.

Hieronder zie je een screenshot van de vorige paragraaf zoals ik hem schrijf. Die twee underscores zijn Markdown en zorgen er voor dat de tekst schuingedrukt wordt in de uiteindelijke webpagina.

Tegelijk zorgen die twee extra karakters er voor dat de lengte van die paragraaf in page.content langer is dan dezelfde paragraaf in page.excerpt. Dat is vervelend, maar
gelukkig heeft de onderliggende taal van Jekyll, Liquid, een mooie oplossing. De filter “Markdownify” zorgt er voor dat ik per post op de voorpagina de hele post kan omzetten in een HTML versie. Ik doe dat met

<span class="p">{%</span><span class="w"> </span><span class="nt">assign</span><span class="w"> </span><span class="nv">fullContent</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">page</span><span class="p">.</span><span class="nv">content</span><span class="w"> </span><span class="p">|</span><span class="w"> </span><span class="nf">markdownify</span><span class="w"> </span><span class="p">%}</span>

De markdown code wordt nu een webpagina. Vervolgens kan ik de lengte van page.content en page.excerpt vergelijken.

<span class="p">{%</span><span class="w"> </span><span class="kr">if</span><span class="w"> </span><span class="nv">page</span><span class="p">.</span><span class="nv">excerpt</span><span class="w"> </span><span class="o">!=</span><span class="w"> </span><span class="nv">fullContent</span><span class="w"> </span><span class="p">%}</span>

Als bovenstaande waar is zijn de twee ongelijk en is het nodig om een link te tonen naar de volledige post. Als ze gelijk zijn, dan is er dus geen verschil in de samenvatting en de volledige post en is het onzinnig om een “Lees verder” link te tonen.

Een kleine irritatie die misschien niemand ooit is opgevallen, maar voor nu wel is opgelost. Je kunt de gewijzigde code trouwens bekijken in de Gitlab repository. Net als de rest van de code voor deze site.

Creating a Faster Jekyll

door Leave a Comment

De ontwikkelaar van open source editor Textmate heeft een plugin ontwikkeld om de blogsoftware Jekyll sneller te maken. Dat is geen overbodige luxe. Als ik lokaal deze statische site generator gebruik om wat te testen en te schrijven, duurt het erg lang om de resultaten te zien. In zijn blogpost beschrijft Odgaard hoe hij dat verbeterd. Het is niet zeker of deze plugin problemen gaat geven met het uitgebreide ecosysteem van andere plugins die gebruik maken van de interne structuur van Jekyll

De titel is gered….

door Leave a Comment

De titel is gered. In moderne CMS systemen zijn dit soort rand-problemen vaak al afgevangen met plugins en code, maar omdat ik zo nodig alles zelf wil maken en aanpassen naar mijn gewenste situatie, moet ik dit soort problemen zelf oplossen.

Wat was er aan de hand? Ik schrijf dit blog voor 99% via textbestanden die ik op mijn laptop opsla en automatisch naar Github stuur. Daar wordt de site samengesteld met alle blogposts die je hier ziet. Dat is vooralsnog een prima methode. Maar er komen steeds meer mogelijkheden om blogposts te maken op mijn onderliggende systeem (Ruby, Jekyll en Github) waarbij met name het protocol Micropub interessant is. Omdat ik hier ondersteuning voor heb ingebouwd, kan ik via andere editors eveneens blogposts maken, of interessante bookmarks opslaan. Ik ben daar zelf mee bezig geweest via Pinboard, maar dat project lag wat stil. Nu heb ik via Quill een fijne oplossing gevonden die soort-van-werkt. Het is nog niet ideaal en ik zou zeker in de gebruikersinterface en mobiele mogelijkheden wat veranderingen doorvoeren. Maar goed, er is iets om weer mee te testen.

Als ik echter een korte notitie maak via Quill om hier te posten, dan kan ik daar geen titel aan meegeven. Voor die uitzondering had ik nog geen oplossing. Het was immers een uitzondering die nog niet eerder was voorgekomen. Omdat ik alles zelf schrijf, zorgde ik er altijd voor dat ik een titel had voor mijn post. Nu werd dat dus anders. Het missen van de titel breekt zowel de navigatie naar de permalink-pagina van de post alsmede de titel in de RSS-feed. Tijd om mijn Wickie de Viking helm op te zetten en een oplossing te bedenken.

Een veelgebruikte oplossing is om de eerste woorden of aantal karakters van de blogpost als titel te gebruiken. Gelukkig heeft Jekyll en de opmaaktaal Liquid hier een prima oplossing voor die snel was te implementeren.

In het template voor de voorpagina heb ik een conditie gemaakt die checkt of het titel-veld leeg is. Als dat zo is, dan laat ik de eerste 4 woorden van de tekst zien. Dit is een eenvoudige oplossing:

{% elsif post.title == '' %}
<h1>{{post.excerpt | strip_html |truncatewords: 4}}</h1>

Dezelfde code kon ik direct gebruiken in de template voor de RSS feed en in de template voor de artikelpagina zelf. Een kleine wijziging, die me wel wat tijd heeft gekost om uit te vogelen en vooral goed te testen. Uiteindelijk ben ik blij met het resultaat en dat is wat telt.