re-rolled against 10.3.1, but I did not bother with the tests
Updated route subscriber to work on multilingual sites
Patch updated with translation support
That seemed to have fixed the issue for me. Attached is my patch.
When I revert a revision to Draft, it is updating the published SQL table for my field (eg: paragraph__field_X), as well as creating a new row in the revisions table (paragraph_revision__field_X). This does not happen when you make a new draft - only when you revert to a draft.
I noticed this because I have some custom code elsewhere that is manually querying the non-revision SQL table for my field and I was surprised to find the reverted draft values instead of the published values.
It looks like we call prepareRevertedRevision which is hard-coded to $revision->isDefaultRevision(TRUE);. Is this correct? Seems like it should be false if reverting to a draft.
When I revert a revision to Draft, it is updating the published SQL table for my field (eg: paragraph__field_X), as well as creating a new row in the revisions table (paragraph_revision__field_X). This does not happen when you make a new draft - only when you revert to a draft.
I noticed this because I have some custom code elsewhere that is manually querying the non-revision SQL table for my field and I was surprised to find the reverted draft values instead of the published values.
It looks like we call prepareRevertedRevision which is hard-coded to $revision->isDefaultRevision(TRUE);. Is this correct? Seems like it should be false if reverting to a draft.