Web-Based Editor?

feature
13

Just adding relevant links for reference here.

  1. golloum has a web-editor which can be started locally.
  2. 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?

14

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 :slight_smile:

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:

  • create/edit/delete content
  • meta-data management
  • theme management
  • white-labeling/branding
4 Likes
15

Good sumary @isaac

As to Q: Primary/target users of an editor?:

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.

16

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.

17

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.

The above is me thinking loud.

18

nomadsagency discuss@gohugo.io writes:

The lack of a web-baded editor is the major issue for me with static
site generators.

[…]

I’m aware that these backends are proprietary but it could serve as a
option until we got another solution.

Nikola Python-powered SSG has something
(http://plugins.getnikola.com/#webapp) which might be worth to take a
look at…

Sincerely,
Gour

19

Shouldn’t this already be possible via the new “dynamic content” feature in Hugo?

20

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.

Thoughts?

21

I’ve changed my user name from nomadsagency to Mattias_W.

Thanks for checking this out isaac. I guess OAuth would be useful for other things as well.

22

IMHO, I don’t think it’s such a good idea to include a web-based editor into Hugo. There are so many ways that a web-based editor could be implemented that I don’t think we will find a solution that fits all. I would rather like to see separate editors that integrate well with Hugo.

I wrote about File-Based CMS and Hugo as Static Site Generator to outline a possible way that Hugo and web-based editors could play together.

I think it’s much better to keep generator and editor separate, what are your thoughts on this?

3 Likes
23

Agree totally. +1

24

@marcojakob Can you elaborate on why you think they should be kept separate?

On one hand, the editor would be 100% dependent on the format that the generator supports.

On the other hand, the generator isn’t at all dependent on a specific editor and many different ones could be used.

I do think that an API/server would need to be developed that can do things like list the taxonomies and their terms. This is a prerequisite to any editor if we want to do it right.

I’m all for many different options for the editor. I don’t see anything wrong with Hugo shipping with a default editor option and other editors also being developed as independent tools.

I have a very open mind about this and would love feedback.

25

spf13 discuss@gohugo.io writes:

I do think that an API/server would need to be developed that can do
things like list the taxonomies and their terms. This is a
prerequisite to any editor if we want to do it right.

I’m all for many different options for the editor. I don’t see
anything wrong with Hugo shipping with a default editor option and
other editors also being developed as independent tools.

I also do not have anything against having web-editor shipped with Hugo
or being part it since it would clearly fill one important feature -
ability for less savvy users to create the content.

In my use case it is very much required to migrate non-profit org web
site to Hugo since we have multiple authors and some are capable only to
launch web browser and create the content.

1 Like
26

@spf13 I would really love to have a web-based editor and maybe there is a good way to integrate it with Hugo. But I think it’s something that needs to be thought through carefully.

I might be completely wrong here, but I’ll try to share my thoughts:

In its current form I can describe what Hugo does in one simple sentece: “Hugo takes text files, combines them with templates and creates HTML”.

If you introduce web-based editing it might become more complex to describe what Hugo is and what it does. @isaac has provided a nice list above with questions to be discussed. Those questions show that the list of features could quickly grow large:

  • User management, permissions
  • Versioning content, rollback, compare versions (git?)
  • Complete editing workflow (like Drupal’s workflow module)
  • Multiple languages of interface
  • Multiple languages of content
  • Managing content types (which would define the form fields that are displayed to enter the content)
  • Search functionality in the editor
  • Managing media assets
  • Deployment to development, staging and production environments
  • And more…

Now, I actually need (almost) all those features and I would love to get all this in one binary. But I don’t think this will all happen in a way that makes me and most others happy at the same time.

I guess my biggest concern is that Hugo could loose some of its charm that comes with just (or mostly) beeing a static generator. Hugo is about “making website creation simple [and fun] again” - and it does it in an awesome way! (Wasn’t this the reason we moved away from Wordpress/Drupal/Joomla?)

I expect Hugo with an Editor to be perceived differently by users. New users might first look at screenshots of the editor and think about what is missing and what they don’t like. Then some might turn away not recognizing they missed out on (one of) the best static generators even if it could be used without or with other editors.

Like I said, maybe there is a good way to integrate it. But it is important that communicating what the core of Hugo does stays simple and clear.

An alternative could be to provide various options for editor integrations (community provided in a similar style as the Hugo themes). Some possibilities:

27

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.

I agree that user management and workflows push Hugo away from single-user system. I’d argue that it pushes it in the wrong direction since I like the “does one thing very well.”

I’d also argue that it doesn’t need to be pushed in that direction. If Hugo’s built-in HTTP server supported GET/PUT/POST/DELETE, then a web-based editor is just a smart JavaScript app that knows how to edit markdown and pass it on to the server to save it. All the other features could be wrapped around it, too. You want a list of taxonomies? Have Hugo create it in a well-known location and pull it into the app. You want version control? Add webdav.

But at that point, we have Hugo-as-Apache, and what is the advantage in that? Again, I’m not talking for everyone, but I’d still be doing my development on my local computer, having Hugo watch and reload the browser window to see the changes. If I’m using a WYSIWYG in another browser window or straight-up vi on the Markdown file, I’m still editing locally and pushing to the live server after I’m done.

28

But do we? Appache is a monolitic giant, certainly much more than a simple HTTP server supporting RESTful actions, right?

I personally really like this idea. Most of the “snazzy” aspects of editors and stuff is Javascript anyway, so why not just improve Hugo to provide a RESTful API that a “fat-client” Javascript app could sit on top of and do its magic?

Such an editor could be modular, even developed in a separate but connected repo, and perhaps it’d be possible to build two “flavors” of the Hugo binary:

  • one with an editor
  • one without an editor
    (from what I understand, it’s possible to include front-end assets in a Go binary via the help of something like Go Rice and Go BinData-AssetsFS and perhaps others, though I’m not sure if this is a good approach or not – anyone care to chime-in on this?).

Me too :slight_smile:

1 Like
29

PS: It seems that some big things are brewing for for “friendlying-up” front-end/Go integration. I’ve just learned about Slurp, from this (recent) Reddit thread, “How do you manage frontend web assets” [with Go].

The Discourse team (iydk, this is a Discourse forum, and it’s pretty sweet, imo) rallied and harnessed tons of contributor involvement in the building of Discourse (check out their great meta forum). Something similar seems possible with a Hugo frontend project (as it may be more “approachable(?)” for non Gohpers).

I myself read the post “Discourse as your first Rails App” multiple times, as I was at the time thinking of traveling down the Rails path. If there was a post “Hugo as your first Go app”, I’d certainly read it, but it’s not as exciting to hack-away at something that has no visual interface (at least for me).

Here’s what comes to mind:

  • a “Hugo frontend” repo that’s a ready-made environment for “front-end development in Go”, utilizing something like Slurp [Gulp.js for Go] in a dev environment that could be a nice “gateway project” for frontend folks (there are lots of us) to enter into the world of Go.
  • perhaps write the actual front-end Javascript in Go? This would be possible (in theory, I suppose) via something like GopherJS. There are llikely many pros and cons to this approach, but it’s at least a worthwhile consideration.

Just some thoughts.

1 Like
30

+1, most certainly.

But it seems that a Hugo Frontend could still be part of Hugo, and shippable via a single binary (via thoughts (and likely other ways) above).

If Hugo exposed a simple RESTful API (the core Hugo, with/without a frontend, perhaps) then in theory anyone could write a custom frontend, right?

31

I think the first step here is to design a minimal REST API that hugo would provide that would a foundation for a front end to build on. The key is that it needs to be as minimal as possible to still be functional.

Would anyone like to take a stab at a first draft of this? Here seems as good as anywhere to discuss it.

1 Like
32

Personally, I’d love to see something like StackEdit. It works on and offline, syncs with multiple storage services supported by Hugo, has some level of collaboration and comes with a WYSIWYG editor built in.

Since it’s open source, it could be forked and integrated with Hugo. Preferably, if the integration is loosely coupled, as StackEdit continues to improve one could upgrade it without losing functionality. The same would work viceversa, as Hugo improves, integration would be maintained. Here’s where the API proposed would make a lot of sense.

Just a thought.

1 Like