We recently got around to updating Workbench Moderation to the latest tagged 3.x release, and soon discovered a problem with our moderation workflow.
When content is edited, it is placed into moderation as normal and is sent through its paces and everything is okay. When that content is finally published, any fields attached to that content that had their values edited are displaying the old revision data, not the data for the currently published revision, i.e., the revision ID and field_*_value contain the values from the last relevant record in the field_revision_* table and not the values for the previous record, which is what is now published.
I tried this on a clean test install with only the latest tagged releases of Entity API, Drafty, and Workbench Moderation, and the results were the same.
Here is an example of the two tables from my clean test environment:
MariaDB [test_drafty_workbench]> select * from field_revision_field_moderation_test_field;
+-------------+--------+---------+-----------+-------------+----------+-------+-----------------------------------+------------------------------------+
| entity_type | bundle | deleted | entity_id | revision_id | language | delta | field_moderation_test_field_value | field_moderation_test_field_format |
+-------------+--------+---------+-----------+-------------+----------+-------+-----------------------------------+------------------------------------+
| node | page | 0 | 5 | 20 | und | 0 | Test 1 a | NULL |
| node | page | 0 | 5 | 21 | und | 0 | Test 1 b | NULL |
| node | page | 0 | 5 | 22 | und | 0 | Test 1 a | NULL |
| node | page | 0 | 5 | 23 | und | 0 | Test 1 c | NULL |
| node | page | 0 | 5 | 24 | und | 0 | Test 1 b | NULL |
+-------------+--------+---------+-----------+-------------+----------+-------+-----------------------------------+------------------------------------+
5 rows in set (0.00 sec)
MariaDB [test_drafty_workbench]> select * from field_data_field_moderation_test_field;
+-------------+--------+---------+-----------+-------------+----------+-------+-----------------------------------+------------------------------------+
| entity_type | bundle | deleted | entity_id | revision_id | language | delta | field_moderation_test_field_value | field_moderation_test_field_format |
+-------------+--------+---------+-----------+-------------+----------+-------+-----------------------------------+------------------------------------+
| node | page | 0 | 5 | 24 | und | 0 | Test 1 b | NULL |
+-------------+--------+---------+-----------+-------------+----------+-------+-----------------------------------+------------------------------------+
1 row in set (0.00 sec)
The published revision is 23, but the fields are displaying the data for revision 24.
How we are currently working around this is with this modification in drafty.module:
/**
* Implements hook_entity_update().
*/
function drafty_entity_update($entity, $type) {
$recursion_level = &drupal_static('drafty_recursion_level', 0);
if ($recursion_level == 1) {
// Doing this in hook_entity_update() so that the entire process is
// completed within entity saving. However this results in two entity saves
// within entity insert. The other option is hook_exit(), which is not
// better since for example that would happen outside the transaction.
//
// This is necessary because the fields do not get updated when publishing a
// draft revision. This also ends up creating a third copy of the revision.
if ($entity->status === 1) {
list($id) = entity_extract_ids($type, $entity);
$vid = $entity->vid;
drafty()->setRevisionToBePublished($type, $id, $vid);
}
drafty()->restorePublishedRevisions();
}
$recursion_level--;
}
This does have the drawback that a third copy of the content is created, but at least the fields are now displaying the correct data.
I have been through all the issues in this queue and tested many patches, but nothing addresses this, so I'm curious if anyone else has encountered this problem and if there is a better fix for it.
Comments
Comment #2
oadaeh commentedWe updated our workaround to:
to account for entities that do not have a status or vid.
Comment #3
jyraya commentedHello,
I tried to reproduce this issue in my instance without success.
I tested with:
I do not know if another module could affect the test scenario.
Here are the DB tables records related to my test. The last state of my tested content is:
"<p>Test 1d</p>""<p>Test 1e</p>"And here, you can find what I have in DB at that moment:
I also observed the DB when I published the content the first time and a second time without any draft revision.
In the 3 cases, I always received the expected behaviour and values.
Could you give revision history of the "workbench_moderation_node_history" table for your tested content?
Comment #4
oadaeh commented@jyraya I will try to get the "workbench_moderation_node_history" table for you some time this week.