Web-Based Editor?

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

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

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.

What about “Victor” ? :slight_smile:

2 Likes

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:

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.

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 Sir Trevor JS | Made by Many or http://createjs.org/) while also setting the stage for creating an official Hugo webeditor.

Any updates on this, @saturdayplace?

This seems incredibly interesting, and quite relevant:

Federalist is a unified interface for publishing static government websites.

1 Like

Any updates on this, @saturdayplace?

I’m afraid not. Anyone else who wants to knock it out, please feel free.

I agree, and a web-based file editor also will also reduce the security of Hugo. Granted, there still isn’t a database to hack, but I wouldn’t want people bots to be brute forcing their way into my Hugo admin.

In other words, a web-based editor for Hugo would give a lot more potential problems that, for me, are not worth the added convenience of a web-based editor.

[quote=“michael_henderson, post:27, topic:155”]
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.[/quote]
Indeed. The greater performance and security of Hugo is an important selling point. If Hugo starts to behave more like WordPress with a web-based editor, Hugo looks bad in that comparison (much smaller community, plugin features, for example). But if Hugo “stays Hugo” it’s much more unique (compared to WordPress, Ghost, Drupal, and the like).

An admin front-end, whether it’s web-based or a desktop app, can be completely optional. It doesn’t need to be bundled with the Hugo core, thus it won’t give you any more potential problems.

But for that developer/designer who’s been tasked with developing a website that the client can manage themselves 95% of the time, that UI interface add-on is gonna be the only thing keeping you from resorting to WordPress (or GetGrav or Kirby, if you’re still set on going static).

At netlify we’re working on an open-source CMS for static site generators. It’s currently in private beta (just shoot me a mail with your github handle at matt@netlify.com and I’ll get you access) and works well with hugo.

We just launched the updated site for http://www.staticwebtech.com/ build with hugo, and that’s the first public hugo site that use netlify CMS.

The idea is to build an extensible CMS for static content that assumes you’re using a generator or build tool and not working directly with HTML. It has a flexible live preview in the style of the site you’re editing and (just like prose) it will turn edits into git commits.

As some others in this thread, I believe a lot in a decoupled approach to this, where the CMS layer is about editing content, and the build tool is about generating HTML and assets.

We’ll be starting to post and talk much more about this project in the next months and will hopefully be ready to open up the repo to everybody soon (we just want the getting started experience to be a bit more straight forward first)…

8 Likes

@biilmann Very excited to check this out. Just sent you an email :slight_smile:

Awesome! I’ve sent you an invite :slight_smile:

There’s also the new http://prosemirror.net/ which enables editing in (Common) Markdown.

http://marijnhaverbeke.nl/blog/prosemirror.html

Hi everyone!

I’m working on a add-on for Caddy web server to support Hugo with a nice admin interface to manage posts, upload images, edit other files, schedule posts, etc. You can read more in this issue. I hope you enjoy. Fell free to help =D

2 Likes

Users, who prefer a web-based frontend insteab of a text editor, should take a look at Rango.

@nomadsagency I agree with some of what you said re: a web-based editor/UI. I would love to see an interface similar to that developed by the webhook team, which is, IMHO, by far the best web-based UI (it’s run as a small ember app) I’ve seen for an SSG. Not to promote non-Hugo items on this thread, but the CMS layer is open source. I, unfortunately, lack the Go chops to implement something like this. The webhook CMS is awesome, to be sure, but the only issue seems to be that large sites can take a very large time to build. Hugo/Go seems like the perfect fix.

Hi team - one option is to consider using existing projects that are focusing on this front-end and interactive space as their core. This include our own Corilla project, which spins out from work we did building Red Hat’s internal publishing tools.

We worked on collaborative technical writing at scale, and solving those pain points for enterprise software teams proved interesting when other departments started using it. We use Corilla internally for all kinds of other projects, and had a great chat with the Trello team recently about their experience of seeing users make tools fit their needs outside of their original needs.

I feel the same will apply with something like Hugo. We’ve dedicated ourselves to front end with an obsession over collaboration and content re-use, and we’re looking for a light weight publishing tool. We are currently using Harp and Read The Docs on the output stages, and love that there’s such a range of options in this space. Given our dev cycles we will need to narrow our focus down to one output channel though, so are keen to learn more about Hugo.

This is definitely something we could work together on, and as we are pushing each release as open source as well, I’m sure there’s a lot of the community that can take from that.

1 Like

The bit I can’'t get past is ‘why’? Aren’t these ideas, although smart, just the beginning of a dynamic CMS system?

I get it would be re-generating the site as static. But what if 20 users are active at that moment? I guess cached pages can be served. But then the question might be ‘how can we get the changed content to users now?’ Then we’ve got dynamic page creation… and hello Hugo CMS.

In my opinion, three things limit user (non-tech) editing of content for static sites is 1) not haviing the generator and source, 2) markdown, 3) front matter

2 and 3 might have a solution. I have long thought with SSGs that content could be text files, with paramaters and styling controlled by filename and location, layout and CSS, and config files. I think for a non techy client / user, front matter and markdown is a lot less appealing than the client creating / modifying a simple text file and writing stuff unformatted.

Even simpler / better would be a colloborative space (like dropbox) where these text files can be uploaded and a gulp script (or maybe even Hugo itself) includes that content in a daily site generation.

Also, for those of you who have worked with clients on CMS systems who are not good content writers, it also gives the chance to check it before it goes live.

A bit passionate about this because it is actually a current project (Hugo demo site as a potenntial product for certain types of clients). I come from 100% CMS development world, so I want to open the doors a bit to the client, but not lose the big advantages of a single static high-performance, non-security concerning website.