Skip to content
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

Remove some of the block pattern caching #5495

Open
wants to merge 2 commits into
base: trunk
Choose a base branch
from

Conversation

spacedmonkey
Copy link
Member

@spacedmonkey spacedmonkey commented Oct 16, 2023

Scale back on the caching of block patterns. Still do glob on every request. This way the code can easily detect the remove and adding of files in this directory.

Trac ticket: https://core.trac.wordpress.org/ticket/59591
Trac ticket: https://core.trac.wordpress.org/ticket/59633


This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

@spacedmonkey spacedmonkey self-assigned this Oct 16, 2023
Copy link
Member

@felixarntz felixarntz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @spacedmonkey, the approach certainly helps detecting new and deleted patterns, but it's not a proper solution for the root of the issue. When a pattern is updated, it will still be in the cache.

FWIW I disagree that any of these changes need to be made. This is a half baked solution. Either we should be able to rely on WP_DEVELOPMENT_MODE, or we should not (in which case all of the block theme file caching in core would need to be reverted/removed).

Despite the above, what you're doing here partially addresses the concerns on the ticket, so I'm not strongly opposed to merging this as a small improvement. But we should have unit tests to make sure it doesn't introduce problems, especially this late in the cycle.

@spacedmonkey
Copy link
Member Author

Despite the above, what you're doing here partially addresses the concerns on the ticket, so I'm not strongly opposed to merging this as a small improvement. But we should have unit tests to make sure it doesn't introduce problems, especially this late in the cycle.

@felixarntz You mind doing some performance profiling on this change? I believe one glob is better than 50 files exist for performance. Sadly I will not have time to work on this, as I am busy with other things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants