Make WordPress Core

Opened 4 weeks ago

Last modified 5 days ago

#61605 assigned enhancement

Add Support for dynamically changing WordPress styles variations using filter

Reported by: noamanahmed's profile noamanahmed Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Themes Keywords: has-patch
Focuses: Cc:

Description

A new filter is added to support new style variations

https://wordpress.org/support/topic/custom-wordpress-styles-variations-for-block-themes-using-plugin/

I will create a PR on Github to add this.

Attachments (1)

Screenshot from 2024-07-04 16-30-05.png (64.2 KB) - added by noamanahmed 4 weeks ago.
Style Variations

Download all attachments as: .zip

Change History (11)

This ticket was mentioned in PR #6999 on WordPress/wordpress-develop by noamanahmed.


4 weeks ago
#1

  • Keywords has-patch added

Here is the trac ticket

https://core.trac.wordpress.org/ticket/61605

This is my first PR to WordPress.org. Let me know if there is any guidelines I forgot to follow.

#3 @sabernhardt
4 weeks ago

  • Component changed from Bundled Theme to Themes

#4 @youknowriad
4 weeks ago

  • Component changed from Themes to Bundled Theme

Thanks for the ticket. I think that's a great idea but I'd consider another approach instead. We already have a register_block_style function in PHP that allows to register the block specific style variations. https://developer.wordpress.org/reference/functions/register_block_style/

In WordPress 6.6, this function has been updated to allow register block style variations using a theme.json like structure. So I think we should work on expanding this function instead (or generalizing into a style registry that is not specific to blocks).

cc @aaronrobertshaw as he worked on this and might have better insights.

Also depending on where the change need to be made, it may be better to start this work in the Gutenberg repo.

#5 @noamanahmed
4 weeks ago

@youknowriad

The approach you suggested works only if you want to register block style. I am basically trying to change the style variations which come. The function you linked doesn't help in achieving that.

If you take a look at the picture I attached you would understand. Basically the get_theme_item() calls the WP_Theme_JSON_Resolver::get_style_variations() and get_style_variations was missing a WP filter. I think my approach is a single line of code allowing alot of new ways where this can be tweaked.

Also I am not an expert in Gutenberg. Is it possible if some one can take over as it's just a single line of change?

#6 @youknowriad
4 weeks ago

Yes, I know but I'm suggesting that there's no difference between these style variations conceptually today and we should have a single registration function for both of them. Specifying blockTypes like we in the theme's styles folder would allow to register block specific ones, omitting it would allow registering global ones.

I know it requires more work but I think it's good to be consistent there and have a unique registry for these.

#7 @sabernhardt
4 weeks ago

  • Component changed from Bundled Theme to Themes
  • Version trunk deleted

#8 @aaronrobertshaw
4 weeks ago

Great discussion and ideas here!

I like the suggestion of a single registration function for style variations. There could be a future where theme and block style variations are more interchangeable. Long term, a single registration function should prove easier to maintain, evolve, and discover.

To accommodate registering theme style variations, we'd need a registry to store them like the block styles are in WP_Block_Styles_Registry. Unfortunately, WP_Block_Styles_Registry was marked as final when it was created which makes it difficult to experiment in Gutenberg first.

With either register_block_style or WP_Block_Styles_Registry, if their scope is expanded beyond block style variations, they probably need a rename too.

One approach that might make exploring this feature easier, could be, creating a more generic registry (e.g. WP_Style_Variation_Registry) and a new global function (e.g. register_style_variation). The existing function and registry class could then be updated to essentially be wrappers and perhaps even deprecated eventually.

#9 @noamanahmed
4 weeks ago

I am trying to achieve the functionality using a custom plug-in and all the current functionality is tied to a theme (child or parent)

The end goal is to allow the functionality to be tweaked using a plug in

Can you share some functions or other files which needs to be changed according to your approach so I can review that too?

@aaronrobertshaw I am not a WP Core contributor and I would need a little guidance in what you are suggesting.

Do you think I should create a new WP_Style_Variation_Registry and a new global function register_style_variation?

#10 @aaronrobertshaw
5 days ago

@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 `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:

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!

Note: See TracTickets for help on using tickets.