Request in-page editing / create.js / create.php

[felix]

Hi Ryan,

first - as this is my first post - let me say i just started using processwire and already fell in love with it. You're doing a great job!

There already are several threads about replacing the current wyswig editor (TinyMCE) with [insert $editor here].

I did a forum search and wondered why no one mentioned implementing in-page editing like most "big cms" (drupal 8, typo3 neos, symfony cmf...) currently are. In my opinion this is an absolut killer feature from a clients/authors point of view.

As create.js is just an editing API people could also start using whatever editor they like (currently availabe editors are: hallo.js, aloha, ckeditor, redactor).

If you never read about create.js you should visit http://createjs.org/ and have a look at the demos as well as this blog post: http://bergie.iki.fi/blog/createjs-in-2013/ .

There already is a PHP library (create.php - https://github.com/flack/createphp ) which aims to help integrating create.js into existing applications/cms.

I'd absolutely love to see this feature in an upcoming version of processwire (even though i will also keep using processwire it if there won't be in-page editing ).

Best regards,

Felix

[Luis]

Hi Felix, welcome to the COM.

It would not be an problem to integrate in Page editing, but I think this shouldnt be placed to the core.

With some little php template scripting its very Easy to implement the plugin and edit Pages via the API.

[Pete]

Just building on what Luis said, the thing about ProcessWire is that it doesn't make any assumptions about your templates on the front-end, so you couldn't package it as a working part of the core anyway as the first thing most people do is implement their own templates which would strip out the necessary tags to make this work.

I think it could certainly be a module (just so it gets bundled with one or more of those editors) that can be downloaded and installed with simple instructions for the developer to implement the necessary tags into their template though, so that's certainly worthwhile someone pursuing.

There are some considerations though, such as the way images are handled in ProcessWire, that require further thought as well (hence why I'm thinking a module again).

As with most things in PW though, it's certainly possible to implement

[felix]

I see your points and fully agree.

At first i wanted to start this topic in the modules section but realized there were mostly "look at my finished modules" topics, so i decided to post it as a general wish.

Could somebody please move this thread to the "modules" section?

//edit: I apologize i forgot to also thank all contributors in my first posting and would like to do so now

[Pete]

Done, and tagged as a module request

[apeisa]

I think that create.js is interesting (and made in Finland, JEJ!). I am not much fan of RDF, but in that scenario it actually seems to make a lot of sense. See this (modified their example markup to fit pw):

<div about="/path/to/mypage/" typeof="sioc:basic-page">
  <h1 property="title">Some title</h1>
  <div property="body">
    Some content
  </div>
</div>

The interesting part is that how to automate (or whether automate it at all?) the RDF in markup? 

[felix]

@apeisa have a look at https://github.com/flack/createphp

[ryan]

I think this is definitely a great idea for a module. But it's also true that it kind of goes against the whole markup agnosticism, and is pretty limited when you consider the broad range of inputs possible with Inputfields. In the context of ProcessWire, it's only a partial input solution. Most importantly, front-end editing goes against content portability and is thus not a best practice. We should be abstracting content away from design, not tightly coupling content into it. I think many using a front-end solution would try to design and fit their content for the space they are typing in. Then the content is a mess when the site goes mobile, responsive or gets redesigned, etc. Promoting content portability is an important job of a CMS, and front-end editing is not good for content portability. That being said, it's great eye candy and there are plenty of cases where I think the benefits of it would outweigh the negatives too. As a core solution, I think front-end editing is a bad idea. But as a modular option for those that want it and understand the tradeoffs, I think it's a great idea. I can think of cases I would use it myself too. 

[MatthewSchenker]

Greetings,

I've spent a lot of time (really, a lot) on the whole subject of front-end editing.  It's something that users really want, but I agree with Ryan that we need to make sure it works in the whole scheme of site development.

I think it's good to make a distinction between two separate but somewhat similar practices:

• Front-end editing
• In-place editing

The difference, I like to say, is the idea of "literal" content control.

The one that causes trouble is "in-place editing," where clients want to have a window right there on the page in the exact spot where the material appears.  They want to create and edit content in that "literal" space.  This has many problems.

"Front-end editing" is more feasible -- with good development practices.  The user can link to an editing function for the page.  But they are taken to a proper interface for editing or creating content that takes into account that content cannot always be placed so directly.  The interface to edit and create content is not literal.

Seen this way, it's up to us as developers to explain to clients what each of these methods is, and why even though one seems prettier it's actually not as good for their sites.  It's a few extra steps, but if we design an interface that is easy to understand, users have no problem with the extra steps.

Thanks,

Matthew

[Joss]

I have to agree with Matthew that I have mixed feelings with inline editing. Having said that, where it is implemented to allow basic tweaking rather than complete rebuilding, I think it can have its place.

Since most of the JQuery/HTML5 editors are implemented on a tag by tag basis, it is easy from the template point of view to allow inline editing on some parts and not others.

Personally, I do like simply clicking on an edit button and going to a neat, proper edit page (either by popup or other) where you have the tools as set out when originating an article and then returning to the published page on save.

Consequently, my main interest in the new generation of editors is their clean lines, simple implementation and speed.

A lot of this is down to the design of the actual page which is being edited. If you look at Google Sites, you have a very fixed page structure and when you go into edit it will look exactly the same and yet be fully and properly editable.

If your page is split up with all kinds of boxes, interrupted with adverts and so on, it really does not work quite as well.

In addition, an author should write to make best use of the subject first and layout second. It is up to the editor or editing process to make sure the final piece fits in the necessary hole.

Personally, I don't think any edit tool I have come across gets the balance right - they seem to be either too quirky or completely overblown

[mindplay.dk]

This discussion came up in the office again today with a designer, and I came across this thread while googling the subject.

I've been obsessing over this topic for a decade - I've hated WYSIWYG editors since they emerged, and I still hate them, for the same reasons.

All the technical issues aside, conceptually, giving clients complete control over HTML in my opinion is a bad idea to begin with. But also, I have the opinion that bare HTML is simply the wrong medium for content, because it provides no structure and no control; no means of enforcing any standards on content.

What I would really like to see, is something like Hallo or Aloha integrated with a template-based content editor - and I mean templates in the sense of structural HTML templates of some kind. This content editor would let you pick from templates pre-created by designers/programmers for the site. It would have semi-rich content areas here and there, meaning paragraphs, h1-h6, strong/em, a-tags, ul/ol/li - but not things like inline images or tables. Instead you would have nested "micro templates" for things like "image with caption", "image gallery", and other much richer types of content than you can feasibly do with just a WYSIWYG.

This would provide much better control than just an HTML editor - and it is possible now, with contenteditable being widely supported, and great in-place editors like Hallo and Aloha now available. Bigger or smaller sections in deeply nested "micro templates" could provide the right level of in-place editing for actual content, and modern user-friendly UI for everything else - without trying to bake everything into user-editable HTML markup ("mce_"-attributes in your HTML markup anyone?) and without losing the ability to actually update these templates on the server-side, reflecting changes on existing content.

I long and yearn for the day when I can actually present a client with a content editor that I myself could stand to use... ;-)

