Views integration (use Views' render pipeline to re-render edited fields in Views)

Possibly; only if Views uses regular Field formatters. Postponed until after feature freeze.

That works if views display content, not individual fields now.

What's the plan for this? will be like panels, really tricky to get rerendering right.

They're doing more than just calling field_view_field() with some kind of animation? i.e., Views is probably wrapping it in something else, which might be some kind of "internal Views render pipeline", which is hard to get at?

That's an important one, will see how it goes today.

Got a first implementation, basically, same problems as panels, there is no view mode so we don't have the necessary informations for rerendering the field properly after it's been edited.

No support for title, author or date field yet.

http://drupalcode.org/project/edit.git/commitdiff/1206b74bcf24964df30e5c...

title supported now, should be the same with author and date, haven't tested yet.

Aaaaand it works with ajax views now :)

Doesn't seems to work with Rendered Entity fields for now ;(
Needs work.

Turning into a meta. There are a lot of aspects for views integration what's supposed to be working now are views fields. I can't say anything for the rest :)

Please file a new issue and update the issue summary, it'll be easier to track this way.

Created a new issue for the bug I've described in 8 and updated the issue description.

Subscribe

Thanks very much for your work.

I reckon a simple solution for editing data in views (specifically for me in tables of multiple nodes) would be hugely appreciated by the community. It would certainly be hugely appreciated by me.

