WordPress.org

Make WordPress Core

Opened 9 years ago

Closed 4 years ago

#18623 closed feature request (wontfix)

Allow themes to pre-register multiple custom backgrounds

Reported by: zamoose Owned by:
Milestone: Priority: normal
Severity: minor Version: 3.3
Component: Customize Keywords: dev-feedback needs-patch
Focuses: Cc:

Description

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?

Attachments (6)

custom-background.php-step-1.diff (15.8 KB) - added by kobenland 8 years ago.
Refactoring of custom-background.php. I'm just throwing it out there, Feedback more than welcome!
choose-background-images.diff (21.2 KB) - added by kobenland 8 years ago.
Makes uploaded background images reusable - like custom headers sans the randomness. Based on step-1.diff
18623.diff (29.4 KB) - added by obenland 7 years ago.
18623.2.diff (29.3 KB) - added by obenland 7 years ago.
18623.3.diff (32.1 KB) - added by obenland 7 years ago.
18623.4.diff (32.2 KB) - added by obenland 7 years ago.

Download all attachments as: .zip

Change History (42)

#1 @zamoose
9 years ago

  • Summary changed from Allow for themes to pre-register multiple custom backgrounds to Allow themes to pre-register multiple custom backgrounds

#2 @wpsmith
9 years ago

  • Cc travis@… added

#3 @Marco_Teethgrinder
9 years ago

  • Cc Marco_Teethgrinder added

#4 @kawauso
9 years ago

  • Keywords needs-patch added

#5 follow-up: @nacin
9 years ago

+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.

#6 @zamoose
9 years ago

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

#7 @cais
8 years ago

  • Cc edward.caissie@… added

#8 in reply to: ↑ 5 @kobenland
8 years ago

  • Cc obenland@… added

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.

#9 @kobenland
8 years ago

  • Keywords dev-feedback added

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! :)

#10 @zamoose
8 years ago

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
8 years ago

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

@kobenland
8 years ago

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

#11 @kobenland
8 years ago

Updated. Thanks for your feedback!

#12 @sabreuse
8 years ago

  • Cc sabreuse@… added

#13 @greenshady
7 years ago

  • Cc justin@… added

#14 @mercime
7 years ago

  • Cc mercijavier@… added

#15 @obenland
7 years ago

#22348 was marked as a duplicate.

#16 @dgwyer
7 years ago

  • Cc d.v.gwyer@… added

#17 @Frank Klein
7 years ago

  • Cc contact@… added

@obenland
7 years ago

#18 @obenland
7 years ago

  • Keywords has-patch added; needs-patch removed

Maybe something for 3.9?

@obenland
7 years ago

@obenland
7 years ago

This ticket was mentioned in IRC in #wordpress-dev by obenland. View the logs.


7 years ago

#20 @jcastaneda
7 years ago

  • Cc jomcastaneda@… added

@obenland
7 years ago

#22 @SergeyBiryukov
7 years ago

  • Component changed from Themes to Appearance

This ticket was mentioned in IRC in #wordpress-dev by obenland. View the logs.


7 years ago

This ticket was mentioned in IRC in #wordpress-dev by obenland. View the logs.


7 years ago

#25 follow-up: @celloexpressions
7 years ago

  • Focuses ui added

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.

#26 in reply to: ↑ 25 @obenland
7 years ago

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

#27 @helen
7 years ago

  • Focuses ui removed

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.

#28 @celloexpressions
7 years ago

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 :)

#29 @helen
7 years ago

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 :)

This ticket was mentioned in IRC in #wordpress-dev by obenland. View the logs.


6 years ago

This ticket was mentioned in Slack in #core-customize by valendesigns. View the logs.


5 years ago

#32 @celloexpressions
5 years ago

  • Keywords needs-patch added; has-patch removed
  • Milestone changed from Awaiting Review to Future Release

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.

#33 @ramiy
4 years ago

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

#34 @celloexpressions
4 years ago

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.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


4 years ago

#36 @melchoyce
4 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.