Orchard 1.7 Front-End Inline Editing feature team

Topics: Announcements
Nov 6, 2012 at 8:09 PM

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

Nov 7, 2012 at 12:40 PM

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.

Nov 8, 2012 at 4:32 AM

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

Dec 28, 2012 at 6:47 AM

CKEditor 4.0


And there's an alternative to CKFinder named KCFinder.


Would be nice to see fully integrated in Orchard

Dec 28, 2012 at 5:01 PM

@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)? 

Dec 28, 2012 at 8:49 PM

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

Dec 28, 2012 at 8:57 PM

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.

Dec 28, 2012 at 10:51 PM

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.

Dec 29, 2012 at 2:22 AM
Edited Dec 29, 2012 at 2:47 AM

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.

Dec 29, 2012 at 8:19 AM

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

Dec 29, 2012 at 6:39 PM

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.

Dec 29, 2012 at 8:39 PM

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

Dec 29, 2012 at 11:44 PM

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.

Dec 30, 2012 at 11:05 AM

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?

Dec 30, 2012 at 7:25 PM

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 !

Dec 30, 2012 at 9:19 PM

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

Jan 8, 2013 at 3:09 PM

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: 




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.

Jan 8, 2013 at 7:40 PM

The below look like great solution



Jan 8, 2013 at 11:12 PM

@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!

Jan 9, 2013 at 12:27 PM

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

Jan 10, 2013 at 4:49 AM
Edited Jan 10, 2013 at 5:29 AM

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/


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


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.

Jan 14, 2013 at 3:45 AM

What about supporting markdown as well as HTML?

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

Jan 14, 2013 at 7:05 AM

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.

Jun 14, 2013 at 5:26 PM
Is this still targeted for 1.7? Also, when is the projected date for release for 1.7? I'm really looking forward to the workflow module. :)
Jun 15, 2013 at 8:41 AM
1.7 is targeted for the next week or two. Still some bugs to fix.

Inline editing is still a work in progress, its moving but not as fast as one would like.
Jun 17, 2013 at 12:02 AM
Where is the development for inline editing occurring exactly and who is leading the effort? I'd love to put some time and hours into this.
Jun 17, 2013 at 10:16 AM
Edited Jun 17, 2013 at 10:16 AM
I am currently the one working on it.

Project is here.. https://orchardinlineediting.codeplex.com

Documentation is here:.. https://orchardinlineediting.codeplex.com/documentation

More than welcome to join in
Jun 17, 2013 at 12:23 PM

Excellent information! Where exactly is the code at at the moment? What is the most helpful thing that I can do right now?

Jun 17, 2013 at 1:11 PM
The code is in the repository on codeplex, you just need to clone it to Orchard.InlineEditing

hg clone https://hg.codeplex.com/orchardinlineediting Orchard.InlineEditing

from there you can use it.

First thing is to download it and try an get it working.

Things outstanding off the top of my head:
  1. apply inline editable to alternates
  2. test fields work
  3. more examples.
Jun 17, 2013 at 1:54 PM
Thanks for the information Jetski. I wish I had the ability to help with coding, it's just not my area of expertise. I really like the idea of inline editing, thanks for your work on it.
Jun 26, 2013 at 2:25 AM
Hi there. I found time to get the code and start playing with it. Looks like I got it working for title and html body with your wonderful examples and documentation, The tinymce editor for the body seems to only work in IE 10 and not in chrome and firefox. Is that a known issue? Should I be trying something different?

Jul 31, 2013 at 3:39 PM
Is this still in the works? I'd really like to implement this on form-created content items to where authorized users can modify some fields on the front-end.
Jul 31, 2013 at 5:45 PM
Hey, The code still works. You jsut need to create tempaltes in your view. check out my examples within my theme.

Aug 8, 2013 at 2:31 PM
Edited Aug 8, 2013 at 2:48 PM
I followed your example @ https://orchardinlineediting.codeplex.com/documentation and could not get it to work. Module enabled, I basically duplicated your example of making the title modifiable on the front-end.
  1. Module enabled.
  2. CSHTML copied and created in Theme/Views/EditorTemplates/Parts.Title.InlineEdit.cshtml
  3. Modified placement.info to read
