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.
Rework the internal APIs so that if an entity's revision ID is blank it automatically uses the entity ID.
End goal: Make sure that the module works with Taxonomy Revision.
Comments
Comment #1
AdamB CreditAttribution: AdamB at Reading Room commentedThis would be great if this could be added to this module.
Comment #2
DamienMcKennaCould you please test the latest -dev release to see if the problem still exists?
Comment #3
chris@bootcampmedia CreditAttribution: chris@bootcampmedia commentedI've tried using metatag v7.x-1.21 and 7.x-dev with taxonomy_revision v7.x-1.4
If I install taxonomy_revision first, I don't notice any problems.
But if I install metatag first, and create a few taxonomy terms with metatag values, and subsequently install and enable taxonomy_revision, then the metatag values that I had already created are not visible in view or edit modes.
As far as I can tell, this is because without taxonomy_revision installed, the metatag values are created with a 'revision_id' value of 0, whereas the taxonomy_revision module expects that most modules would create revision_id values with a default value equal to the entity_id.
Comment #4
DamienMcKenna@chris: That makes complete sense. And it's also really frustrating :-\
I checked how Field API handles it, and yes, if the entity type doesn't support revisions then it does duplicate the entity ID to the revision ID.
So Metatag needs to be updated to work this way.
Bummer.
I'm updating this to a bug report, because it means Metatag doesn't accurately match the Field API handling for entities that don't support revisions, and "major" because it leads to data inconsistencies.