I wish there was something like this, but for serial dynamic content, like blog posts, reviews, etc. People are really attached to WP, but customization and themes are a nightmare.
I think people are attached to Wordpress for the same reason we are attached to Javascript. At the time, it was one of the only ways of easily creating a blog.
The problem with Wordpress is that once you need to do something outside of the norm then all of the sudden you need deep knowledge of Wordpress's inner workings.
There was never a time when WordPress was the only easy way for even a non-technical person to create a blog, they just did a great job marketing that that was the case.
I spent a very brief time as a contributor to WP internals (not core by any means but a handful of contributions) and not only do you need a lot of internal knowledge to do anything outside of point-and-click, like you said, a lot of the core folks had never worked on any other large software projects, didn't do anything outside of WordPress, and had very little desire to make sure what they were doing was sound from a software engineering / code quality standpoint. It's a pretty great example of the big ball of mud / spaghetti code cliche.
Ok I will bite. What was an alternative to WordPress especially back then that actually was as easy to use as WP AND had the ecosystem of plugins that WP has. Focus on non technical users only who have no idea how to write code.
You're correct. Alternatives were slim. But in retrospect, perhaps that was part of the problem? WP had zero incentive for clean code, QA, industry standards, etc. The more it grew, ironically the less it cared. The embedded base of site and dev as well as the plugin and theme ecosystem maintain the momentum forward, somehow.
I don't think it was even the marketing but the product placement. I remember in the 2000s if you wanted hosting that wasn't a dedicated server, the scene was dominated almost entirely by CPanel with a one click installer for Wordpress.
Once the plugin ecosystem sprung up around it, WP was off to the races.
Definitely possible in the future, although to keep the project focused I'd imagine using a plugin or fetching that content from a separate CMS tailor-made for that kind of content would be ideal.
It's not really static. It grabs data from a database, or an API, and renders using entity-specific templates, both from a single entity perspective (post.php theme) and listing (search.php, index.php).
What I mean is: having something like Primo that allows visual management of such dynamic blocks and themes would be nice, so Editors can just play around with the result of their content calls (which the CMS handles transparently, doesn't matter if a SQL query or an API call).
That is static - none of it is based on user input so it can be compiled into a static HTML page every time you publish a new post or edit a page theme or anything. There's no reason the system needs to pull that 5 year old blog post from the database every time.
That depends on the desired features. E.g. if you have a tag cloud displayed in the sidebar on each page, author list, etc., any change to any post could potentially mean all pages have to be rebuilt. Or if you have different ways to display items (full, thumbnail), different ways of sorting them, and maybe even variable pagination (i.e. "show me page 7 with 15 items per page"), and it can very easily become unfeasible to statically generate all possible permutations. In the context of "systems that allow newbies to get results" this may not be as important, even there you might want to have little neat things like displaying relative dates. Dynamic doesn't have to mean user input, it just means dynamic. And then there's search, in case you want/need to handle that yourself.
A probably very naive solution to that I came up with and experimented with is keeping track of all things that go into a page, and tag the cache of it with them, so I could invalidate all cached items that refer to a thing that was just changed (where that thing can be anything, a tag, the site title, whatever), but I ended up scrapping in favor of caching everything for 1 hour no questions asked, because it was just total overkill for my use case.
How is it not user input? Editor can opt to show whatever in his list, playing with the external source filters: most visited, or last published, or less visited.
Once the editor is done with his work, if you want to compile a bunch of HTML/CSS and push to Netlify, that's fine. But his interaction with the CMS is not static at all.