WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 7 months ago

#17551 closed enhancement (worksforme)

Need a post_id query that works regardless of post_type.

Reported by: andy Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.2
Component: Query Keywords: needs-patch
Focuses: Cc:

Description

The query parameter p works for posts and pages but not attachments. When the ID in question refers to an attachment, the result is a 404. Why?

When generating a stats report for a remote blog, the WordPress.com Stats/Jetpack system at first only knows the post_id of a new post. Eventually it learns the correct permalink by querying the blog, but until then its best guess at a working link is ?p=$post_id.

This problem (and possibly others) would be most easily solved by a core query parameter that can find any post_type by its ID alone. Unless there is a reason to limit p, I propose we make p work for all post_types. If there is a reason, how about a new public query parameter post_id?

Change History (9)

comment:1 scribu3 years ago

+1 for post_id, but it still wouldn't match attachments, since they have post_status=inherit.

comment:2 nacin3 years ago

Is this something that can be done from a plugin?

comment:3 in reply to: ↑ description ; follow-ups: solarissmoke3 years ago

Replying to andy:

The query parameter p works for posts and pages but not attachments. When the ID in question refers to an attachment, the result is a 404. Why?

But it doesn't issue a 404... it redirects to ?attachment_id=N

comment:4 in reply to: ↑ 3 ; follow-up: dd323 years ago

Replying to solarissmoke:

Replying to andy:

The query parameter p works for posts and pages but not attachments. When the ID in question refers to an attachment, the result is a 404. Why?

But it doesn't issue a 404... it redirects to ?attachment_id=N

Only when it's attached to a published post I believe.

I can't really see a need for a public query var here.. nor private (as you set post_type = any, post_status = any for that one). Perhaps wherever Stats is getting the post ID from, it should be passing a permalink too.. either that, or i'm completely mis-understanding the implementation..

comment:5 in reply to: ↑ 3 andy3 years ago

Replying to nacin:

Is this something that can be done from a plugin?

Of course. Plugins are limited in power only by who writes them. I wondered whether p was this way by design or by accident. If by accident, we can fix it. If by design, we can design a new parameter. If core doesn't want that, I'll put it in the plugin.

Replying to solarissmoke:

But it doesn't issue a 404... it redirects to ?attachment_id=N

Compare http://ma.tt/?p=38232 and http://ma.tt/?attachment_id=38232. The parent post is published yet the 'p=' query produces a 404, not a redirect.

comment:6 wonderboymusic8 months ago

#21660 was marked as a duplicate.

comment:7 wonderboymusic8 months ago

  • Keywords needs-patch added

comment:8 in reply to: ↑ 4 SergeyBiryukov7 months ago

Replying to dd32:

Replying to solarissmoke:

But it doesn't issue a 404... it redirects to ?attachment_id=N

Only when it's attached to a published post I believe.

?p=N (where N is an attachment ID) redirects to the "proper" permalink if it's attached to a published post, and to ?attachment_id=N otherwise (see [14355] and [14595]). I could not reproduce the 404 error neither in current trunk nor in 3.0.

Replying to andy:

Compare http://ma.tt/?p=38232 and http://ma.tt/?attachment_id=38232. The parent post is published yet the 'p=' query produces a 404, not a redirect.

Both links now redirect to http://ma.tt/2011/05/balloon-ride/mcm_9083/.

comment:9 andy7 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.