File-Based CMS and Hugo as Static Site Generator

I love static site generators, especially Hugo, but I also need a way for non-technical editors to create content.

I wanted to post a long comment of a plan how the best aspects of static site generators and file-based CMS could be combined. Unfortunately, the forum doesn’t trust me enough to add more than two links and images… So, I extended it a bit and created a blog post on my website, instead:

Making Content Editors and Web Developers Happy Again

I would really love your opinion on this. I mention Hugo as my tool of choice but have a few wished for Hugo (that are on the roadmap anyways). See the section about My Wishlist for Hugo in the article above. Here is a summary:

Allow content with non-MD extensions: I describe a way to use complex content that has multiple Markdown sections per file (with TOML). This is already possible with Hugo. But, the .md extension doesn’t really make sense if the content file only contains TOML. When issue #147 will be fixed, Non-MD files will be accepted in the content folder. We would need to make sure that the .toml files would also be processed like .md files.

Assets in the content directory: I’m desperately waiting for Issue #147 to be fixed. This would allow us to place content like images next to the MD/TOML file. I would love to have a subfolder for each page that bundles all assets for a page together! This would greatly simplify things for a Static CMS.

Dynamic image resizing: Ideally, the content editor would not need to worry about the image sizes but would just upload it to the content folder. Hugo would then pick up the image and resize it, based on the size defined in the template. We would need to figure out a good place for the resized images to be stored so that they don’t need to be recreated every time.

Web-Based CMS: An interactive web-based editor for Hugo is already beeing discussed and is on the Hugo Roadmap. I don’t know, however, if it is such a good idea to include this in Hugo. I think it would be better to keep the CMS and website generation separate.


We’re not that far away from an awesome way to build websites, IMO. The biggest part will be to create or adapt a File-Based CMS. I think that Hugo should continue to be awesome at it’s core task: generating static websites. There are only two features needed in Hugo: Allowing .toml instead of .md files for content (which is more of a cosmetic thing) and better image/asset handling.

What do you think?

4 Likes

+1 for articulating “Static CMS”.

I hope not :slight_smile:

Seems we need something between a Static CMS and a Flat File CMS (which are still fully dynamic, just using the filesystem for storage). Essentially, a Hugo that instead of reading and writing (dynamically), just rebuilds the static site (statically, but seemingly dynamically).

WRT to assets in the content directory: i still think supporting Textbundle/Textpack is the way to go.

@Middling Interesting. I’ve never heard of it.

Do you suggest that Hugo should support such Textbundles in the Content directory? If yes, maybe your suggestion could be discussed in the feature request for Non-MD files in the content directory.

Very interesting! I read your blog post about 2 days ago, before I read your post here.

I had for some time been thinking about creating an untraditional CMS that primary will use directories and files instead of a database as storage. I was also thinking it could be possible to do it also with very large websites.

Some of my implementation ideas is to read-only mmap files, so the kernel reads the files and not a hugo CMS. That will make it possible to use much more data, than there are available RAM for.
This blog post is a really good read: So what’s wrong with 1975 programming ? - I personally learned that I should change programming style from that FreeBSD kernel developer.

hugoshm - is a hugo that uses shared memory (SHM). Shared memory is really fast, and I think it is possible that hugoshm would be at least an order of magnitude faster than hugo. I think that kind of performance is possible, if hugoshm only works on changes/new content, and uses cache files which are already parsed files. All files (cache files and not cache files) are mmap’ed into shared memory by hugobuild. If fx. navigation is changed, then hugoshm writes a new cache file to disk, and then concatenates everything in the correct sequence from cached files to create a changed file. Note that the cached files are memory mapped, so they are only a pointer dereference away.

hugobuild - is the build tool that shares its mmap´ed files (cache files and not cache files) with hugoshm. hugoshm is started by hugobuild, and an argument tells hugsoshm which address is the shared memory entry-point address. hugobuild does not (must not!) change shared memory while hugsoshm is running. hugobuild discovers new files and mmap them, and unmap any older cache file, and finally delete older cache files after it had been unmap´ed. hugobuild is responsible for uploading changes and new content.

hugocms - is the CMS that interacts with hugobuild and the user(s) browser(s). hugocms notifies user agent(s) (usually browser(s)) about changes via a websocket.

Wow, sounds ambitious. I would already be very happy if we “only” had the CMS part. I think Hugo with a static CMS would work quite well with most websites.

I must say I don’t fully understand your thoughts about memory, mmmap, etc. But I’m not so sure if it’s a good idea to drive the idea of file-based content too far. There is a reason that databases were built and I think a major one is that they increase performance compared to file-based systems. For small and medium websites, especially during build time, the increased performance of a database is really not needed. But if you get to very large websites maybe you’d be better off with just using a database.

I’m working on a prototype of a Hugo-driven file-based CMS…

Great, @fireproofsocks. Curious to know more about your project.

Sweet! Do share :slight_smile:

We’re currently beta testing our Hugo CMS. See 60 sec demo video here:

Message me if you want to try it out :slight_smile: scott@forestry.io

1 Like

I’m closing this topic as there is a much more active one at