Workbench Moderation integration

Well, the core behavior is to create a field revision for each language when a new entity revision is saved. I don't know what Workbench Moderation is doing to alter this behavior but I'm not sure it's something that can be fixed on the ET side. Some detail in this sense would be helpful.

Related issue #1046282: Make the module work with revisions.

Just a question: did you try the latest dev? It radically changes the way translations are created/edited by reusing the regular node form and making it language aware (it requires Drupal core 7.15). There are some chances that things will just work.

This is an integration issue.

I'm still seeing this issue with the latest dev version of Entity Translation.

Steps to reproduce (with Drupal 7.22 and Workbench Moderation 7.x-1.3);

- Create a node with Language Neutral and publish directly
- Edit the node to be English and publish directly (field revision is correctly moved to the field_revision_* table)
- Edit the node to be Language Neutral as draft
- Moderate the node to published

There is now a duplicate row in the field_data_* table.

I will need to tweak the function entity_translation_overview() in order to list the correct titles.

@d3claes: Have you managed to get the issues resolved? Any patch you can share?

Edit: These problems seem to affect entities using the core revision system without workbench moderation. I made a separate issue for it. #2189567: Problems enabling and disabling translation on a field with revisions enabled I believe the resolution of this will fix the problems mentioned in this post.

There are some problems with enabling and disabling translation on a field when using workbench moderation.

Setup: Create a content type with workbench moderation and field translation enabled. Create 2 fields, neither of them translatable. Create a node with data in both fields. Publish the node. Create a new draft with edited values for both fields. Make one of the fields translatable with the "Copy data" option enabled.

Case 1:

1 - Edit the draft. The translatable field will appear blank.
2 - Enter a value in the translatable field: The original value is lost.

Case 2:

1 - Publish the draft. The published node will have the original value for the translatable field, but the old value for the untranslatable field.
2 - Disable translation on the node. It will freeze. (Doesn't freeze if you edited the node as per Case 1)
3 - Interrupt it and try to disable translation again, it will complete.
4 - Make another new draft with edited values, and enable translation on the same field like last time.
5 - Go to edit the draft, the non translatable field will appear blank (Opposite of the result from Case 1).

I have submitted a patch for #2189567: Problems enabling and disabling translation on a field with revisions enabled and although it solves the issue in core it is only a partial solution for workbench moderation. With this patch, enabling translation on a field will result in the data tables being filled with the data from the latest (possibly not yet published) revision causing it to appear published even though the node still had the correct vid and workbench_moderation_node_history still has the correct values.

Here is a patch that fixes the issues I have mentioned. It does not address #6 and #8. If you need something working right now I would recommend applying this patch and not allowing your entity translatable content to be saved as language neutral, which should avoid the data problems mentioned in #8, but for now #6 will still happen.

I do not recommend this patch to be committed due to repetition of functionality. It would be better if this query could be rewritten so that the published revision of the entity will come last in the order, but I haven't found a good way to do this.

  $query = new EntityFieldQuery();
  $result = $query
    ->fieldCondition($field_name)
    ->entityOrderBy('entity_id')
    ->age(FIELD_LOAD_REVISION)
    ->range($offset, $limit)
    ->execute();

Re-uploading #12 for the bot.

If I understood them correctly issues #8 and #10 should be addressed by #2285931: Field translations not purged from data table when (re)saving the live revision . The attached patch instead introduces generic support for forward revisions in ET and adds Workbench Integration for the node translation handler. This should fix #6.

The patch includes #1046282: Make the module work with revisions as it depends on it. Posting the full version as it solves a small conflict between the two branches.

Awesome, thank you very much for working on this!

I've just played around with the patch and had some trouble.
The cause was that EntityTranslationDefaultHandler::setEntity() always added empty translations and there was no recovery later on.
Thus I've changed the patch a little bit so that EntityTranslationDefaultHandler::setEntity() uses $this->getTranslations(); to figure out the translations. To do so I had to move the update of the entity properties before the translation handling code.

Now everything seems to work fine - however, I've to admit that I haven't yet tested all the workbench / revisioning related scenarios ;)

