- 🇦🇺Australia pameeela
Thank you for reporting this problem. We rely on issue reports like this one to resolve bugs and improve Drupal core.
There hasn't been any new info or reports of this in six years, and it never had clear steps to reproduce. Does anyone have updated info on whether it is fixed or steps to reproduce it? If not provided within ~3 months, this issue will be closed.
Thanks!
- 🇨🇦Canada Nathan Tsai
Okay, I'm running into this problem with media (and without redis/memcache/any in-memory database system).
Transaction isolation level: REPEATABLE-READ
Unfortunately, I also can't consistently replicate this.
- 🇫🇮Finland heikkiy Oulu
We have encountered this issue in at least two client projects. While investigating the issue, the issue can be fixed temporarily by clearing caches and this allows the content to be saved again. But after the content is saved again, the second revision is visible again and it blocks saving the content a second time with the same error related to untranslated fields not being editable.
- 🇨🇦Canada Nathan Tsai
More details re: media revisions numbers not being accurate.
(Note: I'm using Drupal 10.3.)
So, what's happening is that when a media item is loaded, it's not loading the latest revision.
E.g. When there are two revisions 454 and 455, for some reason the system is loading 454 by default (instead of 455).
--
Also, this code makes the system act really strange. Specifically, after running this code, the newest revision ID is not displayed on the new media revision UI (mentioned here: https://www.drupal.org/node/3366630 → ).
$mediaStorage = $this->entityTypeManager()->getStorage('media'); $lastestId = $mediaStorage->getLatestRevisionId($media->id()); $lastestMedia = $mediaStorage->loadRevision($lastestId); $media->set(HrConstants::documentIsInitializedField, $lastestMedia->get(HrConstants::documentIsInitializedField)->value); $media->setNewRevision(TRUE); $media->setRevisionLogMessage('Resave to avoid revision number being incorrect.'); $media->save();