Edit currently only supports Views that render entities using the "Rendered Entity" format.

Edit should be able to edit any Entity Field in any type of View, even if it is rendered via "the Views render pipeline" (e.g. when using the per-View field rewriting stuff) and not only when it is rendered via "the Entity/Field render pipeline".

Thoughts and feedback from dawehner on this problem in D7: #1830518-15: Views integration (use Views' render pipeline to re-render edited fields in Views), further in comments 19 and 20.

We need to figure out what exactly is necessary to make this work in D8.

(Yes, this is a fairly vague issue summary, but it's just to make sure there's an issue for this problem space that will still have to be addressed. It will be improved once higher priority Edit issues have been solved.)

CommentFileSizeAuthor
#15 edit_and_views-1962606-15.patch3.74 KBWim Leers
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Wim Leers’s picture

Priority: Critical » Major

Downgrading, because in-place editing still works, just in a from a UX POV inconsistent way.

Wim Leers’s picture

Title: Edit + Views » Edit + "Field" Views (table, grid …)

Implemented in Drupal 7

I just implemented this in Drupal 7, because I'd already received feedback from Views maintainer dawehner on how to do this in Drupal 7. I imagine that it would be very similar in Drupal 8 Views.
See #1830518-25: Views integration (use Views' render pipeline to re-render edited fields in Views), a 30-second screencast is attached there.

Note that the Drupal 7 version of Edit currently still uses the "global edit mode", where *every* field on the page becomes in-place editable, instead of just the fields for a particular entity, like it is in Drupal 8. The Drupal 7 version will also move towards the Drupal 8 model, with per-entity in-place editing and no more global edit mode.

Problems with supporting in-place editing on "Field" Views (besides "Content" and "Rendered Entity")

"Content" and "Rendered Entity" Views naturally form no problem; since it uses the Field/Entity render pipeline, this behaves the same as on the full entity page. Typically, there are also many (it not all) fields of the entity in these representations, making either perfectly suited for in-place editing on a per-entity basis.

However, it is the "Field" Views (inherent to e.g. the table and grid styles) that are problematic. Imagine you have a table View with 3 columns: the node title, tags and image fields. With a "global edit mode" (as is the case at the time of writing in the Drupal 7 Edit module), you will get 150 in-place editable fields at the same time. That's

  • an overwhelming sea of blue outlines
  • going to cause problems with knowing what it is exactly that you're editing
  • impossible to reconcile with per-entity editing in the way it is currently implemented in Drupal 8: it would require contextual links (a pencil icon) per entity, and thus *50* pencil icons — one for each row!

Therefore it is questionable whether it is a good idea at all to have in-place editing for "Field" Views.

moshe weitzman’s picture

For a table and grid, could we do contextual links per row?

Wim Leers’s picture

In theory: yes. In practice: not really. Imagine 50 low-height rows with node titles and tags. That means 50 contextual link triggers squashed on top of each other. Poor UX. Also: loading those 50 contextual links is probably bad performance-wise (mostly front-end, but also back-end), and it's probably very bad for keyboard/screen reader users too.

webchick’s picture

In a table view, I'd love to have just one contextual link for the whole table, which then turns each of the individual cells editable. Insta-spreadsheet-esque bulk editing would be SO kick-ass! :D

I'm not sure how to reconcile this desire with the programming/architecture challenges, though.

Wim Leers’s picture

#5 (and actually also #3), see this part of #2:

impossible to reconcile with per-entity editing in the way it is currently implemented in Drupal 8: it would require contextual links (a pencil icon) per entity, and thus *50* pencil icons — one for each row!

The "per-entity" aspect might not seem very present today, but note that we're working on the entity-level toolbar. Please take that into account when suggesting solutions.

webchick’s picture

Right, but regardless of how it's currently implemented, "not 50 pencil icons" is what a user would expect. :)

I don't think per-entity toolbar is too horrific in this model, but it would require there to be multiple tempstores at play, which could indeed get tricky. You'd almost need a "meta" Save/Undo button at the top. ("View-level toolbar"? :P)

Wim Leers’s picture

I'm not worried at all about multiple tempstore entries. That's the trivial part.

It's the UX I'm worried about. Imagine five simultaneously displayed entity toolbars? And as long as in-place editing is on a per-entity basis, it's always very clear to the end user *what* he is editing. That's no longer the case when using (specially styled) Views: is this the title of this entity or that entity? Or it not even a title? This ties back to #1862784: Improve Edit module's labeling of "editable things".

webchick’s picture

Well, presumably the entity toolbar would only be visible for the entity whose field you're currently editing. The others would hide as soon as you moved off a row that affected a given entity. But that's what I meant about a View-level "Save" button (like the view-level contextual link gear), to trigger the "Save" buttons in all the various entity toolbars, visible or not.

Anyway, it's a tricky problem to be sure, and hopefully Kevin can come up with something whiz-bang awesome. :)

Wim Leers’s picture

Yes, let's wait for his Magical Sparkly Ponicorn Rainbows solution :)

moshe weitzman’s picture

Lets move away from the pencil icon for Views.

For views that already have an Operations dropdown, lets add the contextual links in there. For those that don't, we add a column containing the dropdown list of contextual links. Or maybe thats contextual links list part of a View's definition such that the admin adds it as a column.

tkoleary’s picture

Here is an invision prototype that covers *some* of the cases http://invis.io/68DU87XS

Webchick is asking XJM to come up with a few more edge cases we can test out to validate this approach.

xjm’s picture

One thing that doesn't make sense to me in #12 is what "full edit" would link to. With relationships, the content in a given row could be composed of multiple entities, so there's no one thing that "full edit" would necessarily relate to. Edit: Maybe the entity base table and we just ignore fields from relationships.

