DEV Community: Dennis Hagemeier

Generate Social Media Preview Images

Dennis Hagemeier — Wed, 18 Dec 2019 18:07:32 +0000

This article was originally published on my personal website.

Why Social Media Preview Images?

You wrote a great blog entry. You share it on Twitter, WhatsApp or Facebook. And you want your audience to notice the blog entry and click.

Presentation is the key. First thing that catches the eye is not your well-formulated tweet, but the preview image.

Without optimization, a tweet looks like this example from Gatsby:

Small Twitter preview image

With a matching preview image, the Tweet is much more present:

Big Twitter preview image

A normal person would now open Photoshop, create a template file and save the image for the post. But it would be… boring. So I use NodeJS, Netlify and automate the whole thing 😄

For this example I use the SSG 11ty, but the functionality is not limited to a CMS. You can also generate and process a template file with WordPress.

Generate HTML template

My first approach to creating thumbnails was to generate SVGs. A basic design in SVG, changing variables like title or URL dynamically, converting to PNG or JPG and — fiddlesticks. Because SVGs fail with multiline text. At the latest with longer headings this becomes a real problem.

Instead, an HTML template forms the basis. As already mentioned I use 11ty, for this I combine Nunjucks as template language. With the help of a pagination I then generate an additional thumbnail HTML for each regular HTML page.

I chose 1200x628 pixels as dimensions, so the thumbnail fits perfectly for Facebook, Twitter and WhatsApp. If you create thumbnails for other platforms, you can find the current dimensions at Sprout Social.

---
pagination:
 data: collections.all
 size: 1
 alias: preview
permalink: "/assets/preview-images/{{ preview.data.title | pslug }}-{{ preview.data.language | url }}-preview.html"
eleventyExcludeFromCollections: true
---
\<!doctype html\>
\<html\>

\<head\>
 \<meta charset="utf-8"\>
 \<meta name="viewport" content="width=device-width, initial-scale=1.0"\>
 \<meta http-equiv="X-UA-Compatible" content="ie=edge"\>
 \<meta name="robots" content="noindex, nofollow" /\>
 \<style\>\<!-- CSS --\>\</style\>
\</head\>

\<body\>

 \<div class="preview"\>
 \<svg xmlns="http://www.w3.org/2000/svg" width="80" height="91" viewBox="0 0 441 500" class="logo"\>\<path d="M386.9 311.7c7.7-44 27-82.8 54-113.8C425.2 66 337.2 0 177.2 0H0v500h177.2c80.7 0 145.3-23.2 193.7-69.7 6.9-6.7 13.4-13.7 19.3-21-7.6-30.8-9.2-64-3.3-97.6zm-103.5 53c-27.8 29.3-66.1 43.9-114.9 43.9h-55.8V91.7h55.1c49.7 0 88.4 13.7 116 41C311.3 160 325 197.5 325 245.1c0 50.5-13.9 90.3-41.6 119.6z"\>\</path\>\</svg\>
 \<h1\>{{ preview.data.title }}\</h1\>
 \<h2\>www.d-hagemeier.com\</h2\>
 \</div\>

\</body\>

\</html\>

Example of a generated file

Exclude the crawlers from Google & Co. via “nofollow” so that your HTML preview templates do not appear in search engines.

Generate JSON with the required data

To pass the HTML templates to the image generator later, you next create a list of all HTML templates and their paths. Here is an excerpt from my JSON file:

[
 {
 "filename" : "import-tweets-from-twitter-api-in-11ty-en-preview",
 "path" : "https://www.d-hagemeier.com/assets/preview-images/import-tweets-from-twitter-api-in-11ty-en-preview.html"
 },{
 "filename" : "from-wordpress-to-jamstack-en-preview",
 "path" : "https://www.d-hagemeier.com/assets/preview-images/from-wordpress-to-jamstack-en-preview.html"
 },{
 "filename" : "5-tips-you-can-learn-in-las-vegas-for-your-business-en-preview",
 "path" : "https://www.d-hagemeier.com/assets/preview-images/5-tips-you-can-learn-in-las-vegas-for-your-business-en-preview.html"
 }
]

