Make WordPress Core

Opened 14 years ago

Closed 5 years ago

Last modified 3 years ago

#15515 closed enhancement (wontfix)

content_save_pre et al don't supply context

Reported by: johnbillion's profile johnbillion Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.3
Component: Posts, Post Types Keywords: has-patch needs-refresh bulk-reopened
Focuses: Cc:


All of the {field}_save_pre filters don't provide any additional parameters with context. The {field}_edit_pre (when editing) and post_{field} (when displaying) filters pass the $post_id variable as a second parameter. The {field}_save_pre filter is the odd one out.

Currently if a plugin uses (for example) the content_save_pre filter and needs to know anything about the post (eg. the post type) then it has to use the global $post object directly. It works, but it's not ideal.

Can we add some context to these hooks? All they need is a second parameter containing the $post_id variable to bring them in line with the other field filters.

Attachments (2)

15515.patch (795 bytes) - added by johnbillion 14 years ago.
15515.2.patch (504 bytes) - added by johnbillion 14 years ago.
Patch for commetn_save_pre

Download all attachments as: .zip

Change History (13)

#1 @westi
14 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

Excellent idea. Patches Welcome :-)

#2 follow-up: @SergeyBiryukov
14 years ago

Should post ID be added to pre_{field}, pre_post_{field}, {field}_pre and comment ID to comment_save_pre as well? Or is {field}_save_pre the only one that needs modification?

14 years ago

#3 in reply to: ↑ 2 @johnbillion
14 years ago

  • Keywords has-patch added; needs-patch removed


Replying to SergeyBiryukov:

Should post ID be added to pre_{field}, pre_post_{field}, {field}_pre and comment ID to comment_save_pre as well?

Yeah I've added it to pre_{field}, pre_post_{field} and {field}_pre too.

14 years ago

Patch for commetn_save_pre

#4 @johnbillion
14 years ago

Patch for comment_save_pre as suggested by SergeyBiryukov. However it might be worth discussing if the other comment fields should be filtered too at this point, for consistency.

#5 @nacin
10 years ago

  • Component changed from Plugins to Posts, Post Types

#6 @johnbillion
9 years ago

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

No interest in 5 years. Everyone just uses the global $post at this point.

#7 @westonruter
9 years ago

  • Milestone set to Future Release
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version set to 2.3

I'm interested.

Using a global $post is not robust since calling wp_insert_post()/wp_update_post() (via a plugin) will not necessarily set the $post global. Besides, relying on globals isn't a practice we should encourage anyway.

#8 @westonruter
9 years ago

My use case here is to intercept some pre-save filters for a certain post type. But in the case of wp_insert_post(), the $post_id would have to be empty since the post hasn't been inserted yet, so that context wouldn't be directly available.

#9 @johnbillion
9 years ago

  • Keywords needs-refresh added

#12 @johnbillion
5 years ago

  • Keywords bulk-reopened added
  • Resolution set to wontfix
  • Status changed from reopened to closed

Still no interest in 4 years.

#13 @swissspidy
3 years ago

Unfortunately this workaround of accessing the global $post doesn't seem to work. It's never set, neither are any other useful globals.

I want to filter wp_kses_allowed_html only for a specific post type. My current workaround is to use the wp_insert_post_data filter, which provides access to both the sanitized and unsanitized post data. So in this filter I just run the unsanitized data through KSES, but now with my filters applied.

Note: See TracTickets for help on using tickets.