Netlify Wordpress

Netlify Headless Wordpress
Netlify With Wordpress
Jamstack Conference

A seamless integration Netlify listens for any changes from WordPress and new content is fetched using the WordPress APIs Netlify prerenders your entire site using any tools and frameworks you configure Once generated, your site is deployed across Netlify Edge in a single atomic update.
Anyone (to include technical team members) can create a post, edit an existing post, or edit an.

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.

Netlify sought to simplify the deployment process with Netlify CMS, which allows developers to create websites and projects with a lightweight page experience. Final Thoughts on Netlify vs. Netlify and WordPress are two of the most robust content management systems, but they cater to very different markets. 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. I've moved over to this YouTube Channel for doing these kinds of screencasts now: this post: http.

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

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.

Netlify Headless Wordpress

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.

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).
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.
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.
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

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.
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.
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.
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.

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 Download chome browser to macbook pro. ), 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.

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!

For a lack of better word. ↩
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. ↩
There is a lot of redundant stuff in there, for WP creates several versions of all images you’ve imported at different resolutions. ↩

TL;DR: I migrated my homepage fromWordPress.com to GitHub Pages for speed and flexibilty,then to Netlify for HTTPS support.

Update (5/1/2018): Github Pages now supports HTTPS for custom domain:https://github.blog/2018-05-01-github-pages-custom-domains-https/ so netlify is not necessary for HTTPS

WordPress.com	GitHub Pages	Netlify
Easy to Use?	Yes	Use Git+Markdown	Use Git+Markdown
Cost	Free for basic	Free for basic	Free for basic
Load Speed?	Slow	Fast	Fast
Flexibility	Low	Very flexible	Very flexible
HTTPS for Custom Domain	Yes	No	Yes
Build logs	NA	No	Yes

Table: Comparison of the 3 platforms.

1. From Wordpress.com …

I have been using WordPress.com to host my homepage athttp://dataninja.me for almost a year.It was a good solution for quickly spinning up the site, butI hit the limit as I was planning to put in more professional contents (python and R markdown stuff).Overall, for my use cases, WordPress.com was too:

slow (heavy overhead),
ugly (espeically Korean and highlighted codes), and
inflexible (e.g. cannot change fonts easily; adding custom pages are hard).

2. Moving to Github Pages …

So, I considered GitHub Pages / Jekyll again.Last time when I tried to use it (~3 yrs ago),the static site build process was clunky and it took some work to make the site look pretty.It seems the situation has changed a lot over past couple of years.Now, the default theme (minima)looks OK and the build process is simpler and faster.So, unlike WordPress.com, GitHub page is:

fast to load,
pretty by default,
flexible, and
free.

I use GitHub and Markdowns,especially, R Markdown,almost daily anyway. So why not??So, I decide to switch back.The process looked like this on OSX.(Replace https://github.com/jaimyoung/jaimyoung.github.io with your own GitHub Pages repo.)

Backup the old GitHub Pages repo, if you had one already.
- (In my case, this meant moving https://github.com/jaimyoung/jaimyoung.github.io to https://github.com/jaimyoung/jaimyoung.github.io-old)
Install brew-maintained ruby not to pollute the OSX system ruby(Of course, your OSX must have homebrew installed already):
Install Jekyll per Jekyll Quickstart Guide, i.e.
Create github page repo https://github.com/jaimyoung/jaimyoung.github.io, and make the jaimyoung.github.io directory to track the github repo:
Serve the test site on http://localhost:4000/ by running:
Import old WordPress.com contents per WordPress.com to Jekyll import guide.
1. First you need to install jekyll-import (https://github.com/jekyll/jekyll-import):
  and a couple other dependencies.
2. Then, export the old WordPress.com contents per direction to some xml file. (In my case, I exported from https://statkwon.wordpress.com/wp-admin/export.php to datasciencefun.wordpress.2017-12-25.xml).
3. Copy it over the the blog directory and import to the page like:
4. Browse the imported files (mostly under _pages folder in my case), clean them up as needed, and move them to correct folders or collections.
Modify theme files as needed.
- In my case, I had to overwrite:
  - _includes/head.html : to add font-awesome
  - _includes/header.html : to use custom navigation menu at the top
  - _includes/footer.html : to add linkedin contact as well
- Find the theme files https://jekyllrb.com/docs/themes/ by running: Clip studio where did pencil download mac.
  copy the files to your repo, and make necessary changes. See my github repo for the changes I made to above files.
Use Jekyll Collections to organize “따라 하며 배우는 데이터 과학” (my Korean data science book) pages under _ipds-kr/ directory.
Set up redirect for a few pages, using Redirects on GitHub Pages. In my case, I wanted to move ipds-kr-slides-ppt to ipds-kr/slides-ppt, etc.
Set up and add Disqus for comments.
Set up and add Google Analytics for site analytics.
Transfer dataninja.me custom domain from WordPress.com to GitHub Pages per directions.
- github help page is a bit unclear; google is your friend here, which gives you a more thorough instructions on specific name provider. For namecheap.com for example, this page was helpful.

3. Then to Netlify…

Now everything almost works.But it turned out that github pages doesn’t support HTTPS for custom domain.This is a huge problem for me since:

There already are quite a few https://dataninja.me domain names on the Facebook, LinkedIn, etc.,
Chrome browser doesn’t handle https to http change easily,
Google search engine indexing values https a lot higher than http sites, and
there seems to be no plan to support https for custom domtain in github

Now, Netlify(https://www.netlify.com/) comes to the rescue.It is mentioned in the above github thread,as a great (free) solution that provides HTTPS support for custom domains.I also found it mentioned in some R markdown/bookdown/blogdown sites, so it looked reputable.

The process was pretty simple and took ~10 minutes:

Set up netlify account and hook it up to github repo and start building.
1. Initially, the build failed (of course) but it was easy to troubleshoot thanks to the build logs like this:
  So, that’s a lot more transparent than github (+1).
2. Thanks to the logs, I could track the build failure to the wrong ruby version. To fix, I added .ruby-version with 2.4.2 per help page and the build succeeded.
3. Now, the page is up and running at https://${random_words}.netlify.com/.
Set up DNS. Netlify provides their own nameservers, so it was pretty simple to follow their directions.
Final step is, the original requirement, to get HTTPS working. Again, this was super simple and HTTPS certificate was up and running in a few minutes.

After these, the site is now up and running at https://dataninja.me/.Pretty sweet!

Making Disqus comments working on Netlify

To use Disqus comments, one adds the following line in _config.yml:

Netlify With Wordpress

This works in github pages, but Netlify version doesn’t activate the comments.It is because minima theme has the following lines

until it activate disqus comments. The environment is set by Github Pages when the site builds,but Netlify doesn’t, hence no Disqus comments.To fix it, per Netlify config directions,set this environment variable in the site deploy setting:

(The URL looks like https://app.netlify.com/sites/pensive-keller-afeae1/settings/deploys#build-environment-variables in my case).

Voilà, now the comments works on Netlify.

Conclusions

I described how I migrated my homepage fromWordPress.com to GitHub Pages for speed and flexibilty,then to Netlify for HTTPS support.

Update in 3/11/18

After notebook migration,my xcode build pipeline broke,which prevents me from installing jekyll =(After 2 hrs of trying to re-install xcode,I concluded it’s not worth it and got lazy(!)and decided to use Docker (of course).Per https://github.com/BretFisher/jekyll-serve,This is all I need:

Lesson: spend at most 1 hr on your own IT; Look for Docker solution after that.

References

Jamstack Conference

Getting started with Jekyll - Series by CloudCannon