Panelizer support (use Panels' render pipeline to re-render edited field panes in Panels)

It's probably because the view mode is missing. Can you paste the content of the ajax call to /edit/metadata for your page?

( edit ) very little was done for views/panels at the moment, this will be worked on in the coming weeks.

Thanks.

Yes, the _custom_display should be the proper view mode of the field.

I'm not working on the panels support yet, I'll be looking at that early next week.

Looked at it, we're going to need a panels wizard for the rescue. It's either very tricky or I missed a major piece of panels API that makes it simpler.

I have 4 days left on D7 edit module on it. With the other issues it's hardly possible for me to fix it for me in this time.

Trying to improve the title, because this problem definitely does not happen "out of the box".

Can you please confirm that this change accurately reflects the problem at hand?

Alright — thanks. Those specifics are very helpful :)

The Views half of this problem has been addressed in #1830518-25: Views integration (use Views' render pipeline to re-render edited fields in Views).

So let's make this issue solely about Panels.

The Drupal 8 backport (#2111667: Backport Drupal 8's Edit module to Drupal 7) has made this issue fixable! It brings explicit support for custom render pipelines by defining a custom view mode and implementing hook_edit_render_field(). See edit.api.php.

No matter what I do, I can't get a Panel node to use a custom display mode (which results in that _custom_display part at the end).

Until I get very clear and precise steps to reproduce, I'm afraid I can't solve this. I don't have enough experience with Panels to be able to get Panels node working properly, it seems to me.

Marking as a postponed feature request as per #2168725: [META] Add support for in-place editing entity types other than Node:

To get a 1.0 stable release of Edit out the door, a scope has been determined:

• support for in-place editing nodes
• support for using Edit in combination with Panels pages to do page layouts

Otherwise, Edit would probably be in a perpetual beta, in order to test against all entity types in Drupal 7. Drupal 7's Entity API was a contrib afterthought, not part of Drupal core, hence there are lots of subtle problems — Edit has helped consolidate Entity API in Drupal 8.

Thank you for your understanding.

@minorOffense are you saying there is a way to use edit module with Panels when it overrides a view mode? I know that edit module will work for nodes embedded in a panel but I can't get it to work at all if Panels overrides the view mode.

Marked two other issues as duplicates:

• #2169873: Compatibility with Panels / Panelizer
• #2214743: Edit with Panel panes not working for me

@minorOffense: Any pointers on how you got it to work?

I wonder if it was patched to remove integration with Panels after they discovered problems.

I've got it working, in these four scenarios:

1. panelizer view mode = page_manager, renderer = standard
2. panelizer view mode = page_manager, renderer = IPE
3. panelizer view mode = teaser et al, renderer = standard
4. panelizer view mode = teaser et al, renderer = IPE

I tested both the node title and the field_tags field in those four scenarios. The field_tags field was always overridden with a custom title in Panelizer, with the first field item hidden and the field items displayed in reverse order (to make sure that we definitely are using Panelizer's render pipeline). Always tested with an article node.

To get this to work, I've had to write some of the ugliest work-arounds I've ever seen. And I've seen quite a few, having written https://drupal.org/project/hierarchical_select. Many kittens were tortured in the process: Panels/Page Manager/Panelizer do a lot of things very, very wrong.
The first two scenarios (i.e. those using the "page manager" panelizer view mode) required awful hacks (see the "part 1" patch). But what's worse is that additional hacks are needed for the last two scenarios (see the "part 2" patch). There's only a fairly small shared set of required hacks.
Hence I put as much as I could in includes/panelizer.inc, so that the hackiness is as contained as possible. I'm especially nervous about it since it's nigh impossible to provide test coverage for this.

I'm posting this as a patch first instead of committing it right away, so that you can test it and provide feedback to make sure it's actually working before I tag a 1.1 release.

P.S.: make sure to clear all caches after applying this patch!

@Wm: Excellent work! Out of interest, for the problems you saw in CTools, Panels and Panelizer, how much of them are bugs / oddities that could be improved in those modules, thus lightening the load on Edit?

#23: the work-arounds fall in two categories:

1. small things that are being done incorrectly, but could be fixed fairly easily ("oddities", best example: panelizer_panelizer_pre_render_alter() in the patch)
2. more fundamental flaws, that either require rearchitecting or big BC breaks ("bugs", best example: panelizer_ctools_render_alter() in the patch)

Since I've never been successful in getting fixes committed to Panels, I didn't even consider filing patches. Should I reconsider that? :)

As it happens, I know one of the Panelizer co-maintainers ;-)

Panels is co-maintained by Jakub Perry from Acquia and Panelizer is co-maintained by Damien here so we should be good with patches for both going forward.

I was trying to get the patch from #23 working but not having any success at first. I tried two workflows:

1. Install Drupal (using Lightning profile) with Edit 1.x-dev and Panelizer 3.x-dev
2. Appy patch
3. Clear all caches

or

1. Install Drupal (using Lightning profile) with Edit 1.x-dev (patch already applied) and Panelizer 3.x-dev

Both scenarios result in this JS error on Panelizer pages:

Uncaught TypeError: Cannot read property 'getAttribute' of undefined

I was worried maybe this was profile specific so I went ahead and subverted using the Lightning profile and went with vanilla Drupal 7.28 + Panelizer 3.x-dev (and dependencies Ctools and Panels both in dev) + Edit 1.x-dev with the patch applied and its dependencies (Entity 1.x-dev and Libraries 2.2). In this scenario... it seems to work. So now trying to figure out whats up with Lightning, but I think this is safe to RTBC if @DamienMcKenna approves.