Create Google Storage

Netlify has a big disadvantage: With every deploy the old data is deleted. There are tricks with undocumented cache directories, but I didn’t want to rely on them.

Netlify would normaly delete and recreate all image data for each deploy. Depending on how many blog articles you write and how many images are generated, this generates a lot of work.

Instead, I decided to store the thumbnails in the Google Storage. Google Storage belongs to the Google Cloud Platform, offers the storage of data in so-called buckets and is free of charge for the first 12 months.

The creation of a suitable bucket is easy after login, I have attached my personal settings in brackets:

“Create a bucket”
Give a name (“previewimages”)
Select storage location (“Multi-region”, “eu”)
Select memory class (“Standard”)
Set up access control (“detailed”)
Advanced settings (all set to default)

Once the settings are done, your new bucket is waiting for you and you could already upload files manually.

To let our script store files in the bucket later, we need the corresponding Google Credentials. Just follow the official Google instructions and create a new service account. You will then receive a JSON file with your access keys. Save these keys well, they will only be generated once per service account!

Save the values CLOUD_PROJECT_ID, BUCKET_NAME, CLIENT_EMAIL and PRIVATE_KEY as .env variables, so they do not appear publicly.

Packages and settings

Time for our actual script, in my case I called this previewimages.js. First you add the required NPM packages…

yarn add axios puppeteer @google-cloud/storage dotenv

…and register them in the script:

const axios = require('axios');
const puppeteer = require('puppeteer');
const { Storage } = require('@google-cloud/storage');
require('dotenv').config()

Next, add your variables.

If the error error:0906D06C:PEM routines:PEM_read_bio:no start line appears in Netlify later, my solution was to encode PRIVATEKEY to base64. In the local development environment I had no problems, it seems to be due to the multi-line format of the key.

const GOOGLE\_CLOUD\_PROJECT\_ID = process.env.GOOGLE\_CLOUD\_PROJECT\_ID;
const BUCKET\_NAME = process.env.GOOGLE\_BUCKET\_NAME;
const CLIENTEMAIL = process.env.GOOGLE\_CLIENT\_EMAIL;

// If you have encoded your private key using base64:
const PRIVATEKEY = Buffer.from(process.env.GOOGLE\_PRIVATE\_KEY, 'base64').toString();
// If not:
const PRIVATEKEY = process.env.GOOGLE\_PRIVATE\_KEY;

const credentials = {
 client\_email : CLIENTEMAIL,
 private\_key : PRIVATEKEY
}

And last but not least you deposit the basic settings:

const settings = {
 source: "https://PATH-TO-YOUR-JSON-FILE.json",
 imgwidth: 1200,
 imgheight: 628
}

Axios data processing

First, you load your JSON file via Axios and pass the data to your processing function.

axios.get(settings.source)
 .then((response) =\> {
 setupGoogleStorage(response.data);
 })
 .catch((err) =\> {
 console.log('Error Axios: ', err)
 });

Google storage function

To prevent existing thumbnails from being recreated, first check which images are already stored in the bucket.

Create a new function setupGoogleStorage and authorize access to your bucket. Then we loop through the HTML template links and check via file.exists() if the image is available.

If the picture exists, only a short message appears in the console. If it has to be created, you pass the path, file and filename to the get function.

async function setupGoogleStorage(response) {

 try {
 const storage = new Storage({
 projectId: GOOGLE\_CLOUD\_PROJECT\_ID,
 credentials: credentials
 });
 const bucket = storage.bucket(BUCKET\_NAME);

 var i;
 for (i = 0; i \< response.length; i++) {

 let filename = response[i].filename;
 let path = response[i].path;
 let file = bucket.file(filename + ".png");
 let exists = await file.exists().then(function(data) { return data[0]; });

 if(exists == true) {
 console.log("Image already exists: " + filename + ".png")
 } else {
 await get(path, file, filename)
 }

 }
 } catch (err) {
 console.log("Error setupGoogleStorage: ", err);
 }

}

