This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit ezplatform.com

eZ Community » Forums » Developer » Front end editing and the web site...
expandshrink

Front end editing and the web site toolbar

Front end editing and the web site toolbar

Thursday 24 February 2011 7:22:19 pm - 22 replies

 

I was very happy to see that front end editing was one of the focal points of eZ Publish 4.5. However, now that I've had the chance to do a quick test run of the first beta, my excitement has faded.

 

In my opinion, one of the biggest problems of the existing front end editing functionality in eZ Publish is it's modularity, or lack thereof. Implementing front end editing into a custom site is something that, in my opinion, should be as easy as activating an extension. That's currently not the case.

 

I'm not saying that there hasn't been made progress in this area, though. Taking the web site toolbar out of ezwebin and putting it into its own extension was a step in the right direction, and so is the new feature of 4.5 which places the toolbar floating on top of the site as apposed to having to be squeezed into it.

 

Still, the default edit and other management templates are sure to break your design without some custom CSS modifications, and even then, the custom design you've built might not be suited to fit those templates. As a result, our company rarely implements front end editing unless we have to, probably resulting in a worse usability reputation for eZ Publish.

 

To me, eZ Publish front end editing is missing two key features which are required in order to make it truely useful (and implementable):

 

Edit/mangement views in modular boxes

 

If all the edit and other management views of the front end were handled in modular boxes, or in some other type of separate overlay, there wouldn't be any need to customize the design to fit these templates. Also, the website toolbar could be shipped with a set of CSS files styling just these views, without conflicting with the rest of the site.

 

It seems to me that this way of handling front end editing is the solution emerging as the best practice.

 

Inline editing

 

Most templates (pages) are a combination of several content objects. Still, the toolbar assumes that you're only interested in editing the main node of the page, giving you only one edit button.

 

I would make the case that 90% of the time, you're only interested in editing 1 of the attributes in the class (that is, unless you're creating a new object).

 

As a result, it would be much better if you, when logged in with the proper priveliges, could hover over any element outputted by the attribute_view_gui (just a suggestion for how this could be fairly easily implemented) and have a set of edit/management icons appear which in turn would make that content editable in a modular box.

 

I've already sent these ideas to eZ when I heard that they were working on front end editing (without them taking much notice), so I guess this is just my cry for help (or to see if anyone agrees that this is a sorely needed improvement).

Thursday 24 February 2011 10:35:42 pm

Hello Eirik,

Thank you for your feedback. I've sent a note to Engineering and asked for them to have a look at your feedback. They might have some answers to why they chose the current setup for the front end editing, which is the toolbar floating on top.

Kind regards, Robin

p.s. is your first name Eirik, or Eirik Alfstad? So I approach you correctly next time happy.gif Emoticon

Thursday 24 February 2011 11:11:31 pm

Please, don't take this as a promise or anything, but as far as I'm concerned, your cry for help isn't ignored. Without digging into implementation details, the idea of making anything displayed with {attribute_view_gui} is very sexy. Really. We couldn't deliver as much as we wanted to regarding front-end editing for various reasons, but the topic is far from being abandoned.

I hope this makes you feel at least a tiny bit better (digital hug) blunk.gif Emoticon

Thursday 24 February 2011 11:24:08 pm

Inline editing would be a really a cool feature. once i had the chance to try using Tridion. i thought sometimes about it, and yep, attribute_view_gui could be the start point. but i would go further and if you are hovering an attribute_view_gui, only that attribute could be edited. i think this is doable with some javascript and ajax stuff.

a big +1 for this kind of feature!.

Thursday 24 February 2011 11:49:06 pm

Hello Eirik

Attribute level editing has surfaced quite a few times in the past. The content model implemented with eZ Publish makes it quite hard to achieve this (editing an attribute means editing the whole object).

See for example the discussion http://share.ez.no/forums/setup-d...-only-1-attribute-of-a-contentobject a bit over 3 years ago

So its not new, but it requires some fundamental changes in the paradigms used by eZ Publish (which I proposed as part of Project V)

Paul

Friday 25 February 2011 7:09:59 am

@Robin: Just to be clear, I think that the toolbar floating on top is a good idea. However, it's only one of the steps needed in order to make the front editing truly implementable. And it's just Eirik, BTW.
@Bertand: Thanks for the digital hug! happy.gif Emoticon
@Carlos: I might not have been clear, but that was exactly my idea as well.
@Paul: Thanks for weighing in. Could you please say a few words about what makes this hard? We've been using the eZContentFunctions class a lot lately, and this seems to make it easy to only pass the attributes one wants to have changed. I'm aware that the content/edit view does not make use of this class as of now, but I guess an attribute editing view would have to be written from scratch in any case.

Friday 25 February 2011 11:14:34 am

Hi all,

Re: inline attribute editing.

I've been working on extension to do this. It's kind of half-way through but I don't have the time to finish it at the moment (I don't work with eZ Publish in my day job)

I'd love peole to contribute/take it over/use the ideas:

https://github.com/stevoland/ez_sedit

The frontend is quite nice - the backend is a total hack + the inline attribute editing feature won't work.

