[wp-trac] [WordPress Trac] #56849: Modify `_config_wp_home()` and `_config_wp_siteurl()` to become pre_option filters

[WordPress Trac]

#56849: Modify `_config_wp_home()` and `_config_wp_siteurl()` to become pre_option
filters
------------------------------------+---------------------
 Reporter:  flixos90                |       Owner:  (none)
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  6.2
Component:  Options, Meta APIs      |     Version:  2.2
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+---------------------

Comment (by flixos90):

 @costdev @peterwilsoncc Those are great points. Sharing my thoughts on
 them:

 * I like the idea of running the `"option_{$option}"` filters too in those
 cases, this should help with BC. This should address the main concerns
 here.
 * Checking the usage of `_config_wp_home` and `_config_wp_siteurl` across
 plugins, it is extremely rare, and almost none that adjusts the filters.
 The only relevant usage is in a plugin called "Uploads by Proxy". See
 https://wpdirectory.net/search/01GQFRDPZP9WFQ7YY5KBEH6WS4 and
 https://wpdirectory.net/search/01GQFRM6GBN1YSCK80BCCXJMFZ.
 * What we could potentially do to work around even more edge cases is to
 automatically migrate the removal and addition of the `_config_wp_*()` to
 the `"option_{$option}"` filter if that happens in third party code. We
 can add a condition to `remove_filter()` and `add_filter()` that handles
 this, maybe even with a PHP notice (or deprecation warning?), that those
 callbacks should be attached to `"pre_option_{$option}"` instead.
 * We can also write a brief dev note on this change as a reference for
 developers that may be relying on this logic in some special ways.

 WDYT?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/56849#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform