[wp-trac] [WordPress Trac] #38557: Format for registering a default header image is ambiguous

[WordPress Trac]

#38557: Format for registering a default header image is ambiguous
-----------------------------------+------------------------------
 Reporter:  bradyvercher           |       Owner:  pento
     Type:  defect (bug)           |      Status:  reopened
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  Themes                 |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:
-----------------------------------+------------------------------
Changes (by joemcgill):

 * keywords:  has-patch => has-patch 2nd-opinion


Comment:

 I appreciate trying to reduce redundancy and the make the logic more clear
 here, but I'm not sure the best approach is to transform the format of the
 `default-image` for custom headers when the setting is registered without
 at least doing some research into how themes are using the registered
 data.

 Seeing how the purpose of `get_theme_support()` (based on the function's
 description) is to get "theme support arguments passed when registering
 that support", I also don't think we should be doing any data
 transformations within that function.

 As you mentioned, `get_theme_mod()` handles the `sprintf` transformation
 when you pass in a default, but that only helps when the theme mod isn't
 set. We also seem to process defaults in other places before setting the
 theme mod (e.g., `reset_header_image()`) I agree that one option might be
 to add a helper function for retrieving the default image URL to
 consolidate the logic here. In the mean time, I think we should add the
 `sprintf` logic to the customizer, which is where the this ambiguity has
 lead to bugs.

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