If anyone else has found a good workaround (I've looked at slicktable - rendering issues and Editable fields - you have to patch it for D7) I'd love to hear about it.

Cheers.

The commit mentioned in #5 — http://drupalcode.org/project/edit.git/commitdiff/1206b74bcf24964df30e5c... — introduced:

1. .edit-inline, but it's no longer used
2. a new parameter to edit_wrap_pseudofield(), but was never documented

Fixed both: http://drupalcode.org/project/edit.git/commit/c5fb045

Oops.

.

As nod_ alluded to in #5, it "works" right now, but only in a very, very broken & hackish way.

Views has its own render pipeline, and thus doesn't care (AFAICT) about the Node/Entity/Field "view mode" and that render pipeline. But that's the only pipeline that Edit module was designed to work with.

So I pinged Views maintainer dawehner on IRC to ask how we could achieve this:

So I'm currently struggling with Edit in Drupal 7. nod_ has done as much as he can to make Edit work with Views without diving very deep into Views. So, it is now possible to edit Entity Fields in Views. BUT! We currently re-render it via the field module render pipeline, not the Views module render pipeline. So, when the modifications are saved, the re-rendered result can look completely wrong. How can we fix that?

The current implementation (which doesn't use the Views render pipeline) can cause the most bizarre problems, like this one: #1951182: Ajax HTTP Error 500 when editing a hidden image . That user has configured his node to *not* display a particular field (i.e. on the corresponding node page, that field would not show up at all). He then has a View that does show the image. Because we use the entity/node/field render pipeline, and that one is configured to hide that particular field, upon editing the image field via the View, it causes total breakage.

IMO, we should disable all Views integration until we can provide at least some assurances about reliability, currently we cannot provide any.

Worst case, we will need to trigger a full page reload after each-place edited field… This is the worst case scenario, in case Views is insufficiently flexible; i.e. if it does not allow us to use the Views render pipeline to re-render a single "Views field" (which in turn contains a (Entity) Field).

Another area where our very, very experimental Views integration shines through: we're probably adding our output wrapping at the wrong stage, because it currently has the potential to break "group by" Views; I tried to "fix" it with a work-around: #1905074-5: Views Group By broken, because Edit module even applies its output wrapping to hidden fields.

And another one: #1946856-3: Views sometimes strip tags, causing Edit & display to break.

I think I managed to fix one Views integration issue: #1905074-5: Views Group By broken, because Edit module even applies its output wrapping to hidden fields :)

Yeah the views "render pipeline" is certainly kind of ugly and has problems to deal with such an use-case in all kind of areas.

Views has its own render pipeline, and thus doesn't care (AFAICT) about the Node/Entity/Field "view mode" and that render pipeline. But that's the only pipeline that Edit module was designed to work with.

Right, instead of a view mode views passes along the formatter settings directly to views_field_view, kind of similar like panels does it.
If you could put in additional metadata (the view name + view display_id + field name) you could just pull out this formatter settings and use it directly in edit_field_edit().

Something like this kind of code should give you the settings
so you could do something similar then views_handler_field_field::set_items()

$view = views_get_view($name);
$view->set_display($display_id);
$view->init_handlers();

$view->field[$field_name]->options['settings'];

Even this might fix a bunch of issues, for example #1946856: Views sometimes strip tags, causing Edit & display to break would not be fixed, because this kind of rewrite features
are implemented on the style plugin level. That's needed because for example rewrite on tables mean something else then rewrite on a simple ul-li listing. In order to support that there seems to exist only ugly hacks:

Setup a view with just a single entity as result and try to call template_preprocess_views_view_fields() and pull out the changed field.

Btw.: In theory you could change a value, so the row itself should disappear, because one of the filters might apply then,
which then indeed would require a full reload of the rendered view.

Thank you, dawehner, that comment is full of awesome information! :)

FWIW: I did not say Views' "render pipeline" is ugly — I just don't know how to use it! That's why I pinged you for pointers :)

So, you're saying:

1. more metadata is needed: a View's: 1) name, 2) display ID, 3) field name (the Views field name, that is) — makes total sense!
2. BUT: isn't some kind of "row ID" missing? AFAICT the above information identifies a column within a view that is rendered in a certain way (display), but not a particular row.
3. (Edit should then use this additional metadata to call Views' render pipeline instead of the Node/Entity/Field render pipeline.)
4. AND: you showed how we can retrieve the specific settings for a field, but I still have no idea how to actually render just one specific field.
5. FINALLY: indeed, Views' "Rewrite" functionality is always going to have the potential to interfere with in-place editing. Which makes me think: is it a good idea at all to make fields in-place editable in Views? Should we create an in-place editable version of each Field that's available as a Views Field and then prevent all the rewrite options from being applied to these?

Your "btw" is also a great remark. I have no idea how we can efficiently detect that. I think it would be acceptable to not have filters re-apply after a user has made changes. But can this also mean that a View will refuse to re-render a modified Views field because it would not be rendered on reload due to the applied filters?

#1900462: Support Rendered Entity Views field is a non-problem, it works great, precisely because it's rendered by the Entity/Node/Field render pipeline.

1. BUT: isn't some kind of "row ID" missing? AFAICT the above information identifies a column within a view that is rendered in a certain way (display), but not a particular row.

   The problem with a row ID is, that you would also need the total result, as the result might change in the meantime. The actual entity ID fit's somehow much better.

2. AND: you showed how we can retrieve the specific settings for a field, but I still have no idea how to actually render just one specific field.

   You could maybe setup a fake $view->result and run the views render pipeline, which then will call the render method on the field.

3. FINALLY: indeed, Views' "Rewrite" functionality is always going to have the potential to interfere with in-place editing. Which makes me think: is it a good idea at all to make fields in-place editable in Views? Should we create an in-place editable version of each Field that's available as a Views Field and then prevent all the rewrite options from being applied to these?

   This would certainly safe a lot of potential problems, though the users would have to reconfigure their views. Not sure about the workflow you want to have with just the edit module, but I guess people would love to just use it on existing fields.

4. Your "btw" is also a great remark. I have no idea how we can efficiently detect that. I think it would be acceptable to not have filters re-apply after a user has made changes. But can this also mean that a View will refuse to re-render a modified Views field because it would not be rendered on reload due to the applied filters?

   The more I think about it, the more it seems to be that the user actually don't want to have the filter applied, because the main point of using
   inline editing seems to be, to see the actual changed viewable output on a particular entity, not of the actual total result. That's though just guessing.

@wimleers
my cents on http://drupal.org/node/1830518#comment-7234030

In 5. you say:
FINALLY: indeed, Views' "Rewrite" functionality is always going to have the potential to interfere with in-place editing. Which makes me think: is it a good idea at all to make fields in-place editable in Views? Should we create an in-place editable version of each Field that's available as a Views Field and then prevent all the rewrite options from being applied to these?

there are a lot of working solutions in other module.
I must say here, I have only looked a little bit in the code of the edit module.
Think these are way that could be done.

VBO way
Views bulk operation module adds a VBO to views, that must be used if a a view should be a VBO view. Independet from the views style, so you can use it with table style or unformatted style.

Pro: Simple and it worked
Contra: All fields or single fields in a view are editable. another point is that it does not use JS.

Editable fields
the module provides an field formatter and a fallback formatter.

Pro: worked in views und uses JS. single fields or some fields in a view can be editable.
Contra: modules uses the full drupal bootstrap to load it via field api.

Simple Checkbox
Another way could be to provide a simple checkbox for every field in the views field configuration.

greets bennos

Views bulk operation module adds a VBO to views, that must be used if a a view should be a VBO view. Independet from the views style, so you can use it with table style or unformatted style.

The VBO way is just a explicit way in the views API to register form elements. As edit module can't hook directly in the way a single handler is rendered, I don't see a way how to use that.

#23: The whole point of Edit module is that it works *without* modifying anything. You make it look like you want it to look, and it is still possible to do in-place editing. If we can't do that, then there's no point in making Edit work for Views.

Attached patch makes in-place editing on fields in Views use Views' render pipeline. It's still a prototypey patch in that it hardcodes support for Views, but it's easy enough to generalize the current code (see the @todo).

A lot of thanks go to dawehner, without whose help this would have taken much, much longer to figure out. Thank you!

Attached is a 30-second screencast that shows it in action.

Also see concerns about in-place editing of "Field" Views (like the one in the screencast) in the corresponding D8 issue: #1962606-2: Quick Edit + "Field" Views (table, grid …).

Yeah, I haven't tested this with any sort of Relationships or re-written fields yet, but currently it breaks on something as simple as displaying the NID of a node. In the edit_metadata page callback, if even a single field fails, the whole page callback returns a MENU_NOT_FOUND response rather than assembling the rest of the editing metadata for the fields which did not fail. This means that NID (which isn't an "extra field" nor a normal field) breaks the process and causes a View to not have any editing metadata attached, as well as generating an ugly error popup when the page initially loads.

Yeah, hacking this:

    if (!_edit_is_extra_field($entity_type, $field_name)) {
      if (!$field_name || !($instance = field_info_instance($entity_type, $field_name, $bundle))) {
        return MENU_NOT_FOUND;
      }
    }
    else {
      $instance = array('field_name' => $field_name);
    }
    if (!$langcode || (field_valid_language($langcode) !== $langcode)) {
      return MENU_NOT_FOUND;
    }

to instead be this:

    if (!_edit_is_extra_field($entity_type, $field_name)) {
      if (!$field_name || !($instance = field_info_instance($entity_type, $field_name, $bundle))) {
        continue;
      }
    }
    else {
      $instance = array('field_name' => $field_name);
    }
    if (!$langcode || (field_valid_language($langcode) !== $langcode)) {
      continue;
    }

fixes that problem by just skipping those fields. I don't know if that is likely to break Other Stuff™ elsewhere in the module though; I assume someone had a good reason for causing a full metadata 404 if one of the fields was unavailable.

I have applied Kazanir's hack from #28 and it also has fixed the issue for my view displaying an image field with a default image. Here's a patch that makes the changes above. I have done some cursory testing and haven't noticed any issues. I'll post back if I do notice something.

#27–#29: Thanks — currently this is on hold because we're first figuring out in #1962606: Quick Edit + "Field" Views (table, grid …) how to make the in-place editing UX work well even for complex Views.

this patch fixes a similar issue
https://drupal.org/node/2015295

@Wim: it might help to have some maintainer advice on these connected issues:
* #2015295: Edit Module fails for "pseudo" fields provided via Relationship or Appended Global Text in Views
* #2022031: Support Views Relationships
My educated guess is:
* #2015295: Edit Module fails for "pseudo" fields provided via Relationship or Appended Global Text in Views That RTBC fix might be committed asap to lower pain, and does not interfere with this issue
* #2022031: Support Views Relationships That feature request will be implemented or enabled by this issue.

Updating the description because now this is a meta issue

I committed the patch in #25 while moving the Edit + Views integration into a separate module: http://drupalcode.org/project/edit_views.git/commit/2908558.

Please see #2149185: Figure out a way to *start* in-place editing inside a View — on a per-entity basis, just like elsewhere on the problems we need to solve before we can make Edit + Views integration a reality.