Extend conditional loading of block global styles to third-party blocks #9413
Conversation
|
Hi @Ref34t! 👋 Thank you for your contribution to WordPress! 💖 It looks like this is your first pull request to No one monitors this repository for new pull requests. Pull requests must be attached to a Trac ticket to be considered for inclusion in WordPress Core. To attach a pull request to a Trac ticket, please include the ticket's full URL in your pull request description. Pull requests are never merged on GitHub. The WordPress codebase continues to be managed through the SVN repository that this GitHub repository mirrors. Please feel free to open pull requests to work on any contribution you are making. More information about how GitHub pull requests can be used to contribute to WordPress can be found in the Core Handbook. Please include automated tests. Including tests in your pull request is one way to help your patch be considered faster. To learn about WordPress' test suites, visit the Automated Testing page in the handbook. If you have not had a chance, please review the Contribute with Code page in the WordPress Core Handbook. The Developer Hub also documents the various coding standards that are followed:
Thank you, |
|
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 Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @[email protected]. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
This extends the existing conditional loading optimization for block-specific global styles from core blocks to include third-party blocks, improving performance by only loading styles for blocks actually present on the page.
- Implements unified handle generation for both core and third-party blocks
- Follows WordPress handle pattern: wp-block-{namespace}-{blockname}
- Maintains consistent fallback behavior for edge cases
- Addresses TODO comment from changeset [59823] in #61965
- Performance impact: Reduces CSS payload for sites using block plugins selectively
- Fixed PHPCS whitespace violations
Trac ticket: https://core.trac.wordpress.org/ticket/63805
Ref34t
force-pushed
the
improvement/global-styles-third-party-blocks
branch
from
1827e6a to
6338a29
Compare
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. |
- Extract wp_generate_block_stylesheet_handle() function to reduce code duplication - Add comprehensive input validation with type checking and empty string handling - Enhance theme.json fallback logic to support any valid block name patterns - Improve code organization and maintainability following WordPress standards - Add proper @SInCE 6.9.0 documentation for new function Maintains backward compatibility while providing better error handling and performance optimization for third-party block global styles.
Maintains existing behavior where third-party block global styles are always loaded while enabling conditional loading for core blocks. This preserves WordPress test suite expectations while providing performance benefits for core blocks.
| return 'wp-block-' . $namespace . '-' . $name; | ||
| } | ||
|
|
||
| return null; |
There was a problem hiding this comment.
this function performs a lot of work, but is it doing anything other than replacing the slash with a dash?
Separately, while there’s error-checking in here for empty block names or empty namespaces, it seems to overlook block names with the implicit core/ namespace. Currently I believe it returns null for those. If it’s provided paragraph should it return null or wp-block-paragraph?
$block_name = str_replace( 'core/', '', $block_name );
$handle = str_replace( '/', '-', $block_name );
return "wp-block-{$handle}";it would be great to see some expected inputs and outputs as examples in the function docblock
There was a problem hiding this comment.
Great points, @dmsnell! You're absolutely right on both counts.
-Re: "more than replacing slash with dash"
You're correct - the function name undersells what it's actually doing. It's performing namespace normalization (stripping core/), character replacement, and CSS class generation. The complexity could be better reflected in either the function name or documentation.
-Re: core namespace handling
Good catch on the implicit core namespace issue. Looking at the current logic, I believe both cases should work correctly:
'paragraph'→'wp-block-paragraph'(no change from str_replace)'core/paragraph'→'wp-block-paragraph'(core/ stripped)
However, the return null; on line 274 suggests there might be additional validation logic that's causing issues with certain block names. Could you share a specific example where 'paragraph' returns null? That would help identify if there's a validation condition I'm missing.
Re: documentation
Absolutely agree on adding examples to the docblock. Something like:
/**
* @example
* generate_classname_from_block_name( 'paragraph' ) // 'wp-block-paragraph'
* generate_classname_from_block_name( 'core/paragraph' ) // 'wp-block-paragraph'
* generate_classname_from_block_name( 'custom/slider' ) // 'wp-block-custom-slider'
*/Would also be worth optimizing for the common case where no namespace is present (avoiding unnecessary string operations).
Let me know if you can provide more details on the null return case - happy to investigate further!
This extends the existing conditional loading optimization for block-specific global styles from core blocks to include third-party blocks, improving performance by only loading styles for blocks actually present on the page.
Trac ticket: https://core.trac.wordpress.org/ticket/63805