Panels /node/%/edit forms

Thanks for pointing this out Blue_Jumpers_Filip. We need a task plugin for node/%node/edit that follows the same basic structure as the patch in #1188590: Task plugin for 'node/%node/draft' and 'node/%node/revisions/%/view' The fact that Workbench Moderation is already using hook_menu_alter() on this path might complicate things.

Blue, If you have the time and knowledge please write such a patch and post it here. I'd rather not delay the other patch for this one.

Discovered this after posting [what I think is] the same issue over in #1532244: Ctools page manager unable to override node_edit form because of workbench_moderation_node_edit_page_override. Has there been any movement on this? I'm in the same boat, where I want to clean up the admin experience for my users, but workbench_moderation is preventing the use of panels/page manager to modify the node/%node/edit form.

I've actually started working on this based on the work in #1188590: Task plugin for 'node/%node/draft' and 'node/%node/revisions/%/view' and should have a patch soon.

So I started looking into this and there are a couple of things that could be done.

1) You can create a new custom Task for node/%node/edit

This is the path I originally went down.
This would require that workbench_moderation_menu_alter *NOT* clobber node/%node/edit (since that is what keeps you from assigning the panel page to that path)
BUT on a similar note - it would also mean that the 'virgin' page_manager task provided for node/%node/edit would also not be available for other uses.

I chatted with EclipseGc about this and figured there had to be a better way. He agreed and pointed me in a new direction.

2) Create an argument and context plugin for workbench_moderation moderated nodes
I also went down this path, but ran into some issues (but maybe its the overall better way to fix this).
I started by cloning the code of the original ctools provided 'node' plugins for both the argument and the context - and adjusted the context plugin to find the current 'draft' node to load up for editing.
But, the node context is deprecated in favour of the entity context - fair enough.
So I cloned that code, but really there is only a single line that needed changing -

elseif (is_object($data)) {
    $ids = entity_extract_ids($entity_type, $data);
-  $id = $ids[0];
+ $id = $ids[1];
  }

And that is only because despite passing in the draft version of the node to the entity context - it would get the ids of the entity (i.e. original node id and vids) and return the original nid and then set the context to that (undoing the discovery and loading of the draft node in the argument plugin).

As I type this I realize I could have simply returned the id of the draft node to the context and I could have simply used the original entity context - and not created a custom one.

Regardless I got to that point, and configured a panel page with the new argument and loaded entity. This all worked but I then ran into an issue with diff module and had to shelve this for a bit.

So after typing this out, I'm going to go back and make a few fixes and attach a patch to have some other eyeballs on this.

I continued to plug away on this one. In the end all the plugin creation was overkill (and never quite working right). I was able to simply make an alteration to the existing ctools and page_manager plugins via alter hooks.

The solution was so simple in fact, I kind of hate myself for having wasted so much time exploring the other options.

Patch is against 7.x-1.x

Same patch slightly better code comments.

Here's a patch against the 1.1 release if you're a drush make and apply patch kind of person.

I've applied the patch in #7 and it's working well so far, will comment if I see any issues.

Any chance the patch will be included in the next version of Workbench Moderation?

I am bit confused here, I wonder if someone could shed some light on this - from what I can tell this patch is included in the 7.x-1.2 release from May 17. However, as soon as I enable workbench_moderation my page override for node/edit gets disabled. Then when I go to re-enable it I get the following message which I thought this patch was supposed to address:
Page manager module is unable to enable node/%node/edit because some other module already has overridden with workbench_moderation_node_edit_page_override.

Any help is appreciated!

Looking at the commit log it seems to have not been committed for the 7.x-1.2 release, however the patch does apply cleanly to that release. I assume the maintainers are waiting further feedback on any issues, or that it is in the dev branch and will be in a future release.

I've not had a chance to test it yet, but will report if I do and see any.

Verified patch against latest and everything works!

Patch #7 on 7.x-1.2 is working for me so far.

Thanks!
-Tim

Working nicely for me as well.

The patch works great, but the comments are a bit circumspect, and I'm not 100% sure of the approach.

But, I would definitely consider this a bug. I had just finished carefully crafting a node edit form, and enabling this disabled it with no warning at all.

