Fine-grained disable the block editor

[JPry]

• Add initial block editor controller
• Add methods for block loading for post type
• Use ::class to reference the registered classes
• Register the Block_Logic provider
• Mark the editor class as deferred
• Remove no-op method
• Tweak Regexes
• Correct docblock parameters
• Simplify dynamic block stripping
• Fix typo
• Use interpolation and clean up some methods
• Apply formatting to the file

🎫 Ticket

[TICKET_ID]

🗒️ Description

🎥 Artifacts

✔️ Checklist

• Ran npm run changelog to add changelog file(s). More info here
• Code is covered by NEW wpunit or integration tests.
• Code is covered by EXISTING wpunit or integration tests.
• Are all the required tests passing?
• Automated code review comments are addressed.
• Have you added Artifacts?
• Check the base branch for your PR.
• Add your PR to the project board for the release.

[tec-bot]

PR to update Action Scheduler version to match WooCommerce version has been created: #2514

[lucatume]

Use tribe_cache()[ $cache_key ] (ArrayAccess API) for memoization. Static variables will not flush on wp_cache_flush calls making programmatic cache invalidation difficult (includes test, but not only those).

[lucatume]

On the topic of memoization: is this worth it? Are there so many calls to this method to justify it and run the risk of serving a stale result (e.g. because the post types have been filtered later)?
It looks like the expensive call in this method is the one to $this->determine_current_post_type(); should that method memoized?
I'm asking this question as I do not have an order of how many calls are made to this method.

[JPry]

On the topic of memoization: is this worth it? Are there so many calls to this method to justify it and run the risk of serving a stale result (e.g. because the post types have been filtered later)?

My thought process here was that every place that calls should_load_blocks() could potentially get to this method as well. Because this method runs apply_filters(), and that isn't necessarily a light call, I wanted to minimize the number of times the logic needs to run.

With that said, I can switch to tribe_cache() instead.

I'm asking this question as I do not have an order of how many calls are made to this method.

At the moment it's only called in one place. However, I was trying to be defensive about it ahead of time, knowing how the calls are likely to expand over time.

[lucatume]

Will this work reliably in REST API and Ajax context?

[JPry]

Will this work reliably in REST API and Ajax context?

That's a good question: I think it would make sense to have a separate case for those situations outside of this method, since the post type isn't as relevant in those contexts.