Steps to reproduce:
- Install Drupal 10.2.6
- Enable a second language (any language)
- configure a language prefix to determine current language
- enable translation on a node bundle
- enable revisioning on that node bundle
- install the diff module and configure it
- create content in that node bundle
- translate that content
- go to the revisions tab
- Notice that Revision histories of translated nodes are not being taken into account. For instance, when I am viewing a node with the following url structure: /{langcode}/node/{vid}/revisions
SOLUTION:
Apply the patch
Revision histories of translated nodes are not being taken into account. For instance, when I am viewing a node with the following url structure:
/{langcode}/node/{vid}/revisions,
The current logic of $entity->moderation_state->value within the getModerationState() function fails to take into consideration the loaded language of the node in question. By default, the published states reflect the original node language revisions NOT the language specified by {langcode}.
| Comment | File | Size | Author |
|---|---|---|---|
| #48 | diff-3004705-48.patch | 1.47 KB | hemuvyas97 |
Issue fork diff-3004705
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
toiletfinder.com commentedComment #3
toiletfinder.com commentedComment #4
toiletfinder.com commentedComment #5
awm commentedComment #6
toiletfinder.com commentedComment #8
toiletfinder.com commentedComment #9
alan d. commentedComment #11
simbaw commentedI have the same problem, and used the patch as below, this problem is solved.
Comment #13
yesct commentedI also ran into this with drupal 8.7 and diff 8.x-1.0-rc2
patch 4 from #11 fixed the state showing in the node revision log for content with translation to other languages.
I suspect that the fails in the automated tests indicate the tests need updating, maybe they are testing something they dont mean to.
adding needs tests tag to indicate the next step is to update tests.
unassigning since it has been a while, and to indicate anyone can pick up the next steps.
Comment #14
maximpodorov commentedI confirm the patch #11 solves the problem. Let's test again.
Comment #15
maximpodorov commentedWell, the tests are green now. Let is be RTBC.
Comment #16
smulvih2Patch #11 works for me.
Comment #17
dbielke1986 commented+1 Would be nice to see this patch in the upcoming release!
Comment #18
oleh.tarasiuk commentedComment #19
kunalkursija commentedI faced this issue too, Where it seems like
$entity->moderation_state->valueseems to be ignoring the moderation state of the translated nodes. Thereby showing 1 moderation state for all the revisions visible on the revisions tab(of node translations).Tried patch from #18 and it seems to be solving the problem.
Comment #20
alvarito75 commentedPatch #18 also fixed the problem
Here is the project version that might help others:
Comment #21
kevin w commentedRe-roll patch for v1.3.0
Comment #22
acbramley commentedThank you for your contribution. This issue currently does not meet the Contribution guidelines which are required to get this change committed.
Comment #23
joseph.olstadComment #24
joseph.olstadComment #25
joseph.olstadPatch has been working well for over 6 years running and is still needed
Comment #26
joseph.olstadExisting test coverage should ensure that this doesn't cause regression.
It's been 6 years without test coverage. Would be good to fix this.
Comment #27
joseph.olstadComment #29
joseph.olstadpatch #11 is the one we've been using for years.
patch #18 and #21 failed phpstan, both of these patches are a bit tough on the eyes.
patch #11 passes tests, it's a one line fix.
6 years now and counting.
Comment #30
joseph.olstadComment #31
joseph.olstadSame fix also applies to the 2.x branch
Here's the diff (patch compatible) from the MR.
Comment #32
acbramley commentedWe need test coverage for the bug fix.
It should go into 2.x first.
Comment #33
recrit commentedposting a static patch for composer builds
Comment #34
joseph.olstad@recrit, it's possible to use the automatically generated patch from gitlab
Comment #35
joseph.olstadWe could borrow some test code from another contrib project that has language negotiation , bundle translation enabled.
Would have to dig a bit but I'm sure it's out there, most of the test code for this has already been written somewhere else.
Comment #36
recrit commented@joseph.olstad using the automatically generated patch is dangerous since it is actively updated. A static patch is preferred to avoid any issues with new code pushed to the MR.
Consider the common scenario below.
- Day 1: Local development builds with the automatic patch. Composer lock is built.
- Day 2: MR is updated with new code, potentially incompatible with other patches to the module or custom code on the site.
- Day 3: Local development precedes, but composer.lock does not know the MR updated since the github URL has not changed.
- development continues ....
- Day 10: Staging deployment: This builds a fresh composer install, so it now pulls in the latest changes from the MR. The new changes cause the build to break.
Comment #37
joseph.olstadThe actual patch code it hasn't changed in several years.
with that said, all that is left is test coverage and that won't affect anyone using it.
Comment #40
gaurav_manerkar commentedComment #41
gaurav_manerkar commentedPlease review updated mr - https://git.drupalcode.org/project/diff/-/merge_requests/156
Comment #42
acbramley commentedStill needs tests and linting is failing
Comment #43
goodmood commentedRerolled patch for latest changes in 2.x branch so it can be applied to 2.0.0 version of the module
Comment #44
dbielke1986 commentedAgain +1 Would be nice to see this patch in the upcoming release!
:-)
Comment #45
acbramley commented@goodmood changes must be posted to MRs, you can force push over MR156 since that is conflicting now.
@dbielke1986 it won't be in a release until we have a green MR with changes and associated tests.
Comment #47
mparker17I found this didn't apply to 2.1.1, so I fixed the merge conflict and force-pushed over merge request !156 as requested by @acbramley in #45
Comment #48
hemuvyas97 commentedRerolled patch for latest changes in 2.x branch so it can be applied to 2.1.1 version of the module
Comment #50
acbramley commentedStill needs tests