[felix]

typo3 neos which is now in beta does most of the frontend in place editing stuff as well as adding content templates exactly the way you've mentioned. I must admit that at it's current, more advanced state it's exactly what i had in mind when i was opening this thread. but after all it's still typo3 (typoscript, flow... yikes!). that's why i won't be using it.

[apeisa]

I like the idea of CKeditor widgets (especially combined with advanced content filters that CKeditor already has): http://ckeditor.com/demo#widgets

[pwired]

Front end editing for customers/clients is a hot topic since the days of cms. Sooner or later your customer/client is going to ask you how he can edit/change parts of his website him self in a simple way. Examples are changing text or prices for his products. I think nowadays a cms should have included this from the start. Anyway I think markitup is a nice third party solution.

http://markitup.jaysalvat.com/home/

[Martijn Geerts]

<pwired>I think nowadays a cms should have included this from the start.</pwired>

I disagree on this. I prefer well formed structural information, not the graphical representation in one situation. 

Content should have an independent value, not fixed to one distribution, so it can be used on a multitude of platforms.

There are situation where in-page editing makes sense, but we should not forget there's high value in structural information.

[Joe]

I'd absolutely love to see this feature in an upcoming version of processwire (even though i will also keep using processwire it if there won't be in-page editing ).

I agree. I think the issue with in-page editing is not that it is technically speaking a better solution. But the spontaneous response by a lot of (prospective) clients is just too positive for it to be dismissed (...or they will go somewhere else!). I just recently showed my PW demo site to someone, they liked it, but the spontaneous feedback was that it would be even nicer if content could  be edited right on the page.

The thing is, I´m talking about small website owners, not people running a newspaper or large company website (who presumably are IT-pros). And to them the more intuitive the thing feels, the more appealing it is...

Obviously one has to strictly limit the options people have when editing, but that is the same when using RTEs on the back-end, to me it really is only about the CMS feeling more intuitive with on-the-page (inline) editing, not about new functions.

I truly like PW and feel that after a fair bit of searching I have found the CMS I really want to use - but it is pivotal to me that I get front-page inline editing running. I already have it working for text content using CKEditor (it´s easy, if someone needs some help with this I´m happy to post it.) But for handling images and links within the PW structure I still have to send users to the back-end, hope to be able to fix that soon.

[Joss]

It is interesting to balance the discussion of in-page editing against the ideas being discussed elsewhere about versioning, drafts and previews.

For me, although I love the tactile idea of in-page editing, there needs to be some sort of safety system in place that stops people experimenting/publishing/experimenting more/republishing/changing/forgetting to publish and so on.

However intuitive it might be, I can see some huge holes opening up on a live site if there is not strict editorial controls or someone writes something in a block of text that is too short but thinks - "nah, that will be fine!"