Thank you very much for all of your work on this. I'm just starting to test #16 against ET 7.x-1.0-beta3+9-dev, and I also see successful tracking of revisions by language. The only issue I see so far is editing a revised translation in a non-default language (we have an English/French site with English as the default language) copies the title_field value from the current language revision being saved to the default language fields. I suspect this is an issue for the Workflow queue, but I could use help in figuring out where to direct this.
What I see:
1. Edit body content in default language (English), save and publish -- all good, new revision created.
2. Edit body content in non-default language (French), save and publish -- body content tracked as new revision, but French title overwrites the title of the English content.

I'm testing against Workbench Moderation 7.x-1.3.

Many thanks for any further feedback.

Re-roll - the revision handling is now already part of dev.

1. +++ b/includes/translation.handler.node.inc
   @@ -25,6 +25,21 @@ class EntityTranslationNodeHandler extends EntityTranslationDefaultHandler {
   +      // Workbench moderation integration -> 1.x.
   

   Wrong indentation.

2. +++ b/includes/translation.handler.node.inc
   @@ -25,6 +25,21 @@ class EntityTranslationNodeHandler extends EntityTranslationDefaultHandler {
   +    // State flow and Workbench Moderation 2.x integration.
   +    if (module_exists('state_flow') && function_exists('state_flow_entity_get_active_revision')) {
   +      return state_flow_entity_get_active_revision($this->getEntity(), $this->getEntityType());
   +    }
   

   This deals with entities in general, not just nodes, can we move it to the parent class?

Thanks for the feedback. Here we go.

Found an issue with the entity type agnostic implementation - needed another check to ensure we can use state machine.

Getting this little nasty error after applying the patch:
PHP Fatal error: Cannot redeclare EntityTranslationNodeHandler::getCurrentEntityRevision() in //entity_translation/includes/translation.handler.node.inc on line 41

Maybe something changed in the latest dev?

The approach of using the 'current' workbench moderation revision doesn't really make sense to me.

Using this patch and workbench moderation, when you create a new translation that is in 'draft' status, the translation acts as if it is published. A user who should not be allowed to view an unpublished draft is able to view the new translation.

Similarly if you had a published version of the translation and a new unpublished draft of the translation it would show visitors the new unpublished draft.

I experimented with changing workbench_moderation_node_current_load to workbench_moderation_node_live_load in getCurrentEntityRevision. I thought it made more sense that we would load up the live revision rather than the 'current' one (which means the one we can currently edit). This made the viewing of the published node make sense (no more viewing unpublished draft translations) but made it impossible to edit or view a translation that wasn't already published.

@joelpittet I've re-rolled the patch against the latest dev. But it doesn't seem like there's anything that could cause that error. Did something go wrong when patching?

@Jody Lynn Good point, not sure how to proceed here. I need to dig into it again first. Setting to "Needs review" to run the both - but definitely "Needs work".

@plach Gosh, what would I do without you. Too unfocused to change the ticket status even though I just wrote about it :D

So patch is green, however the findings of Jody Lynn still need to be addressed - thus back to needs work (for realz now).

I guess the easiest thing would be if we continue to use the 'current' draft on the 'Translate' tab but use the 'live' draft when viewing the node. What you see when you view the node though seems caused by what happens during saving the translation: the current patch saves the draft translation field data into field_data_ tables rather than only to field_revision_ tables.

Thanks for your help plach and das-peter

@das-peter you are likely right my error message does smell of a bad patch job;) Thanks for the re-roll.

From my end, this patch looks good, because we can just tell our staff to treat language-based revisions as a matched pair. If you need to revise one language, just make sure you resave a placeholder draft revision in the original language. We can treat this as a training issue rather than waiting for a more wholesale (and likely fraught) revision to add language fields to the revision tables themselves. Many thanks again for the work on this.

Could we broaden this issue slightly to also cater for the revisioning module? See patch attached.

interdiff for patch above

Nothing against that, if it works :)

@drasgardian Thanks for also putting up the interdiff.

Let's see how the testbot takes it.

Re-roll against latest dev.

