Fix flash when clicking on template name when a plugin registered template matches a default WP theme template #7676
Conversation
…plate matches a default WP theme template
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
…lable for all post types
…st type slugs aren't leaked by get_block_templates()
Aljullu
force-pushed
the
fix/flash-clicking-template-name
branch
from
db4ea9b
to
8ab1d7a
Compare
|
Thanks for the review, @apermo! Would you mind taking another look? I added a couple of commits that fix some edge cases and add unit tests. |
Co-authored-by: Christoph Daum <c.daum@me.com>
I can't merge either, this happens on the subversion by those with commit right(core commiters), I just reviewed. |
Aljullu
force-pushed
the
fix/flash-clicking-template-name
branch
from
70f64a1
to
8ef61a6
Compare
| if ( isset( $query['post_type'] ) && ! isset( $template_file['postTypes'] ) ) { // The custom templates with no associated post types are available for all post types. | ||
| $candidate = _build_block_template_result_from_file( $template_file, $template_type ); | ||
| $default_template_types = get_default_block_template_types(); | ||
| if ( ! isset( $default_template_types[ $candidate->slug ] ) ) { | ||
| $query_result[] = $candidate; | ||
| } | ||
| } elseif ( | ||
| ! isset( $query['post_type'] ) || | ||
| ( isset( $query['post_type'] ) && isset( $template_file['postTypes'] ) && in_array( $query['post_type'], $template_file['postTypes'], true ) ) | ||
| ) { | ||
| $query_result[] = _build_block_template_result_from_file( $template_file, $template_type ); | ||
| } |
There was a problem hiding this comment.
This is definitely better than the one you posted minutes ago.
After checking, I agree that this is equivalent, but I'm unsure wether this is really an improvement. Because the readability in my eyes was better before with single ifs.
Adding a continue; to the first if would likely have the same result. But I'm not convinced about that either.
Maybe moving the comments, and having those better in sight will do the trick here? This would also ask for a comment at the elseif
There was a problem hiding this comment.
Thanks for the feedback! Yeah, I don't have a strong opinion, I prefer the elseif as it makes it clear there is no overlap between the two paths. I added an extra comment in 0cfab7c as you suggested. Please let me know how it looks.
There was a problem hiding this comment.
the readability in my eyes was better before with single ifs
I know this is probably getting into a "personal preference" territory, but I tend to agree with @Aljullu that if(){...} elseif(){...} makes it clearer that the two conditionals don't overlap. Also makes this code a very tiny bit faster as the elseif() may not need to be evaluated :)
Co-authored-by: Andrew Ozz <743931+azaozz@users.noreply.github.com>
This PR includes the changes that need to be backported from WordPress/gutenberg#66359 into WC core.
Trac ticket: https://core.trac.wordpress.org/ticket/62319
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.