Problem/Motivation

I was reviewing the Media module recently and saw two bits of logic that definitely won't work with Content Moderation:

1. \Drupal\media\Plugin\QueueWorker\MetadataFetcher::processItem loads media items by ID, which will always load the default revision. If I understand this correctly, changing the source field on a forward revision (Draft) of a media item will not update the metadata for the latest revision.

2. \Drupal\media\MediaStorage::shouldUpdateMetadata compares the new source field value with $media->original. If $media->original isn't set the default revision of the media is loaded. Instead of loading the default revision, we should load the latest revision, I think. This one is a bit trickier and may not present practical bugs.

Proposed resolution

Add explicit support for forward revisions in the media module.

Remaining tasks

Audit more of the media module and determine what parts are incompatible with content moderation, then write a patch.

User interface changes

None.

API changes

Undecided.

Data model changes

None.

Comments

samuel.mortenson created an issue. See original summary.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Issue tags: +Media Initiative

+1. All aboard the Content Moderation Pain Train!

marcoscano’s picture

marcoscano
Primary language Portuguese, Brazil
Location Barcelona, Spain
commented

Just wanted to mention that using content moderation at the media level will likely prevent to use it at the node level (assuming a node-referencing-media model). Technically it's possible, but with the relationship means we have today (entity_reference, links, etc) it would be of little use to have them both moderatable (and not being able to see all forward revisions at the same time, for example).

Having that said, I'm 100% in agreement that forward revisions with workspaces should work as well for media entities. So the underlying problem still needs to be addressed, maybe just some rewording to refer to the use case that's more likely to be used?

sam152’s picture

sam152 commented

I think there are a couple of issues that could be spun off from here. To address the issue with using moderation on both nodes and media items raised in #3 we could do something like the following:

The 'latest-version' route should load the latest revision of all referenced entities during rendering.

That would allow you to create a draft of a node with a draft of a media item and preview both pending changes.

For the queue meta-data updater, I think we would need to load the exact revision that triggered the queue item creation, update the metadata there and NOT create any new revisions (pending or otherwise) from that point forwards. So we could spin off:

Media queues should store and load specific revision IDs.

And:

Content moderation should provide an API for skipping new-revision creation for subsystems that require updating metadata.

Thoughts on splitting the effort like this and the approaches in general? I'm not sure this would create a seamless media/parent entity moderation workflow, but it would probably provide better underlying integration of the various components.

amateescu’s picture

amateescu commented

The 'latest-version' route should load the latest revision of all referenced entities during rendering.

That would allow you to create a draft of a node with a draft of a media item and preview both pending changes.

This is exactly what Workspaces does by default, and there are existing discussions about refactoring Content Moderation to use workspaces under the hood (#2972622-3: Split the workspaces UI into a separate module), which would bring this functionality for free :)

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

FYI I built this really, really kludgy module that tries to work around this limitation:

I recommend not using it and architecting your site around Paragraphs and Paragraphs Library, but if you must do it this way, this kludgy module might help.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

sam152’s picture

sam152 commented

Good point @amateescu, I agree that bundling the moderation of multiple things together is the domain of workspaces.

I think the issue summary still describes a change that media needs to make, that is the queued thumbnail feature should be using revision IDs and also probably marking each revision as syncing: #2803717: Allow 'syncing' content to be updated in content moderation without forcing the creation of a new revision, #2329253: Allow ChangedItem to skip updating the entity's "changed" timestamp when synchronizing.

effulgentsia credited pavlosdan.

effulgentsia’s picture

effulgentsia commented

Adding issue credit to this issue to @marcoscano, @pavlosdan, and @Sam152 for helpful comments made in #2969678: Integrate Media Library with Content Moderation that are more in the scope of this issue.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

smustgrave commented

Wondering if this is still an issue or been mitigated elsewhere

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

chris matthews’s picture

chris matthews commented
Status: Active » Closed (duplicate)

I believe this issue should be closed as a duplicate of #2969678: Integrate Media Library with Content Moderation