Wordpress is part of the LAMP stack, and there are easy tools like XAMP to get you up and running locally. With a tutorial it should be doable. It’s probably better if you get hosting with auto-install if you’re really averse to tinkering.
That said I wonder why you’d need Github Pages if you’re already set up with Wordpress...
>That said I wonder why you’d need Github Pages if you’re already set up with Wordpress...
Maybe there's something I don't understand here? Wordpress.org isn't hosted, it's just the website software itself. Hence the need for Github Pages (although most people just use a hosting provider like Siteground).
But it’s specifically made to be a blogging software, to me it just feels like an extra step to convert your writing, unless the Github Pages ecosystem gives you lots of benefits.
I looked at it with excitement and realized that it’s Windows only. It doesn’t seem to have support for macOS or Linux, and the website doesn’t even have a standard “system requirements” section (or one I could easily find in the documentation).
It was because I wanted to host and serve my website via Github Pages rather than go with a managed hosting provider. As my post exemplifies, that was a mistake.
Laravel has a great tool called Valet. Makes running multiple instances of WordPress locally a breeze. You just point it to a folder and it creates a local [directory_name].test. Works great for static html too
Confused why the poster wanted to use GitHub pages. Sounds like a hassle considering hosting with Wordpress.com you point your domain too. ️
I've never heard of Laravel before - checking it out now.
I wanted to use Github Pages because I had my previous site on Github Pages. GH Pages was easy to setup and provided good hosting/serving for free. I wanted the same for my new Wordpress site and naively thought I could make it work.
I have the same problems as both OP and the blogger: I want absolutely nothing to do with the hosting of the blog itself. I just want it to be a writing platform, a very very simple one, and nothing more.
This allows me to do plenty of things. There are no servers to manage, and I write my posts with vim and use Markdown. I have a simple theme. Deployment and testing happens automatically through Amplify.
If I really, really, absolutely must, I can dig deeper into Hugo and do whatever I want. But if I just want to stick to the basics, I write files in the content folder and edit the settings file the first time. That's it!
And because it's in AWS, I can use cert manager and Route53, things I already know from work, to put my domain on it.
This was a lot easier for me than anything else. I previously used Ghost hosted on a Digital Ocean instance, but I quickly grew tired of having to update Ghost, dealing with node, etc. Plus having to worry about securing the site and the instance. Patching the instance. Backups.
How about Hugo’s stability when upgrading? I haven’t tried it myself, but have read many a comment (including on HN) on how even minor version upgrades end up breaking things.
I honestly haven't updated! Or at least, not purposely. The package in Ubuntu's repo is at v0.68.3 which was released at the end of March. So apparently I updated at least once. Latest version is 0.74.3.
A lot of the updates I am missing seem to be simple bug fixes.
> whatever setup minimizes the daylight between wanting to write, and writing.
No matter your setup, writing in markdown is the fastest way to get your ideas/thoughts to a presentable format. That should work in all good CMS/blog/static/dynamic software.
The markdown can have associated markdown settings that are either in a comment at the top or a sidecar file that can be adjusted to any platform.
Whenever I write I do it in markdown, get the thoughts out, clean it up, add presentation. Then I know there is no lock-in or ownership of the content to any system.
If you do change systems there may be some initial settings/markup/declarative hooks you need for things like embeds/code highlighting etc, but after that you are rolling.
Standards whether specified or market standards, always help you evade lock-in and can make your content a free agent when needed.
Software today is a mine field of lock-in created by large entities that want you to develop in an abstracted layer above the simple standards, even at the programming level we have lost focus of shared standards that give you platform freedom.
After various iterations of my personal webpage, and losing content in every migration, I've just ended up just going with raw HTML in the style of motherfuckingwebsite.com.
It helps that my hobby is retrocomputing, so my plain HTML pages can actually be loaded on a 25 year old version of Netscape. Doing my writing on an old PowerBook running System 7.5 also helps cut out distractions, and being a bit of a novelty makes the writing fun instead of a chore.
"running WordPress locally is a nightmare... I should also caveat that I know almost nothing about Apache, MySQL, FTP, and PHP."
Without wishing to be too snarky, this could be rewritten as "Running this software is a nightmare if you know nothing about the technologies it is built on." And being slightly more snarky, my response would be: well, duh.
I'd add you need to know how your OS will handle the installation, IIRC Mac OS comes with pre-installed PHP and/or Apache which uses configuration files you might not know to look for and may conflict using the same ports etc. Its a mess.
It's not a mess. It's just different from what you're used to.
Running WordPress on macOS is slightly different from running WordPress on Ubuntu, which is different from running it on CentOS.
I maintain WordPress sites on all three. None of them are inferior to the other for this purpose. They just have different conventions.
In fact, I've had far fewer problems running multiple WordPress installations on macOS than I have on CentOS. But that's because I understand Apache better than the author of this article. Pretty much the only problem comes during a major OS upgrade when the installed backs up some of your configuration files and replaces them with the default. But once you deal with it one or two times, you know what to do.
For local WordPress development, we used Bitnami's WordPress image[1]. Later, we used Local by Flywheel[2]. Both used VirtualBox so it was nice to get the entire WordPress stack with minimal installations. We only had a .NET developer at the time but he was able to "pick up" the LAMP stack with these solutions.
What would you consider understanding the tech? I can't write a single line in Apache config nor can I do a Hello World in PHP or query anything in MySQL, but I can setup and install WordPress on a local machine or a server.
I don't feel like that I understand the underlying tech, but as long as you know how to install WordPress, you can install WordPress.
For my purposes (set up a simple blog and get it running), I truly don't think that I need, or should, have to learn the ins and outs of the tech stack. In fact I chose WordPress specifically _because_ I wanted it to abstract most of the implementation details away from me.
I don't think this is true for development generally.
Perhaps it wasn't intended, but the post read as a complaint that it wasn't easy, but self-hosted WordPress (i.e. wordpress.org rather than wordpress.com) doesn't sell itself as a one-click install CMS. (Although there are things like MAMP that allow you to delegate the basic server setup).
>For my purposes (set up a simple blog and get it running), I truly don't think that I need, or should, have to learn the ins and outs of the tech stack.
Well ... if you want a simple blog, then you can setup an account with the 10million hosted blogging services that are out there. And if you want a wordpress blog, then you can set up an account with wordpress.com, or get a hosted solution with Wordpress/LAMP already preinstalled, or get a VM with Wordpress pre-configured (e.g. Vagrant Box with Wordpress: https://themeisle.com/blog/vagrant-wordpress/).
What you wanted however, was a locally hosted Wordpress (why?) that you installed and configured (on Windows no less). That's fine, but Wordpress requires PHP, and requires a web-server, and requires a database - so you'll have to be able to understand what all those pieces are in order to install and configure them together.
>In fact I chose WordPress specifically _because_ I wanted it to abstract most of the implementation details away from me.
Which it does. There is a difference between being a user of Wordpress and installing and administrating Wordpress. For the former, understanding the tech stack is not required. The UI is meant to be used by non-tech savvy people. For the latter, yeah, you need to be familiar with the tech stack. That you're not, and you had some trouble installing it, that's not the fault of Wordpress.
This was pretty much my thoughts too. This use case is quite a bit outside of the realm of what Wordpress is intended to be used for. Local deployments are only really intended to be for people who are serious about administrating their own web server or developing plugins for Wordpress, so it's assumed that you already have the knowledge to set up a web server with PHP and MySQL.
The people who want a "writing first" experience _with Wordpress specifically_ have many paid hosting providers to choose from, but that would defeat the purpose of the article.
Making a one-click installation process would also take a significant amount of dev resources to handle all the different platforms and require expertise that isn't required for the main product, given that it is a PHP project which is almost entirely cross platform by default.
I run a shared hosting business. Mostly wordpress, of course. Most people have their first contact with all this when their site is hacked (plugins not updated for years) and they have to clean up. Then we need to babysit them - but to a degree that is what we are paid for. And for good reason.
> Well, Wordpress can know auto-update the plugins...(sic)
And your site (Or some parts of your site) could break at any point in time without your knowledge and remain broken for a long time until you find that it’s broken. There is no platform that doesn’t require “babysitting” with maintenance and testing.
The problem is most Wordpress plugins are abandoned. Most sites default to auto updating plugins, but if the plugin author isn’t pushing security patches it’s a big vulnerability.
Wordpress plugins are notoriously bad at input sanitization. Even many large, commercially supported plugins get abandoned or simply aren’t secure.
I think your response would be unfair. If you think about the statement "running this software is a nightmare if you know nothing about the technologies it is built on" outside of this context, it clearly doesn't typically apply. You wouldn't apply that to using a web browser or a word processor, right? Should 'blog writing' software really have such a greater barrier of entry?
I don't think so. The author actually gave themselves a weird goal - to use Wordpress as the text editor, and export/copy the static content to github. I'm not sure why they would do that, but OK! In the end, their problem wasn't with the workflow but with setting up local version of Wordpress (why? why not use a hosted version of Wordpress????), PHP, Apache, MySQL and FTP(!!).
WordPress isn't actually that hard to setup. It's a little harder on Windows, because setting up PHP on Windows just isn't as natural as on Linux but XAMPP makes it as easy as possible.
>Should 'blog writing' software really have such a greater barrier of entry?
But it doesn't. You have a plethora of (free) hosted blogging solutions. You could also get private hosting with the LAMP stack already pre-installed and configured.
Why someone would do this: Wordpress has a solid editor, lots of plugins, and is used by millions so the workflow is well tested. The resulting pages are a perfect fit as static content.
You can accomplish this by using a CDN that caches everything, or use plugins that export static files like WP2Static, or use integrations with static site frameworks like Gatsby that treat WP as a CMS.
But yes, doing it all from scratch yourself is probably not worth it, especially if you're unfamiliar with the tech.
>Why someone would do this: Wordpress has a solid editor, lots of plugins, and is used by millions so the workflow is well tested.
Sure - why not. The question, why do you need to host it locally? You can just create a free account on wordpress.com, or get a private hosted solution for peanuts and with the LAMP stack already configured.
But to be fair, the authors core point is correct - running Wordpress locally and then deploying to the internet is an absolute tire-fire.
For context my wife uses wordpress to build various sites. I got lumped with the task of moving this online. It was super painful, as WP encodes the URL name (i.e. localhost) flipping everywhere.
I eventually resolved this by editing the tables which stored the URLS (fortunately, as a DS I know SQL) and doing some sed on various files that cached the URL.
I now refuse to do this, and set her up online with a website before she does any work, because moving it is so painful.
>Should 'blog writing' software really have such a greater barrier of entry?
It doesn't.
You can open an account on Wordpress.org and be writing your blog in 1 minute.
You can use your virtual hosting's manager to install Wordpress and be running in 10 minutes.
You can download MAMP or WAMP (packaged Wordpress + MySQL + Apache + PHP) and be running locally in 15 minutes.
This guy wanted to do an install locally manually, patch it to produce static pages (which is not what it was made for0, hook it up with GitHub pages, and so on. And all that without bothering to know how.
while you are right for a tl;dr, from the article, the feeling I'm getting is more that those are known unknowns only now for the author, and they were unknown unknowns at the beginning.
The fact that each moving part wp needds is tricky in its own way doesn't make the experience better if you are encountering them for the first time :)
The author was probably not aware how complicated set of dependencies (moving parts) wordpress needs compared to jekyll. Which is fair if from the outside the two seem to be products in the same category.
For what it’s worth, many WordPress devs are using docker solutions anyways these days. For example, core WordPress and Gutenberg (the block editor) are often developed using Docker. You can do it other ways too, but much of the tooling is built around docker anyways.
In fact, myself and a few others have spent some time improving the local environment situation with a tool called wp-env [1]. So long as you have docker & node installed, you can install wp-env with npm. Then you can just use “wp-env start” to get a local WordPress instance running. It’s fairly straightforward to configure for basic needs too! No need to understand Apache, SQL, FTP, or even PHP to get it running.
All this to say: there are open source solutions to the local dev environment problem even being developed and supported by core WordPress teams. :)
Wow this article makes me feel old. Running wordpress locally is something I have done so many times in the past, but yes, I would not imagine it being a good fit for then turning it into a static site.
These days there are a lot of better CMS options for JS single page applications.
I find the first mistake here to be trying to use WordPress. Maybe it's just because I use it so much (or rather, as a developer, I'm often hired to fix other people's mess and broken code) but it is genuinely my most hated piece of software.
Not the OP, but I’ve fought Wordpress plenty of times as well. Probably the worst time was when I was writing a WP authentication plugin for my org. I was reading the docs when I ran into this gem[0]:
> The semantics seem rather fuzzy. If id is a WP_User or other object, or an array of properties, it seems to clone it without touching the cache. Otherwise if id is a number it seems to try to read it possibly from the cache, or from the database using ->get_data_by(), which can also update the cache. If id is empty it reads by login name.
I realized that if even the offical documentation didn’t know what Wordpress was doing, I definitely had no hope.
I’m not the fellow you’re replying to, but here’s my 2C. My perspective might be out of date, as I haven’t touched WP in 5 years or so.
-The plug-in APIs have been largely written by accretion, making them confusing and hard to grok. I always vaguely feel like I’m doing something wrong, that this shouldn’t be this difficult... Furthermore, API functions are inconsistently named, and return hard-to-predict datatypes.
- The theme tools are similarly confusing, and can make simple tasks take a lot of time. Sure, you just have to create magicfilename.php/css and put this magic snippet into it - but the discoverability in that is pretty garbage and results in a lot of hacks that solve things in the wrong way.
- Using other people’s plugins was a crapshoot, as plugin conflicts were (are?) pretty common. For a casual user plugins are a massive footgun, as WP makes it easy to install decade-old unmaintained junk plugins full of security holes.
Compare all of this to Drupal, which while far from perfect actually tries to design sane APIs and solid code, and iterates on it to correct their mistakes.
In my case, it just seems architected entirely backward, because of an accident of history that was LAMP and the only options at the time for having any kind of software running "on the internet" that could provide an authoring interface. The authoring software and its database and all the security surfaces and performance and cost associated with those should only be incurred when author changes are being made, not 24/7 when people are viewing content that isn't changing. The viewing experience can (and should) closely resemble a CDN of static pre-rendered documents, possibly plus thin edge-worker type logic around interactive features like comments or form submissions.
Check out the public API, read the source, look at the data model.
Wordpress is a workhorse on the web, but it is a complex, inconsistent mess full of weird edge cases. It is much harder to introspect, debug and reason about than it should be. You need tons of specific, specialized knowledge to interact with it as a developer.
The reason for that seems to be this: it is built with people in mind who cannot code, but the reality is that for many cases this doesn’t suffice, so you end up with a hodgepodge.
Mine are mostly state-related. The DB and files from a live site are so tied up in basic config & functionality that if you only have the source code repo you may as well have nothing.
The truth is that most people just want a static website and use wordpress because they don't know better and then trivial things break for them and now half the web is broken. It is easier to create static websites by hand or using any other service imo, even for non-tech people. Dynamic websites are a different story but after almost 2 decades since word press I doubt there are no alternatives, wordpress just has a reputation and inertia.
I tell potential clients i turn down to use site builders like Wix, Squarespace, etc. Yeah they're $30 but I'm going to change your way more in a year to setup and maintain WordPress for you.
I'm also a huge fan of WebFlow, especially for people that have some basic knowledge of CSS or really just want to tinker with every paragraph :)
if you wanted a cms and was using jekyll, why not something like https://forestry.io/ ? it's git-aware, which means it should work with github pages (i've not tried it myself, other than a cursory look-see).
> For example, I tried and failed multiple times to add a <meta> tag to the head of my index.html file. This theoretically should have been a very simple change.
The thing “they don’t tell you” about static site generators is that you should vendor your site theme. Don’t expect to both get upstream updates and make HTML level changes.
Every month there's a new static site generator invented. Every time I check to see if they handle this type of thing cleanly. Every time I'm disappointed.
Hell, I'd be happy with a decent theme library that actually gets tested and regularly updated.
It takes a while to understand the wp modular system, that's why people get paid to set it up and customise it for specific needs.
That being said, deploying WordPress takes minutes. And running it locally as well. Docker images are available if installing hundreds of libraries isn't your thing.
If anyone does want to convert Wordpress pages to static pages then WP2Static seems to be the best option https://wp2static.com They even list alternative tools that are better in certain use cases https://wp2static.com/alternatives/
I think part of the problem is because you were previously used to GitHub Pages with Jekyll, you were trying to use a new (but old) tool (Wordpress) with GitHub Pages and it's not a great fit for it. I'm sure it's possible somehow, but it wouldn't be straightforward. Just conceptually I'm not sure how it would even work: GH Pages is for hosting static sites (AFAIK) and WordPress uses a DB and dynamically writes posts. So I'm guessing you're trying to do a setup where you locally run WP, write from the WP interface, saves posts in your local Mysql DB, and then generate a static site (html files output) and pushing those files into a GitHub repo?
It's a roundabout way to publish to a web site to say the least. If Jekyll has enough issues where you need to tweak its config in Ruby every time you want to write, you could try a different static site generator (e.g. Hugo for golang, or Miner [1] for Svelte. Disclaimer: I worked on Miner.).
I think the product you're looking for is a static site generator + the use of a client-only WYSIWYG markdown editor that connects to your git repo via OAuth and lets you write on a good UI instead of plain text markdown files. The SSG is one of above; unfortunately I don't have a recommendation or know of a client-only WYSIWYG MD editor with git OAuth integration.
Please omit personal swipes from comments on HN. In this case, since the comment consists of nothing but a personal swipe, it would be better not to post.
How much of the tech stack would I need to know to be a developer then? The framework, the programming language, the server, the OS, the Hardware, the networking infrastructure...
In modern software, it's unreasonable to understand the entire system that you're developing for. It especially doesn't make sense in a business sense...
Use the right tool for the work you're trying to do. WordPress is probably the right tool for the author's problem. GitHub Pages is probably not the best tool to use with WordPress.
A carpenter doesn't try to build a chair without understanding how both a saw and a measuring tape work. People who want to build a chair with a saw and a surveying rig are probably better off going to a chair store.
It seems that the author overestimated his technical abilities, and blames the tools he chose, rather than himself for choosing those tools.
But no, static site generator plus headless CMS is not the answer, regardless of how many comments here enthusiastically say so.
I’ve been down the static site generator rabbit hole for the past 7 years...and realized they aren’t really well suited for anything other than tiny developer blogs that don’t ever get updated (dev writes his occasional post in VScode)—-or, giant company marketing sites that get hooked up to enterprise-y headless CMS products like contentful.
If you’re somewhere in between, I’m starting to think Webflow is the answer. In fact, I’ve started moving all my side project marketing sites/blogs over to them and couldn’t be happier.
The problem with [insert static site generator] + [insert headless CMS] is that getting off the ground is a massive pain in the ass.
If you’re trying to set up a static site for your side project, let me give you a preview of what your next couple of weeks will look like:
First you have to pick a SSG. There goes a day of research. Then pick the next hot CSS framework (of course, you shouldn’t waste your time on this, but you will). Tailwind! Sick! Then setup a build process. Then troubleshoot the inevitable issues. Fixed. Then setup a git repo. Then hook the repo up to Netlify. Then hook up continuous deployment. Then get the domain. Then configure the domain to talk to Netlify. Then realize your hot new SSG doesn’t do any SEO stuff for you. Setup xml sitemaps. Generate proper tags & structured data. Then you have to create the actual site. Realize your CSS framework is overkill. You’re already a week in. Optimize for breakpoints. Cool. Almost ready. Now let’s write some content. Shit, I’m never going to write if I have to fire up my code editor each time. Look into headless CMS options. There goes a day of research. Pick one. Now Setup models in the CMS. Try to figure out how to hook it into your git repo and trigger deployments to Netlify. Realize the UI of the headless CMS you picked is clunky. Never actually write any content. Forget how you even set everything up. Get frustrated. You haven’t even hooked up any analytics or email signup capability yet. Give up.
On Webflow I’ve managed to cut the previous paragraph down by about 80%.
95% of your list is applicable to any other project you might venture on. This is absolutely nothing specific to static site generators. In fact, if you started a WordPress site from scratch, you'll probably be adding a ton more things to that list.
I run a couple of Jekyll sites, with Directus as my headless CMS, and my experience is pretty much the same as writing posts for a Wordpress site. I wrote the post in a simple editor, save it, and manually trigger a deployment on Netlify. Even the deployment can be automated if I were to set up some simple build hooks.
There are a view downsides and limitations, but nothing I can't live without. And it actually helps me keep everything as simple as possible.
> Shit, I’m never going to write if I have to fire up my code editor each time.
This is the most important part. I edit my site by typing in a WYSIWYG editor and hitting the save button. It works on any Internet-connected computer I can get my hands on, without installing any software.
> But no, static site generator plus headless CMS is not the answer, regardless of how many comments here enthusiastically say so.
> I’ve been down the static site generator rabbit hole for the past 7 years...and realized they aren’t really well suited for anything other than tiny developer blogs that don’t ever get updated (dev writes his occasional post in VScode)—-or, giant company marketing sites that get hooked up to enterprise-y headless CMS products like contentful.
> If you’re somewhere in between, I’m starting to think Webflow is the answer. In fact, I’ve started moving all my side project marketing sites/blogs over to them and couldn’t be happier.
> The problem with [insert static site generator] + [insert headless CMS] is that getting off the ground is a massive pain in the ass.
> If you’re trying to set up a static site for your side project, let me give you a preview of what your next couple of weeks will look like:
> First you have to pick a SSG. There goes a day of research. Then pick the next hot CSS framework (of course, you shouldn’t waste your time on this, but you will). Tailwind! Sick! Then setup a build process. Then troubleshoot the inevitable issues. Fixed. Then setup a git repo. Then hook the repo up to Netlify. Then hook up continuous deployment. Then get the domain. Then configure the domain to talk to Netlify. Then realize your hot new SSG doesn’t do any SEO stuff for you. Setup xml sitemaps. Generate proper tags & structured data. Then you have to create the actual site. Realize your CSS framework is overkill. You’re already a week in. Optimize for breakpoints. Cool. Almost ready. Now let’s write some content. Shit, I’m never going to write if I have to fire up my code editor each time. Look into headless CMS options. There goes a day of research. Pick one. Now Setup models in the CMS. Try to figure out how to hook it into your git repo and trigger deployments to Netlify. Realize the UI of the headless CMS you picked is clunky. Never actually write any content. Forget how you even set everything up. Get frustrated. You haven’t even hooked up any analytics or email signup capability yet. Give up.
> On Webflow I’ve managed to cut the previous paragraph down by about 80%.
I'm sure Webflow is a delight to use, but some 20 dollars a month is an insane amount to pay if you run several projects that might or might not be profitable.
I'm already paying some something like 12 dollars a month for domains on average and 10 dollars for a small web server which adds quickly up. If I had to run all the projects on something not-self-managed, we'd be talking about hundreds every month.
> 20 dollars a month is an insane amount to pay if you run several projects that might or might not be profitable
I used to have this mentality as well. Do everything for free, use open source, self-host everything--the classic frugal hacker mindset.
Then I realized that I was spending 80+ hours tinkering around with static sites and different headless CMS option and had done absolutely none of the actual work required to bring people to my sites (which is the more important work).
When I take small freelance gigs I charge roughly $100/hr. That means I spent $8,000 of my own time on tinkering around with what was essentially bullshit.
Forcing myself to pay for SaaS tools has been amazing at focusing my attention. It's a perfect signal for what I should be working on.
If I don't feel confident investing $20/month in a site for my project, why the hell is anybody going to feel confident paying that or more for what I'm creating?
It's forced me to kill what's not worth my time, and focus on what actually has the real potential.
WordPress is a nightmare because of the issues surrounding speed, security and scalability. But if you use a static WordPress hosting solution (like Strattic for example - I'm the CEO) that solves all that, so you can benefit from WP's robust CMS while enjoying a perfect, static output. https://www.strattic.com
WordPress is an incredible blog editing software, which is why it's so popular, so I get the author's intention.
It'd be amazing to have something that let's you open a desktop app, have WordPress with all (or most of) its themes and ease and plug-ins for blogging, deploy changes to a git repo, and from there to a host -- in a way where you don't need to know more than how to make an account on say Github and Netlify.
Maybe there already is something like that, I'd love to know if so!
Well it's not WordPress and you're missing out on the plugin-ecosystem (and there aren't that many themes yet) but the closest I know that fits your vision would be Publii [0].
I don't understand how the author was able to set up a Jekyll/github/DNS/markdown website and later hitting a roadblock with the whole Apache/PHP/FTP/MySQL stack.
Is the root of all this the fact that github offers free hosting through github pages ?
Just to point out a caveat with the original idea: all the posts would be stored in a local database. If something where to happen to it, it’s quite miserable to recreate posts from scratch, even if you have the source material. Don’t ask how I know.
PS, author, if you see this, make sure to use a child theme or custom plugin to make code changes. Otherwise a security update (which are usually automatic these days) will wipe out your custom changes.
>Here’s what I know now: running WordPress locally is a nightmare. Successfully figuring it out was way harder than it should have been. If you’re trying to do this yourself, don’t. You most likely don’t need to, and there’s probably another solution you can use to get to what you want. (I should also caveat that I know almost nothing about Apache, MySQL, FTP, and PHP.
Running "ls" can be a nighmare too if you know nothing about filesystems, files, file types, flags, manpages, and so on.
The TLDR is right at the end when I have already read the whole thing! :)
By the way, I recently migrated a weblog from Wordpress to Hugo on Netlifly. It was easy! Just add a post in GitHub and it automatically triggers a build in Netlifly and the post is live in seconds! You can also have your own custom domain for free.
Don’t have recent experience with Jekyll but can’t imagine it being that painful with the build/customization.
What we really need is a good static output generation built-in wordpress that actually works and downgrades successfully. Instead, the team decided to work on a page builder (Gutenberg) which was/is far behind Elementor and the rest. Static generation is an absolutely essential feature in my opinion for having the peace of mind regarding security. I tried EVERY SINGLE one of the static generation plugins out there for a client project (avada theme/elementor/wpml) and none of them worked. (But apparently they do work if you use the SaaS version, not tried it myself)
So I guess Automattic will not solve it as it would hurt their wordpress.com business and if somebody comes up with a good static generation option will just turn into another SaaS offering.
Not the GP, but I'm guessing they prefer static sites simply because they are much more difficult to hack or compromise in some way. There's no database to defend from injection attacks, etc.
Yes. Of course. Most of the problems with Wordpress websites are because of bugs in programs written in PHP. When you no longer serve PHP and are just serving a bunch of HTML/CSS files then there is nothing left to hack. (unless you want to target the webserver [such as Apache, etc.) but 9/10 times it is some sort of an outdated software or just some previously unknown bug in some plugin. Less attack surface, more peace of mind.
124 comments
[ 3.7 ms ] story [ 383 ms ] threadThat said I wonder why you’d need Github Pages if you’re already set up with Wordpress...
That said, I personally would rather write in markdown or asciidoc and there are a ton of great static site generators for alternatives to Jekyll.
Maybe there's something I don't understand here? Wordpress.org isn't hosted, it's just the website software itself. Hence the need for Github Pages (although most people just use a hosting provider like Siteground).
https://laragon.org/
It needs more love.
Confused why the poster wanted to use GitHub pages. Sounds like a hassle considering hosting with Wordpress.com you point your domain too. ️
It is a Mac app though.
I wanted to use Github Pages because I had my previous site on Github Pages. GH Pages was easy to setup and provided good hosting/serving for free. I wanted the same for my new Wordpress site and naively thought I could make it work.
This is what happened to me when I thought it would be a good idea to build my own blog software.
These days I'm a believer in using whatever setup minimizes the daylight between wanting to write, and writing.
I ended up using Hugo hosted on AWS Amplify and CodeCommit: https://gohugo.io/hosting-and-deployment/hosting-on-aws-ampl...
This allows me to do plenty of things. There are no servers to manage, and I write my posts with vim and use Markdown. I have a simple theme. Deployment and testing happens automatically through Amplify.
If I really, really, absolutely must, I can dig deeper into Hugo and do whatever I want. But if I just want to stick to the basics, I write files in the content folder and edit the settings file the first time. That's it!
And because it's in AWS, I can use cert manager and Route53, things I already know from work, to put my domain on it.
This was a lot easier for me than anything else. I previously used Ghost hosted on a Digital Ocean instance, but I quickly grew tired of having to update Ghost, dealing with node, etc. Plus having to worry about securing the site and the instance. Patching the instance. Backups.
A lot of the updates I am missing seem to be simple bug fixes.
No matter your setup, writing in markdown is the fastest way to get your ideas/thoughts to a presentable format. That should work in all good CMS/blog/static/dynamic software.
The markdown can have associated markdown settings that are either in a comment at the top or a sidecar file that can be adjusted to any platform.
Whenever I write I do it in markdown, get the thoughts out, clean it up, add presentation. Then I know there is no lock-in or ownership of the content to any system.
If you do change systems there may be some initial settings/markup/declarative hooks you need for things like embeds/code highlighting etc, but after that you are rolling.
Standards whether specified or market standards, always help you evade lock-in and can make your content a free agent when needed.
Software today is a mine field of lock-in created by large entities that want you to develop in an abstracted layer above the simple standards, even at the programming level we have lost focus of shared standards that give you platform freedom.
It helps that my hobby is retrocomputing, so my plain HTML pages can actually be loaded on a 25 year old version of Netscape. Doing my writing on an old PowerBook running System 7.5 also helps cut out distractions, and being a bit of a novelty makes the writing fun instead of a chore.
Without wishing to be too snarky, this could be rewritten as "Running this software is a nightmare if you know nothing about the technologies it is built on." And being slightly more snarky, my response would be: well, duh.
Running WordPress on macOS is slightly different from running WordPress on Ubuntu, which is different from running it on CentOS.
I maintain WordPress sites on all three. None of them are inferior to the other for this purpose. They just have different conventions.
In fact, I've had far fewer problems running multiple WordPress installations on macOS than I have on CentOS. But that's because I understand Apache better than the author of this article. Pretty much the only problem comes during a major OS upgrade when the installed backs up some of your configuration files and replaces them with the default. But once you deal with it one or two times, you know what to do.
[1] https://bitnami.com/stack/wordpress/virtual-machine
[2] https://localwp.com/
I don't feel like that I understand the underlying tech, but as long as you know how to install WordPress, you can install WordPress.
For my purposes (set up a simple blog and get it running), I truly don't think that I need, or should, have to learn the ins and outs of the tech stack. In fact I chose WordPress specifically _because_ I wanted it to abstract most of the implementation details away from me.
I don't think this is true for development generally.
Well ... if you want a simple blog, then you can setup an account with the 10million hosted blogging services that are out there. And if you want a wordpress blog, then you can set up an account with wordpress.com, or get a hosted solution with Wordpress/LAMP already preinstalled, or get a VM with Wordpress pre-configured (e.g. Vagrant Box with Wordpress: https://themeisle.com/blog/vagrant-wordpress/).
What you wanted however, was a locally hosted Wordpress (why?) that you installed and configured (on Windows no less). That's fine, but Wordpress requires PHP, and requires a web-server, and requires a database - so you'll have to be able to understand what all those pieces are in order to install and configure them together.
>In fact I chose WordPress specifically _because_ I wanted it to abstract most of the implementation details away from me.
Which it does. There is a difference between being a user of Wordpress and installing and administrating Wordpress. For the former, understanding the tech stack is not required. The UI is meant to be used by non-tech savvy people. For the latter, yeah, you need to be familiar with the tech stack. That you're not, and you had some trouble installing it, that's not the fault of Wordpress.
The people who want a "writing first" experience _with Wordpress specifically_ have many paid hosting providers to choose from, but that would defeat the purpose of the article.
Making a one-click installation process would also take a significant amount of dev resources to handle all the different platforms and require expertise that isn't required for the main product, given that it is a PHP project which is almost entirely cross platform by default.
Well, Wordpress can know auto-update the plugins...
And your site (Or some parts of your site) could break at any point in time without your knowledge and remain broken for a long time until you find that it’s broken. There is no platform that doesn’t require “babysitting” with maintenance and testing.
You still need to check on them, sure.
>and remain broken for a long time until you find that it’s broken
Well, if you don't find out that it's broken fast enough, perhaps you don't need it anyway!
Wordpress plugins are notoriously bad at input sanitization. Even many large, commercially supported plugins get abandoned or simply aren’t secure.
I don't think so. The author actually gave themselves a weird goal - to use Wordpress as the text editor, and export/copy the static content to github. I'm not sure why they would do that, but OK! In the end, their problem wasn't with the workflow but with setting up local version of Wordpress (why? why not use a hosted version of Wordpress????), PHP, Apache, MySQL and FTP(!!).
WordPress isn't actually that hard to setup. It's a little harder on Windows, because setting up PHP on Windows just isn't as natural as on Linux but XAMPP makes it as easy as possible.
>Should 'blog writing' software really have such a greater barrier of entry?
But it doesn't. You have a plethora of (free) hosted blogging solutions. You could also get private hosting with the LAMP stack already pre-installed and configured.
You can accomplish this by using a CDN that caches everything, or use plugins that export static files like WP2Static, or use integrations with static site frameworks like Gatsby that treat WP as a CMS.
But yes, doing it all from scratch yourself is probably not worth it, especially if you're unfamiliar with the tech.
Sure - why not. The question, why do you need to host it locally? You can just create a free account on wordpress.com, or get a private hosted solution for peanuts and with the LAMP stack already configured.
For context my wife uses wordpress to build various sites. I got lumped with the task of moving this online. It was super painful, as WP encodes the URL name (i.e. localhost) flipping everywhere.
I eventually resolved this by editing the tables which stored the URLS (fortunately, as a DS I know SQL) and doing some sed on various files that cached the URL.
I now refuse to do this, and set her up online with a website before she does any work, because moving it is so painful.
I did try the obvious things first, to be fair.
Another way is to perform the find and replace with PhpMyAdmin.
It appeared to work a few times (or at least my wife/her customers didn't complain).
offline editing?
It doesn't.
You can open an account on Wordpress.org and be writing your blog in 1 minute.
You can use your virtual hosting's manager to install Wordpress and be running in 10 minutes.
You can download MAMP or WAMP (packaged Wordpress + MySQL + Apache + PHP) and be running locally in 15 minutes.
This guy wanted to do an install locally manually, patch it to produce static pages (which is not what it was made for0, hook it up with GitHub pages, and so on. And all that without bothering to know how.
The fact that each moving part wp needds is tricky in its own way doesn't make the experience better if you are encountering them for the first time :)
The author was probably not aware how complicated set of dependencies (moving parts) wordpress needs compared to jekyll. Which is fair if from the outside the two seem to be products in the same category.
In fact, myself and a few others have spent some time improving the local environment situation with a tool called wp-env [1]. So long as you have docker & node installed, you can install wp-env with npm. Then you can just use “wp-env start” to get a local WordPress instance running. It’s fairly straightforward to configure for basic needs too! No need to understand Apache, SQL, FTP, or even PHP to get it running.
All this to say: there are open source solutions to the local dev environment problem even being developed and supported by core WordPress teams. :)
1: https://make.wordpress.org/core/2020/03/03/wp-env-simple-loc...
These days there are a lot of better CMS options for JS single page applications.
> The semantics seem rather fuzzy. If id is a WP_User or other object, or an array of properties, it seems to clone it without touching the cache. Otherwise if id is a number it seems to try to read it possibly from the cache, or from the database using ->get_data_by(), which can also update the cache. If id is empty it reads by login name.
I realized that if even the offical documentation didn’t know what Wordpress was doing, I definitely had no hope.
[0] https://codex.wordpress.org/Class_Reference/WP_User
-The plug-in APIs have been largely written by accretion, making them confusing and hard to grok. I always vaguely feel like I’m doing something wrong, that this shouldn’t be this difficult... Furthermore, API functions are inconsistently named, and return hard-to-predict datatypes.
- The theme tools are similarly confusing, and can make simple tasks take a lot of time. Sure, you just have to create magicfilename.php/css and put this magic snippet into it - but the discoverability in that is pretty garbage and results in a lot of hacks that solve things in the wrong way.
- Using other people’s plugins was a crapshoot, as plugin conflicts were (are?) pretty common. For a casual user plugins are a massive footgun, as WP makes it easy to install decade-old unmaintained junk plugins full of security holes.
Compare all of this to Drupal, which while far from perfect actually tries to design sane APIs and solid code, and iterates on it to correct their mistakes.
Wordpress is a workhorse on the web, but it is a complex, inconsistent mess full of weird edge cases. It is much harder to introspect, debug and reason about than it should be. You need tons of specific, specialized knowledge to interact with it as a developer.
The reason for that seems to be this: it is built with people in mind who cannot code, but the reality is that for many cases this doesn’t suffice, so you end up with a hodgepodge.
I'm also a huge fan of WebFlow, especially for people that have some basic knowledge of CSS or really just want to tinker with every paragraph :)
I mostly just wanted a better writing experience and CMS. (I talk about that in a section on the post).
The thing “they don’t tell you” about static site generators is that you should vendor your site theme. Don’t expect to both get upstream updates and make HTML level changes.
Hell, I'd be happy with a decent theme library that actually gets tested and regularly updated.
That being said, deploying WordPress takes minutes. And running it locally as well. Docker images are available if installing hundreds of libraries isn't your thing.
You might not be able to find it as a plugin, the author made a deliberate decision to delist the plugin from wordpress.org https://staticword.press/t/removal-of-wp2static-from-wordpre...
It's a roundabout way to publish to a web site to say the least. If Jekyll has enough issues where you need to tweak its config in Ruby every time you want to write, you could try a different static site generator (e.g. Hugo for golang, or Miner [1] for Svelte. Disclaimer: I worked on Miner.).
I think the product you're looking for is a static site generator + the use of a client-only WYSIWYG markdown editor that connects to your git repo via OAuth and lets you write on a good UI instead of plain text markdown files. The SSG is one of above; unfortunately I don't have a recommendation or know of a client-only WYSIWYG MD editor with git OAuth integration.
1: https://github.com/bigicoin/miner
Thanks for recommending Miner! Checking it out right now.
Then you have no business being a developer
https://news.ycombinator.com/newsguidelines.html
In modern software, it's unreasonable to understand the entire system that you're developing for. It especially doesn't make sense in a business sense...
A carpenter doesn't try to build a chair without understanding how both a saw and a measuring tape work. People who want to build a chair with a saw and a surveying rig are probably better off going to a chair store.
It seems that the author overestimated his technical abilities, and blames the tools he chose, rather than himself for choosing those tools.
But no, static site generator plus headless CMS is not the answer, regardless of how many comments here enthusiastically say so.
I’ve been down the static site generator rabbit hole for the past 7 years...and realized they aren’t really well suited for anything other than tiny developer blogs that don’t ever get updated (dev writes his occasional post in VScode)—-or, giant company marketing sites that get hooked up to enterprise-y headless CMS products like contentful.
If you’re somewhere in between, I’m starting to think Webflow is the answer. In fact, I’ve started moving all my side project marketing sites/blogs over to them and couldn’t be happier.
The problem with [insert static site generator] + [insert headless CMS] is that getting off the ground is a massive pain in the ass.
If you’re trying to set up a static site for your side project, let me give you a preview of what your next couple of weeks will look like:
First you have to pick a SSG. There goes a day of research. Then pick the next hot CSS framework (of course, you shouldn’t waste your time on this, but you will). Tailwind! Sick! Then setup a build process. Then troubleshoot the inevitable issues. Fixed. Then setup a git repo. Then hook the repo up to Netlify. Then hook up continuous deployment. Then get the domain. Then configure the domain to talk to Netlify. Then realize your hot new SSG doesn’t do any SEO stuff for you. Setup xml sitemaps. Generate proper tags & structured data. Then you have to create the actual site. Realize your CSS framework is overkill. You’re already a week in. Optimize for breakpoints. Cool. Almost ready. Now let’s write some content. Shit, I’m never going to write if I have to fire up my code editor each time. Look into headless CMS options. There goes a day of research. Pick one. Now Setup models in the CMS. Try to figure out how to hook it into your git repo and trigger deployments to Netlify. Realize the UI of the headless CMS you picked is clunky. Never actually write any content. Forget how you even set everything up. Get frustrated. You haven’t even hooked up any analytics or email signup capability yet. Give up.
On Webflow I’ve managed to cut the previous paragraph down by about 80%.
I run a couple of Jekyll sites, with Directus as my headless CMS, and my experience is pretty much the same as writing posts for a Wordpress site. I wrote the post in a simple editor, save it, and manually trigger a deployment on Netlify. Even the deployment can be automated if I were to set up some simple build hooks.
There are a view downsides and limitations, but nothing I can't live without. And it actually helps me keep everything as simple as possible.
This is the most important part. I edit my site by typing in a WYSIWYG editor and hitting the save button. It works on any Internet-connected computer I can get my hands on, without installing any software.
> But no, static site generator plus headless CMS is not the answer, regardless of how many comments here enthusiastically say so.
> I’ve been down the static site generator rabbit hole for the past 7 years...and realized they aren’t really well suited for anything other than tiny developer blogs that don’t ever get updated (dev writes his occasional post in VScode)—-or, giant company marketing sites that get hooked up to enterprise-y headless CMS products like contentful.
> If you’re somewhere in between, I’m starting to think Webflow is the answer. In fact, I’ve started moving all my side project marketing sites/blogs over to them and couldn’t be happier.
> The problem with [insert static site generator] + [insert headless CMS] is that getting off the ground is a massive pain in the ass.
> If you’re trying to set up a static site for your side project, let me give you a preview of what your next couple of weeks will look like:
> First you have to pick a SSG. There goes a day of research. Then pick the next hot CSS framework (of course, you shouldn’t waste your time on this, but you will). Tailwind! Sick! Then setup a build process. Then troubleshoot the inevitable issues. Fixed. Then setup a git repo. Then hook the repo up to Netlify. Then hook up continuous deployment. Then get the domain. Then configure the domain to talk to Netlify. Then realize your hot new SSG doesn’t do any SEO stuff for you. Setup xml sitemaps. Generate proper tags & structured data. Then you have to create the actual site. Realize your CSS framework is overkill. You’re already a week in. Optimize for breakpoints. Cool. Almost ready. Now let’s write some content. Shit, I’m never going to write if I have to fire up my code editor each time. Look into headless CMS options. There goes a day of research. Pick one. Now Setup models in the CMS. Try to figure out how to hook it into your git repo and trigger deployments to Netlify. Realize the UI of the headless CMS you picked is clunky. Never actually write any content. Forget how you even set everything up. Get frustrated. You haven’t even hooked up any analytics or email signup capability yet. Give up.
> On Webflow I’ve managed to cut the previous paragraph down by about 80%.
I'm sure Webflow is a delight to use, but some 20 dollars a month is an insane amount to pay if you run several projects that might or might not be profitable.
I'm already paying some something like 12 dollars a month for domains on average and 10 dollars for a small web server which adds quickly up. If I had to run all the projects on something not-self-managed, we'd be talking about hundreds every month.
I used to have this mentality as well. Do everything for free, use open source, self-host everything--the classic frugal hacker mindset.
Then I realized that I was spending 80+ hours tinkering around with static sites and different headless CMS option and had done absolutely none of the actual work required to bring people to my sites (which is the more important work).
When I take small freelance gigs I charge roughly $100/hr. That means I spent $8,000 of my own time on tinkering around with what was essentially bullshit.
Forcing myself to pay for SaaS tools has been amazing at focusing my attention. It's a perfect signal for what I should be working on.
If I don't feel confident investing $20/month in a site for my project, why the hell is anybody going to feel confident paying that or more for what I'm creating?
It's forced me to kill what's not worth my time, and focus on what actually has the real potential.
FWIW, being able to write through my code editor in markdown is what got me to start writing
It'd be amazing to have something that let's you open a desktop app, have WordPress with all (or most of) its themes and ease and plug-ins for blogging, deploy changes to a git repo, and from there to a host -- in a way where you don't need to know more than how to make an account on say Github and Netlify.
Maybe there already is something like that, I'd love to know if so!
[0]: https://getpublii.com/
Is the root of all this the fact that github offers free hosting through github pages ?
PS, author, if you see this, make sure to use a child theme or custom plugin to make code changes. Otherwise a security update (which are usually automatic these days) will wipe out your custom changes.
Running "ls" can be a nighmare too if you know nothing about filesystems, files, file types, flags, manpages, and so on.
By the way, I recently migrated a weblog from Wordpress to Hugo on Netlifly. It was easy! Just add a post in GitHub and it automatically triggers a build in Netlifly and the post is live in seconds! You can also have your own custom domain for free.
Don’t have recent experience with Jekyll but can’t imagine it being that painful with the build/customization.
So I guess Automattic will not solve it as it would hurt their wordpress.com business and if somebody comes up with a good static generation option will just turn into another SaaS offering.
Theme options leave something to be desired, though.