I did some more testing with this and right now I can only get it to work using the Standard renderer. When I switch over to IPE, I get the Uncaught TypeError: Cannot read property 'getAttribute' of undefined.

Demo: http://lightningfreedev.devcloud.acquia-sites.com
I have this mocked up to try out on this site. You can login with the user 'demo' and password 'demo' - the role is set up to allow creating and editing content. Basic Pages do not have Panelizer. Articles have Panelizer with Standard renderer. Landing Pages have Panelizer with IPE (error shown there).

I've now locally reproduced the problems described in #28. I can reproduce all problems with the "Landing Page" content type. For some reason, the data-edit-entity-id attribute does not get set for Landing Pages, which cases that JS error. But even if that weren't the case, it should break, because for some reason the view mode gets set to panelizer- instead of panelizer-<panelizer view mode ID>. Currently investigating.

Note that on your demo site, Panelizer is not enabled for Article nodes, unlike what you're saying. I don't have permission to enable it there, but please enable it to verify that it is indeed working in that case.

Very happy to report that not only did I manage to fix it, but fixing this actually required me to remove a bunch of hacky code :) The situation is now a bit better!

(In short: I confused testing IPE + page_manager with IPE + teaser, and hence came to wrong conclusions and more complicated than necessary and because of that incomplete work-around.)

Now the patch is relatively sane:

• for page_manager ("full page") nodes, we have panelizer_ctools_render_alter() to add data-edit-entity-id
• for panelizer view mode ("actual view mode") nodes, we have edit_preprocess_panelizer_view_mode()
• hack #1 is to fix the contextual-links-region element being set on the wrong element (in edit_ctools_render_alter())
• hack #2 is to pass the panelizer view mode along with the entity being rendered, because that's information that's otherwise impossible to get at

(Also moved some things around to make it easier to follow along.)

Just tested #30 locally and its working well in all the scenarios I've tested. Have not had time yet to update the environment but I think this looks good from my tests.

Re: the demo environment.
Panelizer is enabled on the Article content type (its being overridden) but since the IPE is not turned on for that bundle, the 'Customize' and 'Layout' buttons are not enabled. You should be able to see the 'Panelizer' local task though if you are logged in and edit the panels stuff from the back-end.

So, let's try to make this patch simpler by fixing the other modules.

For hack #2, I opened #2267601: Impossible to get (or even calculate) the Panelizer view mode in theme layer.

For hack #1, I tried opening an issue with a suggested fix, but to fix it, we either need to introduce a new hook in the if (module_exists('contextual') …) {…} part of ctools_context_handler_render_handler(), which is a no-go, or we must fix the CTools API and therefore break it. The key problem is this:

      $build = array(
        '#theme_wrappers' => array('container'),
        '#attributes' => array('class' => array('contextual-links-region')),
      );

      if (!is_array($info['content'])) {
        $build['content']['#markup'] = $info['content'];
      }
      else {
        $build['content'] = $info['content'];
      }

This causes contextual-links-region to be set on a newly created container of the actual contextual region, instead of on the actual contextual region. The reason it works this way is because $info['content'] is allowed to be a string. That should not be allowed; it should always be a render array. (This is where an API change would be necessary.)
Because a string may be returned as the main page content instead of a render array, it's impossible to just set a class on the top-level element render array. Hence the way CTools works around this is by necessity. But Edit needs to be able to set an additional data- attribute on the same element as the element that has the contextual-links-region class. But to do so, we would need to add an additional hook — it is assumed that no altering is ever necessary here; which would be true, if contextual-links-region were actually set on the right element, but that's impossible, because it may have to operate on a string of markup instead of a renderable array.

Conclusion: removing this hack is going to be more effort than it's worth.

I think this is ready to go.

@Wim: Can you please submit a patch in #2267601: Impossible to get (or even calculate) the Panelizer view mode in theme layer for whats needed there, I'll give it a review. Thanks.

#34: it's in the issue summary; can't you just indicate whether that's an acceptable solution?

Updated to work with the patch in #2267601: Impossible to get (or even calculate) the Panelizer view mode in theme layer.

Interdiff?

I tested this out. The edit infrastructure does indeed load on a Panelized page, with fields being available for editing via a contextual menu. However, I don't see any way of saving the changes - there's no "save" button visible either globally, or in Admin Menu or Navbar. Am I missing something?

An intediff for the patch in #36, as requested.

Re #38 - the 'Save' button appears only after making a change to a field. Screenshots below.

Before making an edit

After making an edit

Did either of you try it with ckeditor?

I have, yes.

@Brant: Try nesting the WYSIWYG field in a field group.

Ok, it seems that #2190213: Add support for Field group was causing my testbed to not work correctly.

Ah - I thought you might be trolling me for a minute there. :)

Excluding the Field Group support, this appears to be working. Excellent sleuthing, Wim!

FYI I committed the patch in #2267601: Impossible to get (or even calculate) the Panelizer view mode in theme layer.

One minor bug I found. Rendering a File Entity via Views provoked the error, but this could happen to any non-panelized entity I suppose.

The Panelizer view mode is not always set for every entity type, so we should ensure it exists before we start doing stuff with it.

#48: Perfect, thank you!

And… committed! At last! :)

Attached is the patch that I committed — it has the necessary renaming since #2276941: [meta] Rename edit module to quickedit happened.

Brant: please do a final round of testing to confirm it's all working, then I'll tag a 1.1 release :)

After switching to the 'Quick Edit'-module on latest Spark d7 php 5.3 the attached error message appeared. Any ideas?