Web-Based Editor?

feature
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
33

I’m all for an editor, workflow management, content management, and other wonderful things for Hugo. That being said, personally, I’d like to see the core of Hugo remain focused on being the best static site generator the world has ever seen and having infrastructure including and beyond what I mentioned above kept separate. Such a architecture would allow for each user to use and deploy Hugo in exactly the way that works best for them.

As a wise man once said: “This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together.”

2 Likes
34

I’d totally like to take a crack at building a REST API, if no one else is chomping at the bit.

35

That would be great. Before you write code, let’s agree on a design and some end points here. Please provide a first stab at what it would look like.

36

Basics I’d expect from a web-based editor (which I think lead to endpoints):

  • List source/content dir (HTTP GET)
  • Returns either a nested <ul> or a JSON object that represents the source dir. A client would render this to give a user a visual overview of their content’s structure.
  • Read selected file from source/content dir (GET)
    • Returns the file’s contents. Clients would render the file contents in their editor
  • Delete items from the source/content dir (DELETE)
    • Returns an HTTP 200 with a message saying the delete was successful
  • Add new items to the source/content dir (POST)
    • Returns 201 (created) with a location header with the new item’s URL.
  • Save to a file in source/content dir (PUT. Assumes the file was already created above)
  • Returns an HTTP 200 with a success message
  • Rename items in the source/content dir, including moving to different sub-directories (POST or PUT, depending)
    • Returns 200 if PUT (just a rename, or 201

Does that sort of give the color you’re looking for? Cutting my teeth here on open source contributions.

37

The REST api looks fine, but …

I think this should somehow be a separate thing.

The day the Hugo server exposes a CRUD api to my file system is the day I will think hard before I even use it for the stuff I use it for today.

3 Likes
38

I agree with @bjornerik: Maybe I just don’t understand, but why would you want Hugo to provide a file system API? That would mean I would need to keep Hugo running constantly on some server. I know that people seem to be using Hugo as a server in production, but I still see it as something completely different to the core use of Hugo, which is a static site generator.

Couldn’t we just use something else than Hugo for handling all the file system and possibly file versioning stuff? I would rather use hugo as a generator that only runs when something on the file system changed.

I’m not too familiar with file systems/server interactions. So maybe someone could clearify what the advantages were to using Hugo for this task.

39

It will be a separate command. Could even be a separate binary.

Steve Francia
spf13.com
@spf13

40

I’ve been leaning towards having a separate executable that builds upon Hugo to accomplish its tasks, leaving Hugo to focus on static site generation and what it does now. This executable should be focused on running the site live and enabling additional functionality like a web-based editor, or content search.

It should leverage Hugo to accomplish this.

For web-based editing we would also need to add session management and OAuth2.