Obviously I had nothing to do with the naming of Hugo, but it seems to me that its name is a nod to Golang (Hu-Go) and a tribute to the legendary Victor Hugo.
2 Likes
I would suggest Hugh - a CMS for Hugo
Hugo is a first name basis environement.
Hurry, first names starting with the Hu sounds are going away fast. You donât want to be that loser who settles for Humphrey. (no offense to Humphreys, they just shouldnât be a Hugo service)
PS: Nice work by the way.
Oops, hugh.com and hugh.io are taken.
Maybe Huglify - Netlify + Hugo. It is certainly available⌠
I have some real ideas, but iâm still accepting opinions.
Thanks for the tip anyway. And for the compliment.
PS: I hope to release a small video very soon to show it working. Iâm just polishing a little bit more.
Well, âVictorâ might be one choice.
Wikpedia says the illustrator for Les Miserables was a âEmile Bayardâ so, another idea is âEmileâ or âBayardâ since your CMS is a visual GUI on Hugo.
1 Like
Or Zola. Never liked Victor Hugo anyway, let him stay at Netlify 
2 Likes
I have been building a CMS for Hugo for a while and plan on launching this spring, although itâs not Hugo-centric enough to really call it a Hugo Admin Interface, more of a Markdown CMS.
My business (Graphia Ltd) is focussed on making it easier for companies to write their internal documentation (SOPs, handbooks, instructions, guides, runbooks, etc) in a web-friendly manner, to allow them to save their documents in a open format that doesnât require heavy, slow, inefficient and ugly tools (cough Sharepoint) that make reading a strain for users; rendering a word processor in a browser to read a file is beyond pointless.
How it works
The backend is written in Go and the frontend in Vue.js, importantly, the content is written to and read from a git repository. The database is only used to hold user credentials, everything else is in git.
Creating a document actually creates a bundle, so all images are stored with the content - really important when youâve got hundreds of operating procedures full of images, diagrams and charts!
Every time a directory or document is created, saved or deleted, the CMS actually creates a Git commit.
As expected, the full history for every file is easily viewable through the frontend although in fairness the UI here could do with some polish!
Some nice features
- Frontmatter is automatically dealt with by the editor, fields are placed alongside the document and everythingâs put back together server-side prior to commit.
- Advanced authors/users can upload their SSH public key (as they would on GitHub, Gitlab etc) and clone the repository, push commits etc.
- Designers can do the same with the Hugo theme to customise at will
- The CMS works with Hugoâs Multilingual Mode and makes creating translations of documents easy. Thanks to the bundling, all translations live in a single directory and can share assets. The CMS wonât ever do auto-translation but will (at some point!) automatically generate XLIFF files that can be sent to translators.
What it isnât designed to do
- File-based user permissions
- The web UI will be aimed at regular business folks and will have no knowledge of branches and merging
What it doesnât do yet
- There is no UI to edit Hugo settings
- Take enough advantage of Hugoâs shortcodes (yet). I want to be able to (and have some ideas on) allow users to drag in CSV or
.dotfiles and let users configure charts, graphs and tables. But thatâs in phase two with the new âblockâ based editor. - Auto completion for links, this is next on my todo list
- Auto publish on commit
Long term goals
If there is any interest in it as a product, I would love to open source the CMS and shift my companyâs focus to the onboarding process - definitely the biggest hurdle for most companies. Getting decades of poorly-formatted Word docs into consistent Markdown is quite a big task and not for the feint of heart.
3 Likes
The target market for this product, IMO, would be folks not using text editors, folks who are stuck with Word and/or Confluence. And thatâs a huge market⌠unfortunately.
Products like these give me a little hope that documentation in future will be all plain text.
So much this! I am currently working/promoting for development of new documents in plain text (Org mode erm, better than Markdown⌠but Markdown is still waaay much better than Word docs ). Itâs a slow process, but eventually will get there⌠Though, need to fight the new evil: Confluence âdocumentsâ⌠which are ephemeral web pages, and not even documents.
2 Likes
Completely agree on the Confluence thing @kaushalmodi mentions . We moved away from it, because it was similar lock-in to using Word, since the whole thing was in a DB (and, java which was a horrific nightmare to self-host; oh, the headaches!).
Iâm not sure if anyone on here knows about DITA, which was originally developed by IBM to store their incredibly massive library of documentation. Even if you never use it, itâs an interesting technology to learn
a bit about.
When I was researching âfuture proof documentationâ a few years ago, I came across DITA, and various editors for it. A company called Codex had developed an editor for a subset of the DITA spec, and this editor was by far the easiest to use among the ones I tried (DITA can be pretty complex). The CMSs being developed for Hugo and/or generic sets of text documents, mentioned here, especially given the new concept of âbundlesâ in Hugo, reminded me of this foray of mine into the DITA world.
We took a pretty odd approach in my company to getting away from Word, which was not DITA (in the end), but rather to author our documents in markdown, and store them in a table in our home-grown ERP database. Most people are authoring in a markdown text editor and pasting a version into the textarea in the ERPâs UI.
I back up all the various data in this DB a few times a day, and stick the output files into a git repo. Itâs not pure markdown, but, itâs at least accessible in a text editor and, in a repo so I can diff them. The biggest itch my staff have is, images and attachments are not very easy to upload to these documents.
I love the idea of having a simple editor that can work with Hugo bundles, so I might convert our process yet again.
3 Likes
Thank you for your feedback.
Essentially the CMS web interface is straightforward enough for people used to Word or Confluence to grasp. Navigating to a document, editing it and saving it with a commit message (that will probably be renamed to âdescribe your changesâ or similar) are all trivial, the process and workflow are all familiar to anyone who has used a CMS.
For advanced users (IT folks, developers) the notion of supplying a SSH key and cloning the repo and using <editor> shouldnât be a problem.
The problem area is that some authors will find the web editor too limiting and the cloning process too complicated. I know that the long term answer to this is to build a better web editor, but thatâs a mammoth task and I want to launch with a basic editor first to ensure the concept is sound.
The quicker approach is to make cloning and working locally easier, which isnât too bad on a Unix/Unix-like OS, but setting up SSH keys on Windows was a ballache last time I tried it. Plus, gitâs stageâcommitâpush workflow really isnât straightforward.
Thankfully, the rise in popularity of Visual Studio Code with built-in git and the fact that Windows is getting SSH should hopefully make this much simpler.
Since I started this topic, I actually went away and built the thing that I needed, which may end up being useful for a subset of yâall, too. Itâs pretty basic, but does what I need, which is: something that enables collaboration on static sites without needing to educate writers on Git. My target audience is folks who are used to MS Word or Google Docs, trying to ease their transition. The idea would be that a more technical person does the more complicated parts of the setup of Hugo using whatever tools they prefer, but then the writers and editors have something more specialized to their needs.
The software is called Drax (because itâs meant to go alongside Hugo, and Hugo Drax was a heck of a Bond villain.) Itâs open source, and designed to be easily deployable to cheap hosting, so if you need to customize it or donât like tying yourself to third-party websites, you have options.
It only does GitHub as a backend, and intentionally abstracts away a lot of Git. Editors and collaborators can annotate text, and the annotations are stored as separate files. (This can lead to problems if the main files are modified outside of Drax, but it does its best to sync up annotations based on diffing with Git, and lets you know if they might be out of whack.) You can also add a .drax/config.json file to the repository and set a âcontent rootâ so that writers only have to deal with the less-scary (for them) directories.
The editor itself was built from scratch with CodeMirror; I didnât love SimpleMDEâs formatting operations, and spent a while getting it to feel right. CodeMirrorâs Markdown parsing isnât quite perfect (though Iâve submitted some patches there), so thereâs something to be desired, but itâs close enough for the moment.
It doesnât as yet do an HTML preview (mainly because the âstyled plaintextâ does most of the job I need it to do), support image uploads, or Hugo shortcodes. It intentionally doesnât handle users, access control, or any of that kind of thing, just punting it all over to GitHub. I know this makes it unsuitable for some peopleâs uses, but thatâs ok!
It ainât the slickest design, but has a minimalism that keeps it from being too offensive.
Anyway, itâs a thing I made for my own needs and is getting a workout from a small group, but if anyone else finds it useful, feel free to give it a go! There are almost certainly bugs lurking about, but there shouldnât be anything at the âOMGâ level.
5 Likes
@beny, @alexandros, @Yudy_Ananda
Since youâve demonstrated some interest, here is the Hokus preview video.
And the oficcial website: https://www.hokus.io/
@regis, @RickCogley and @bep
Thank you for your efforts in helping me find a name. I ended up choosing the name âHokusâ, a short and catchy name (I guess), keeping only the âHâ of Hugo.
Iâm eager to hear any feedback about the preview video and Iâm accepting volunteers to help. As I said before, I intend to release the source code in GitHub.
8 Likes
Looks very good! Canât wait to take it for a spin in a Windows VM.
1 Like
Since the application is developed using Electron, it should run on Windows, Linux and Mac.
I think I just need to generate the binaries. Iâll do that for Linux as soon as possible, but it will take some time (my wife wonât let me do that in this weekend).
Awesome, cant wait till you release linux and windows version 
Is Hokus available on Github yet? Quite interested in trying to build and use it.
Not really,
The repository exists, but itâs empty: https://github.com/julianoappelklein/hokus
I still have to refactor some code (I donât want people to see my mess) and add some important features.
Iâll report to everyone who subscribed to the website newsletter about any release or update.
When the time come, any help would be much appreciated.
If you havenât subscribed yet, please do.
Tried to subscribe but not sure it worked, some odd json view was the result rather than a confirmation.
Just checked, your email is there.
BTW, the javascript from the subscribe form was broken for a short time, but the fallback (non ajax) worked fine.
Very interesting - Great work â
from here https://golangme.com/blog/how-to-easily-edit-your-hugo-website/
I try to find more info about itâŚ
But I find nothingâŚ