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 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.
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 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.
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...
Well, Wordpress can know auto-update the plugins...
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 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.
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 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.
-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.
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%.
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.
FWIW, being able to write through my code editor in markdown is what got me to start writing
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.
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.
That said I wonder why you’d need Github Pages if you’re already set up with Wordpress...
It needs more love.
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).
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.
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.
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.
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.
Confused why the poster wanted to use GitHub pages. Sounds like a hassle considering hosting with Wordpress.com you point your domain too. ️
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.
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.
> 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.
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...
I mostly just wanted a better writing experience and CMS. (I talk about that in a section on the post).
Then you have no business being a developer
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...
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.
Thanks for recommending Miner! Checking it out right now.
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...
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.
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!
These days there are a lot of better CMS options for JS single page applications.
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.
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).
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.
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.
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.
Theme options leave something to be desired, though.
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.
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.
Is the root of all this the fact that github offers free hosting through github pages ?
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.
