Make WordPress Core

Opened 12 years ago

Closed 11 years ago

Last modified 9 years ago

#22556 closed defect (bug) (wontfix)

A taxonomy archive query for attachments can't return results

Reported by: ocean90's profile ocean90 Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.5
Component: Query Keywords: 3.6-early close
Focuses: Cc:


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


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

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:

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,

Attachments (2)

22556.patch (2.7 KB) - added by ocean90 12 years ago.
22556.diff (2.8 KB) - added by wonderboymusic 11 years ago.

Download all attachments as: .zip

Change History (22)

12 years ago

#1 follow-up: @mdgl
12 years ago

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.

#2 in reply to: ↑ 1 ; follow-up: @nacin
12 years ago

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.

#3 @ryan
12 years ago

  • Version set to trunk

#4 in reply to: ↑ 2 @mdgl
12 years ago

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!

#5 @nacin
12 years ago

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.

#6 @mdgl
12 years ago

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.

#7 @nacin
12 years ago

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.

#8 @nacin
12 years ago

  • Keywords punt added

#9 @ocean90
12 years ago

  • Keywords 3.6-early added; punt removed
  • Milestone changed from Awaiting Review to Future Release

#10 @jfarthing84
12 years ago

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.

Last edited 12 years ago by jfarthing84 (previous) (diff)

#11 @jfarthing84
12 years ago

  • Cc jeff@… added

#12 @wonderboymusic
11 years ago

  • Milestone changed from Future Release to 3.7

patch is the same, with no fuzz and whitespaces

#13 @wonderboymusic
11 years ago

In 25278:

Add unit test for tax_query against attachments.

See #22556.

#14 @wonderboymusic
11 years ago

  • Keywords close added

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.

#15 @wonderboymusic
11 years ago

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

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

#16 @helen
11 years ago

#25686 was marked as a duplicate.

#17 @webbistro
11 years ago

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.

#18 @dglingren
10 years ago

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!

#19 @paddelboot
9 years ago

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.

#20 @dglingren
9 years ago

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.

Note: See TracTickets for help on using tickets.