Web-Based Editor?

Yes, this seems like one logical approach. Another approach would be to build the entire editor ui as a single page app, written either in JavaScript or something that compiles to it (such as Go :slight_smile: - perhaps using GohperJS (github | hacker)? anyone have experience here?.

There seem to be infinite possible implementation-directions with an editor, each having their merits and potential drawbacks. Hence the api-first approach, right? Once a simple API is finished folks could harness it in multiple ways (something along the lines of this http://getcockpit.com/, or even for simple front-end editing, in the spirit of / utilizing something like Sir Trevor JS | Made by Many or http://createjs.org/) while also setting the stage for creating an official Hugo webeditor.

Any updates on this, @saturdayplace?

This seems incredibly interesting, and quite relevant:

Federalist is a unified interface for publishing static government websites.

1 Like

Any updates on this, @saturdayplace?

I’m afraid not. Anyone else who wants to knock it out, please feel free.

I agree, and a web-based file editor also will also reduce the security of Hugo. Granted, there still isn’t a database to hack, but I wouldn’t want people bots to be brute forcing their way into my Hugo admin.

In other words, a web-based editor for Hugo would give a lot more potential problems that, for me, are not worth the added convenience of a web-based editor.

[quote=“michael_henderson, post:27, topic:155”]
I don’t speak for everyone, heck, I hardly speak for anyone, but the flight from Wordpress was due to performance and security, not because blogging wasn’t fun.[/quote]
Indeed. The greater performance and security of Hugo is an important selling point. If Hugo starts to behave more like WordPress with a web-based editor, Hugo looks bad in that comparison (much smaller community, plugin features, for example). But if Hugo “stays Hugo” it’s much more unique (compared to WordPress, Ghost, Drupal, and the like).

An admin front-end, whether it’s web-based or a desktop app, can be completely optional. It doesn’t need to be bundled with the Hugo core, thus it won’t give you any more potential problems.

But for that developer/designer who’s been tasked with developing a website that the client can manage themselves 95% of the time, that UI interface add-on is gonna be the only thing keeping you from resorting to WordPress (or GetGrav or Kirby, if you’re still set on going static).

At netlify we’re working on an open-source CMS for static site generators. It’s currently in private beta (just shoot me a mail with your github handle at matt@netlify.com and I’ll get you access) and works well with hugo.

We just launched the updated site for http://www.staticwebtech.com/ build with hugo, and that’s the first public hugo site that use netlify CMS.

The idea is to build an extensible CMS for static content that assumes you’re using a generator or build tool and not working directly with HTML. It has a flexible live preview in the style of the site you’re editing and (just like prose) it will turn edits into git commits.

As some others in this thread, I believe a lot in a decoupled approach to this, where the CMS layer is about editing content, and the build tool is about generating HTML and assets.

We’ll be starting to post and talk much more about this project in the next months and will hopefully be ready to open up the repo to everybody soon (we just want the getting started experience to be a bit more straight forward first)…


@biilmann Very excited to check this out. Just sent you an email :slight_smile:

Awesome! I’ve sent you an invite :slight_smile:

There’s also the new http://prosemirror.net/ which enables editing in (Common) Markdown.


Hi everyone!

I’m working on a add-on for Caddy web server to support Hugo with a nice admin interface to manage posts, upload images, edit other files, schedule posts, etc. You can read more in this issue. I hope you enjoy. Fell free to help =D


Users, who prefer a web-based frontend insteab of a text editor, should take a look at Rango.

@nomadsagency I agree with some of what you said re: a web-based editor/UI. I would love to see an interface similar to that developed by the webhook team, which is, IMHO, by far the best web-based UI (it’s run as a small ember app) I’ve seen for an SSG. Not to promote non-Hugo items on this thread, but the CMS layer is open source. I, unfortunately, lack the Go chops to implement something like this. The webhook CMS is awesome, to be sure, but the only issue seems to be that large sites can take a very large time to build. Hugo/Go seems like the perfect fix.

Hi team - one option is to consider using existing projects that are focusing on this front-end and interactive space as their core. This include our own Corilla project, which spins out from work we did building Red Hat’s internal publishing tools.

We worked on collaborative technical writing at scale, and solving those pain points for enterprise software teams proved interesting when other departments started using it. We use Corilla internally for all kinds of other projects, and had a great chat with the Trello team recently about their experience of seeing users make tools fit their needs outside of their original needs.

I feel the same will apply with something like Hugo. We’ve dedicated ourselves to front end with an obsession over collaboration and content re-use, and we’re looking for a light weight publishing tool. We are currently using Harp and Read The Docs on the output stages, and love that there’s such a range of options in this space. Given our dev cycles we will need to narrow our focus down to one output channel though, so are keen to learn more about Hugo.

This is definitely something we could work together on, and as we are pushing each release as open source as well, I’m sure there’s a lot of the community that can take from that.

1 Like

The bit I can’'t get past is ‘why’? Aren’t these ideas, although smart, just the beginning of a dynamic CMS system?

I get it would be re-generating the site as static. But what if 20 users are active at that moment? I guess cached pages can be served. But then the question might be ‘how can we get the changed content to users now?’ Then we’ve got dynamic page creation… and hello Hugo CMS.

In my opinion, three things limit user (non-tech) editing of content for static sites is 1) not haviing the generator and source, 2) markdown, 3) front matter

