WordPress.org

Make WordPress Core

Opened 17 months ago

Closed 7 months ago

Last modified 5 weeks ago

#22556 closed defect (bug) (wontfix)

A taxonomy archive query for attachments can't return results

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

Description

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,

Attachments (2)

22556.patch (2.7 KB) - added by ocean90 17 months ago.
22556.diff (2.8 KB) - added by wonderboymusic 9 months ago.

Download all attachments as: .zip

Change History (20)

ocean9017 months ago

comment:1 follow-up: mdgl17 months 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.

comment:2 in reply to: ↑ 1 ; follow-up: nacin17 months 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.

comment:3 ryan17 months ago

  • Version set to trunk

comment:4 in reply to: ↑ 2 mdgl17 months 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!

comment:5 nacin17 months 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.

comment:6 mdgl17 months 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.

comment:7 nacin17 months 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.

comment:8 nacin17 months ago

  • Keywords punt added

comment:9 ocean9017 months ago

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

comment:10 jfarthing8416 months 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.

Version 0, edited 16 months ago by jfarthing84 (next)

comment:11 jfarthing8416 months ago

  • Cc jeff@… added

wonderboymusic9 months ago

comment:12 wonderboymusic9 months ago

  • Milestone changed from Future Release to 3.7

patch is the same, with no fuzz and whitespaces

comment:13 wonderboymusic7 months ago

In 25278:

Add unit test for tax_query against attachments.

See #22556.

comment:14 wonderboymusic7 months 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.

comment:15 wonderboymusic7 months 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

comment:16 helen6 months ago

#25686 was marked as a duplicate.

comment:17 webbistro6 months 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.

comment:18 dglingren5 weeks 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!

Note: See TracTickets for help on using tickets.