default-filters.php contains non-tweakable parameters

[rsepierre]

'default-filters.php' should NEVER use the "plugins-loaded" hook.
The reason being that this removes EVERY THEME DEVELOPER any kind of power around that setting.
Those "default filters" becomes "definitive and non editable filter" for theme developers.

For me this breaks my custom image size workflow

The best hook to replace "plugins-loaded" (according to wordpress's own documentation) would be "init"

---

add_action( 'plugins_loaded', '_wp_add_additional_image_sizes', 0 );

---

Also I don't understand why image sizes can't be more simple and centralized.
"thumbnail, medium, large" are treated as wordpress option and are user editable
"medium_large" is treated as an non-user-editable invisible wordpress option
NEW "big_image_size_threshold" which is a filter and basically a new image size (messes up the different image sizes names by the way)
NEW "1536x1536 and 2048x2048" that are hooked before any theme developers can access it which makes them non-editable for users and theme developpers.

The latest two (1536 and 2048) are indeed "plugin developpers" editable IF those plugin developers are willing to use bad practice and go for the "plugins-loaded" hook instead of the "init" hook.

This is breaking change for EVERY THEME DEVELOPPER and encourages bad practice for plugins developpers to interract with it.

This is very bad because EVERY DEVELOPPER should manages and have full control over his image sizes pipeline and avoid the default one at all costs. It's getting clunkier, less functionnal and more bloated with each update. It is really simple to fix but wordpress is really going the other way around and now preventing developers from working with it.

Trac ticket: https://core.trac.wordpress.org/ticket/50681

[SergeyBiryukov]

Hi there, welcome to WordPress Trac! Thanks for the ticket.

Just noting that this was added in [46066] / #43524.

[rsepierre]

@SergeyBiryukov

Please consider changing severity from "normal" to "blocker" again as it is PREVENTINT EVERY theme from handling the two arbitrary images sizes wordpress decided to add, and thus can add unfitted / unedittable behavior with the media library from wordpress core.

I personally CAN NOT recommend any of my customers to update their wordpress CORE as it is not compatible with the theme and CAN NOT BE MADE compatible.
As themes has to do with "appearance", mine including php and js scripts to handle dynamic image sizes generation, srcset, and lazy loading images for better loading time, quality and responsiveness.
Every customer updating core will have polluting image sizes not fitted to work with the script and IMPOSSIBLE to customize (I would have to create a separate plugin just for this one parameter alone).

I can assure you that many theme handle image sizes on their own (because native ones are quite messy) and I can provide links to examples (other than my owns) if necessary.

changing the hook from "plugins_loaded" to "init" is not only the recommended wordpress standard written in the documentation. It is also NOT BLOCKING every theme developer from interacting with the action.

add_action( 'init', '_wp_add_additional_image_sizes', 0 );

Severity should be BLOCKING because it is currently BLOCKING theme developers with arbitrary uneditable and, for some, unsuitable media library behavior.

Furthermore, I would also add that I tested the "init" hook and it doesn't alter the desired behavior in anyway while at the same time, releasing theme developers from their burden and enabling theme customers to update core to benefit from security patches again.

[peterwilsoncc]

The reason this is not considered a blocker is that theme authors may modify the images sizes by calling remove_image_size() in functions.php, for example:

<?php
// 2x medium_large size.
remove_image_size( '1536x1536', 1536, 1536 );
// 2x large size.
remove_image_size( '2048x2048', 2048, 2048 );

Plugin authors can modify the sizes with a similar approach provided it is run later than the plugins_loaded default priority.