Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
The revision system doesn't enforce writing a revision log message. Even if we'd enforce it, there would be no guarantee the message would be meaningful (take Git commit messages for comparison...) - It's thus very complicated to understand what exactly was changed and what type of information was modified: is it content? Is it metadata? Is it both?
Currently, the only way to try and understand what happened between revisions is to install the diff module and compare revisions. This is better than the default core behavior, but is still not acceptable because you shouldn't have to randomly pick 2 revisions to compare and understand changes, either in content or metadata, or both. This is time-consuming, unintuitive and frustrating.
Proposed resolution
- Determine if we should stop creating new revisions when only metadata was changed. This would need us to dramatically change the way we understand 'revisions' (better understood by software engineers) and consider them to be 'page history' for content instead (better understood by content authors). Metadata would thus have no business being mixed with content changes - This would need us to think about a way to track metadata changes one way or another, still.
- Create a new column at
node/NID/revisionssuch as it's immediately obvious what was changed. This can be at a high-level only, and would point people to 'revisions' that would make sense to compare only. E.g. when you're trying to understand who or when was changed the node author on a node. A good module to seek inspiration from would be revision_log_default. - Determine if we could then have a dropdown/select to filter out revisions by metadata changes or content changes. This would really only work if we'd differentiate both conceptually instead of seeing revisions as 'everything that was changed since the last node save'.
Remaining tasks
Discuss and come up with a solution.
User interface changes
TBD.
API changes
TBD.
Data model changes
TBD.
Comments
Comment #2
timmillwoodI think the issue we need to address first is, what is metadata?
In a content entity we don't differentiate between what is a "content" field and what is a "metadata" field.
Ideally I feel we should create a revision for every single change of a content entity, although metadata should not be part of a content entity. The definition of metadata is "a set of data that describes and gives information about other data" therefore it should be be a separate thing, a separate object, a separate entity. We should introduce a MetaEntity or MetadataEntity alongside ContentEntity and ConfigEntity. The MetaEntity is non-revisionable and relates to the ContentEntity as a whole rather than a particular revision. It can be updated without changing or adding a revision to the ContentEntity. The ContentEntity will always get a new revision and may or may not update the MetaEntity.
Comment #3
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@timmillwood, we actually do have a way to differentiate metadata fields, they are the ones specified in the
revision_metadata_keysannotation key.If we also add #2862574: Add ability to track an entity object's dirty fields (and see if it has changed) to the mix, we will be able to easily know if only a revision metadata field was changed and not force a new revision in that case :)
Comment #4
timmillwoodThe
revision_metadata_keysshould create new revisions when changed. I think this issue relates to entity wide metadata.I wonder if we could enforce that new revisions are only created when revisionable fields have been updated.
Comment #7
timmillwoodI'm not sure this is strictly a Content Moderation issue.
Comment #8
hchonov@timmillwood, this depends on the system. You might have a complex workflow and creating a new revision might force you to go through the workflow chain and if you want to simply fix a typo you would prefer to skip that. It always depends on the system and in our we have a check which always creates a new revision if an entity has been modified - ideally you would need #2862574: Add ability to track an entity object's dirty fields (and see if it has changed) like @amateescu pointed out, but we use
CEB::hasTranslationChanges()for that in a combination with the patch from #2838602: [PP-2] Optimize CEB::hasTranslationChanges by caching its result and serving subsequent calls from the result cache - big performance boost so that we don't slow down the saving process.@anavarre, it would be nice if you tell us what exactly do you mean by metadata.