- fathima.asmat London, UK
Patch 6 works for new translations but does not affect existing draft translation that should be treated as default revision when there isn't a published translation. So we may need something like:
// Check if any of the translation revision has a published version, // otherwise set the latest translation to default revision. if (!$update_default_revision && $entity instanceof TranslatableInterface && $entity instanceof RevisionableInterface) { $update_default_revision = $entity->isNewTranslation(); if (!$update_default_revision) { $update_default_translation_revision = FALSE; $published_translation_revision = FALSE; $langcode = $this->languageManager->getCurrentLanguage()->getId(); $storage = $this->entityTypeManager ->getStorage($entity->getEntityTypeId()); $revision_ids = $storage->revisionIds($entity); if ($revision_ids) { foreach ($revision_ids as $revision_id) { $revision = $storage->loadRevision($revision_id); if ($revision->hasTranslation($langcode) && ($translation = $revision->getTranslation($langcode)) && $translation->isRevisionTranslationAffected()) { if ($workflow->getTypePlugin() ->getState($translation->moderation_state->value) ->isPublishedState()) { $published_translation_revision = TRUE; break; } } } } if (!$published_translation_revision && $entity->hasTranslation($langcode) && $translation = $entity->getTranslation($langcode)) { $update_default_translation_revision = !($workflow->getTypePlugin() ->getState($translation->moderation_state->value) ->isPublishedState()); } $update_default_revision = $update_default_translation_revision; } }
Patch attached.
- Status changed to Needs review
over 2 years ago 2:18pm 23 February 2023 The last submitted patch, 31: content-moderation-unpublished-translation-3088790-31.patch, failed testing. View results β
- Status changed to Needs work
over 2 years ago 1:53am 2 May 2023 - πΊπΈUnited States dabblela
Agreed with @fathima.asmat, this definitely needs a way to update the default revision of a translation that has never been published. I think it can be done with this code, but I'm a little wary of potentially looping through every revision of a node so I took a different approach.
I was able to fix the issue here by:
1) applying the patch from π New translations for moderated nodes are not created in the initial workflow state Needs work
2) setting the default moderation state to "Default moderation state" and
3) creating a new state called "Pre-published" with "Default revision" enabledThis approach has worked better in testing with modules that use `hasTranslationChanges` (eg, paragraphs), I think because the default revision field is set earlier in the entity save process.
- ππΊHungary mibfire
https://www.drupal.org/project/drupal/issues/3088790#comment-14937914 π Inconsistent database because of a bug in the Content Moderation module Needs work
This patch doesn't work in the following case:
- Content moderation with https://www.drupal.org/files/issues/2023-02-23/content-moderation-unpubl... β and moderation/translation enabled on a content type.
- Enable Croatian language.
- Create a Draft node in Croatian.
- Translate this node to English(Draft).
- Submit the Croatian translation into Published state.
- Submit the Croatian translation into Unpublished state.
- Check the node view page of Croatian translation where the "Latest version" tab should be visible(but it is not because the default revision is always the last revision).
However this scenario works with https://www.drupal.org/files/issues/2020-06-09/3088790-10.patch β and https://www.drupal.org/project/drupal/issues/3329066#comment-14962117 π Creating a new translation may delete translations with drafts Fixed patches. Plus this works with https://www.drupal.org/project/drupal/issues/3088790#comment-14839675 π Inconsistent database because of a bug in the Content Moderation module Needs work too.
- πΊπ¦Ukraine v.dovhaliuk
A new patch resolves an issue if Content Moderation is enabled for the Taxonomy, and
$revision_ids = $storage->revisionIds($entity);
throws an errorundefined method <code>revisionIds()
- First commit to issue fork.
- Merge request !13011Issue #3088790 by bahuma20, zolt_toth: Inconsistent database because of a bug... β (Open) created by thomwilhelm
- π¦πΊAustralia thomwilhelm Sydney
OK so I ran into this issue recently, clearly translations + content moderation is a very complicated subject in Drupal, but I thought it would just be worth doing a bit of research into why this happens now.
So I'm working on a site that uses translations + the old workbench moderation module, and have been looking into migrating to content moderation. Everything went pretty well, but some of our internal Functional tests were broken in a strange way. Namely the following case (basically comment #16 on this ticket):
- Create a published version of an English page.
- Create a draft version of that page in Japanese.
Now when you go to any view that relies on node_field_data, the Japanese version of the page isn't there. In our case this mean it wasn't appearing on both /admin/content and a custom view we'd built to show pages that were "Draft content".
I started digging into whether this was an issue on Vanilla Drupal 11 and I found that is it. The draft version of the Japanese page doesn't appear at all on /admin/content, and while it does appear on the view of moderated content /admin/content/moderated, it's Content type field is empty.
Basically a new entity will be saved as the default revision (even being created in draft), but a new translation will not. This is due to the logic that's in content_moderation/src/EntityOperations::preSave:
$update_default_revision = $entity->isNew() || $current_state->isDefaultRevisionState() || !$this->moderationInfo->isDefaultRevisionPublished($entity);
If you review isDefaultRevisionPublished, in content moderation this returns true if any of the translations are published (which in this case, the English translation is published) so this returns TRUE. Whereas in workbench moderation it was only checking if the translation language was published (which in this case would have been Japanese) so this returns FALSE.
As content moderation forked workbench moderation, you can see this behaviour diverged in core here: https://www.drupal.org/project/drupal/issues/2862988 β
In that issue, if you read comment #13 and #14 you can see basically the same issue we are experiencing now was discovered, and the following fix was added:
$update_default_revision = $entity->isNew() + || $entity->isNewTranslation() || $current_state->isDefaultRevisionState() || !$this->isDefaultRevisionPublished($entity, $workflow);
Which is interesting as that's basically the same logic this issue has landed on. So when this this get removed?
This
$entity->isNewTranslation()
line was then removed as part of the following issue: https://www.drupal.org/project/drupal/issues/2860097 βTo try and move this forward, I've rebased the MR created by @EduardoMoralesAlberti onto a new MR targeting Drupal 11.x, added some extra test cases to the Content type label not appearing in the moderated content view, and made an attempt to fix up any behaviour that this changes (note: it's still marked as failing, but I believe that's due to unrelated issues in CI).
I'd welcome any feedback from anyone more familiar with translations / content moderation.
- πΊπΈUnited States smustgrave
Haven't reviewed yet but issue summary should follow the standard template please. Current steps are saying install Drupal 8.7.8 so definitely out of date.
Thanks!