2 and 3 might have a solution. I have long thought with SSGs that content could be text files, with paramaters and styling controlled by filename and location, layout and CSS, and config files. I think for a non techy client / user, front matter and markdown is a lot less appealing than the client creating / modifying a simple text file and writing stuff unformatted.

Even simpler / better would be a colloborative space (like dropbox) where these text files can be uploaded and a gulp script (or maybe even Hugo itself) includes that content in a daily site generation.

Also, for those of you who have worked with clients on CMS systems who are not good content writers, it also gives the chance to check it before it goes live.

A bit passionate about this because it is actually a current project (Hugo demo site as a potenntial product for certain types of clients). I come from 100% CMS development world, so I want to open the doors a bit to the client, but not lose the big advantages of a single static high-performance, non-security concerning website.

I think the point here is there isn’t one right answer. I think it’s best
to have flexibility and decoupling of these jobs (content management and
content rendering).

I love the Dropbox idea. I think that could work well for a lot of people.

I also love the caddy add on and think it could also work for a lot of

My experience[1] working with non-technical content creators is that they tend to break at these points:

  • Creating file names properly (e.g. what should be “/well-formatted-filename.md” ends up being “/poorly formatted even though you told me how” with the file extension being left off even if they get the name right.

  • Errors in front matter. YAML, particularly with quote marks within strings, and forgetting to do quote marks.

  • If creating documents to put into a system (as opposed to editing documents already in the system), they tend to create the documents, including front matter, in MS Word, which can introduce artifacts and kill builds.

And of course, if posting on Github, your failures are silent. No error reporting if you’re not on the command line, so they can’t even be prompted to fix them. That behavior would likely get in the way of a Drop-box solution, as I imagine that anyone who who could easily do those things could just as easily push to a repo from the command line.

I’ve been kicking the tires on some of the existing editors.

  • Prose.io works a lot better than it used to, but is a bit geeky.
  • Cloudcannon (a commercial product) is very nicely designed and fairly user-friendly, and close to being stable, though it only works on Jekyll for the foreseeble future (I only bring it up as a model, but the way they handle front matter is really well done), and
  • Netlify’s CMS, which is open source (though right now works best when tied to their hosting service), shows a lot of promise, though it’s got a way to go before being used real-world. It’s an Ember app and seems to slow down a bit listing a lot of content.
  • 18F is in the early stages of creating an editor, which I understand should work with Hugo. I’ll know more about this soon.

I’ve yet to spend any time with some of the interfaces mentioned here, like Rango or the Caddy add on.

I too would love to see something to solve this issue. I’ve been using Webhook where I need non-technical people to do content entry, but I fear that project is languishing, and I am also fairly well amazed by Hugo’s performance and the power of its template language.

[1] My tests were mostly with graduate students, in the legal field, where attention to detail is paramount, but I suppose its a different sort of details than what we’re accustomed to.


I agree with most of your statements.

I walked a similar path although in my case I am looking for a simple solution for small business customers. When it comes to good SEO results today only static carefully designed pages are reasonable. Hugo helps to speed up the construction of the website just like any other generator and has some undeniable advantages. Unfortunately customers usually also want to update their sites :slight_smile:

I can write articles on my site in HTML, but for my clients markdown, yaml etc. are simply black magic.
Everyone wants to sign in somewhere and input text in forms as in Wordpress or oldschool php monsters.

The best of used solutions to date is webhook.com. A great interface. It looked great. Nice offer, I mean the price for the features and cloud hosted CMS. But it looks that guys are unable to cope with the challenge. The service is not suitable for commercial use for many reasons and I cannot recommend it.

I tried but could not run Rango. I tried also Caddy-cms. Apart from some problems when trying to save new posts it looks very promising.
I’m close to decision of coding myself something like a webhook (ember app), but more focused on single website usecases. Or start of new adventure with golang and hugo-cms contribution :wink:

As this is my first post. Many thanks Steve SPF13 for sharing your work. Thanks to you and other contributors I learned a lot.

1 Like

Glad you gave it a try @adprof! It is brand new so I’m sure @hacdias would be happy to hear about your experience and fix the problems you had. We’re both very interested in making it the ideal solution for as many Hugo users as possible.

Thank you Matt. I created one minute ago a Github issue with my 2-minutes video test. I would be glad if I helped with the development.

Would love to get a large hugo site to play with if you’ve already setup netlify CMS and can give me access.

We haven’t done any performance optimizations yet - so right now for a big list of posts, the CMS will parse them all straight away and stuff them into one big list. Adding pagination and being smarter about when to parse the metadata/markdown, should go a long way in terms of making it really fast even with large collections…