1. What Is Wordpress
2. Netlify Install Wordpress
3. Wordpress Founder
4. Jamstack Conference

Description Easily deploy static sites to Netlify using WordPress as backend. This plugin builds your static website using Netlify webhooks to trigger the deploy process. You would make whatever changes you want locally, and then run WP2Static to generate the static files that are then deployed to GitHub, where Netlify picks them up. Your domain name would point to where Netlify tells you to point it, to serve the static files from their CDN. 600GB /month (then $20 per 100) Build minutes. The time it takes Netlify to build your site—to run site generators, compile JavaScript, and perform other tasks. 300 minutes /month (then $7 per 500) 1000 minutes /month (then $7 per 500) 1000 minutes /month (then $7 per 500) Websites.

This is overview article how WordPress and Eleventy works together. I’m writing this article in WordPress block editor as usual but front-end is now served by Eleventy. In other words

• back-end is still WordPress.
• front-end is static using Eleventy.
• site (foxland.fi) is hosted in Netlify.

Code can be found in Github:

• Foxland Eleventy site.
• Foxland WordPress theme and plugin.
• Original demo code for Eleventy and WordPress.

Why WordPress and Eleventy

In general there are couple of main points why use static site generator like Eleventy:

• Security.
• Scale.
• Performance.

Netlify have good article about what are the benefits of using static site generators.

For me it’s the freedom to be in charge about everything in front-end. And it’s also like going back to roots when serving static HTML.

And it’s also like a breath of fresh air to check something new once and for a while. Eleventy is perfect fit for me for that. It’s simple enough but yet powerful.

Yeah, but why keep WordPress in the equation?

I want to simulate real world needs where solid CMS is needed for content editors. Clients have been happy with the block editor for getting their rich content published.

What Is Wordpress

And I have been playing around with WordPress for a long time. It saves me back-end developing time. I’ve been pretty happy about block editor myself.

Development workflow

I’ll try to write more detailed articles in key concepts later on but here are the development process in general.

Getting data from WordPress to Eleventy

Data workflow in Eleventy is super powerful. Basically data can from many different sources. In our case let’s focus on Global data files, our source for WordPress related data.

• That means that _data/posts.js file gives us access to posts key based on filename.
  • Then we can get post title using posts.title.rendered.
  • And content using posts.content.rendered.
  • And so on.
• And _data/pages.js file gives us access to pages key based on filename.
• In those data files we fetch posts and pages using REST API endpoints.

After that we repeat the same pattern for every peace of data we need from REST API.

Caching data locally

It makes no sense to fetch data from WordPress REST API every time you make a tiny change in your template file. It would be super slow experience when developing the site in Eleventy.

So let’s cache the results locally! There is great NPM package flat-cache for that.

1. Fetch data from REST API and save it locally using flat-cache.
2. Set cache duration, for example 1 hour or 1 day.
3. Only fetch again from remote URL if cache duration have expired.
4. All fetched data can use the same logic for fetching the data.

There is also eleventy cache assets, which also uses flat-cache.

WordPress in subdomain

WordPress is installed in subdomain. Although I have a little weird setup when WordPress is under different main domain in foxland.foxnet.fi.

Because nothing needs to render in front-end from WordPress theme index.php and style.css are basically empty.

Other than that it’s just setting some Gutenberg block editor theme supports. And whatever you might need in the admin or in the editor.

Note that I enqueue editor styles from the live site directly.

This is handy because Eleventy can handle editor styles at the same time it handles front-end styles. And I get to enjoy same styles in the editor. Nice!

Custom Plugin registers some post types and custom blocks. In this case they could have been in theme also since theme doesn’t really handle anything else than admin related stuff.

Only other plugin is Headless Mode.

Deploy to Netlify

Site itself is hosted in Netlify. New data or code get published automatically when I push the code in master branch in Github. I can also trigger deployment manually from Netlify account.

But this really isn’t going to scale, is it. There needs to be some kind of automated process for deploys when new content get published.

