A taxonomy archive query for attachments can't return results

[ocean90]

In #21391 we made it easier to use custom taxonomies for attachments.

Example:

function ds_register_attachment_taxonomies() {
	$args = array(
		'label' => 'Color',
	);

	register_taxonomy(
		'image-color',
		'attachment:image',
		$args
	);
}
add_action( 'init', 'ds_register_attachment_taxonomies' );

This makes it also possible to make a query for this specific taxonomy. Example: 5 images has the term "red". The query: http://example.com/image-color/red/

But: The page returns no attachments.

The query:

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts INNER JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id) WHERE 1=1 AND ( wp_term_relationships.term_taxonomy_id IN (404) ) AND wp_posts.post_type IN ('attachment') AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'private') GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC LIMIT 0, 1

The problem is the AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'private') part. Attachments post status is inherit, therefore no results.

The attached patch checks if the current post type is attachment and sets the post_status to inherit.

I would like to get this in 3.5, since it's one of the new features and could be really annoying,

[mdgl]

Hmnnn, interesting!

Now that the, erm, "attachment" of attachments to posts is being "de-emphasised" we will likely have many more attachments with no parent post.

Which post status exactly is being inherited by such attachments? And should the post status of the parent also affect which attachments are returned by queries such as the one you describe?

Related #22085, #22439.

[nacin]

Replying to mdgl: It's only de-emphasized in the UI. If it is uploaded through a post, it will be assigned a parent. If it is uploaded via media-new.php, it is not. This is the same as previously.

[mdgl]

Replying to nacin:

Replying to mdgl: It's only de-emphasized in the UI. If it is uploaded through a post, it will be assigned a parent. If it is uploaded via media-new.php, it is not. This is the same as previously.

Unfortunately, no, this is not the case. Prior to 3.5 an unattached media item became attached anytime it was inserted into a post/page, with the following effects:

• the media item is made a child of the post/page (by setting post->post_parent)
• the media item gets a new permalink based on that of the post/page

With 3.5-RC1 media items uploaded independently remain unattached even if they are inserted into a post/page. This causes numerous problems, as outlined elsewhere and including:

• loss of pretty permalinks for attachments
• changed behaviour of existing gallery shortcodes (without an explicit include list) that no longer automatically pick up all images included in a post/page
• changed behaviour in most themes when displaying their attachment or image templates
  • navigation link to post/page to which this attachment belongs will be missing or default to the attachment itself
  • navigation links to next/previous attachment or image will be missing or cycle around all unparented attachments or images instead of only those belonging to the particular post/page

The default TwentyTwelve theme seems to just about get away with this because of the way various functions handle a default post ID of zero, but the result is clearly not what the theme designers intended. It is also quite unnerving to be presented with next/previous links to a seemingly random collection of images when viewing an "unadopted" attachment page!

I might further point out that the re-labelling of the "Uploaded to" column in the Media Library screen is not really correct. Yes, this column does mean what it says for media items created after the installation of 3.5-RC1 but for existing items it should really continue to say "Attached to". Also, unattached posts still say "(Unattached)" in this column with a link to "Attach" which doesn't match semantically with "Uploaded to".

Anyway, I'm finding it really hard to help here, because it is not at all clear what you are trying to achieve by the so-called "de-emphasising" of post attachments. Maybe I'm missing something or getting it wrong, but overly defensive replies to my comments also doesn't really move us forward (and I'm not singling you out here Andrew!).

Yes, there are anomalies in the underlying content model of attachments (as I pointed out elsewhere) but these will not be fixed by seemingly arbitrary changes to the front-end and lack of explanation or involvement of the wider WP community!

[nacin]

Prior to 3.5 an unattached media item became attached anytime it was inserted into a post/page

Can you point to where this occurs? In a new ticket, please, because this is a problem unrelated to this ticket. A change in functionality was *not* intended.

[mdgl]

Agreed, we're off-topic here but from koop's remark (comment:ticket:22085:3) this seemed like a deliberate change of behaviour, so I assumed you knew what you were doing :-) Suggest we just re-open ticket:22085.

[nacin]

This seems like a fairly dangerous change even in beta. Not happening for 3.5.

Should an attachment with 'inherit' join the posts table again to check the post status of the parent? I think we do that elsewhere.

[jfarthing84]

Just encountered this myself. It seems to me the best approach would be to treat attachments more like regular post types, in that all post statuses should be available to them as well. That way, if it's status is set to inherit, we can assume to check the parent for it's status. Likewise, if it is set as publish, treat it as it's own post - no need to do the status join.

Also, this would assign regular permalinks for those "unattached" (publish) attachments or the current (based on post parent) style permalinks for "attached" (inherit) attachments.

[wonderboymusic]

patch is the same, with no fuzz and whitespaces

[wonderboymusic]

In 25278:

Add unit test for tax_query against attachments.

See #22556.

[wonderboymusic]

I don't think this fix is necessary. I added a unit test in [25278] to query attachments with tax_query - it requires manual intervention just like any other post_type with non-default properties. I don't think tax archives by default should pull in attachments. If you want them, you can hook pre_get_posts, but that shouldn't be the default behavior, IMO.

[wonderboymusic]

see my previous comment, and no one has responded to close

[helen]

#25686 was marked as a duplicate.

[webbistro]

To be honest, I find it weird that modern WordPress considers media taxonomies "non-default properties". For any custom post type it is quit default.

I am finishing a plugin right now, but using pre_get_posts for any kind of media taxonomy which name I don't know in advance looks a bit tricky, not impossible, but I'd love to see a better implementation.

Every client of mine asks me of media taxonomies as well as of a proper bulk edit for the media library. They were waiting for 3.5, then they asked me many times if new media library organization is now any better, they heard there were a lot of improvements. It's funny, but many of small business owners consider new media uploader just a more beautiful, not more convenient or more problem solving. They expected a better organizing features and, frankly, me too. Many people don't actually need any kind of gallery plugin, they need better management for their media files: to find, to post, to group, etc.

This post type looks like goddamned. I am sorry, I am new to the Trac, maybe this subject has been discussed many times and I just don't know some reasons why all is so... Is it reasonable to rise the problem of missing media library basic features at all? Of course, it is supposed that specific features should be released as plugins. But even media library plugin development does not seem obvious, because there are continuous limitations with the attachment post type which force me to use improper tricks, I'd love not to use. I'd love to see attachment post type and its default properties the same great and flexible as any other WordPress post type.

Thanks in advance to everyone's kind response.

[dglingren]

I can emphasize with @Webbistro's pain and his comments. I have developed Media LIibrary Assistant, a plugin that adds taxonomy support, quick and bulk edit and a number of other features to the Media Library. It would be great to see more if these functions in core!

[paddelboot]

Why adding the possibility to assign taxonomies to attachments when we are not able to use attachment taxonomy templates? Doesn't seem consistent. The problem with pre_get_posts was already mentioned by @webbistro.

[dglingren]

Taxonomy support for Media Library items (attachments) is one of the most popular features provided by Media Library Assistant. MLA provide shortcodes for composing galleries, term clouds and pagination controls in the content of pages and posts; no template files required.