Make WordPress Core

Opened 9 days ago

Last modified 8 days ago

#61958 assigned enhancement

Rename `wp_should_load_separate_core_block_assets()` to clarify its purpose

Reported by: flixos90's profile flixos90 Owned by: flixos90's profile flixos90
Milestone: 6.7 Priority: normal
Severity: normal Version:
Component: Editor Keywords: 2nd-opinion
Focuses: template Cc:

Description

The wp_should_load_separate_core_block_assets() function and the should_load_separate_core_block_assets filter were introduced in WordPress 5.8 (see [50836] and dev note).

While initially the function's and filter's purpose was to determine whether to load individual block stylesheets for core blocks (vs the one large wp-block-library stylesheet), this purpose has notably changed over time: Today, this function is called to determine whether or not to load block assets on demand (vs unconditionally throughout the entire site). In other words, it also covers third-party blocks, but the entire purpose is different. It still also controls whether to use individual stylesheets for the core blocks, but at this point that is mostly a side effect of loading block assets on demand.

The function name, filter name, and their documentation is confusing. Not only does it not explain what it actually does today, it is also inconsistent in itself in that it sometimes refers to "core block types", while other times it refers to "block types" (in general). This Slack thread is an example of how the current naming and documentation leads to confusion.

This ticket proposes renaming the function and filter and updating the documentation to clarify the purpose. Of course, technically we can't just rename things, so this will mean deprecating the current function and filter in favor of a new function and filter.

Potentially a good name would be wp_should_load_block_assets_on_demand. This could work for both the function and the filter. The documentation should then focus on this primary purpose, while additionally explaining that this will furthermore lead to individual core blocks stylesheets being used instead of wp-block-library (which still makes sense in this context, because loading wp-block-library is anything but on demand 🙃).

For additional context, see this Slack thread, which is based on the other thread above.

Change History (6)

#1 @flixos90
9 days ago

@gziolo @aristath Based on your involvement in the original function back then, it would be great to get your perspective.

@fabiankaegy Your thread led to opening this ticket, so your feedback would be appreciated too.

This ticket was mentioned in Slack in #core-editor by flixos90. View the logs.


9 days ago

#3 follow-up: @swissspidy
9 days ago

IMHO there isn't much value in renaming this function, it will just cause unnecessary work for extenders and maintenance burden for core maintainers. We'd just need to keep back compat for 2 functions and filters.

+1 to improving the documentation though. Maybe we can just start with that and go from there?

#4 in reply to: ↑ 3 @flixos90
9 days ago

Replying to swissspidy:

IMHO there isn't much value in renaming this function, it will just cause unnecessary work for extenders and maintenance burden for core maintainers.

I disagree. The function and filter names are confusing (as proven by the Slack thread for example), so there is value in renaming them. There would be an easy migration path, and deprecations will realistically never be removed anyway, so there's no breakage. Code using the old function/filter would continue to work forever, they'd just be encouraged to migrate.

#5 @aristath
8 days ago

I think renaming these makes sense...
When the function and the filter were first introduced, their scope was narrower, and the names made sense.
That is no longer the case, and they are the cause of some confusion.

+1 from me.

#6 @flixos90
8 days ago

Related is #61965, which proposes having a way to do what wp_should_load_separate_core_block_assets() appears to do today (based on its name), independently of what wp_should_load_separate_core_block_assets() actually does today. 🤯

Note: See TracTickets for help on using tickets.