I was a Drupal dev for ~10 years. Once upon a time, I built many sites with it, and I recommended it to many folks. Despite its flaws (and it always had flaws), it was a great piece of software in its heyday, and it had (and still has?) an amazing community.
I'd still choose it over WordPress any day. But the days when I'd recommend either of them (or indeed anything in PHP) are long gone. Your best bet now is probably a static site generator such as Hugo. If you insist on staying in database-driven CMS land, at least go with Django or Rails.
Hugo metadata allows to define a publication date for content. Then you need to run the Hugo build periodically to have the content published.
The hugo cli has options to build "drafts" and "futures" so that you can preview them.
I have used Hugo in the past to generate websites from external content sources, such as trello, gitlab, GitHub, RSS feeds, Dropbox, headless CMSes, etc. Some of them provided webhooks to trigger the build, others required polling and periodic rebuild, yet others can commit to a git repo and trigger a CI pipeline. Most of the time, hugo was more of a composable solution to a given flow than a constraint i had to build around thanks to its capabilities to use "data content" and not only markdown files. Using json as the metadata "front matter" for documents often proved very handy when using API sources.
Hugo is very fast, so build time wasn’t a big concern. There was no incremental build however, so for a very large corpus it could be an issue. The most problematic issue is that Hugo doesn’t ever delete anything from a previous build, but overwrites on top, so that could be problematic if you involuntarily publish something and then want it off. The same kind of issues you get into with caching or object storage. My "solution" was the classic parallel builds, symlink and cleanup dance.
Just wanted to add that I use Hugo in combination with a super simple CI/CD pipeline, and I just rsync the public/ directory every time the pipeline runs with the delete option enabled. This makes it relatively trivial to delete content after the fact, because I can just delete the content from the repository and have the pipeline remove it.
There is nothing wrong with Wordpress and the LAMP stack. It’s fine for many great use cases. It powers, and will continue to power many of the biggest sites in the world.
Static sites are a tradeoff, and you’re often dealing with other messes especially with non-technical users.
The problem isn't LAMP, the problem is wordpress. It stores state that should be in files in the database, and state that should be in the database in files, so they are tightly coupled, and you have to snapshot both at the same time.
It's also a security nightmare and runs dynamic code on every page load by default, so a fresh wordpress install in its default state will fall over when on HN on Reddit or Slashdot, unless you install third party caching plugins to avoid that.
The vast majority of those people contract out the (complicated) maintenance in keeping it secure and performant, or they get hacked and their site goes down, or they get ~no traffic so performance doesn't matter and neither does their choice of blog software.
Entire large businesses (WPEngine, for example) have been built upon the overhead costs from blog operators having to compensate for it being a bad app.
My close friend is one of the sysadmins for the WP instance mentioned in TFA. Pull back the curtain and it's pretty ugly and resource-intensive to run WP at scale; I've done it myself.
The only problem not addressed is that the browser directly interfaces with code that has access to the database and host computer. A static site generator is leagues more secure since you can lock anything that touches the database/CMS content behind multiple layers of authentication and 2fa, significantly reducing the attack surface.
Come off it. Much as I prefer Ruby and Python the CMS domain is dominated by PHP and ASP.Net. Whilst there are Rails and Django-based CMSes their combined adoption is a drop in the ocean compared with Drupal alone, never mind Wordpress.
Agreed. I love Drupal, and hate WordPress. It seems like Drupal module developers are more interested in solving trivial problems so they can focus on the bigger ones, while WordPress plugin developers are more interested in making a buck with a trivial solution.
The problem is finding people who actually know how to use it. It's great, but it takes years to learn properly. Before that it can be frustrating as hell.
It seems easy enough at first, like you can just use whatever contributed modules you need, but that only works on simple sites (like the same ones Wordpress is great for). To use Drupal well, you have to actually know the APIs and write your own custom modules, otherwise the site becomes a buggy resource hog.
I like Drupal, I have multiple 8/9 sites I still run and I've used it since 6, but there's some pretty good reasons not to use it.
I haven't used Drupal since Drupal 7, but I really liked the Fields API. Drupal felt like it had more built in that WP should have built in but didn't. I believe Drupal 8 went with a templating language as well. That's something else I wish WordPress would adopt.
Strongly disagree. Drupal is a great CMS and there's a reason the government uses it so extensively.