One solution is to trigger Netlify build automatically using Netlify build hook and IFTTT. This could be set every day or in every hour (or whatever frequency you’d like).

It would also be handy to call https://api.netlify.com/build_hooks/YOUR_ID_HERE directly from WordPress admin when needed. It could happen automatically when new content is Published or manually clicking “Build site” button when there have been updates on content.

I need to play around with this but for now once per day using IFTTT is enough for me. Build time can also be minutes or even more if the site is big. In my case it’s just 1-2min. This is something to consider if client want to publish content pretty much immediately.

Learn Eleventy

Here are couple of links where I have learnt Eleventy:

• Official docs.
• Let’s learn Eleventy in Netlify.
• Jérôme Coupé Introduction to Eleventy.
• Learn Eleventy from scratch course.

After years, I’ve been able to kiss WordPress bye-bye and migrate to a fully static site build with Jekyll and deployed to Netlify. In this post I’ll tell you why, and show you how.

Why not WordPress?

I’ve nothing against WP in principle, it’s not the right tool for me. I blogpost on average once a month, it makes no sense for me to be bound to a Linux hosting with mySQL access, a BackupBuddy subscription plan and a dozen of other WP plugins to run this site. Have you seen my posts? A couple of images, few snippets of code, some text. Really, WP is plain overkill; plus, I don’t want to worry about WP updates, PhpMyAdmin, DB access errors, log-ins, plugin incompatibility and fancy dashboards anymore.

Now I have a simpler, static site which I update writing text files on my disk, committing to a free git repository, which Jekyll files are automatically built, hosted and served over https for free by Netlify.

Static vs. Dynamic

As opposed to WP, where each PHP template¹ is filled on-demand – i.e. when a user requests a page, fetching the content from a database and returning the processed data as html – a Static site is pre-compiled so to speak, and simply made available online all at once.

As a consequence, a WP site needs a machine running some server-side scripting language such as PHP, a database like mySQL, and some processing resources; a static site is happy when it is hosted on a server that is (a) turned on, and (b) connected to the net.

SSGs

Netlify Install Wordpress

If you’re not familiar with the concept of Static Site Generators, they’re command-line tools that get a bunch of HTML/JS/CSS with template code and markdown files as input, and output a full static website. Your job is then to move the files on the server.

There are several SSGs available: to the best of my knowledge, the most popular ones are Jekyll (written in Ruby), Hugo (written in Go) and Hexo (Javascript). Each one of them has its peculiar templating system and folders structure.

All of them share the sublime idea that you compose your writing (both pages and blog-posts) in MarkDown: a text file with a basic set of formatting rules, such as **bold**, _italic_ etc. Hence, all your website content is not hidden into some resources-hungry DataBase, but exposed to you as plain text files with a .md extension.

Which SSG to pick

If you start fresh (i.e., you don’t run a SSG already) or you don’t have plenty of time on your hands, I suggest you to look at the available templates for Jekyll (free or paid), for Hugo and for Hexo. Beware high expectations: they’re all quite bare. Pick the one you like the most, and then learn that templating language to customize it.

On a superficial level, that’s all you need. To me – and I’m not really into SSGs enough to get all the nuances – besides the templating language, the only other difference is compilation speed. Being written in Go, Hugo goes like a rocket. My website is compiled by Hugo in 1.5 seconds, whereas Jekyll takes ~14 seconds, and Hexo is not that much better.

Keep in mind that each time you modify a thing and save, the process re-generates (if you want, incrementally) the whole website, so 14 seconds to see whether a CSS rule or a template tweak really do what you originally meant them to do, may be a long time to wait – the fifth time in a row that you hit save.

I am on Jekyll, using a mildly customized version of the Steve theme, which costed me like $15. I already run CC-Extensions on Jekyll, I’m mildly familiar with it, so I’ll keep being patient if it takes seconds to compile.

WordPress migration