Code looks good and works for me. Turns out that a patch from #2557429: Make workbench_moderation_node_edit_page_override() work with Entity Translation is also required to make this work.

Confirming that with the patch from #37 above, and #2557429: Make workbench_moderation_node_edit_page_override() work with Entity Translation and also this patch for WM #2285931: Field translations not purged from data table when (re)saving the live revision , the problem is fixed.

Setting this to critical, as the following workflow shows unpublished data to anonymous users:

1. Set a node type to have both entity translation and workbench moderation enabled, with at least one translatable field.
2. Create a new node, in the site default language, eg English
3. Create a new translation, say in French, setting both the Translation status to 'unpublished' and the workbench status to 'Draft'.
4. Go to the URL for the French version of the node. The French field data is visible to anon users.

@joachim +1.
I am also facing the same issue.

Just enhanced the integration with Workbench Moderation 2.x / State Machine 3.x: #2546728: Edition of a node revision with Entity Translation language switcher
Now you can manage translation of a dedicated revision - not just the active one.

Let's get this patch in asap. we run it since months on a productive system and it seems to work quite beautifully. :)

@plach The path scheme stuff is wonderful :) Thanks for that!

Not opposed to special casing for some modules, but CPS + drafty do not need this to work properly with ET.

- So revisioning could implement hook_entity_load() and load the right revision. (See cps_entity_load in CPS module)
- And workbench moderation with state_machine / drafty should work without problems with ET anyway as CPS uses drafty, too for all low level stuff.

The only other special casing we have in CPS that might have an effect is using entity_status module to create the first revision in unpublished state, but that is mainly important for CPS, because the status of the revision and the live data does not match, so should not affect WM or ET.

Good to know. I'd be happy to commit #2376839: Rewrite to use the new Drafty module so that we don't need any of this, but I'm waiting for someone to RTBC it.

Please help review/test if you can!

Yes drafty was written specifically to avoid problems like this (and a similar set of problems with field_collection). I think the best status here is postponed.

Oh, can confirm this for Workbench Moderation 2.x / State Machine 3.x.
Works out of the box - without this patch.

I've tried the Draft rewrite patch in #2376839, and translating content with more than one revision still doesn't work properly. Once there is more than one revision, the translate tab still shows links to the published revision, and there is no apparent way to translate the current draft revision.

#37 (with the two other patches linked in #39) makes everything work nicely.

Re-rolled the patch in #37 to work the latest dev entity_translation.

Given the talk over at #2376839: Rewrite to use the new Drafty module, which is proposing to:

1. Create 7.x-3.x branch
2. Commit the Drafty rewrite patch to it
3. Release 7.x-3.0
4. Move all 7.x-1.x issues to 7.x-3.x
5. Stop committing anything to 7.x-1.x
6. Mark 7.x-1.x unsupported

and that the Drafty patch does not solve this issue (entity translation is incompatible with workbench moderation), is it time to unpostpone this issue? If 7.1 is replaced with the Drafty-powered 7.3, then presumably the next step for this issue will be to update/create a new patch that makes Workbench Moderation (with Drafty) compatible with entity translation?

[Original post deleted]

Oops wrong issue queue.

I'm working on this, got most things working (using the new version of workbench moderation with drafty), but still some issues to sort out. Hopefully have a working patch ready some time early next week. (Though with the strategy I'm using it's workbench moderation that will be the target for the patch.)

I have a patch ready that seems to be working, will create an issue in the workbench_moderation queue tomorrow. I solved it by switching out the menu path load-function wildcard. Took a lot of fiddling around but I think I finally got it right.

[deleted]

Rerolled #37 to work with beta5

I am using Drupal 7.43
Entity Translation 7.x-1.0-beta5 + workbench_moderation-1707156-47.patch
Workbench Moderation 7.x-1.4 + workbench_moderation-2218133-24.patch

Do I need to apply workbench_moderation-2218133-38.patch instead of "2218133-24"?

Hello, all

I am using Node Clone 7.x-1.0.
After using patch workbench_moderation-1707156-47.patch or workbench_moderation-1707156-55.patch,
Clone function cannot works with the following error:
"The website encountered an unexpected error. Please try again later."

