-
-
Notifications
You must be signed in to change notification settings - Fork 222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUGFIX Workspace aware NodeCacheEntryIdentifier #5083
BUGFIX Workspace aware NodeCacheEntryIdentifier #5083
Conversation
Im currently digging into the history of this |
Nice. Such a simple change. |
originally the Neos 8.3 node was a neos-development-collection/Neos.ContentRepository/Classes/Domain/Model/Node.php Line 1806 in eada1db
With this pr 8336726 the method was removed from the Neos 9-dev Node (in preparation for standalone). A few days later And code was rewritten to use this new helper @cache {
mode = 'cached'
entryIdentifier {
- documentNode = ${node}
+ documentNode = ${Neos.Caching.entryIdentifierForNode(node)} |
While on it i would also like to move it to |
I know this pr is kindof exploding with comments relative to the lines changed but imo thats a good part. For example until now i was not really aware of this breaking change from 8.3 and so with this in mind we could possibly back-port Also to better fit the fusion pattern: being rather short we could also consider using Imo fusion is the part were we should put much dedication into as well, that means knowing all breaking changes and designing a well suited api. (The original change was obscured in a 148 additions and 71 deletions change set which would not even make it to auto generated release notes) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the other hand Neos.Caching.entryIdentifierForNode
vs Neos.Caching.entryIdentifier
doesnt make that big of a difference and would cause just extra work right now.
I think we can keep it and i took the time to create a list of things like this, which have to be migrated manually and possibly backported to 8.3
The change was taken too lightly and the whole content cache flushing depends on the assumption that after publishing or discard, everything will be rendered. With this knowledge and the added test we should be able to refactor it correctly in the feature without introducing a regression again.
…amid-to-NodeCacheEntryIdentifier BUGFIX: Fix content cache for discard, revert #5083 for now
No description provided.