Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Many of the core content entities (eg. menu items, custom blocks, etc) don't have changed timestamp tracking. This is a problem for various things.
- Data migration / content push would need to check uuids and last changed timestamps to optimise content pushing.
- Editing conflict / race condition tracking where multiple people attempt to edit and save on top of each other also needs change timestamp tracking.
- Cache invalidation should use last change timestamps on entities, such as the menu cache based on menu link item entities. We need this data.
Proposed resolution
- Add an interface for entities that support changed timestamps: #2044583: Add EntityChangedInterface to allow entities with "changed" field to be properly cached
- Expand on changed timestamp support to more entities:
- Generalize node changed validation: #2082509: Generalize node changed constraint to entity changed constraint
User interface changes
None.
API changes
Add interface for change tracking. Expand use of that, change schemas to introduce change timestamps.
Comments
Comment #1
gábor hojtsyProper brace.
Comment #1.0
gábor hojtsyAdd custom blocks issue
Comment #1.1
gábor hojtsyAdd menu item issue.
Comment #1.2
gábor hojtsyAdd terms.
Comment #1.3
gábor hojtsyAdd user issue
Comment #2
dave reidAdded #2074475: Rename {file_managed}.timestamp to 'changed' and add a created timestamp to the summary.
Comment #3
wim leersWe should also do this for comments!
Comment #4
tstoecklerWim Leers: comments already have 'changed' just like nodes.
Comment #5
berdirYes, they're missing a method, though, which is added in #2028025: Expand CommentInterface to provide methods (waiting for comment as a field there)
Comment #6
gábor hojtsy@Berdir: do we really need to wait on that? We can add that method in #2044583: Add EntityChangedInterface to allow entities with "changed" field to be properly cached just as well (and make it implement that interface). These are simple changes.
Comment #7
larowlanRelated #2078387: Add an EntityOwnerInterface
Comment #7.0
larowlanAdding link to fix file entities created and changed timestamps.
Comment #8
gábor hojtsyAdded #2082509: Generalize node changed constraint to entity changed constraint which is needed for eventual edit module integration as well (as we refactor edit to use the new entity API). See there.
Comment #8.0
gábor hojtsyUpdated issue summary.
Comment #8.1
gábor hojtsyAdd https://drupal.org/node/2082509
Comment #9
amateescu commentedWe already have a good mechanism for cache invalidation: cache tags. I'm not sure a bunch of entity queries (executed at a arbitrary time?) is better than that, so this point from the OP doesn't hold too much ground :)
Comment #10
das-peter commentedRelated to #9: Recently I had the pleasure to work with revisions, and scheduled publishing of those. While working with that I was wondering how caching should work in such a scenario and my first impression was that using last change timestamp maybe isn't the best idea. Because, the last change timestamp of which revision?
Comment #11
wim leersComment #12
webchickAs of #2074203: Add changed time tracking to menu links I believe this is done.