- 🇬🇧United Kingdom aaron.ferris
Similar to #11 but in my case this is coming from the Scanner module, feels as though this is more of a band aid than a fix to the root problem but im yet to see why nodes saved in the Scanner module aren't setting revision_translation_affected.
Patch from #10 does work for me, but as above pretty sure the root is the scanner module.
- First commit to issue fork.
- Merge request !42Move revision translation conditions to query, and work on the translation when building the row. → (Open) created by mrshowerman
- last update
10 months ago 30 pass, 4 fail - Status changed to Needs review
10 months ago 12:51pm 7 February 2024 - 🇩🇪Germany mrshowerman Munich
Created MR based on #13.
It removes the now unnecessaryif ($revision->hasTranslation($langcode) && $revision->getTranslation($langcode)->isRevisionTranslationAffected()) {
condition, and also sets the correct language on the revision before building the row (see #3269933-4: Inconsistent moderation state for translated content → ). - 🇺🇸United States recrit
@mrshoweerman This issue appears to be related to 🐛 Revisions controller getRevisionIds() should filter by language Needs review . See patch #5 🐛 Revisions controller getRevisionIds() should filter by language Needs review that correctly checks whether the entity type is translatable and it updates the automated tests. These fixes could be combined with this fix in 2882334
- last update
10 months ago 30 pass, 4 fail - 🇩🇪Germany mrshowerman Munich
Addressed #22.
I tried to fix the same issue as in #2769741: Node revisions page might not list a default revision → here too by using anorConditionGroup()
that's basically saying "either the revision affects the current translation, or it is the default revision", but that produced two additional LEFT joins of the same tables that are already used, which resulted in the conditions being applied to different versions of the same table.
Maybe someone else can help me out with that one.