Allow themes to pre-register multiple custom backgrounds

[zamoose]

We currently have the ability to register multiple header images and to randomly cycle through them or allow users to select one and stick with it. Is there anything that would prevent a similar implementation for custom backgrounds?

[nacin]

+1. Feature parity here would be great. Random backgrounds probably aren't a big headline feature though.

The way we allow for remove_theme_support('custom-header-uploads') would be a nice enhancement as well.

This will miss the boat for 3.3 without a patch soon.

[zamoose]

Any interest in trying to get this into 3.4? I'd love to see it there.

[kobenland]

Replying to nacin:

+1. Feature parity here would be great. Random backgrounds probably aren't a big headline feature though.

When you say feature parity, would that also include Themes registering their own background-images?

Would refactoring of /wp-admin/custom-background.php make sense as a first step?
I created a patch, where I took most of the stuff out of admin_page() and made it nice and clean with the Settings API. This way it would be easier to add more settings later.

[kobenland]

So I thought I might as well attach the patch and see how you guys like it.

The first diff:
I really didn't change functionality at all here. I just moved all the settings into callback functions for their settings fields functions. So it's just something I thought might help along.

As for the second diff:
I just added the possibility to choose from previously uploaded background images and refrained from supporting random backgrounds as that would add a lot of overhead and dublicate code.
Let me know if this is something that really needs to be patched, too.
This is what I did:

• Changed the order of the settings to make it similar to the custom header screen:
  1. Preview
  2. Upload
  3. Image selection
  4. Remove button
  5. Reset button
  6. all the rest
• Benefit would be less code (form markup, noces and nonce checking) and a more stringent user experience (as if I knew anthing about that)
• Dublicated the CSS code to make the image selection behave like the custom header selection. It probably would be a good idea to merge selectors, but I didn't want to impose on merging the documented sections within the file.
• get_uploaded_background_images() behaves a little bit different than get_uploaded_header_images(). It really uses thumnail information (URL, height, width).

I think that's all for now. Looking forward to feedback! :)

[zamoose]

Please issue your .diffs path-relative -- in other words, diff while in the root of your WP install, instead of from the root of your Mac.

[kobenland]

Refactoring of custom-background.php. I'm just throwing it out there, Feedback more than welcome!

[kobenland]

Makes uploaded background images reusable - like custom headers sans the randomness. Based on step-1.diff

[kobenland]

Updated. Thanks for your feedback!

[obenland]

#22348 was marked as a duplicate.

[obenland]

Maybe something for 3.9?

[obenland]

Related: #18296

[celloexpressions]

We need to make sure that any UI introduced here works with #21483 (which seems far more pressing). In fact, this might benefit from the entire custom header image interface moving to the media modal, which already supports selecting multiple images, if we create a backgrounds section of some sort. This could potentially allow users to select multiple default or custom images to use for backgrounds.

If this is addressed with (and fixes) #21483, we can hide the custom backgrounds page for most users (#25569), so we wouldn't need to worry about implementing a new interface twice or giving that page a much-needed refactoring. It makes a lot more sense for it to be in the media modal rather than in-page, but that would obviously work better for the customizer than the backgrounds page.

[obenland]

There is no new UI introduced in this ticket, it uses the existing UI from custom headers.

[helen]

Removing the UI focus - obenland is correct in that those two UIs should probably match. If specific things are discovered later that need UI or turn this into a UI-heavy ticket (as opposed to API), then we can bring back the focus.

[celloexpressions]

Yes, the UIs should match. However, we should keep in mind that these UIs will most likely change in the (hopefully near) future, and need to change in order to fix usability issues such as the inability to select existing images from the customizer (and the odd implementation of that on the backgrounds page). I was suggesting that we might not want to put too much effort into things that are likely to be deprecated soon.

Anyway, I think I see what this ticket's trying to accomplish now, but it's not incredibly clear reading through everything (doesn't help that the discussion basically all took place before the customizer existed). Attachment descriptions tend to help too :)

[helen]

Just a gentle reminder that the customizer is only available with JS and we do support no-JS in most places. Since these pages exist and are functional, I would strongly prefer that they not just be ignored.

Again, happy to add UI focus back if/when UI is being worked on or is a central need for the ticket. I would just really like to actually be able to sanely manage the focus :)

[celloexpressions]

Based on what's happened with the Customizer and related in the past 16 months, this likely needs a fairly significant reworking. The current header image control (from 3.9) needs to have functionality abstracted into a cropped-image control, and also updated to extend the other media controls (from 4.1). Once that's done, I think it would work to use the same control for headers and backgrounds, both with multiple support and cropping. But we kind of need to circle back to headers and backgrounds and give them a refresh in terms of implementation and feature-parity.

Obenland's old work here is great, but I'm not sure how much is still relevant or not, unfortunately.

[ramiy]

Didn't read the entire ticket, but why can't we use the same logic as ​register_default_headers() ?

[celloexpressions]

The theme.php part of obenland's latest patch 18623.4.diff​ should theoretically still work, so there's a basis for the internal bits there (and it's based on headers, per above).

The path to feature parity between headers and backgrounds, in terms of the images UI, goes through #36581 at least philosophically. Alternatively if we don't want to include the cropping part, we could build whatever would be needed to support this in UI directly in WP_Customize_Background_Image_Control, although I would definitely prefer an implementation that is reusable via the API and generic core controls. As most of the headers code in the customizer is obsolete (predating JS-templated controls), we should not use it directly.

I would suggest that anyone interested in improving background images have a higher-level discussion somewhere (perhaps Slack) to evaluate whether we do want to strive for feature parity with header images, and also figuring out how to approach the cropping and background-size property situation (see related tickets). That would better inform the approach that would work the best here. Also need a decision on whether the old custom background screen (only available for no-JS users now) should still be updated.

[melchoyce]

Doesn't seem to be a huge demand for this, and still a lot of questions to work out. The idea itself made more sense 3-5 years ago, but in general we're seeing a huge trend away from background images on websites. I'm going to close.