Opened 14 years ago
Closed 14 years ago
#17291 closed enhancement (fixed)
Introduce _media_states() to show the status (background, header) on Media page
Reported by: | ocean90 | Owned by: | ryan |
---|---|---|---|
Milestone: | 3.2 | Priority: | normal |
Severity: | normal | Version: | 3.2 |
Component: | Media | Keywords: | has-patch ui-feedback |
Focuses: | Cc: |
Description
My idea is, to introduce _media_states for the media list screen. (_post_states() exists for the posts screen).
Screenshot: http://d.pr/WEf7
_media_states() should show if the image is used as a background and/or header image.
Attachments (2)
Change History (10)
#2
@
14 years ago
Also, you either use _x() - not necessary - or you don't set the second parameter to ().
#3
@
14 years ago
- Milestone changed from Future Release to 3.2
scribu, thanks. I forgot to remove the second parameter. I also have removed 'Custom'. We doesn't use it in strings, only in code.
Marking as 3.2 because I think it's a nice addition to #17240.
#4
@
14 years ago
That patch doesn't remove the _wp_attachment_is_custom_background
custom field from the attachment when you change the background image. You end up with multiple media items with Background Image as the state.
#5
@
14 years ago
Correct, because I believe the idea is that you can switch among uploaded custom backgrounds. So we need to track any uploaded through there, rather than the current one.
#6
follow-up:
↓ 7
@
14 years ago
johnbillion, the same will be happen for Header Image.
At the moment it isn't possible to delete a custom header/background image on the header/background screen. This idea could help you.
Sidenote: Maybe we should also introduce a way to register background images and list custom background images on the background screen too, like we do it now for header images. (see get_uploaded_header_images()).
#7
in reply to:
↑ 6
@
14 years ago
Replying to ocean90:
Sidenote: Maybe we should also introduce a way to register background images and list custom background images on the background screen too, like we do it now for header images. (see get_uploaded_header_images()).
This would be ideal. One step better would be if the header image and background image functionality shared the same code base and their respective admin screens worked the same way.
I would loose the 'Custom' bit: 'Background Image' and 'Header Image' is clear enough, IMO.