Can you clarify which comments are circumspect? In this thread or in the code iteself?

Can you clarify which part of the approach you're unsure of?

Also, did the application of this patch break the node edit form you had crafted or fix it?

Attaching update to latest dev sha: d196989

#17: playnicewithpanels-1285090-12.patch queued for re-testing.

Seems to work for me.

Fixed a documentation issue quickly.

Correction to the last patch file by iSoLate.

works for me against 7.x-1.3
thank you!

Works for me for 7.x-1.3 as well

Works for me, thanks for your work on this.

Just updated to 2.x version and it ruined my nice panels based edit forms.

Could someone update this for the 2.x dev, pretty please?

RTBC++

The patch in #22 works for me! This is necessary in order to use Workbench Moderation with OpenAtrium 2.0 or any other Panopoly-based distribution.

I've attached a patch with an alternative approach.

While the patch in #22 works - it's pretty complicated and Panels-specific. My goal was to come up with an alternate place to put the code added in the page callback, so that the page callback override wouldn't be necessary at all. That would be a super clean, simple fix and it wouldn't be Panels-specific!

However, it turns out that I couldn't find anything that worked except for abusing an access callback. :-/

So, while this approach is much smaller and not Panels-specifc, it is definitely a HACK! I'll leave this issue as RTBC (which applies to the patch on #22, not this one) but it'll be up to the maintainers to decide which they prefer.

I have a change for #29 that will prevent it from performing some unnecessary node loads and in my cause displaying a full screen error. I posted it in another issue before I realized the function was a part of this patch. Please see the issue for details:

#2265641: workbench_moderation_node_edit_access_override can cause problems.

The approach in #29 is more something that belongs in a custom module for a particular site, definitely not something to be included in Workbench Moderation itself. It abuses the access callback of a route in the core Node module to do something that is not access related.

The patch in #22 seems a much more promising approach. I reviewed it but it does have some issues, especially in the documentation:

1. +++ b/workbench_moderation.module
   @@ -2113,3 +2113,103 @@ function workbench_moderation_ctools_plugin_api($module, $api) {
   + * If this is a the ctools node_edit arguments plugin provide a different context
   + * creation callback.
   + * Also if this a page manager node_edit tasks plugin provide a different
   + * hook_menu_alter callback.
   + */
   

   This documents _what_ the code does, but not _why_ this is needed.

2. +++ b/workbench_moderation.module
   @@ -2113,3 +2113,103 @@ function workbench_moderation_ctools_plugin_api($module, $api) {
   + * @see workbench_moderation_ctools_plugin_pre_alter
   + *
   

   Put braces() after the function name.

3. +++ b/workbench_moderation.module
   @@ -2113,3 +2113,103 @@ function workbench_moderation_ctools_plugin_api($module, $api) {
   + * page_manager_node_edit even though workbench_moderation has its own
   + * hook_menu_alter implementation that defined a different page callback.
   + * Page manager can handle this path for workbench moderated nodes because of
   

   * page_manager_node_edit()
   * hook_menu_alter()

4. +++ b/workbench_moderation.module
   @@ -2113,3 +2113,103 @@ function workbench_moderation_ctools_plugin_api($module, $api) {
   +    variable_set('page_manager_node_edit_disabled', TRUE);
   +    if (!empty($GLOBALS['page_manager_enabling_node_edit'])) {
   +      drupal_set_message(t('Page manager module is unable to enable node/%node/edit because some other module already has overridden with %callback.', array('%callback' => $callback)), 'warning');
   +    }
   +    return;
   

   Why set a variable if it is such a cheap check? To prevent the message from showing up more than once? I don't see any place where this variable is deleted again after the situation is fixed. I would just log a notice with watchdog instead.

5. +++ b/workbench_moderation.module
   @@ -2113,3 +2113,103 @@ function workbench_moderation_ctools_plugin_api($module, $api) {
   +      if (!empty($GLOBALS['page_manager_enabling_node_edit'])) {
   +        drupal_set_message(t('Page manager module is unable to override @path because some other module already has overridden with %callback. Node edit will be enabled but that edit path will not be overridden.', array('@path' => $path, '%callback' => $items[$path]['page callback'])), 'warning');
   +      }
   

   I wouldn't show this message in the frontend where it is potentially seen by non-technical editors or visitors. Use watchdog or hook_requirements() instead.

6. +++ b/workbench_moderation.module
   @@ -2113,3 +2113,103 @@ function workbench_moderation_ctools_plugin_api($module, $api) {
   +    // Why str_replace things back?
   +    $items[$path]['page arguments'] = array($type->type);
   +  }
   

   Well that's a good question, there is no str_replace() here :)

7. +++ b/workbench_moderation.module
   @@ -2113,3 +2113,103 @@ function workbench_moderation_ctools_plugin_api($module, $api) {
   + * Custom context creation callback for the ctools node_edit arguments plugin
   + * @see workbench_moderation_ctools_plugin_pre_alter
   

   Comment should end in a period.

8. +++ b/workbench_moderation.module
   @@ -2113,3 +2113,103 @@ function workbench_moderation_ctools_plugin_api($module, $api) {
   + * @see workbench_moderation_ctools_plugin_pre_alter
   + *
   

   Append braces() to the function name.

9. +++ b/workbench_moderation.module
   @@ -2113,3 +2113,103 @@ function workbench_moderation_ctools_plugin_api($module, $api) {
   + * workbench_moderation_node_current_load.
   + */
   

   Missing ().

10. +++ b/workbench_moderation.module
    @@ -2113,3 +2113,103 @@ function workbench_moderation_ctools_plugin_api($module, $api) {
    +    // If unset it wants a generic, unfilled context.
    +  if ($empty) {
    

    Indentation.

@pfrenssen

1) The reason why is that without this you can't have panels on a node edit page with workbench moderation. This very issue is the answer to that.
2) Nit, but correct.
3) ??
4) This variable is all about page manager and keeping other panels from overriding the same node/edit form.
5) This would be displayed in the back end not the front end.
6) If you see the comment describing the function "This callback is the same as the original defined in the plugin except..." its literally copied and pasted. I figure the comment meant something to the original author.
7) Nit, but correct.
8) Nit, but correct.
9) Nit, but correct.
10) Nit, but correct.

