Netlify CMS and WordPress can be categorized as 'Self-Hosted Blogging / CMS' tools. Some of the features offered by Netlify CMS are: Netlify CMS and WordPress are both open source tools. It seems that WordPress with 12.7K GitHub stars and 7.78K forks on GitHub has more adoption than Netlify CMS with 9.22K GitHub stars and 1.27K GitHub forks. 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.
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?
- 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.
- I've moved over to this YouTube Channel for doing these kinds of screencasts now: this post: http.
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 template1 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.
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, like2018-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 FrontMatter2 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 likehttp://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 WP3
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
), 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. ↩
Good morning,
I am interested in exploring the options available to use a WP site with Netlify. I would like to keep the WP backend for familiar/easy editing.
I see a couple of WP plugins that trigger an auto deploy to Netlify upon a WP edit. I also see WP2Static that is now on Github.Is one of these a good way to go?
I now see another approach using the WP API (https://www.smashingmagazine.com/2020/02/headless-wordpress-site-jamstack/).
In setting up using one of these ways, I assume I have to do some upfront work to get the WP site over to Netlify. What methods are available to accomplish this. If possible, I prefer not to use an SSG. Is WP2Static considered an SSG?
So many choices, lol.
Thanks
- This topic was modified 6 months, 3 weeks ago by .
- This topic was modified 6 months, 3 weeks ago by .
- This topic was modified 6 months, 3 weeks ago by .
- This topic was modified 6 months, 3 weeks ago by .
Jamstack Conference
Yes, WP2Static is a SSG. And since they removed that plugin from the repository, we don’t support it here. I’m not sure I understand the difference between WP2Static and the plugin they had here: https://wordpress.org/plugins/static-html-output-plugin/ which they have in a different GitHub repository. (Maybe that’s the original name, and they are moving forward in a new repo with WP2Static name.)
The trick with making a static site with WP is you need two separate places: one for the PHP to run and the other to serve the static output. (so where does your domain name point?)
If you have your host for the PHP, you might as well simply serve the result as normal, since it is still online and vulnerable to hacks. So it makes sense to use WP locally, and deploy to Netlify (usually via GitHub). Or use one of the services to host WP behind a firewall, and deploy for you. (Sitesauce, Shifter, Strattic)
Running it as headless still requires a PHP backend, so it’s no faster or more secure than normal, although you can host on a service that does this for you.Consider the interactive parts of your site: comments, forms, search, login, ecommerce before you switch. You have to remove all of that (or find static substitutes) before you deploy what WP2Static generates. I found a plugin Remove WP Overhead recently, which helps with some of the stuff in the <head> section.
I’ve been working on a plugin for generating a static search index for the Lunr search since I don’t want a branded external search on my client’s site.it makes sense to use WP locally, and deploy to Netlify (usually via GitHub). Or use one of the services to host WP behind a firewall, and deploy for you. (Sitesauce, Shifter, Strattic)
Does “in-house computer” equate to “use WP locally”? If so, yes, that’s what I was referring to. (install WP on your computer)
No, by putting WP on your computer, you are removing it from its online presence. You would have the only access to it. 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.
The interactive features of WP have to be replaced with Javascript interacting with external APIs, for things like sign-in (MemberSpace, MemberStack), contact forms (FormKeep, or just use a mailto link), searches (Algolia or Google), forums (maybe Discourse).
A static site is not a good fit for all. It just depends on what interactive things your site does.I assume you mean groups of people. If you are doing some sort of membership site, it’s not a good match for static.
Take a look at https://www.tnd.dev/ for resources.
https://jamstackfns.com/ also has some.
You can write interfaces yourself, see https://functions.netlify.com/
Netlify Install Wordpress
- The topic ‘WP to Netlify’ is closed to new replies.