Also, would we be limiting this functionality only to displays that use a row style plugin? Maybe only to core's native table, grid, and list row styles?

Maybe we would need to add a property to hook_views_data() indicating when a given field can be edited and the path to edit it?

Finally, one hurdle that we are also dealing with for blocks is that what you see is not necessarily what you get. Views can do any manner of preprocessing on a cell, such that the final output might bear no resemblance whatsoever to what's displayed in the cell. Maybe we just accept that and let the user discover this when they switch from viewing the value "My field value of 89 coyotes" to the editable "89".

webchick’s picture

As you identify edge cases, is it possible to come up with a View export that contains these edge cases (even in D7 if needed, not sure how much we can do with this in CMI yet)? That'd really help Kevin for refining the design to work on something tangible.

Wim Leers’s picture

Status: Postponed » Active
Issue tags: +sprint
FileSize
3.74 KB

Here's an initial patch.

Edit currently does in-place editing on a per-entity basis. But a View contains many different entities (e.g. nodes 1, 2, 3, 4 and 5). Hence the prototype in #12 would require very drastic changes in code that is currently already changing for other reasons (#1678002: Edit should provide a usable entity-level toolbar for saving fields, #1979784: Factor Create.js and VIE.js out of the Edit module, #1971108: Convert contextual.js to use Backbone (and support dynamic contextual links) and #1966704: In-place editing for taxonomy terms and custom blocks).

So, in this attached patch, you have to enable in-place editing on a per-entity basis by doing this in your browser console (it's what clicking the "Quick edit" link for other entities does):

Drupal.edit.app.model.set('activeEntity', 'node/1');

to switch to another entity:

Drupal.edit.app.model.set('activeEntity', null);
Drupal.edit.app.model.set('activeEntity', 'node/2');
Bojhan’s picture

@Koleary What are you planning on doing?

dawehner’s picture

Oh damn I totally forgot that. Here is just a list of "edge cases" on which there might be problems, without concrete views exports.

  • Multi-value fields: Let's assume you want to lis all images attached to a list of nodes. On each node, there might be more then one image. For that
    you can configure in the views UI to show each image as a separate row. This might be problematic because there are multiple rows associated with a single entity.
  • Relationship on the same type: A more or less common use-case for listing taxonomy terms is to list together with the name of the parent term. So technical a single row respresents multiple entities at the same time, so edit the whole line itself does not work.
  • Relationships between content types: Let's list some nodes together with it's authors. The name of the author might come from the author user, but what you actually want to change is the setting on the node (not the username itself). There might be the need to distinct between values and referenced values.
  • Non-editable fields. There are fields like an edit link, a custom text etc. which are not assosiated with the actual content, but are just views intern. The inline UI have to be able to take care about that
  • Aggregated values: Views allows you to build queries like: Give me the list of users + the amount of content they have created. This amount field is not editable at all, so this have to be different as well.
moshe weitzman’s picture

So technical a single row respresents multiple entities at the same time, so edit the whole line itself does not work.

For this issue to succeed, I think we have to overcome that assumption. Can the editor queue up edits per row and then send them for saving later? That is, can we get the editor to not care where the data comes from? If that sounds unfeasible, maybe we only allow editing one field at a time, and we save after each one. I know this differs from entity editing but Views is really its own (challenging) beast.

Wim Leers’s picture

Status: Active » Postponed

We discussed this at DrupalCon Portland; the conclusion is for in-place editing + Views to be successful, this needs to happen: #2010946: "Lifting" of data- attributes from a field to its containing "view cell" ([quick]edit.module integration).

This issue is now blocked on that issue and #1678002: Edit should provide a usable entity-level toolbar for saving fields.

webchick’s picture

Version: 8.x-dev » 9.x-dev

At this point, this is probably D9 and/or D8 contrib.

xjm’s picture

Per @dawehner, we will still want #2010946: "Lifting" of data- attributes from a field to its containing "view cell" ([quick]edit.module integration) in order for contrib to do this in a clean way. The alternative without that patch is custom preprocesses for every single views style the user might install from contrib or anywhere.

tkoleary’s picture

@xjm

That would be bad :/

Wim Leers’s picture

Issue tags: -sprint, -VDC, -Spark

Progress has been made in #2010946: "Lifting" of data- attributes from a field to its containing "view cell" ([quick]edit.module integration), this is now no longer blocked on feedback from me; I posted a review.

In the mean time, Edit should stop assuming that the "view mode" parameter is always an Entity API view mode. We want to make sure that a custom view mode is possible. The bottom hunk in #15's patch demonstrates this already, but it should be formalized.
For that, I opened #2083387: Make it possible to use in-place editing on entities rendered by a custom render pipeline (e.g. Views). Let's get that done, it's what enables in-place editing within custom render pipelines in Drupal 8 contrib!

Wim Leers’s picture

Issue tags: +VDC, +Spark

d.o tag monster--

Wim Leers’s picture

d.o tag monster--

saltednut’s picture

Issue summary: View changes

I assume an 8.x branch of http://drupal.org/project/edit_views would be the contrib mentioned in #20

Wim Leers’s picture

#26: correct.

xjm’s picture

Title: Edit + "Field" Views (table, grid …) » Quick Edit + "Field" Views (table, grid …)
Component: edit.module » quickedit.module
catch’s picture

Version: 9.x-dev » 8.1.x-dev
tkoleary’s picture

8.1? OK. Looks like I need to revisit the designs.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Wim Leers’s picture

Status: Postponed » Closed (works as designed)