<Match DisplayType="Detail">
    <Place PartsTitleInlineEdit="Inline:1" />
Am I missing anything else? This should make my title part editable anywhere on the site right?
Aug 9, 2013 at 10:08 AM
Edited Aug 9, 2013 at 10:08 AM
It looks like Mardown got confused when I posed my example.

<Match DisplayType="Detail">
    <Place Parts_Title_InlineEdit="Inline:1" />
Aug 12, 2013 at 5:10 PM
Still didn't work. Not sure what else could be wrong, I followed the example to the letter.
Aug 12, 2013 at 11:14 PM
Can you zip up your orchard folder and upload it somewhere? I have it working on my side following the online instructions.

Aug 18, 2013 at 8:41 AM
Hey CoreComps.

How are you finding it?

I have been thinking of making a dedicated module that provides templates out of the box... i.e. Orchard.InlineEditing.Templates or something like that. This means that uses would then have this out of the box rather than having the add stuff to their theme.

Do you have any suggestions or things you would like to change?

Also I am thinking of moving the project to GitHub as that is primarily where I do most of my work these days.
Aug 21, 2013 at 2:50 PM
Sorry for not replying, work has me pinned down. I am in the process of transitioning to Wordpress for my work site (still use Orchard for my personal page), so I likely won't need to use this feature for Orchard. My belief is that a feature as useful as inline editing should be tied to fields within Content Types/Definitions, which would mean a greater adoption rate for users who aren't programmers. For example, if you add a Text field, you should have a simple checkbox to "Allow Inline Editing" for that field. Anyone with a basic understanding of CMSs and/or web design could work with that and leverage a very powerful function. Since I wasn't able to get it to work I am not sure what has been done already, or how it works within Orchard. I wish you guys luck with the project and hope it continues to grow.
Aug 25, 2013 at 3:02 PM
Jetski5822 wrote:
Hey CoreComps.

How are you finding it?

I have been thinking of making a dedicated module that provides templates out of the box... i.e. Orchard.InlineEditing.Templates or something like that. This means that uses would then have this out of the box rather than having the add stuff to their theme.

Do you have any suggestions or things you would like to change?

Also I am thinking of moving the project to GitHub as that is primarily where I do most of my work these days
Jetski5822 - First it's a brilliant module so please don't take this the wrong way. The hard part appears to be done by you which is associating the updated content to content item and storing it to the database. It's a better editing experience that would make this a worth while module.

Having a set templates to support at minimum the out of the box content types from orchard would be valuable. Right now, while I can edit from the front page, it's not exactly inline....it opens a text box and disrupts the layout or view of the page and adds an area for an edit/save button. Now, I still haven't looked into it and maybe it is all in how the css is styled and some minor js changes but this is kind of what I expected when I hear inline edit:


Another alternative might be something like the WYSIWYG popup option that this page shows: http://vitalets.github.io/x-editable/demo.html

Finally, maybe the all integrated approach is all wrong and maybe the focus should be purely on a framework by exposing a set of rest services that allows authenticated users to post updates to content by content ID and field. Then theme designers could implement what ever editor they want as long as they post the content of that update to the appropriate url. To that point, the theme could add a field to content types of your choice exposing the service interface framework for easier use.



Any html posted to the url above will update the body field of the content ID 1451.

Lots of options and easy for me to be critical since I'm not the developer nor a smart enough developer to do much of it myself. On the other hand, I'm super excited to provide ideas and give guidance on how I and others would use it.
May 27 at 1:48 PM
Is this still in production? Maybe included in the next release?

If anyone could show me the latest version, I would like to take a look and maybe fix some bugs if needed?
May 27 at 5:48 PM
I have just migrated the module to Github


The module is still in production, but I haven't looked at it for a while. Let me know if you have any questions.