[wp-trac] [WordPress Trac] #61605: Add Support for dynamically changing WordPress styles variations using filter
WordPress Trac
noreply at wordpress.org
Wed Jul 31 06:37:17 UTC 2024
#61605: Add Support for dynamically changing WordPress styles variations using
filter
-------------------------+------------------------------
Reporter: noamanahmed | Owner: (none)
Type: enhancement | Status: assigned
Priority: normal | Milestone: Awaiting Review
Component: Themes | Version:
Severity: normal | Resolution:
Keywords: has-patch | Focuses:
-------------------------+------------------------------
Comment (by aaronrobertshaw):
@noamanahmed I might be misunderstanding some of the discussion so far but
I think a little work may be needed in core to bring theme and block style
variations closer together before they could be managed by plugins.
The proposed filter might work in the immediate short term but would have
to remain and be supported moving forward. That's where the proposal of a
unified style variation registry comes in.
If using a registry similar to [https://github.com/WordPress/wordpress-
develop/blob/trunk/src/wp-includes/class-wp-block-styles-registry.php
`WP_Block_Styles_Registry`], variations not only could be registered but
also deregistered. That could occur in existing filters, potentially
taking into account even more contextual information.
Off the top of my head, some files and functions that might need looking
at include:
- [https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-
includes/class-wp-block-styles-registry.php WP_Block_Styles_Registry]
- [https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-
includes/blocks.php?plain=1#L2228 register_block_style()]
I'm assuming the `WP_Block_Styles_Registry` class would be updated to be a
wrapper around the new registry so that everywhere that currently uses
that class doesn't need updating.
> Do you think I should create a new WP_Style_Variation_Registry and a new
global function register_style_variation?
That is what has been proposed as an alternative to the new filter. It
will be more flexible and easier to maintain in the future.
As noted earlier on this ticket, it might be that the best place for this
work to begin is within Gutenberg. This may allow for the functionality to
remain experimental until it is ready for a WordPress release.
As for further guidance on how to approach what you are trying to achieve,
I'm not sure I can offer a lot more. I'd need to start working on
implementing the feature to see further ahead.
I hope that helps some though!
--
Ticket URL: <https://core.trac.wordpress.org/ticket/61605#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list