Opened 18 years ago
Closed 11 years ago
#7422 closed enhancement (wontfix)
pass $post_id to filters in sanitize_post_field() on post updates - same for users, etc.
| Reported by: | whoismanu | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Posts, Post Types | Version: | |
| Severity: | normal | Keywords: | has-patch needs-testing gsoc close |
| Cc: | Focuses: |
Description
the function sanitize_post_field in wp-includes/post.php calls most of the "database writes" post filters (e.g. content_save_pre). if a post is updated or created, the function is called in a database context ('db' == $context) and the $post_id argument is not passed to the "database writes" filters. while i understand this behavior on post creation ($post_id not yet available) it seems to me that on a post update the $post_id is readily available and could/should be passed to the filters as well.
an example where this would be useful is a case where i want to access a custom field value of a post that is currently being updated from the function hooked into content_save_pre. in its current form without the $post_id argument this doesn't seem to be possible.
Attachments (1)
Change History (8)
#3
@
17 years ago
- Keywords filters sanitize_post_field posting removed
- Summary pass $post_id to filters in sanitize_post_field() on post updates → pass $post_id to filters in sanitize_post_field() on post updates - same for users, etc.
#5
@
16 years ago
- Cc added
- Keywords has-patch needs-testing gsoc added; needs-patch removed
It shouldn't hurt anyone and in some cases might prove to be useful
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
the same holds for users and other pieces of data.
what's usually done instead is you post-process the post (on the save_post hook)