Think it's compatible with 4.3/4.4.

Cheers

Friday 25 February 2011 12:07:21 pm

forking!.

Friday 25 February 2011 1:35:34 pm

I think i understand Paul, specially when you think about searching and things like that. i mean, is doable to edit an attribute and only one attribute, but from there, we have to think in how ez works in some aspects.

For example, versioning. should we create a new version for every attribute editing inline? for instance, article class. we have title, short-title, body, tags, image... ok. we want inline editing for all, but should we create a new version for one?

if so, how to proceed if two attrs are being edited at the same time? i mean, probably one of your editors takes only care about the body and other take care of the images. editor 1 wants to change body of the article. he hover the body, and start editing. 1 minute later, image editor wants to change the image. he hover the images and start the process...

actually ez publish warns you if the same object is being edited. should we do the same with inline attribute? should we tell the image editor "hey, wait until the content editor finish"?

Other thing to note is related to searching. Actually, many ez publish projects are leaving ezfind the fetch content operations, because you can make more flexible queries from there. but actually, for reindex the title of one of your articles you need to reindex the whole object. if i'm not wrong solr will permit attribute indexing, but do know if this is possible right now.

so, back to the example, if you edit title, short-title and all the others, we would need to republish thewhole object in order to be reindexed? If you don't do that, you will probably get search results having title or texting you typed previously and not the updated by this inline editing thing.

Even if you have delayingindexing enabled, you still need to republish the object in order to be indexed by the cron.. right?

So, yep, still doable and really cool to have it. just thinking about possible unwanted sideeffects happy.gif Emoticon

Friday 25 February 2011 3:37:09 pm

@Carlos: These are some interesting points.

I would argue that editing even just one attribute should produce a new version for the entire object. I belive that when people edit an object (for instance in the admin interface), they usually just edit one attribute in any case, and since that produces a new version, I think editing solely one attribute should as well.

An yes, I think we should produce a warning when someone else is editing an attribute on the object you want to edit, even if you don't want to edit the same attribute. If each attribute modification was to create a new version, I don't see how this could work any differently.

I'm unable to say anything about Solr and indexing, but perhaps someone else could comment on this.

Friday 25 February 2011 4:26:11 pm

well, i say Solr because i can't imagine a search module in ez without it happy.gif Emoticon but the thing is just the same for the standard ezsearchengine.

fortunately there are things that could help here. i mean, default version history limit is set to 10. that can be increased, but also it can increase the whole database size...

and my other worries it's about perfomance. Suppose you have lot of attribs in one case. suppose 30 maybe. for some of them you're probably using custom indexing capabilites... and even more, probably you can be using content -> publish -> after workflows.

my worry it's if wouldn't take too much time editing one attribute because of it...

while writing this i realized about workflows. would you execute that workflow for each attribute editing? and what about 'approving stuff'?

surely Paul can explain it much better, but i think things like this is what he was talking about happy.gif Emoticon.

Friday 25 February 2011 4:42:26 pm

And other think that should be taken in account (imho). for this kind of functionality surely more css files and js stuff will be needed. but those files should be loaded only for those users having rights to work with this kind of stuff.

actually, when you start an ez publish fresh install, website toolbar css and other js like 'insertmedia' are loaded always, even you're an anonymous users not needing it...

probably ezjscore can help with that... thoughts?

Sunday 27 February 2011 12:51:11 pm

Whoa, quite a large discussion, that's great.

First, I think that the fact that we currently can't really edit one attribute only shouldn't be considered a problem. While it is true that under the hood, editing one attribute means editing the object, it is still possible to edit an attribute only, and not pass the others at all. So very pragmatically, yes, one attribute only can be edited.

I think we're getting very close from the proof-of-concept stage: yes, not everything has been addressed. Yes, there are many aspects to this (UI, permissions, ...). But we know:

  • what we can apply this to: attribute_view_gui / content_view_gui
  • what we need to target it at: content/edit, as if "Send for publishing" was clicked

Isn't that sufficient as of now ? This topic is so wide it would be a shame not to at least try ! I know for sure I'm interested in contributing, and that it would be a killer feature. My personal time is a bit limited between my three babies (my soon-to-be son, eZ Market, eZ Publish 4.5 beta), but hell it's cool !

Sunday 27 February 2011 1:34:49 pm

Whoa, quite a large discussion, that's great.

First, I think that the fact that we currently can't really edit one attribute only shouldn't be considered a problem. While it is true that under the hood, editing one attribute means editing the object, it is still possible to edit an attribute only, and not pass the others at all. So very pragmatically, yes, one attribute only can be edited.

mmmm, but how?. afaik, actually edit process creates a new version of the object and add a new version for every contentobject_attribute of the object right?

well, you can "edit" an attribute without the others, but how to deal with versioning with that? actually diff operations takes version for each attribute and check with the previous or whatever is choosen... so if we don't create a new version for each contentobject_attribute, how to deal with it?

and my other worries is about approve operations and things like that as stated above... but yep, we still should try this. i think maybe we should start with the ui things and editing the attribute without worrying on these things... things to we should come back in the future... happy.gif Emoticon

