I have a love hate relationship with the web. I love static site generators and generally hate big content management systems. All the while, the “work local and deploy” model does have significant downsides, especially when working on something where non-techie folks need to collaborate.
Looking at the Hugo roadmap I’m thrilled to see “an interactive web-based editor.” It seems that this could transform Hugo into a sweet and powerful replacement for Wordpress and other big CMS frameworks. Does this seem possible or is it more of a pipe dream?
I’d love to learn more about the vision of a Hugo web-based editor and generally discuss thoughts/ideas that folks have on the topic.
Oh, its possible, at least in certain hosting/dev environments. http://prose.io/ works with github for instance and can work with Jekyll. Since it will edit any markdown file on github I dare say you can get it going right now with hugo content files too.
Need to be willing to put your site on github though…
I imagine exposing a server with an API and then putting editing controls over top your site with JavaScript might be a good solution here. Then the API would just send markdown to be saved to disk and then re-generate the site. Could be fairly straight forward (until you perhaps wanted to deploy to multiple servers, even still not bad).
As others suggested, prose.io seems to be a good starting point. The main problem, to me, is that it relies on github auth, so you cannot manage your website in an autonomous way.
Searching for prose.io again, couldn’t find it except on this topic (and I like Hugo too).
But I stumbled upon some great product : http://sofish.github.io/pen/
WYSIWYG and still accept MD.
One problem though, you can’t edit on mobile as smoothly as on desktop.
I’m am totally for this, but it has to function along the lines of Webflow. It’s what I use now. I’m thinking that if I can get this figured out with my previous Webflow sites I’ll upload to github.
What would this take? A Javascript WYSIWYG that saves to Markdown (like on Github) and have Hugo serve that, too? I don’t know if Hugo accepts POST, but if it did, this could be a one-stop solution. Fire up Hugo with hugo server --watch --wysiwyg and go to town.
golloum has a web-editor which can be started locally.
Gitbook has a nodejs based editor which can be used for offline. They provide download options. I suspect they use similar codebase for their web-based and hosted online editor. Something on lines of http://prose.io/
Can anybody please clarify which direction this is heading for? Local/offline editor OR hosted/online editor on the web?
Does anyone have one? @spf13, do you already have some type of vision for this?
The implementation here seems to be the easy part. Direction? That’s the real challenge (IMO). What’s the main objective? Simple content editing? Or something more robust, like a full-blown admin interface? Something in-between?
Perhaps we first need to identify the questions to ask… Then they can be answered… Then an appropriate solution developed.
Here are some questions I see. Just my 2 cents. Please chime in
Questions to discuss / investigate / answer:
Q:What should be accessible/editable via an interface? Potential Answers:
site content?
site configuration?
other?
Q:Primary goal(s) of an editor? Potential Answers:
editing existing content?
creating new content?
changing site configuration?
viewing site stats?
managing users? users??
managing site assets?
managing theme(s):
style options?
current in use (activating, installing, etc)?
Q:Primary/target-users of an editor? Potential Answers:
tech-mined?
non-tech minded? – seems likely
clients (end users)?
developers? – seems unlikely
Q:Features to include in a Hugo editor? Potential Answers:
I would say non-tech-users. I’m a tech users, and I would still prefer my bash shell over this, but this would be “nice to have” when blogging from a beach somewhere.
The lack of a web-baded editor is the major issue for me with static site generators. I work for an agency and I (we) produce approx one site per month. I love the simplicity of SSG but I’ve never been able to use it for a customer yet, due to the lack of a proper backend. Instead I have to use Drupal or Wordpress which I would like to avoid. I think CMS systems limit our creativity and output.
Clients always ask for the ability to edit content so a Statics site generator is always a “no-no”.
Back to the topic: building a backend that could compete with a CMS would take quite some time. So I’m thinking that integrations to cloud CMS systems like Contentful (uses markup), Cloud CMS or Prismic would be a good (intermediate/additional) option.
I’ve tried some these cloud cms systems and i’m really happy with them. I think that a good integration to one these solutions would give:
faster - integration(s) to these backend would not take that long
better?
free up time for developer so they can focus on making Hugo better instead
options for site builder. They have various cloud cms’s so chose from
I’m aware that these backends are proprietary but it could serve as a option until we got another solution.
I normal cases (due to installation issues) I would agree with you, static site generators is a “no-no” for most clients for content-editing.
For Hugo, which is a one-binary-install, I can imagine one could build some simple client side tooling around the hugo(.exe):
The customer isn’t an idiot (in most cases), and he/she would appreciate the best workflow available; and that is doing the edits in a good local editor with live preview in the browser.
Most customers have no issues with using a text editor and learning the basic Markdown.
One could simplify all the “start server” stuff by wrapping Hugo in a client version of such, with a “site browser”, start stop etc.
After reading a bit more about Hugo’s dynamic content feature (haven’t used it yet), it seems that one possible thing preventing this type of setup (using it to with a content management api service) would be authentication. From the docs:
Currently you can only use those authentication methods that can be put into an URL. OAuth or other authentication methods are not implemented.
