Support » Requests and Feedback » save_status_pre firing at wrong time

  • On line 497 of wp-admin/post.php the status_save_pre filter is applied. After that filter is applied, a number of things are done to the post status by post.php.

    Of specific interest to me is the fact that the “future” status will never be passed to status_save_pre filters because it’s not determined to be “future” until after the post status is filtered.

    The post is only converted to “future” if it is a “published” post. “Private” posts do not get that treatment (I think this is the right way to do it), but I’m developing a plug-in to allow for private posts (wp-sentry) and this behavior is breaking future posts.

    The filter only gets “published” or “private” — if the plugin forces the post from “published” to “private” it won’t be set to “future”.

    Better behavior would be to call the filter (or add another filter) before the post save to allow plugins to respect future posts and differentiate between them and other private posts.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Moderator Samuel Wood (Otto)

    (@otto42) Admin

    wp-admin/post.php does not have 497 lines. And I cannot find the text “status_save_pre” anywhere in the entire codebase.

    So… what exactly are you talking about?

    Apparently I was looking at an older version of the source (and transposed ‘status’ and ‘save’), but the point is still the same: the status filter is being called before WP decides what the final status should be.

    wp_insert_post calls sanitize_post on wp-admin/includes/post.php line 1224. sanitize_post calls sanitize_post_fields, which fires the status_save_pre filter.

    After all of that, WP decides if the post is “future” or not around line 1300.

    That filter either needs to be fired after the post status is actually determined by wordpress, or there should be a different filter fired that plugins can use what won’t muck-up the future posting.

    Moderator Samuel Wood (Otto)

    (@otto42) Admin

    Tell it to trac. That’s the proper place to report it.

    It sounds to me like this behavior would get closed in trac because it’s not a bug. ‘If it is decided that your bug isn’t in fact a bug, but is the intended behaviour, it will be closed with invalid.’

    What, exactly, is the point of this forum? (This question is mostly rhetorical as I have yet to find a moderator who can provide an even remotely helpful answer)

    Moderator Samuel Wood (Otto)

    (@otto42) Admin

    These forums are for user-to-user support, mainly. If you think it’s a valid bug in WP, then trac is the correct place to report it. Bug reports for WP itself don’t really belong here.

    Your bug sounds valid enough to me. If the filter isn’t filtering properly because it’s reset later, then that’s a bug.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘save_status_pre firing at wrong time’ is closed to new replies.