In log:
EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (line 7880 of /includes/common.inc).

workbench_moderation-1707156-47.patch or workbench_moderation-1707156-55.patch have the following problem:

1. Create a new page in the site default language (English), publish it. (There will be only English version)
2. Create new draft and add a new translation (Chinese), but the workbench status to 'Draft'.
3. Go to the URL for the Chinese version of the page. The Chinese body content is NOT is visible But the chinese Title is visible to public

I am also using #55 and I also can not clone nodes on my site with the error mentioned in #57 in my watchdog.

Missing bundle property on entity of type node. in entity_extract_ids() (line 7907 of /home/jmuzz/devel/local.cselect/web/includes/common.inc)

I haven't gotten to the bottom of the node cloning issue but from what I can tell a nid and a vid is getting assigned to the clone before it's in the database. A nid is checked for in EntityTranslationDefaultHandler::isNewEntity() and the code incorrectly determines that it is not a new entity (it really is) and tries to load it from the database in workbench_moderation_node_current_load which will return NULL instead of a valid node.

These calls start from EntityTranslationHandlerFactory::getCurrentRevisionHandler()

Still remains when using Workbench Moderation version 7.x-3.0.

Language switcher disappears after first save of a node after upgrade to 7.x-3.0

Patch doesn't seem to work with 1.0-beta6

This is a straight-up reroll from patch 55, no change other than reroll. I haven't read through this issue at all, just took the patch and rerolled it so that it can be run through the testbot.

I've not actually used this patch, nor am I even sure if I need it or not as I didn't even read through this issue. Just rerolling for your sakes.

Thank you for the re-roll. #63 applies cleanly against beta6 for me.

It doesn't work for me running entity_translation 1.0-beta6 together with workbench_moderation 3.0.
I still have the problem, that I cannot add translations to content and that the language tabs are messed up: I have a system with english and german and when I want to add an english translation to a german node, somehow it turns to the page showing "German" "German" tabs instead of "German" "English".

The language tab issue apparantly seems gone by solely removing the unset in workbench_moderation_menu_alter().

  if (
    module_exists('entity_translation') &&
    isset($items['node/%node/translate']) &&
    isset($items['node/%_workbench_moderation_current_node/translate'])
  ) {
    // Merge in data set by entity_translation_node_menu_alter()
    $items['node/%_workbench_moderation_current_node/translate'] = $items['node/%node/translate'] + $items['node/%_workbench_moderation_current_node/translate'];
    unset($items['node/%node/translate']);
  }

Links look like they are working properly again and translations / drafts can be saved and restored.

Sadly, I am not that deep in entity_translation and workbench_moderation that I can see all strings attached.
So the question is ... what might have been the intention of unsetting this specific item?

Sorry I commented prematurely. Further testing shows me that patch #42 from https://www.drupal.org/node/2218133 solves issues with editing current revisions and doesn't introduce further translation mixup issues. You can basically ignore this comment.

We're testing unpatched workbench moderation 3.0 with drafty and et 1.0-beta6 with the patch at #63. With this combo language-specific drafts are working OK for us. (With the exception that an unpublished draft in a parallel language will be published as soon as one of the language drafts is published.) With patch #42 from https://www.drupal.org/node/2218133 I'm seeing similar issues with mixed up translations.

Without #42 though I see some cases where I can't access a current revision by creating a new draft, or in other words the 'current' pointer points to a much older revision when I try to edit. My workaround is to re-copy the current source as a new draft to reset the 'current' pointer. Not ideal, but the least dysfunctional combination I've found so far.

FYI: There's a new patch (#53) for workbench_moderation and entity_translation integration here:
#2218133: Workbench Moderation and Entity Translation integration
https://www.drupal.org/node/2218133#comment-12176822

NOTE: the workbench_moderation integration patch mentioned in comment #67 is for the entity_translation module.

***EDIT*** NOTE, we're using workbench_moderation 7.x-3.x , inconsistent results still. Might be due to the plethora of patches we're using.
RTBC patch #53 from the other issue.