To me, this sort of editing is fantastic when developing a site - it is really useful to see where you are heading, but after that it can be pure danger unless there is a draft/versioning/preview/editorial system in place so that changes can be made and double checked before the existing page is replaced.

Of course, this applies to editing in the back end too, but I think with front end editing clients will often think "oh yeah, see a mistake, click on it, change it, bosh ... it is done" without realising the implications of editing a site in that way.

[Joe]

Joss, I think you are making a valid point about issues with front-page inline editing here. I believe it just depends on the kind of site:

The reason I am so interested in making front-page editing work smoothly is that I´m intending to create a CMS/site structure ideal for small website owners. These sites are often managed by one person only and they normally do not need versioning.

As to drafts and previews:

there needs to be some sort of safety system in place that stops people experimenting/publishing/experimenting more/republishing/changing/forgetting to publish

I do agree that this would be ideal, taking things a step further. I could imagine that instead of actually editing the live pages directly things could be set up so one would edit a sort of "shadow-version", a page that looks just like the live page but only overwrites it once you choose to do so.

However the draft/preview functionality is not contained in a standard PW setup now either. You can only work on a draft version while you keep it unpublished. I´m not proposing to eliminate that when implementing in-page editing, but you could only do it on an unpublished page in the back end, same as now. If you work on an already published page any change you make goes live once you save it, unless you set it to "unpublished", but that is the case now too.

About forgetting to publish: Well yes, it can happen, same as it could happen now if you click on a link in the back-end after editing a page without clicking "Save" first. I don´t see a difference there. (In either case, maybe a JavaScript popup warning might be something worth implementing to avoid this).

Of course, this applies to editing in the back end too, but I think with front end editing clients will often think "oh yeah, see a mistake, click on it, change it, bosh ... it is done" without realising the implications of editing a site in that way.

It applies to back-end editing also, as you are saying here and I have written above. I don´t really understand then why you think that spontaneously making changes would affect the site differently if done on-page rather than in the back-end?

[Joss]

Hi Joe

It is not that spontaneous edits on the front affect the site differently so much as the temptation to do so

It is the old adage about the button in the empty factory. If it is just a button it either gets ignored or only attracts people who are actively looking for it.

If it is big, bright coloured with a big notice that says "do not press this button," it becomes almost irresistible!  

[Joe]

You have a point there. But on the other hand it just feels good to edit things "on the fly" and people go for it. Changing content easily is what a CMS is about after all. Whether in-page editing is preferable for a site or not will really just depend on the setting I think.

[artol]

We are currently considering whether we should change from Drupal to Processwire at least with some sites. It is quite important desicion for us, since we have about 30 websites from very small to few quite big ones. I have heard and seen lots of good things, but not having an in place editor is a bad thing.

Most of our users are not professional web editors. In our old system we had quick link to editing on backend visible to users browsing web with enough rights and this helped a lot much like in pw. But still I think for an modern cms you shoud have option to use in place editor.

Having it as module preferably including default/example theme working with it out of the box might be a good solution. Versioning would be good, but it is not necessity for us.

[LostKobrakai]

Most of our users are not professional web editors. In our old system we had quick link to editing on backend visible to users browsing web with enough rights and this helped a lot much like in pw. But still I think for an modern cms you shoud have option to use in place editor.

A simple edit link can be done with ease.

Regarding in place editing: I think especially for non professionals it's important to make them aware of the fact, that websites don't come in one shape. There are mobile layouts, responsive layouts, maybe a rss feed, which is shown in a rss viewer. Ryan already talked about that earlier in this thread. Nobody wants to have content with 15 " "'s just that the next word flows to the next line. 

If you just don't like your client to have to leave the current page to edit, take a look at this: http://modules.processwire.com/modules/fredi/.

[mindplay.dk]

Wo and behold, somebody started building that content editor I talked about - separating content from layout:

http://madebymany.github.io/sir-trevor-js/

Very interesting!

Though I expect the server-side rendering needs to be done with e.g. Node and can't easily be done with PHP.

[adrian]

Wo and behold, somebody started building that content editor I talked about - separating content from layout:

http://madebymany.github.io/sir-trevor-js/

Very interesting!

Though I expect the server-side rendering needs to be done with e.g. Node and can't easily be done with PHP.

There was some discussion about Sir Trevor, starting at this post:

https://processwire.com/talk/topic/4189-flexibility-in-page-design/?p=46536

[Beluga]

Aloha Editor is back with something new:

http://www.alohaeditor.org/Content.Node/blog/goodbye-contenteditable.html

http://www.alohaeditor.org/Content.Node/blog/introducing-aloha-ui.html

Basing your editor on contentEditable means that you have to clean up the broken mess of markup the browser leaves behind. Every big editor with wide adoption works exactly that way. It's basically like babysitting a caffeinated lemming. We think that this is the wrong approach. Why would you want to fix something if you can get it right in the first place?

This is why we came up with Aloha Editor 2. We provide you capabilities to create editing experiences embedded seamlessly in your web application. With a stateless API, that was built to give you full control. An API that is easy to use, so you can craft the best experience possible for your users.