Web-Based Editor?

#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.

#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.

#41

I think we start small. Assuming that the person will run Hugo like most people do today. On their local machine as part of their dev workflow, then commit to something like Git/render it live then push that.

If this is the case then we don’t need anything but the most basic of endpoints. Certainly not OAuth2 or anything like that yet.

I think it could be a companion to Hugo (perhaps named after another famous author).

#42

spf13 discuss@gohugo.io writes:

If this is the case then we don’t need anything but the most basic of
endpoints. Certainly not OAuth2 or anything like that yet.

What do you think about this:

It’s probably more proof-of-concept, but I belive something like that is
sufficient for the start?

#43

That’s pretty similar to how I’m thinking about it.

#44

spf13 discuss@gohugo.io writes:

That’s pretty similar to how I’m thinking about it.

Great - it keeps things simple. :wink:

#45

I support the idea @digeratus mentioned: using for example StackEdit to write markdown content. My preferred workflow is as follows:

I would like to write my markdown with my smartphone, tablet or computer (…) from different places. I do not want to run some VCS client on my system just to be able to publish content. And I want to switch between devices and have my content. So a browser-based solution with server-side (centralized) storage would be a good option I think. This is already possible with StackEdit and its cloud integration. What is missing is the glue between the raw markdown files and the generated content published on a website. After finishing the markdown article there needs to be some kind of “fire and forget” button which triggers the rebuild (Hugos core functionality) and the deployment. But I am nearly sure there are existing solutions to automate these tasks (grunt, custom scripts, …)?!

In summary a great solution in my opinion would be a Hugo installation paired with a self-hosted StackEdit installation encapsulated in a light-weight virtual machine. StackEdit has to be made available using a small webserver and the written content should be synced to local vm storage. When publishing an article the content will be processed and published, for example to AWS S3.
This virtual machine could be used local or be deployed to some cloud service / central server (LAN) to allow (multi-user) access from where it is necessary.

#46

There seems to be two schools of thought here:

  • A dedicated ‘Hugo Web Editor’ that is closely bound to Hugo, regardless of whether it’s packaged in the same binary.

  • A ‘web-based interface’ for Hugo. Largely the same concept as Prose.io, but configured to work well with Hugo’s file structure, rather than Jekyll’s.

I subscribe to a highly modular school of thought. This is why all the current static-CMS solutions such as Webhook, CloudCannon (w/ their new Jekyll integration), Site-Leaf, etc, etc; don’t interest me.

As Hugo promotes a CI/CD deployment method from Github through Wercker, isn’t an intelligent editor that acts on the Github repo for the site the best way forward? It splits up all the responsibilities to separate services, and allows a great deal of redundancy if something breaks.

If said editor could be told that posts go/come from X, adding a new page uses Y template and new content files get stored in Z location based on their file path, then we’re in business. It basically requires abstracting away the file-tree from the non-technical user.

As I’m unfamiliar with Go & Hugo, I may have this totally wrong, but surely Hugo needs no API or knowledge of this? As long as the editor acts in accordance with default Hugo file structures (prescribed ones if needs be), then it could work. Content is edited, Github notices the change, causes a huge-build on Wercker and Wercker deploys the site to wherever it’ set to.

Like I say, I may be missing something; but this could work, right? It will obviously have it’s limitation as you would be working with Githubs API, and not one designed for Hugo; but in terms of satisfying the “Non-Tech editing of Hugo sites” brief, it hits all the key points.

Just my £0.02

Cheers.

#47

I was checking the status of Nikola generator yesterday and saw they have something new in regard to web-based editor - it’s called Coil CMS abd it looks very decent and not too complicated.

#48

Okay, so I think I may have approached this from a slightly different angle and I suspect it isn’t really what people are looking for.

I set up my Hugo static site at example.com and installed Codiad at drafts.example.com. I have a “hugo-drafts” project in my Codiad “workspace” folder that is actually just a symlink to my Hugo “content” folder.

Codiad isn’t as feature rich as Sublime Text or Atom but it lets me see my entire site content, provides markdown highlighting, and lets me add or edit any post. It isn’t a slick interface (unless you consider text editors a slick interface - I do) and it doesn’t do the the markdown formatting for me but it allows me to edit anywhere. A cron job updates the site periodically – catching anything that is no longer marked draft.

This took me less than 10 minutes to set up (including server config) and I’m neither a coder nor a web developer. The hardest part was symlinking a folder and making sure the permissions were set correctly. This is probably not the answer most are looking for but I offer it here as the poor-man’s web interface for Hugo. :slight_smile:

#49

Most of the posted solutions work very well with Markdown. But with the increasing integration of Asciidoc features into Hugo could that circumstance exclude the format from being used. Markdown is simple and nice but also lacks some features if you need them.

#50

I would also like to see a section, that lists all drafts haven’t been published so far. Furthermore could the front matter wrapped in a sidenav, where tags, slugs, groups etc. could be changed with a graphical userinterface.
Mainly non-tech minded users, as @isaac metioned, would benefit from editing their posts that way.

Finally, realtime collaborative editing would be nice, if you work in groups. Pushing and pulling the latest commits from the repository wouldn’t be that great.

#51

So i got inspired to have a crack at making an inbuilt web editor for hugo and realized that between the ability to add endpoints to the inbuilt server and the live reloading feature that a very very simple web editor could be made.

The editor i have made includes a simple rest api to view the content directory, edit markdown files and save them. The edit window shows the markdown file as simple text along side an iframe of resulting output. At the moment it assumes the url is a 1:1 of the markdown filepath and name. ie /blog/post1.md is /blog/post1

Saving the files is done via an ajax post request, which should trigger the content file to be rebuilt. The livereload script triggers a reload of the iframe.

I encourage everyone to test it out (if you do please let me know) at https://github.com/rustyoz/hugo/tree/editor

The simplest command to run the editor is: hugo server --watch --webeditor in the project directory.
Browse to localhost:1313/view/

#52

@rustyoz I’ve tried to run the webeditor but it seems, that the corresponding flag isn’t set, because I get an error:

Error: unknown flag: --webeditor
Run 'hugo help' for usage.
CRITICAL: 2015/07/10 unknown flag: --webeditor

Furthermore is your command not listed under hugo -h. I’ve tried it on the branch editor and master (where you merged editor).

#53

Hi Everyone

Have you seen cloudcannon.com. You connect a github repo and you can edit html (once you have placed editable classes to regions of you page. Md files are edited using a very usable markdown editor. all edits are saved back to your github repo.

The cloudcannon folk are jekyll fans so their editor is focused on jekyll folder structure. I have had success using it to deploy static html to google App Engine using codeship.io. I have to rename folders and move some files about using script before I can deploy but it is trivial and the visual editor can be used by anyone including non tech folk.

#54

Hmm its definitely there in the code. Did you build my repo and install it before you tried to run it?

#55

I also get the same error as @digitalcraftsman. I ran go get github.com/rustyoz/hugo. Hugo works, but the --webeditor flag doesn’t.