#2218133: Workbench Moderation and Entity Translation integration

Prior to applying patch #53 french fields were loaded into the english new draft.

Thanks to the patch, the correct field language is loaded when clicking new draft.

Here's the full list of patches we're using
https://www.drupal.org/node/2218133#comment-12190721

setting back to needs review.

Got workbench_moderation and entity_translation working together properly as follows:

had to upgrade entity_translation to latest dev (august 6th 2017)
here's a snippet from my make file:

entity_translation:
    subdir: "contrib"
    download:
      type: "git"
      branch: "7.x-1.x"
      url: "https://git.drupal.org/project/entity_translation.git"
      revision: "0610bda5"
    patch:
    - "https://www.drupal.org/files/issues/entity_translation-fix_content_translation_test-2877074-4.patch"
    - "https://www.drupal.org/files/issues/entity_translation-pathauto_update-2743685-2_0.patch"
    - "https://www.drupal.org/files/issues/entity_translation-2218133-53.patch"

then upgrade to latest workbench_moderation 7.x-3.x dev (latest as of today)
and apply these patches
upgrade_from_1x3_to_3x_fails-2428371-51.patch
workbench_moderation-playnicewithpanels-40.patch
workbench_moderation-2218133-42.patch

Nope, wishful thinking, changes I made according to #73 aren't working for us reliably although the translate links work properly , the new draft link does not reliably work.

I am still working on this. Followup shortly.

confusion that I had observed in #74 due to our content having been incorrectly 'upgraded' via entity_translation_upgrade

This resulted in a patch and a sort of not related but important fix for entity_translation_upgrade #2899658: entity_translation_upgrade_do needs to automatically create the entity_translation row for the source language in entity_translation

The version of entity_translation and the applied patches as described in #53 are working for us in combination with the workbench_moderation latest dev with the patches as described.

So, turns out we didn't need the patch from THIS issue, however we did need patches as described in my comment above. So far it's working great for us.

RTBC comment #73

for workbench_moderation 3.x integration, but not with the patches 'attached' to this issue. RTBC the module versions and patches described in RTBC comment #73 .

patch is patch 53 from
#2218133: Workbench Moderation and Entity Translation integration

working on this now

Additional testing on the latest 3.x workbench_moderation with the latest entity_translation dev branch release has shown that the patches in this issue do not work as well as the ones in these two issues:

I'm going to close this as a duplicate.

Prefer that we go with the solution/patch in
#2734295-4: entity_translation_field_attach_delete_revision() ends up deleting current entity's record from {entity_translation}table

AND using this one as well:

#2557429-17: Make workbench_moderation_node_edit_page_override() work with Entity Translation

This issue still has lots of useful information reported, it should not be closed (especially as a duplicate).
It can be, as per #2734295-12: entity_translation_field_attach_delete_revision() ends up deleting current entity's record from {entity_translation}table that this issue actually solves #2734295: entity_translation_field_attach_delete_revision() ends up deleting current entity's record from {entity_translation}table as well.
But, we need some test-based proof that it does (or doesn't) and for which cases.

To work with this issue at the moment we need:

a) Test cases (will work through the history of this issue to try and figure out what needs testing)
b) Figure out if the current state of interaction of ET+WB+Drafty is still buggy (following from the defined tests)
c) Finally, cross-check against #2734295: entity_translation_field_attach_delete_revision() ends up deleting current entity's record from {entity_translation}table to see what exactly the overlap is, if any.

followup here:
#2557429-31: Make workbench_moderation_node_edit_page_override() work with Entity Translation

***UPDATE***

**UPDATE**

we've put workbench_moderation 7.x-3.x into production. Works great.
using
drafty:
7.x-1.0-beta4
with these drafty patches:

#2910310-21: drafty allow publishing current draft from /admin/content page when node already published when Workbench Moderation 7.x-3.x is enabled
#2579205-117: Delete redundant revisions
#2911357-11: Fix tests; update for latest to Entity Translation changes

http://drupal.org/files/issues/7x1x_drafty_publish_from_admin_content_page-2910310-10.patch
http://drupal.org/files/issues/fix_head_tests_of_drafty7x1x-11.patch
http://drupal.org/files/issues/drafty-n2579205-116.patch

