WordPress.org

Make WordPress Core

Opened 5 months ago

Last modified 7 weeks ago

#47215 new defect (bug)

The media that is "Unattached" is different in list mode vs grid mode

Reported by: pbiron Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Media Keywords:
Focuses: Cc:
PR Number:

Description

When in list mode (on Media > Library), images that have the post_states "Header Image" and "Site Icon" are shown as "Unattached"; whereas in grid mode they are not.

I think the grid mode behavior is preferable, since to me, "unattached" means "is not used anywhere" and clearly "Header Images" and the "Site Icon" are used (assuming the theme supports them).

Change History (2)

#1 @pbiron
5 months ago

After several hours tracking down another problem involving grid mode, I discovered why grid mode doesn't show images with post_states as unattached...and I don't like the reason :-(

Grid mode intentionally does not show any image (whether it is attached or not) with a non-empty value in the _wp_attachment_context postmeta of the attachment post. (see src/js/media/models/attachmetns.js, lines 155-161). That "feature" was introduced in #21819.

Why don't I like this? Because it is not just grid mode in the media library that excludes those images...it is anything that uses /wp-includes/js/media-models.js. One such user is the Customizer, for setting header images.

One consequence of this is the following:

  1. set the active theme to any theme that supports custom-header
  2. launch the customizer and select one or more images as header images
  3. publish that customizer changeset
  4. now, set a different theme that supports custom-header as the active theme
  5. launch the customer and try to set the same header images. You'll find that you can't, because wp.media.model.Attachments strips them out :-(

Why would you want to have the same header images in 2 different themes? In my case, the 1st theme is what is currently used on a given site and the 2nd theme is an in-dev complete rewrite of the 1st theme that has the same basic page layout (including the area where the header image is displayed)...and I need to switch back-and-forth between the 2 themes to make sure that the revised theme hasn't broken things that work in the 1st theme.

Another possibly unintended consequence of this "feature" is that it prevents you from inserting a header image (or site icon, etc) into post content...because the image inserter (in both gutenberg and class) uses the media modal (and hence media-models.js). Why would you want to do that? Suppose you're writing a blog post about how you built the current site. You give detailed/step-by-step instructions of various things like: setting header images, site icons, etc in the customizer. It would be perfectly normal to include those images in the content of that post...but you can't!

@joemcgill since you worked on #21819 do you have any comments? That ticket was about hiding crops of a given image from the media modal, but the solution implemented actually hides things that may not have been cropped. For instance, suppose my theme does:

<?php
add_theme_support( 'custom-header', array( 'width' => 1000, 'height' => 150 ) );

and the header images I upload in the customizer are exactly those dimensions...then the media modal stripping them out because 'context' === 'custom-header' is overkill, since they are not crops, they are originals.

Maybe the the work that @azaozz is undertaking on derived images for 5.3 could be leveraged to make the media modal's stripping of crops less greedy (i.e., don't strip an image just because it is "contextual", but only if it a crop/derivation of another image)?

This ticket was mentioned in Slack in #core-media by desrosj. View the logs.


7 weeks ago

Note: See TracTickets for help on using tickets.