Posted by dhina on January 12, 2012 at 4:27pm
27 followers
| Project: | Workbench Moderation |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
I created a new draft from a published node, edit it and save. The next screen is View draft screen.
Here i am not seeing any of the updates made to the node.
Is it a bug or am i missing something here?
Comments
#1
I am not able to reproduce this. I have made a published node. I make a new draft. I see the published version at node/%node and the draft with the changes I just made at node/%node/draft. Are you seeing the same published version at at both node/%node and node/%node/draft ?
#2
Yes.I am seeing the same published version at both node/%node and node/%node/draft.
(I am using panels/panelizer)
#3
I was looking into the code and found out that in this function,
function workbench_moderation_node_view_draft($node) {$current_node = workbench_moderation_node_current_load($node);
return workbench_moderation_router_item_page_callback($current_node);
}
$current_node gets the edited draft.
But the return statement returns with the current published node.
#4
turns out to be my config issue.
Now i can view draft node properly.
(Still having issues with panelizer creating new draft.may have to open a bug there.)
#5
Panelizer uses the id of the published revision rather than the draft (if it exists) when Workbench Moderation is enabled. On save, the draft content is replaced by a new revision using content from the published revision. Draft content is lost as the moderator sees it.
This is the code from workbench_moderation which gets the current node revision.
function workbench_moderation_node_current_load($node) {// Is there a current revision?
if (isset($node->workbench_moderation['current']->vid)) {
// Ensure that we will return the current revision
if ($node->vid != $node->workbench_moderation['current']->vid) {
$node = node_load($node->nid, $node->workbench_moderation['current']->vid);
}
}
return $node;
}
I'd like to determine if there is a way to make these two modules compatible.
#6
This weakness of workbench moderation is part of why I wrote ERS which does not have this problem, or at least, has ways around this problem that did not require modifying Panelizer to look for a different revision ID.
I'm not really sure there's a clean way to make these two modules work together.
#7
Thanks! This is what I suspected.
#8
I was beating my head on my desk trying to figure out WHY when I made changes to the layout that it kept on reverting to the previous layout setting.
If you are using Workbench Moderation you have to publish your draft after a layout change for the layout changes to take effect and be viewable.
#9
Should it be on Workbench's head to handle overriding the CTools / Panelizer operations, given it is Workbench that is changing what it means to load the display page for a given entity ID? Does Workbench work with Panels?
#10
I don't think workbench moderation can work with panelizer. The two modules would have to cooperate at a pretty high level in order to work together.
#11
We're using the Revisioning module with a site and I'm poking into the problem.
What we're currently seeing with the v7.x-2.x-dev version of Panelizer is that when you save any per-object overrides, the form reloads with none of the changes visible, everything's exactly the way it was prior to the changes being saved. I've tested this both with the "Create new revision" option selected and deselected, that didn't make any difference.
After verifying that there was a problem I then checked the database. Surprisingly enough the records in panelizer_entity, panels_display and panels_pane are correctly updated, they just aren't loaded correctly on the panelizer "content" form.
#12
Digging into it further I've found that the panelizer_edit_content_form() form loads the current entity using the current_revision_id whereas every time Panelizer saves it creates a new revision, even if you tell it not to.
#13
Scrap that, was looking at the wrong installation.
#14
Try this for size. I was digging through the $form object in panelizer_add_revision_info_form() and realized that the '#submit' handler was being added to the root of the $form, i.e.:
<?php$form['#submit'][] = 'panelizer_add_revision_info_form_submit';
?>
However the existing form submission handler was being defined in $form['buttons']['submit']['#submit']. I changed the line above and it started working correctly!
In my limited testing this appears to resolve the problem using the Revisioning module, I'd like to get feedback on a) whether it fixes the problem with Workbench Moderation and b) whether merlinofchaos thinks it's the correct way of handling the problem, for all I know the patch could be opening up another can of worms.
#15
This seems to produce some really nasty problems in some cases, mostly when having a revision that's not yet published, and using the "panelizer" tab. Basically you can lose or not see your panelizer changes just made, or ending up with inconsistent or almost empty panes. Not sure how to handle or go forward with this, but a.t.m., the only way to use panelizer on sections with consistent behaviour is to always use the IPE and always use it with the published revision being the latest one.
Does anyone of you have made the same experience?
I gather the patch in #14 is only trying to fix the problems with revisioning but not workbench_moderation?
#16
@danielnolde: I'd like to hear whether it resolves any issues for anyone else.
#17
Seems to work for the simple case of editing the panel. However, changing the layout still creates a new revision. Perhaps the same fix should be applied to all four subpages?
Regarding the overall issue, the reason why I hit my head on #1804156: Panelizer always creates a new revision was related to trying to make a workaround to make panelizer and workbench_moderation play ball. I believe I have found a working solution by having workbench_moderation implement hook_entity_load, and ensure that the entity is the current revision when the path is node/*/panelizer*, which is the same technique ERS uses.
Further form_altering the panelizer forms to ensure that the checkbox for creating a new revision is checked when the current version is the published version, will hide the logic from the end user and let panelizer edit the current version, and only create a new draft when the current version is published, which I think makes sense.
This could either be in workbench_moderation, or put in an add-on module.
#18
@Xen: Ah, yes, I see that now. Also, each of the other forms has a different structure, a different location for listing the submit handlers.
#19
Lets move discussion of the "make it work with revisions" to #1804156: Panelizer always creates a new revision and leave this focused on identifying what's necessary for Workbench compatibility.
#20
Here's a patch for workbench_moderation that implements what I mentioned above. It's dependent on #1804156: Panelizer always creates a new revision to really work, but it's testable whether panelizer gets the right revision.
#21
@Xen: you forgot to attach the patch :)
#22
What the...
Donno what happened, but d.o has seen the file before, because it adds a _0 suffix..
Oh, very well, here it is...
#23
Applied patch and got this error on the panelizer page:
PDOException: SQLSTATE[42803]: Grouping error: 7 ERROR: column "r.vid" must appear in the GROUP BY clause or be used in an aggregate function LINE 1: SELECT r.vid AS rvid, r.nid AS nid, MAX(vid) AS vid ^: SELECT r.vid AS rvid, r.nid AS nid, MAX(vid) AS vid FROM {node_revision} r WHERE (r.nid IN (:db_condition_placeholder_0)) GROUP BY nid ORDER BY r.vid DESC; Array ( [:db_condition_placeholder_0] => 37 ) in workbench_moderation_entity_load() (line 233 of .../sites/all/modules/contrib/workbench_moderation/workbench_moderation.module).#24
With the fix from #1804156: Panelizer always creates a new revision when you use the Panelizer tab and untick "create a new revision", you get an inconsistent workbench state in the published revision. See screenshot.
#25
While working on #1798294: Can't edit non-current node revisions I've added a patch to add drupal_alter() for customizing the workbench node revisions list: #1868144: Allow the node history list to be customized
#26
@Xen: I'm still looking at your patch, but a couple of things jump out at me initially...
+++ b/workbench_moderation.moduleundefined@@ -210,6 +210,56 @@ function workbench_moderation_menu_alter(&$items) {
+ static $me = FALSE;
+ if ($me || $type != 'node' || !drupal_match_path($_GET['q'], 'node/*/panelizer*')) {
+ return;
+ }
$me always resolves to FALSE in this expression. Is it required?
+++ b/workbench_moderation.moduleundefined@@ -210,6 +210,56 @@ function workbench_moderation_menu_alter(&$items) {
+ !empty($form['revision_information']) &&
Should this be wrapped in an isset()?
#27
I have added a patch to panelizer (7.x-2.x-dev) which fixes a rather serious bug causing node revisions to actually loose panels displays.
http://drupal.org/node/1871552#comment-6866490
#28
I've modified the patch from #22 from Xen to only trigger aggressive latest entity load when not in shutdown mode, since the workbench store function needs to be able to get a specific revision.
This might also fix #24 which seems similar to the issues, we had.
#29
Here is another. Except this is against 7.x-3.1 and adds support for the IPE as well.
There is still a lingering issue w/ the IPE integration for support entitycache. Entitycache will cause some unexpected results still.
Also there are a couple of todos.
#30
We're not using IPE, but we are using panelizer. Xen's #22 patch (mostly) worked for us, but we had to add another conditional check in hook_entity_load:
<?phpfunction workbench_moderation_entity_load(&$entities, $type) {
static $me = FALSE;
if ($me || $type != 'node' || !drupal_match_path($_GET['q'], 'node/*/panelizer*') && (!drupal_match_path($_GET['q'], 'node/*/draft'))) {
...
?>
This worked ok for some period of time, and then something started going wrong with unapproved revisions being visible before they had gone through the complete workflow cycle. We put this down to the node table getting set with the pending vid (even though workbench had it marked as unpublished). It seemed to be due to this hook_entity_load function.. suffice to say it was a ball ache.
Currently we're making do with an conditional check in the workbench_moderation_store() so that the node_save only gets called on certain conditions, i.e.
<?phpif (arg(2) == "edit" || $live_revision->workbench_moderation['current']->state == "published") {
node_save($live_revision);
}
?>
This is a temporary fix at the moment, and w'll need to test it and figure out the real problem first, but thought I'd share what I've got for now.