The Hugo Roadmap still shows that a built-in interactive web editor is still in the plans, but the main topic that I can see about it (here) has kind of trailed off and become focused on third-party solutions.
Is there still interest from the dev team in getting something like this as a built-in solution? If there an existing spec or set of expectations that could serve as a starting point for an implementation?
I’m interested in seeing this happen and willing to put in some work building the feature, but don’t want to duplicate effort, step on toes, or make something that people don’t want.
I am not a dev but I could help with the UI, design menus, icons, styles etc.
I’ve been looking at Hugo content management and checked out various tools during the past few months.
Here are a few features that I would like to see in a Hugo GUI tool.
A double pane markdown editor with live preview and scroll sync, that interprets Hugo shortcodes.
Drag and drop of images in the markdown area would also be very helpful. Atom has a great package that I currently use and when I drag and drop an img its code is filled automatically and also the img file is copied next to its content file.
I would prefer a solution that works locally with Hugo server. Exposing an admin area to the web with a password would not be ideal in my opinion.
I agree with this part especially; this is where existing stuff falls short. Basically I’m imagining being able to pass a flag to the the hugo dev server that enables an editing/admin interface. Something along the lines of StackEdit could work for the actual content, but would need some work in Hugo itself to respond to the changes/write the files/etc.
But it seems like there was previously a lot of traction behind the old spec and design… did anything ever come of that?
Netlify has an open source CMS that iirc people are free to use with Hugo, without even using Netlify, no? Seems to me that the topic in question is so broad, as to necessitate being out of scope and/or 3rd party. Hugo does its job really well, and if I can have a vote, I’d like the core functions to keep improving as they have been.
Agreed. I only raised the idea because I saw it on the roadmap but not getting actively worked on so far as I could tell, and it seemed like a good opportunity to contribute something that I’d also use myself.
But having gotten this feedback from @bep, that pretty much closes it. All well and good! Back to Netlify.
A CMS that requires uploading content to a public Github repo -not ideal for everyone, certainly not for me- amd managing it through a remote interface in the cloud. I will never again rely on any online solution to manage my content (open source or not).
Also the interface of the above CMS (and the other popular one) leave a lot to be desired i.e. no live markdown preview (at least last time I checked).
Anyway I have long abandoned expectations for a content management tool that will be a part of Hugo. @bep 's reply confirmed this.
Anyway @sjml thanks for your input. The best local GUI tool for Hugo and other SSGs I have found so far is Pendulum. But currently I rely on Atom. There are some great packages for Markdown editing in Atom. And it offers an experience much better than a traditional CMS.
Just chiming in to say that a powerful text editor (like GNU Emacs) beats any CMS hands down. Good to see that bep is spending time on core Hugo features than on a CMS which would never match the feature set and convenience of proper editors.
GNU Emacs is the best tool for writing content in Org. It also has really good support for editing Markdown content (but why would you do that if can Org ).
Note that the fact that something is mentioned in an issue/milestone is not remotely the same as
someone is working on it right now or will be very soon (“what is the status of this?” “what is the progress?”)
it is going to be implemented at some point
That is not the case. I care about getting bugs fixed (it creates noise), but other than that I spend my own time on stuff that I find cool. Often that stuff is also cool and useful for others. There is definitively a mental roadmap, a bigger plan, but it is not carved in stone.
As to a web editor / CMS – that is a huge task that isn’t “core Hugo”. If some UX/CMS/developer expert is willing to throw 1000 hours of his/her time on it, great; but until then I think we should do the best possible job to make Hugo attractive for other CMS projects (Hugo is one of 2 static gens with starter templates for Netlify CMS).
It doesn’t have to be developed from scratch. There are other Open Source tools out there that hopefully could be made to work in an efficient way with Hugo.
Anyway I am not a Dev… at least not yet… (even though sometimes it feels like I’m getting there at a snail’s pace)…
But I am a mid-career freelance designer and UX is what I have been doing for a good while now.
So if anyone reading this thread ever feels like developing an Open Source GUI for Hugo that works in the browser through a local server or customizing an existing tool, I’m available to help flesh out the interaction, give input on the user flow from a non-Dev point of view, design the interface etc.
The reason I’m offering myself to be involved in something like this is simple. Hugo is ultra cool. Hugo is my tool of choice for developing websites. But I just cannot see Hugo becoming as common place as other frameworks without a proper GUI (preferably a local one with no dependencies). It doesn’t have to be a part of Hugo. It doesn’t have to pass a flag to Hugo server. What a proper Hugo GUI really needs is a proper live markdown preview and interpretation Hugo shortcodes within that preview. That’s what could make Hugo usable by non Dev content editors.
Anyway. If anyone ever feels like developing a Hugo GUI just send me a private message and I’ll do my very best to help turn it into a reality.
I agree that the actual building of the web frontend is a huge undertaking that’s well outside the scope of Hugo. But I wonder if there are some simple hooks that could be added to the Hugo development server that might make creation of such frontends easier. Minimal changes to just expose things to a web layer that are in the filesystem at the moment.
For example: Imagining a mode (behind a flag) where you can hit the server on a different port and basically just get some data about the site, something like a very simple API. It could minimally do nothing but provide a list of filepaths in the content folder for a start, and give the ability to retrieve the raw text and rendered HTML (the body text, at least) of each file. Being able to replace the text of the raw file would be a bonus, as would the ability to create new ones.
That wouldn’t provide everything that a web editor needs, but it would provide a lot. With just that, someone making an editor could make a drop-in html file that pulls that data from the dev server and presents it prettily. (The making of THAT system, of course, would not be part of Hugo development.)
Apologies if either of the following is true:
The server already does things like this.
This kind of thing would actually be very hard to add because of some internal architecture or design rules.
Most importantly, I want to apologize, @bep if I’ve touched a nerve here. I’m very appreciative of the project as a whole and the work you’ve done leading it. I know from experience what a thankless task managing an open source project is, and I remember how irritating it could be to deal with demanding users. If it seemed like I was casting aspersions, I assure you that isn’t my intention.
If you’d prefer to just drop the matter completely, I’ll call it a day. I’m just thinking about what kind of minimal alterations could be made to enable a better ecosystem of addons. I’ve got enough dev experience to know that pitching a whole huge new subproject is not the way to ingratiate one’s self.
Sure, an API of some nature will happen. It was discussed related to the existing Hugo Caddy plugin, but noone took it the extra mile.
I have been pondering with some prototype ideas myself. The thing is, with Hugo’s speed the markdown preview would be stellar – so if someone could create a cross-platform split-view with a Chrome browser, markdown editor and a file selector …