-
I think the comparison is flawed. Static Sites are just a frontend, and you could generate a static site from WordPress if you wanted to…
CMS on the other hand are content management system and are basically a backend for people to manage the content.
Many CMS propose a frontend, which is not static, but you have other CMS types called headless, or API first CMS that make wonderful backend for static websites.
The headless work great on the web, as backend for apps, pwa, web apps, etc. And itegrate with everything, chatbot, TV, whatever.
-
CMSs that use dynamic code in the frontend tend to rely on that functionality. Maybe not the core product but many of the plugins needed do.
Static Sites are just a frontend, and you could generate a static site from WordPress if you wanted to…
You don’t want to do that believe me! I had to implement exactly this a few months ago. The pain of having to manually figure out which files were missed by the export plugin to manually add them is big. Trying to teach people that most plugins won’t work because code will not be executed for each request seems to be in vain. They happily install whatever might solve their problem and then complain that stuff isn’t working as expected on the static version. Forcing me to try to implement that functionality on the webserver level should that be even possible.
-
I would of course not use WordPress as backend for my static site… But there are many excellent headless that you can use for that. Strapi, CloudCMS, Contentfull, Kentico cloud, etc.
I personally use Cloud CMS.
I agree that if your users are use to WordPress, and that they have freedom to add plugins etc, that is not a viable solution. What I meant with my comment is that a static site is your frontend, a CMS is where you maintain content, or where you are supposed to maintain content.
But CMS have grown to become monsters that supposedly do everything… Like shops etc.
What I advocate in the company I work for is “content as a micro service” where your CMS is used only to create and manage content and not to manage the design, the shop, etc.
This is a little outdated and does not reflect exactly where I am with this thinking, but it is nevertheless the underlying idea : https://jboye.com/2017/06/27/the-making-of-ers-2-0/
-
-
-
-
At home on a FreeBSD server:
- Gitolite (for my private repositories)
- Samba (exposing ZFS volumes to my Windows clients with ZFS snapshots exposed as “previous versions”)
On a KVM VPS running FreeBSD:
- Nextcloud (in a Jail)
- NGINX running my personal blog / website (Hugo) and proxy the Nextcloud installation
I am currently reading the Git Pro book hosted on git-scm.com. It is freely availble as ebook in many formats.
Having read about 1/3 so far I can really recommend it. It is well written and even after using git for years there is plenty of stuff to learn from it. Might it be internals that will become clearer or different aproaches on how to use it.
I think you meant “Pro Git”. :) (I agree, it’s worth reading.)
Yeah I botched that one up, thanks for the correction. :)
The “Git Internals” chapter is pretty eye opening. While not strictly necessary for using git I found understanding how the underlying content addressable store fits into how a repo is put together helps to pull away nearly all the magic.