Make screenshots

Now you actualy take the screenshots. In the get function we start a new puppeteer page and request the screenshot via the getscreen function.

async function get(path, file, filename) {
 browser = await puppeteer.launch({ headless: true });
 page = await browser.newPage();
 const buffer = await getscreen(path, filename);
 await uploadBuffer(file, buffer, filename)
 console.log("Uploaded: " + filename + ".png")
 await file.makePublic();
 browser.close();
}

async function getscreen(url, filename) {
 try {
 console.log("Getting: " + url);
 await page.setViewport({ width: settings.imgwidth, height: settings.imgheight });
 await page.goto(url, { waitUntil: 'networkidle0' });
 const buffer = await page.screenshot();
 console.log("Got: " + filename + ".png");
 return buffer;
 }
 catch (err) {
 console.log('Error getscreen:', err);
 }
}

With networkidle0 Puppeteer waits until there is no more network activity within 500ms. This delays the creation, but also ensures that all CSS files, fonts and images are loaded correctly.

Puppeteer don’t got variables for pagescreenshot in getscreen and saves the screenshot only as a buffer. Now pass this buffer to the Google Bucket:

async function uploadBuffer(file, buffer, filename) {
 return new Promise((resolve) =\> {
 file.save(buffer, { destination: filename }, () =\> {
 resolve();
 });
 })
}

Finished previewimages.js

const axios = require('axios');
const puppeteer = require('puppeteer');
const { Storage } = require('@google-cloud/storage');
const fs = require('fs');
require('dotenv').config()

const GOOGLE\_CLOUD\_PROJECT\_ID = process.env.GOOGLE\_CLOUD\_PROJECT\_ID;
const BUCKET\_NAME = process.env.GOOGLE\_BUCKET\_NAME;
const CLIENTEMAIL = process.env.GOOGLE\_CLIENT\_EMAIL;
const PRIVATEKEY = Buffer.from(process.env.GOOGLE\_PRIVATE\_KEY, 'base64').toString();
const credentials = {
 client\_email : CLIENTEMAIL,
 private\_key : PRIVATEKEY
}

const settings = {
 source: "https://PATH-TO-YOUR-JSON-FILE.json",
 imgwidth: 1200,
 imgheight: 628
}

async function setupGoogleStorage(response) {

 try {
 const storage = new Storage({
 projectId: GOOGLE\_CLOUD\_PROJECT\_ID,
 credentials: credentials
 });
 const bucket = storage.bucket(BUCKET\_NAME);

 var i;
 for (i = 0; i \< response.length; i++) {

 let filename = response[i].filename;
 let path = response[i].path;
 let file = bucket.file(filename + ".png");
 let exists = await file.exists().then(function(data) { return data[0]; });

 if(exists == true) {
 console.log("Image already exists: " + filename + ".png")
 } else {
 await get(path, file, filename)
 }

 }
 } catch (err) {
 console.log("Error setupGoogleStorage: ", err);
 }

}

async function get(path, file, filename) {
 browser = await puppeteer.launch({ headless: true });
 page = await browser.newPage();
 const buffer = await getscreen(path, filename);
 await uploadBuffer(file, buffer, filename)
 console.log("Uploaded: " + filename + ".png")
 await file.makePublic();
 browser.close();
}

async function getscreen(url, filename) {
 try {
 console.log("Getting: " + url);
 await page.setViewport({ width: settings.imgwidth, height: settings.imgheight });
 await page.goto(url, { waitUntil: 'networkidle0' });
 const buffer = await page.screenshot();
 console.log("Got: " + filename + ".png");
 return buffer;
 }
 catch (err) {
 console.log('Error getscreen:', err);
 }
}

async function uploadBuffer(file, buffer, filename) {
 return new Promise((resolve) =\> {
 file.save(buffer, { destination: filename }, () =\> {
 resolve();
 });
 })
}