Sunday 27 February 2011 4:34:59 pm

As I've said, it's not easy, just possible and fun happy.gif Emoticon

About versioning, well, I don't think we actually need drafts when doing frontend editing like this. Or do we ? One goal could be that such an interface will let you edit one (or more ?) attributes in an inline fashion. Either we create the edit interface the best we can, and deal with creating the version & publishing it in one go on the server side handler, or we use AJAX to create a real-draft, and are back to a close-to-standard workflow. About workflows, yes, interruptions of the publishing workflow are tough to answer. We need to look at the possibilities, the constraints, and the actual needs. But let's say this would apply to direct editings.

Now, another solution that could work: whenever node_view_gui / content_view_gui / attribute_view_gui are used, we know which node/object/attribute is viewed, and can therefore know which node/object/attribute could be edited from here. But when using attribute_view_gui, several attributes of the same object could be displayed on the same page. What about adding _ if edit permissions are there _ markup data that will let us scan the page for editable objects, and when asked (through a variant of ezwt ?) to switch to edit mode, buttons would be added (or maybe a side bar ?) that would popup an edit overlay for the edited object. Wouldn't that be sexy ? It ain't as seamless as swapping view with edit, but the display size between view & edit can be totally different, and it wouldn't work at all sometimes...

Sunday 27 February 2011 4:38:33 pm

Anyone up for a mockup ? happy.gif Emoticon

Sunday 27 February 2011 10:12:47 pm

As I've said, it's not easy, just possible and fun happy.gif Emoticon

About versioning, well, I don't think we actually need drafts when doing frontend editing like this. Or do we ?

That's the question happy.gif Emoticon. If not the thing could be easier, but if so, it's possible without doing it at object level?

What about adding _ if edit permissions are there _ markup data that will let us scan the page for editable objects, and when asked (through a variant of ezwt ?) to switch to edit mode, buttons would be added (or maybe a side bar ?) that would popup an edit overlay for the edited object. Wouldn't that be sexy ?

sure it would be sexy, but i would go even further. no need to click in anything. I think a mix between Eirik's idea and yours would it make even more sexy.

the markup will depend on permission, right, but i wasn't thinking in side bars nor ezwt. i'm more of the idea of this buttons can be show on hovering. and, well, as ez works now, if you have rigths to edit the object, you will have the rights to edit all the attributes of that object.

and yep, after an edit overlay different for each datatype could do the job.

first part could be like this, and, ok, if we choose not versioning can be doable setting the content for that specific contentobject attribute. if we need versioning thin is still doable, but i just worried about performance in terms of editing.

Cheers

Monday 28 February 2011 9:30:17 pm

Hi all,

Not had a chance to participate in this discussion as much as I'd like as I'm on holiday but basically I agree with what Bertrand said.

Please check out my extension as a lot of the frontend problems are already solved.

Basically it wraps the output of a node_view_gui and attribute_view_gui with a div containing info about the object in the class name:

<div class="se-lang-eng-GB se-cid-16 se-owid-14 se-pid-74 se-sid-1 se-oid-76 se-nid-78 se-ccaid-189 se-aid-308 se-attribute">

The user's permissions are present as a javascript object and on mouse over of these divs - permissions are checked, cached and the relevant icons displayed.

Here's a screenshot with ezflow out of the box - the user can edit/move/delete etc the node + edit the image attribute:

http://stevoland.net/tests/sedit.png

It also lets you edit the title of the node and works out which attribute to update.

Ajax could then call a module that outputs the attribtue edit template + inserts it into the page. I had trouble with datatypes with complex javascript so an iframe might have to be used like in ezoe.

Here's the extension again. Add it to /extension/_sedit

https://github.com/stevoland/ez_sedit

cheers + keep it up!

Thursday 03 March 2011 7:46:22 pm

@STEVO: Would you care to elaborate on how the extension should be set up, and how we can confirm that it works? I tried downloading it from github and putting it in extension/_sedit. I then enabled the extension globally, cleared the cache and tried logging into the frontend. However, all I can see is a blank button in the toolbar with the tooltip "Edit content inline".

BTW, this was done on a (fairly) fresh 4.4.0 installation with ezwebin.

Thursday 03 March 2011 8:17:05 pm

Hi Eirik. I did the same here, and yep, same result. that click throwed a js error thought. i suppose it's probably because STEVO's extension has js code not compatible with last ez versions... hopefully i can find some time to digging it...

STEVO's extensions seems a really good start point for this need anyway happy.gif Emoticon.

Cheers!.

Thursday 03 March 2011 10:07:08 pm

Sorry - forgot to mention that the extension doesn't override attribute_view_gui and node_view_gui but adds new template functions that wrap them - so you'll currently have to do a search + replace throughout all relevant templates - ezwebin, ezflow, custom frontent templates.
Change attribute_view_gui to attribute_sedit_gui
Change node_view_gui to node_sedit_gui
Also there's a couple of regex search/replaces in /temp/regex.txt that should be used for full effect.
The toolbar button doesn't do anything yet.
Clear all caches etc then you should see divs as mentioned above wrapping content areas and rolling over them will reveal the icons.
Cheers

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from