So nothing much has changed since #6 two years ago. This solution works. And is probably the best solution to this problem given the api's and how page manager and workbench moderation works. Easy patch for someone who'd like to fix 2, 7, 8, 9, 10 to probably get this back to RTBC.

Nevermind

Any news on this? I am considering to use Open Atrium Workbench and I see this issue is critical for it.

Rerolled the #22 patch to work with workbench_moderation-7.x-1.4

#36 is working for me.

My remarks from #31 are not yet addressed.

I used the patch from #36 and applied whatever I could/though appropriate from comment #31 and taking into account #32. Maybe pfrenssen wouldn't mind addressing the rest himself?

Not working here - everything is working up I enable and configure 'node_view' at admin/structure/pages - my draft at node/1/draft is showing the same content as node/1, however the correct content shows at node/1/edit (Draft Edit mode), I've tried this is combination with the test patch at #2447659: "View draft" opens published version / "Edit draft" opens correctly

Thanks. #22 worked just fine.

@dgtlmoon I had the same issue and was also confused by the title of this issue. See https://www.drupal.org/node/2020325 for the solution to your problem.

Patch #40 works for me.

Patch #40 works for me against workbench_moderation-7.x-1.4

Somehow, the node/edit Panel worked, but then after disabling it, I was unable to reenable it.
#40 patch is working so far.

patch #40 is working fine, thanks!

Patch #40 worked for me too. Back to work on Panopoly... :)

Patch #40 works great!

Patch #40 works for me too

Patch #40 doesn't work for me, on 7.x-1.4+9-dev :(

Patch #40 still works great even on workbench_moderation 7.x-3.x
we were previously using this with 1.x as well.

Thanks!
Please commit this

a cache clear after patching should resolve #53

Confirmed patch #40 working fine on latest 7.x-3.0+5-dev

That's RTBC + 8 so far with the only fail reported on older and no longer available 1.x

RTBC+ patch #40

+1 on RTBC.

Patch #40 solved our issue as well applied on 7.x-3.0

adding another similar related issue

@joseph.olstad Committed and pushed to 7.x-1.x / 7.x-3.x as per request.