axios.get(settings.source)
 .then((response) =\> {
 setupGoogleStorage(response.data);
 })
 .catch((err) =\> {
 console.log('Error Axios: ', err)
 });

Embedding as metatag + verification on Twitter

You need the appropriate metatags to display social media preview images. There are the general Open-Graph-Tags and the Twitter-Tags, both belong to <head> of your website:

\<meta property="og:image" content="https://URL-TO-YOUR-PREVIEW-IMAGE.png" /\>
\<meta property="og:image:height" content="1200" /\>
\<meta property="og:image:width" content="628" /\>
\<meta property="og:image:alt" content="ALT TEXT FOR YOUR PREVIEW IMAGE" /\>

\<meta name="twitter:image" content="https://URL-TO-YOUR-PREVIEW-IMAGE.png" /\>
\<meta property="twitter:image:alt" content="ALT TEXT FOR YOUR PREVIEW IMAGE" /\>

The URL for your image is https://storage.cloud.google.com/YOUR_BUCKETNAME/IMAGENAME.png.

In order for your large image to appear on Twitter, you also need to add an additional specification…

\<meta name="twitter:card" content="summary\_large\_image" /\>

…and test the result in the Validator:

Twitter Card validator

Deploy with new article

In order for each new article to receive a preview image directly, all you have to do is specify when the deploy should start. My own workflow for that:

Website sends a webhook (“Outgoing webhook” in Netlify, under “Deploy notifications”) when a new deploy is launched
“Build hook” of the preview page in Netlify triggers new deploy

If you don’t use Netlify, you can trigger the webhook differently. For example, if you’d like to trigger a deploy on every new article in WordPress, then add one of the automatically generated RSS feeds to ifttt.com with the action “Webhook” and the Webhook target of your preview page.

That’s it, happy previewing! 😄

Cookie-free Google Analytics

Dennis Hagemeier — Tue, 19 Nov 2019 10:37:09 +0000

Since the start of the GDPR I am looking for a cookie-free Google Analytics alternative. I am interested in which pages of my blog are accessed, where the visitors come from and, since the relaunch of my blog, what language they speak. I would also like to be able to view the data in aggregated form, for example as a simple dashboard. And since my blog is only my private pleasure, I don’t want to pay a lot of money every month for the analysis data. All this is easy to do with Google Analytics — if it weren’t for the GDPR.

The problem

If I want to use Google Analytics in compliance with data protection regulations, I need the consent of the visitors. So I slap a banner in the face of a new user, “agree” or “disagree” as options. Only to then give his data to Google and make him traceable on numerous websites.

Another disadvantage: More and more people are using extensions like Ghostery to block Google Analytics directly when they visit a page. At the latest with the further development of the browsers (like the Intelligent Tracking Prevention in WebKit) the data becomes less and less reliable.

There are some alternatives to Google Analytics: Alternatives such as Simple Analytics, plugins such as Statify or switching to server log analysis tools, e.g. with Netlify Analytics. Most of them, however, cost money and limit me to the data collected with the corresponding tool. I’m a big fan of the Google Data Studio, so that I can also evaluate data from the Search Console and other sources at the same time.

I’ve even done experiments with Firestore. With my own tracking pixel I have stored the user data there — but then I have to build EVERYTHING by myself. From the simple bot filter to the sorting of sources into channels to the interface with the Data Studio.

So I want Google Analytics — only without cookies and GDPR-compliant.

The solution: Cookie-free Google Analytics

With Google’s standard tracking code, cookie-free tracking is not possible. The script automatically sets multiple cookies for user ID, timestamp or jump tracking.

So I use the second variant to import data to Google Analytics: The Measurement Protocol. Behind it nothing else hides than an interface for the transmission of raw data as HTTP request. If you want to play with the Measurement Protocol, you can go with the Hit Builder.

The solution of the cookie-free Google Analytics script therefore consists in a POST request in which we pack a basic set of user data and pass it on to the Measurement Protocol. I decided to use this data:

User ID (Google requirement for a valid POST request)
User agent (for filtering bot traffic)
Page title
URL
Referrer
Set language