entity_translation 7.x-1.0-beta7

with these patches:

http://drupal.org/files/issues/spelling_mistake_2907275.patch
http://drupal.org/files/issues/entity_translation-translation_status_confusing-2908096-5.patch
http://drupal.org/files/issues/static_cache_for-2557429-17.patch
http://drupal.org/files/issues/entity_translation-2734295-4.patch

workbench_moderation 7.x-3.0+5-dev (2017-02-05)
with these patches:

http://drupal.org/files/issues/upgrade_from_1x3_to_3x_fails-2428371-51.patch
http://drupal.org/files/issues/workbench_moderation-playnicewithpanels-40.patch
http://drupal.org/files/issues/workbench_moderation-preserve-history-2824798-14.patch

this combination of modules works great provided that all content types are using entity_translation (field translation) instead of content translation. Content translation does not work correctly using this setup, so we upgraded all our content types to entity_translation and it's working out well.

note: when you upgrade to entity_translation enabled content types, be sure to delete (variable_del() all the i18n_sync_ABC1234_TYPE , anything starting with i18n_sync_ containing the machine name of the content type that is entity_translation enabled , delete these variables, these variables contain settings that can cause conflicts and should be removed when using entity_translation .

Rerolled the patch in #63 because it fails to apply.

Still facing the anon user accessing the unpublished translation after applying the patches
my scenario is as following:

1. create node in any language with et enabled (lets say en)
2. publish the said node
3. create a translation in another language and keep the translation as draft
4. go to the translation as an anon user and you will be able to see it

Am I missing something here guys? I applied the patches from #82 (the uncommitted ones) plus the one in 83

@josebc the publish/draft state is to the entity , if you want the publish state of the translation to prime over the workflow status/node status then you'll have to probably write your own patch, this would most likely involve the entity_translation module, there might already be a patch for this somewhere in the entity_translation queue or in the workbench_moderation queue or in the drafty queue . have a look for that first.

For my clients they do not use translations this way they always sync the two translations, infact they use the entity_translation_unified_form module which allows you to edit more than one language on the same node edit form.

@joseph.olstad thank you for your feedback, I came here form https://www.drupal.org/project/entity_translation/issues/2604392 which is exactly what I'm facing currently
In my case editors might want to publish one language while keeping the translation unpublished so I will need to find a solution for that

ok, if you create a patch in another issue, make sure to link it to this issue, paste a link in a comment and/or use the related issues functionality.

I had some misconfiguration issue previously, but after fixing that im still having some weird behaviours

• Create a new node with moderation and et.
• Create a new translation and keep as draft.
• Crate another translation and keep draft.
• Publish one of the translations.
• ???
• All translations get published.

Looks like its also creating revisions for other languages when saving any, and for some reason they are getting the same moderation state from the translation that is being published.

@josebc , to our clients the behavior you just explained was accepted by our client.

You may be interested in combining this functionality with the entity_translation_unified_form module.

Patch #83 does not work in some random cases for fiel entities!
It causes error:
EntityMalformedException: Missing bundle property on entity of type file in entity_extract_ids() (line 8049 of /var/www/html/includes/common.inc).

I digged the cause of the error and it starts in this function where I've added 3 lines to it so it handles the error:

public function getCurrentRevisionHandler($entity_type, $entity) {
    $handler = $this->getHandler($entity_type, $entity);
    if (!$handler->isNewEntity()) {
      $revision = $handler->getCurrentEntityRevision();
      
      //patched so in case of the $revision does not exists - the exception is not thrown
      if(empty($revision)) {
        $revision = $entity; 
      }
      //end patched

      $handler = $this->getHandler($entity_type, $revision);
    }
    return $handler;
  }

Assume this is a feature req. and as most of them, they are not critical. As the assigned person have not posted on about 7y, unassigned

For our use case, when doing side by side node edit form with two or more languages using the entity_translation_unified_form module (still stable for D7) comment #82 still holds.
#1707156-82: Workbench Moderation integration
does the job.