Web-Based Editor?


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


#56

I figured out why this is so. Due to go’s import system the main.go file will import from github.com/spf13/commands and so on, making any changes that I have made mute.

I have created a branch which moves all hugo specific imports to my fork.

To maintain compatibility with the orginal spf13/hugo repository I changed my the git origin of the repository to my fork and added spf13/hugo as the upstream remote.


#57

What about “Victor” ? :slight_smile:


#58

Sweet. Got it working. Certainly a start!

Wish I had more spare time right now to experiment with this. Excited to see some progress here.

As a brief aside, a capable web editor for Hugo would totally set it apart from the alternatives. There’s currently no client-friendly static setup that’s open source, self-hostable, and doesn’t rely on any 3rd-party dependency (that I know of, happy to be proven wrong :slight_smile:


#59

Nice to know that you got it working. I’ve started to include EpicEditor that will allow for a preview of the markdown by itself.

One thing at the moment that bugs me is that it still uses the watch system to rebuild the page, which to my understanding rebuilds the entire site if a file is modified. In the context of an editor, I think that the page could be generated from the markdown file and then passed back as a html file, without it touching the publishing directory i.e. use hugo to preview the markdown file.


Hugo UI, would you need it?
#60

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 http://madebymany.github.io/sir-trevor-js/ or http://createjs.org/) while also setting the stage for creating an official Hugo webeditor.

Any updates on this, @saturdayplace?