"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 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.
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.
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. :)
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.
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.
> 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.
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.
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.
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%.
> 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.
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
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.
> 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.
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.
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.
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 :)
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.
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.
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.
> 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.
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.
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/
> 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.
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].
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...
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.
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).
>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.
My background: I’m a technical person who can get around Unix/Linux, work with file permissions, shell, databases, etc., comfortably. Yet, I have to agree with the author and her observations, especially after my trials on macOS.
> Here’s what I know now: running WordPress locally is a nightmare. Successfully figuring it out was way harder than it should have been.
I tried XAMPP recently after a long, long time (this is on Mac). After the initial steps of creating a database (not a problem for me), the database users and modifying wp-config.php, I faced all the errors the author writes about and more, and had to search online for solutions. Updating WordPress core fails due to permission issues. Cannot install plugins or themes from the dashboard because of permission issues. Heck, even uploading media files, like photos for example, for a WordPress post requires permissions to be handled. Even the location where the site is stored has to be mounted first if you’d like to explore, modify files, etc. Don’t even get me started on the black box that is ProFTPD to configure FTP access to the site (neither the ProFTPD site nor the StackExchange Q&A sites were very helpful)!
All this would be forgivable if the documentation was adequate. But I found the XAMPP site’s documentation to be really thin and sparse. One would think that the most popular blogging engine (WordPress) would be included in the documentation. But no, they just wash their hands of by pointing to Bitnami for installing apps, and that didn’t work for me either.
I can understand the XAMPP team focusing only on the basics, but the project has been around for a very long time and should cater to what most users may be using it for.
I recall that XAMPP (and the Bitnami stack) used to be easier to work with. Or maybe my memory of it isn’t good enough.
I also tried MAMP and gave up within minutes (forget about the free trial of MAMP Pro and upgrading to it).
All in all, XAMPP was a total disappointment and a very frustrating experience. I can only deeply empathize with the author who doesn’t seem to have as much exposure to dealing with systems at a lower level as I’ve had.
Right now, I would discourage anyone from trying XAMPP and MAMP (both on Mac; I don’t know if they’re vastly better on Windows or Linux). Just go with an online host with a good control panel and stop wasting your time.
For Windows folks, now that Window 10 WSL2 has been released, running Wordpress locally in something like Ubuntu seems like a better way to go.
I find the drawbacks to WSL2 is that (1) there's no one-click GUI that will install Ubuntu + Wordpress; console commands are still required. It's still a virtual container, so network/file access isn't directly accessible like you get with XAMPP. There was an issue where webservers hosted inside WSL2 were not available on localhost, but that looks to be resolved and should hopefully be available to everyone soon: https://github.com/microsoft/WSL/issues/5298
You could also install Docker inside WSL2 and run a WordPress image. However, wrapping your head around Docker poses its own challenges. Tutorials for Docker + Windows aren't really up to speed with WSL2 and troubleshooting often gives out-of-date advice. For instance PHPStorm Wordpress + Docker tutorials have files mounts from Windows into the container, which gives poor performance. However, I did have luck getting WordPress up and running on my local machine in Docker following this guide: https://www.singularaspect.com/phpstorm-using-xdebug-for-wor...
This is not a wordpress issue and I think it’s unfair to put your problems at its door. The issues you encountered would affect you with any PHP/MySQL application if you chose to run the setup as you have. The optimum solution that I’ve found is Laravel Valet and SequelPro (Both free); valet is your server and SequelPro is your GUI for MySQL. Everything should “just work”.
The problem most likely stems from the fact that Wordpress tutorials are a very competitive space (ads) due to the widespread adoption of the platform, but many are either (a) not very good or (b) out of date. If you follow one that says to use xampp or similar then you will have an experience similar to your own. If you find one that says “use docker” you will have a needlessly complex experience. Tutorials like this should focus on the simplest way to execute something, but are too often written by inexperienced devs or worse, rehashed from other tutorials by marketeers looking to produce SEO friendly content (efficacy of advice be damned).
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.
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.
As someone who works with WordPress every day, I can see both sides of the issue here.
Could it be easier to set up and run locally? Sure. Could it be easier to customize without knowing any code? Sure. But also, getting a dynamic CMS like WordPress to produce static output for use on GitHub Pages is a sort of "square peg, round hole" situation, and it's not surprising that the author ran into some issues.
For running WordPress locally without mucking around with PHP, MySQL, and such, what you probably want is Local [1], which installs everything you need all in one go, and is quite user-friendly. You can spin up local sites in minutes, install whatever plugins you want, and go to town. (If you host with the company that makes Local, you can even deploy to live from inside the app.)
I haven't used any of the plugins designed to make static pages from WordPress, but my gut read is that they probably aren't going to work quite right unless you A) really know what you're doing with WP, and B) you understand the limitations of your chosen static code generation tool. After all, WordPress is meant to be run in a dynamic environment with PHP, MySQL, and a web server. Shoehorning it into some other way of working might not end well, especially if you are new to WordPress.
Anyway, it looks like the author wound up on SiteGround, which as basic shared hosts go is one of the better ones. :) It'll certainly be easier than running WP locally, generating static files, and deploying those to 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.
I recently started working on my own portfolio site, and I wanted to include a blog. I considered Wordpress to be way too overkill for what I needed, plus I wanted to write my own theme. Plenty of flat-file CMS software options exist, which would probably be more like what the writer needs.
Many here mention Publii which perplexed me when I saw it (a desktop app posing as a CMS which is just an SSG) but I guess the writer would actually be the perfect target audience for that.
I recently settled on Bludit since the web admin is very quick to get writing and still takes care of all the extra meta tags and fields without getting in the way of the writing, which is easy enough that I've installed it for some websites where non-tech people are using it just fine. Totally lamenting the lack of templating language but I've been managing.
It's very odd that blog software for the layman tends to require so much setup and flat file CMS software are approximating but not quite achieving a dead simple setup and usage.
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).
The installation documentation has good instructions on how to setup Wordpress. We use chassis (https://beta.chassis.io) to run And develop it locally. If you’re looking to develop your own theme or plug-in it’s worth checking out.
That said creating static sites is not a common use case so the author is finding out its not super easy. Prior to installation warnings are shown for out of date plugins, so she is unfortunate to have skipped them.
Setup an author user then you don’t have to worry about the administrative screens that might be confusing.
I’d suggest to give it another go as it’s worth being self hosted and being in control of your own setup, if you’re interested in learning about PHP and WordPress.
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.
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.
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.
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 ?
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.
FWIW I've used Typepad for my blog since 2004. I may be the only person in the world still using it, since it's never ever mentioned as a WordPress alternative.
>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.
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...
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.