This way of tracking also has some disadvantages:

Tracking is limited to page views.

To save the complete browse history of a user, I would have to assign several page views to one user. Also works with the Measurement Protocol — but I would have to store a user ID as a cookie or in LocalStorage to keep the variable constant over several page views. However, this contradicts my basic idea of completely doing without cookies (and also without LocalStorage).

Instead, each page view generates a new user ID and starts a new session with every page change. This means: No page flow, no number of users (this is displayed, but equal to the page views), no entries or jumps. Every pageview is a new entry and every page change means a jump.

No target group analysis

I’m just transmitting a basic framework of information. Since I don’t give Google enough information to chain several pageviews together and therefore no cross-page tracking is possible, I don’t have any information about the target group. Means: No demographic data, no location, no interests and no network information.

However, I transfer the browser language used and the user agent also provides data on the device category and the browser.

The referrer is transmitted correctly only for the first hit.

Since every pageview means a new session, the referrer is only set correctly for the first hit of a user. For all further calls the website itself is the referrer, so for every further pageview the source is set as “direct”.

An example: If a user finds my blog via Google and looks at the three pages “Articles”, “Home” and “About”, the sources would be:

Articles: google/organic
Home: direct
About: direct

More detailed tracking is only possible in a very cumbersome way

Although events can also be transmitted via the Measurement Protocol, this option would be very cumbersome. If you depend on detailed tracking, you are wrong with this solution and should rather use the Google Tag Manager with customized triggers and events.

Client side script

If I would send the data directly to Google via POST-Request, Google would get a lot of information in the body of the request. Also, many privacy browser extensions would block this request.

So I split the POST request and use a client side script and a server side script (the second as a proxy script).

Variables used

First, I fill my client side file with the variables that I want to transfer later via POST request:

User ID

Google uses for the User-ID (later cid) a Universally Unique Identifier. This can be generated with the following function and saved as a constant:

function uuidv4() { return ([1e7]+-1e3+-4e3+-8e3+-1e11).replace(/[018]/g, \*c\* =\> (c ^ crypto.getRandomValues(new Uint8Array(1))[0] & 15 \>\> c / 4).toString(16)); }
const uuid = uuidv4();

Useragent

const useragent = navigator.userAgent;

Seitentitel

const title = document.title;

URL