I’ve followed this very checklist myself. Perhaps things can be made simpler, but this has worked fine for me – feel free to google stuff if you need more detailed information.

1. Migrate all your comments to Disqus: sign up and follow the instruction to install Disqus on WordPress (you’ll need to get this WP Plugin).
2. Do a full backup: I’ve always used BackupBuddy, which isn’t cheap but works like a charm – perhaps also the built-in WP Export is OK. You need to backup both the WP assets and the DB.
3. Install MAMP or a similar software and restore your WordPress installation on a local server (e.g. on your laptop). This will make the following step faster.
4. On your local WP, install both WP to Hugo and Jekyll Exporter migration tools, and perform both Exports. You’ll get two .zip files with a bunch of MarkDown in them. I’ve found that the Hugo version of the posts returns a better MarkDown conversion – but the files aren’t named as they should (i.e., prefixed with the date, like 2018-11-29-something.md).

Jekyll import

1. I have then manually reviewed the markdown files of the majority of my posts (~150) coming from the export, deleting items in the YAML FrontMatter² that aren’t meaningful, and fixing the markdown.
2. Make sure you keep the original permalink (the post URL): this way each post will have the same URL of your old WP site. This way people who get to you from other sites’ links don’t get 404’ed, and you keep analytics intact.
3. Remove in the MarkDown all the links to http://localhost:8888/. For instance, my Hugo export (the one with nicer markup) has all the posts’ assets with urls like http://localhost:8888/wp-content/uploads/2018/03/logo.png. Do a batch search and replace and turn them to /wp-content/uploads/2018/03/logo.png.
4. Move the markdown posts in Jekyll’s _posts folder, and also move in the website root the exported /wp-content folder, which contains all the images coming from WP³

An example of the YAML FrontMatter for this very post:

GitHub

The whole idea around this SSG thing is that both the site build and the site updates must be easy. I’ve created a git repository on GitHub and pushed my Jekyll website there. Be aware that GitHub itself provides you for free with GitHub Pages, a service based on Jekyll that automatically builds your site each time you push a commit to a gh-pages branch, and hosts the result on https for free.

There are some limitations in terms of Jekyll plugins (see the whitelist here), so I’ve decided to try a different approach.

Wordpress Founder

Netlify

Go create a free account on Netlify, which provides an amazing service similar to GitHub pages. Then link your GitHub/Bitbucket repository, define a build command (mine is simply jekyll build), and they will serve the Jekyll output on a dedicated, public subdomain – that you can use to check the site or point collaborators/clients to.

At this point, you can link your existing domain (the process is quite easy): Netlify will give you few domain name servers to set e.g. on GoDaddy, or wherever your domain is hosted. You’ll be asked also to add to Netlify all the existing CNAME and MX records from your host (copy them from GoDaddy – they are for email, FTP and such).

Then you’ll have to wait some hours for the DNS propagation, during which your website won’be served through https – the free Let’s Encrypt certificate will be issued shortly, and your static site will finally be on SSL.

Jamstack Conference

Conclusions

I am genuinely happy to have streamlined my blogging workflow. There’s lot of room for improvement – e.g. on the theme, SEO, social cards etc. – but given the little time it took:

• I have gotten rid of WordPress and related expenses (pricey hosting and plugins).
• Posts are easier to access, create and edit.
• I generally feel more in control, and less subject to random, time consuming issues.
• I haven’t lost anything relevant in terms of functionality.

If I had more time I’d explore Jekyll and Netlify features more in depth, or even consider adapting my theme to Hugo to save some building time in the future. Luckily, I haven’t got any spare time left 😅 So I’ll just call quit and feel good.
Thanks for reading!

1. For a lack of better word. ↩

2. It’s the header content of each .md file, which is wrapped with three dashes ---. It contains the post’s metadata (e.g. the title, the excerpt), that is used by Jekyll to display it. ↩

3. There is a lot of redundant stuff in there, for WP creates several versions of all images you’ve imported at different resolutions. ↩