This thread is to discuss a front-end inline editing feature for Orchard 1.7.

If this is implemented, may I ask to keep it optional?

A mailing packet that we were using also switched to inline editing. Editing is now 100% easier but we also lost the ability to more advanced things.

The current experience will still be there. inline is just to make it easier and faster to make small edits.

CKEditor 4.0

http://nightly.ckeditor.com/12-12-27-08-51/standard/samples/inlineall.html

And there's an alternative to CKFinder named KCFinder.

http://kcfinder.sunhater.com/demos/standalone

Would be nice to see fully integrated in Orchard

@Skrypt, wow, that CKEditor (the 1st link) inline editing looks amazing. it would be awesome if we could have something like this in orchard? 

To the core Orchard team, wasn't Nick working on inline editing a few months ago? I think it was for the 1.4 or 1.5 release. What happened with that effort? Is it something that we should pick up where Nick left off, or are we starting from scratch again for 1.7? 

If we want to have inline editing working with TinyMce i'd be willing to work on that. I'm not sure if it's possible in as awesome a manner as that CKEditor link. Do we want to try to have the feature be agnostic to which WYSIWYG editor someone is using (TinyMce/TinyMceDeluxe/CKEditor/Markdown)? 

Yes, Nick was working on that and he never finished it, I think.

I just like to add : do not forget that there is more to edit than just blocks of images / text ;)

Like keep it open enough so we can provide our own inline editors for our custom fields / parts.

I've thought a bit about this. Maybe we could limit us to the body part at this point, but to be super cool inline editing you should be able to inline edit all parts. Since the inline editing can't know about the parts each content part therefore has to output some appropriate editor for themselves.

What I'm wondering here is whether the same shape used to edit the content item in the admin should be used (meaning we could use the admin editor) with some additional styles or if there should be a dedicated front-end editor. To configure the editors for inline editing some scripts, styles and stuff would probably be required so even if we use the admin editor something more would have to be passed to the view. I guess.

This should be a dedicated front-end editor. It's basically some JSON object posting from client to server side (Maybe done using SignalR).

The admin should be kept like it is since form POST is also less expensive for client browsers.

It's a feature that we should be able to turn ON/OFF on the website level.

For those who wants to use the inline editing in their own module/widgets the editor should only be added to dependencies of those modules.

For those who still want to use TinyMCE then this feature would not be available... and that's why it needs to be only a dedicated front-end editor.

Because else Orchard would become strongly tied to CKEditor and Orchard should be kept extensible as much possible.

I did start on this yes with Sipke. We got a concept working but will need to revisit the implementation. The code is at http://orchardinlineediting.codeplex.com

Looked at the module. It's nice to see that the concept is working. Though, I think it would be cleaner if the inline editor was using this kind of editing. 

<div contenteditable="true">content here</div>

With TinyMce or CKEditor loaded on top of the editable region. Else, if you load the entire editor in the page ; it kind of break the purpose of seeing the content as it will be displayed when you edit it.

I have been using CKEditor previous versions with asp.net. It is a solid product, but are it's internal really uptodate with css 3 and html 5  ???

There is also the Editor inside Kendo UI which has a GPL license....

I think tinyMCE is still catching up for supporting HTML 5 through extensions.
CKEditor 3.6.1 is the first release to try to support HTML 5.
CKEditor 4 is using HTML 5 features (contenteditable) and support HTML 5.
The KendoUI editor is supporting HTML 5 but no language pack out of the box.

The contenteditable would be a nice solution for html content. However if there should be inline editing for stuff like fields and other parts more work are required. These editors could be dropdown lists, checkboxes or whatever, and I think it wouldbe sweet to be able to change those as well. Or should inline editing be limited to body part?

There's a lot more work involved in making everything inline editable but the first step should be to make HTML parts, inline editable. Remember though that if it's inline editable that it should also try to keep the visual aspect intact on the page. So, for example, if you try to change the date of a blog post, you could double click the date and it would make a date picker pop-up over the actual date zone (instead of the CKEditor) and then you could change the date of this specific blog post. I'm actually writing this because in the actual concept they are making date and other thing editable together wich is wrong since you could want to put the date of your blog post on top of the blog post and the editor in the end of the blog post...

What I'm trying to say is that an inline editor should not be using modal pop-up's that load's an entire form to edit every content ... else it would be the same than to use the actual admin forms on a separate browser tab. We don't want that changes makes the page reload with a complete form post. Just small AJAX posts to the WebApi.

"Inline" equivalent to "In place"...

@JLedel I don't know what is the limit of this but if it needs to be out for release 1.7 ; I would say : "time". And also what @bertrandleroy will dictate !

@Skrypt I agree with you about the inline = in place part. if a field with a dropdown editor is clicked the text goes away and the dropdown list replaces the text. Hit save and the new text goes there. Another example is tags for some content, just click next to the tags and you can add or delete. The key point with what I'm trying to say is that we should keep this in mind so we don't design a solution that only works for html blocks (body part). As for the time aspect I'd rather ship cool inline-editing with 1.8 than some crappy thing with 1.7 that needs to be re-done.

If you really want top visual editing on the front-end you should really use http://aloha-editor.org/

Check out their inline content editing: 

http://aloha-editor.org/demos/3col/

http://aloha-editor.org/demos/960-fluid-demo/

and it is all open source with a huge team of contributors behind it.

That will make Orchard really a top CMS! Front-end content editing is really a must have feature.

The below look like great solution

http://vitalets.github.com/x-editable/

http://vitalets.github.com/x-editable/demo.html

@ylan That's how I'd like fields and stuff to be edited (except for maybe text fields)! Combine that with the inline-editor of the current Html editor and we're good to go in my opinion!

Thanks for the links and suggestions. We're definitely going to have a look at those.

Another suggestion would be to use backbone.js on this projet (or something similar like knockout.js) instead of the fluid-project framework wich looks a little bigger. Backbone is a library, not a framework, and plays well with others. Like this one : http://d3js.org/

http://todomvc.com/

Also keep in mind that knockout.js doesn't have url routing but backbone is. Though there is 

https://github.com/mtrpcic/pathjs
http://millermedeiros.github.com/crossroads.js/

Also knockout.js is a MVVM design patern and backbone.js is a MVC design patern.

http://kmalakoff.github.com/knockback/ is a project that seems to bring the magic together.

What about supporting markdown as well as HTML?

Also, what about the idea of previewing and publishing changes in-line as well?

In case of an input field that uses the markdown flavor, we should probably render a markdown editor.
As for publishing in-line, we have to discuss the design still, but I imagine we could have some sort of tool bar at the top or bottom of the page, which contains a cancel draft / publish button.