A regular URL consists of three parts: The domain (“https://www.d-hagemeier.com”), the path (“/en/articles/”) and the parameters (“?utm_source=facebook&utm_medium=social”). I deliberately transmit them separately from each other so that I can access them individually later.

// Domain
const origin = window.location.origin;
// Path
const pathname = window.location.pathname;
// Parameter
const search = window.location.search;

Referrer

const referrer = document.referrer;

Set language

const language = navigator.language || navigator.userLanguage;

For simplicity’s sake, I then sum the data into a variable:

const sitedata = {
 uuid: uuid,
 useragent: useragent,
 title: title,
 origin: origin,
 pathname: pathname,
 search: search,
 referrer: referrer,
 language: language
}

Post request

I use the fetch-API for the transmission as POST request. My endpoint for this is /.netlify/functions/send, because I use an AWS lambda function over Netlify for my server-side script. But this is not a must; for example a PHP endpoint would be possible, which passes the data to the measurement protocol.

function senddata(data) {
 return fetch('/.netlify/functions/send', {
 body: JSON.stringify(data),
 method: 'POST'
 })
}

senddata(sitedata).catch((error) =\> {
 console.log('Error: ', error)
})

Server side script

As already described, I use a Netlify function on the server side.

I start with the query whether the call is a POST request — and forbid all other calls.

if (event.httpMethod !== "POST") {
 return { statusCode: 405, body: "Method Not Allowed" };
}

Next I parse the transmitted files and save them in the constant data. Then I construct my payload and the endpoint.

const url = data.origin + data.pathname + data.search;
const endpoint = "https://www.google-analytics.com/collect";
const payload = encodeURI(`v=1&t=pageview&tid=UA-85526167-1&cid=${data.uuid}&ua=${data.useragent}&aip=1&ds=web&dl=${url}&dt=${data.title}&ul=${data.language}&dr=${data.referrer}`).replace(/\//g, '%2F');

Now the actual POST request to Google follows. I output the status as console.log or console.error, both are displayed in the Netlify dashboard under the functions.

try {
 const response = await fetch(`${endpoint}?${payload}`, {
 method: 'POST',
 cache: 'no-cache'
 })
 if (response.ok) {
 console.log(`Status ${response.status}: ${response.statusText}`)
 }
} catch (err) {
 console.error("Error: " + err)
}

Attention : To use the fetch-API in NodeJS, I need the corresponding module!

The complete variants of the Client side and Server side scripts can be found in my Github-Repository.

Bonus: Data Studio Template

With these two files, the data is already exported to Google Analytics and can be filtered and evaluated there as usual. But I’m a fan of Google Data Studio, so I created a dashboard with the transferred data and the search queries from the Search Console.

You can view and copy the Data Studio here. Just swap the data sources and you have a good starting point for your own Data Studio.

First published on: https://www.d-hagemeier.com/en/articles/cookie-free-google-analytics/.

Import Tweets from Twitter API in 11ty

Dennis Hagemeier — Wed, 16 Oct 2019 16:30:00 +0000

Learn to retrieve your own tweets via API and dynamically display them in the Static Site Generator Eleventy.

Intro

Twitter is a wonderful platform to discover exciting articles, exchange ideas with people and pass on knowledge. So why not keep your website fresh with new tweets on the home page?

Possibility 1:

Integrate the Twitter timeline via widget. Disadvantages: Little or no influence to design, an additional third-party script and the associated loss of page speed.

Possibility 2:

Save the Twitter timeline directly in HTML via API in the build process. How this works with the Static Site Generator Eleventy is shown in this article.

Create API access data

In order to access the Twitter API, you first need your personal access data. Call the Twitter-Developer-Portal and select Create an app. Most of the fields shown here don't even need to be filled in because the user of your website will never come into direct contact with the API.

In my case the whole thing looks like this:

Twitter Developer App Overview

After clicking on the tab Keys and tokens you get your API-access data - you need all four, so save them!

Twitter Developer API Keys

I use dotenv to prevent my API credentials from appearing publicly on Github. So I add four entries to my .env file:

TWITTER\_CONSUMER\_KEY="YourAPIkey" TWITTER\_CONSUMER\_SECRET="YourAPIsecretkey" TWITTER\_ACCESS\_TOKEN\_KEY="YourAccesstoken" TWITTER\_ACCESS\_TOKEN\_SECRET="YourAccesstokensecret"

Create data object in Eleventy

External data can be conveniently used in Eleventy. All you need to do is create a JavaScript file in the _data folder, which returns the desired data via return (see Documentation for details). First create a file named tweets.js in the data folder.

Then install the Twitter NodeJS package:

npm install twitter --save

My tweets.js file starts with the required libraries:

Next, the Twitter NodeJS package needs our API credentials:

Now we can query different data from the API. We are interested in our own tweets, so we need our user ID (you can also use the account name, but the ID remains the same even if you change the name).

We also add how many tweets we want to retrieve, I’ve chosen the 20 most recent tweets.

If you like, you can add several other options here, a complete overview can be found in the documentation on Twitter.

The only thing missing is the retrieval of the data and its export:

Altogether my tweets.js looks like this:

11ty filter

Eleventy offers the possibility to define your own filters. I currently use two basic filters for the display of tweets.

Filter replies

By default, the API sends each tweet to the timeline, including the tweets you posted in response to other tweets. There are two ways to filter the responses:

1. Filter by API query

You add the value exclude_replies = true to your params variable. However, I decided not to do this because we cannot access the answers on any other page - they are not queried.

2. Filter by 11ty-Filter

With a global filter you can dynamically decide in the template where you want to include answers. The trick: Each reply starts with an @. The corresponding filter belongs in your .eleventy.js file:

Filter URL from tweet text

By default, the API appends the source URL of the tweet to each tweet text. Each of these URLs starts with Twitter’s short URL service — and I take advantage of that in this filter by filtering every URL that starts with https://t.co.

If you want to display the date of your tweets, you won’t be able to avoid formatting. The Twitter API displays the date in the format Thu Apr 06 15:28:43 +0000 2017.

For formatting I use Moment.js. Moment.js allows you not only to change the format of the date, but also to influence the localization. Since I use the filter not only for tweets, but also for other data, I built it as flexible as possible, instead of setting it to the Twitter format.

The filter can now be used as follows:

{{ item.created\_at | date("ddd MMM D HH:mm:ss ZZ YYYY", "Do MMMM YYYY", language) }}

Prepare template

Displaying tweets

After we have formed a data object from the Twitter API into Eleventy, any value can be used dynamically in the template. I use Nunjucks for this.

First we set the tweetExcludeAnswers filter.

{% set twitter = tweets | tweetExcludeAnswers %}

Afterwards we can loop through the data. In this case I also limit the display to the five most recent tweets by using .slice(0, 5).

{%- for item in twitter.slice(0, 5) -%} \<!-- Show tweets --\> {%- endfor -%}

Query for tweet type (retweet, quote, own tweet)

Each tweet can be assigned to one of three categories: A retweet, a quoted tweet (i.e. a retweet with an attached comment) or an original tweet. Each tweet item therefore has two attributes, retweeted and is_quote_status, which is provided with true or false. If both values are false, the tweet is an original tweet.

With this knowledge we can build the templates accordingly:

{% if item.retweeted %}{% endif %}

{% if item.is\_quote\_status %}{% endif %}

{% if not item.is\_quote\_status and not item.retweeted %}{% endif %}

You can find my complete code with all adjustments in my Github repository:

Tweet.js file for creating the data object
Eleventy.js file with the required filters
Nunjucks-Template for displaying the tweets

Bonus: Automatic deploy on new tweet

Since the tweets are only imported in the build process and embedded in the homepage HTML, the page has to be updated with a new tweet. If you use Netlify for hosting, you can save a lot of manual work with automatic deploys.

The trick: Webhooks and the link to IFTTT.

Create Build-Hook

First navigate to Settings > Build & deploy > Continuous Deployment > Build hooks in your Netlify account. After clicking on "Add build hook" only the name is missing (in my case "New tweet") and the selection of the branch. Netlify then shows you a URL in the format https://api.netlify.com/build\_hooks/BUILDID - save this one!

Trigger rebuild in IFTTT

In IFTTT you now create a new applet. Our trigger is the Twitter account: The task should always be executed as soon as a new tweet appears in your account.

The action is then “Make a web request”. Enter the build hook URL just received from Netlify under “URL”, “Method” is “POST” and for “Content Type” we use “application/x-www-form-urlencoded”.

This is what the finished task looks like for me:

IFTTT settings for automatic deployment in Netlify

That’s it, have fun with your tweets!

Originally published at https://www.d-hagemeier.com on October 16, 2019.

From WordPress to JAMStack

Dennis Hagemeier — Tue, 20 Aug 2019 17:30:00 +0000

Away from WordPress, towards JAMStack with Eleventy and Netlify. Multilingualism, a domain move… August makes everything new.

New design, new technology, faster loading performance — the new version of my private website is finally live 🎉

A good occasion to show what has been going on in the backend, what I intend to do with this site in the future and to give you suggestions for your own blog.

Multilingualism & domain transfer

The first change: Instead of d-hagemeier.de my blog is now accessible via d-hagemeier.com. The main reason for this step is the future bilingualism of all content. Each article will be published in German and English in the future (how I have achieved this technically, will soon be published in a separate article).

At the same time the content was old. 2016-old. Basically, an archive of my articles published on other websites. What was missing was the discipline to write more articles.

Marketing, web development and design will be the future focus, my personal goal is to write at least one article per month. Maybe, there will be one or two articles beyond these topics — who knows? 😉

It’s a match: Eleventy & Netlify

Technically, the biggest step is the change to Eleventy and Netlify. For years I have built up all my professional and private projects on WordPress, my first choice for a CMS. But with the release of version 5.0, WordPress seemed bloated to me. It was time for something new.

I had heard about the JAMStack ( J avaScript, A PIs and M arkup), but it was quite difficult to get started. The basic idea is a new approach for high-performance, easy-to-manage websites. Instead of using PHP and databases like WordPress, the JAMStack generates HTML files that can be delivered “serverless”.

Sounds static? Apart from the name of the generators (Static Site Generators, or SSG for short), it isn’t static at all. To make programming as flexible as possible, SSGs rely primarily on template languages such as Liquid or Nunjucks. Variables, filters or loops are resolved and converted during build process.

Other tasks can be solved via JavaScript and the connection of APIs. This makes it possible to solve even complex ordering processes such as those of an online shop without relying on server-based programming languages.

Great theories, yet the introduction was difficult for me. I was used to PHP, had a hard time fiddling with the given structure of the leading SSGs, like Jekyll.

This changed when I discovered Zach Leathermans Eleventy. Based on NodeJS, you get maximum flexibility in the structure, almost every template language imaginable, a detailed documentation with numerous tutorials and starter projects… the start couldn’t have been better.

How does Eleventy work with my website?

All my articles are written as Markdown files. Additional information such as title, publication date or SEO information ends up in the header of the article. Simplified, an article looks like this:

Eleventy does not specify in which directory these Markdown files are located. At the same time I use Nunjucks to create the templates. If you open a Nunjucks file for the first time, the code looks like HTML. Finally there is nothing magical about it — Nunjucks is just an extension for functions and variables.

The basic layout for each content type is very simple:

With include I load additional components, in this case the head and footer area. The head contains nothing else than the doctype, meta tags or the link of the stylesheet (similar to header.php in WordPress). The cool thing about Nunjucks: By using variables from the head of the markdown file, all HTML generated afterwards can be adapted dynamically. For example, the tag looks like this:

For this example, this would result in nothing more than:

By the way, I took only one article from the old version of my website and copied it manually. If I already had a larger amount of articles in WordPress, I would have used the Wordpress Export to Markdown to generate markdown files from the WP export file.

Another change of this new website version: All source code is publicly available on Github. So if you want to take a closer look at the structure, feel free to check out the Repository!

Although being called “serverless”, you still need a server. So I needed a hoster.

So far, my private blog was accessible on a webspace of uberspace. For a “classic” website, I would probably never have changed — the support is out-of-this-world, the performance better than most supercars and the whole business model is based on “Pay what you want”.

But then, along came Netlify. And so my choice was made.

Anyone who asks “why” should try Netlify. Within three minutes my website was online — Netlify only needs to specify a repository, then downloads all required packages, executes the defined build process and provides the live directory directly under a .netlify.com subdomain.

Additional gimmicks simplify a lot, like optimizing CSS or image files, optimizing URLs or creating dynamic redirects by language.

The page will be rebuilt as soon as something changes in the Github directory. Or you can use webhooks and trigger the deploy manually (for my tweets on the home page for example).

ToDos

As always, there is still a lot on my ToDo list.

Currently the website does not contain any category pages. Thanks to tags in Eleventy, custom archive pages are very easy to build (in my case all articles are already divided into matching collections).

I also want to experiment with webmentions. This is a protocol from the IndieWeb, with which information like comments, likes or reposts can be transferred in a standardized way. Thanks to tools like Bridgy, you can even import data from Twitter or Instagram.

My plan: Implement Max Böcks great instructions and show all comments to articles like this one below the article.

Also, I’m working on automatically generate OG-images, the SVG-integration is not optimal yet… you notice, I still have some things to do 😄

Please give me your feedback or write a short message, if you should notice any errors. I’m not finished with this blog yet 😛

Originally published at https://www.d-hagemeier.com on August 20, 2019.