save_post_{$post_type}

[bmb]

a save_{$post_type} hook would be convenient.

[mikeschinkel]

Use case?

When exactly would you propose it being triggered?

[Denis-de-Bernardy]

Convenient, but I'm unsure about the suggested hook name... Plugins that currently rely on save_post would be seriously broken if we don't maintain BC; or plugins that hook into save_post with the assumption that it's explicitly for posts would also affect pages, attachments, etc. (not to mention that it would then get called twice for actual posts unless we check for it).

[bmb]

Replying to mikeschinkel:

Use case?

When exactly would you propose it being triggered?

right after save_post, same as add_meta_boxes and add_meta_boxes_{$post_type}, since this would sort of complement those hooks (e.g. if you added a metabox with add_meta_boxes, save with save_post. If you added with add_meta_boxes_{$post_type}, save with save_{$post_type})

[mikeschinkel]

Agree with Denis, it would have to be named different (maybe "save_post_type_{$post_type}") but I'll also ask if it is really needed? I worry about the overhead of running more hooks when you can already do what the proposed hook does in another hook by adding an if statement?

[dd32]

The overhead of running a extra action on a post save seems rather low, Yes, It's another hook fire, but saving a post is not a time critical operation, such as the front end load, or loading an admin page.

If extra hooks are needed to help plugins avoid multiple if statements, that gets a +1 from me, but it should be fully reviewed to check to see what area's have hook, and what area's still need a hook.

[nacin]

This would be a nice hook to add, but it should be immediately before or after save_post. Should punt at this point.

[SergeyBiryukov]

16176.patch​ adds the hook right after save_post, as per nacin's suggestion. Also added post ID for consistency.

[SergeyBiryukov]

With double quotes

[SergeyBiryukov]

#24299 was marked as a duplicate.

[wonderboymusic]

these are all marked 3.7-early

[ocean90]

Refresh of .2 and with $update

[ocean90]

Looks good, nacin?

[ocean90]

Updated inline docs

[nacin]

It would be nice to pass $post as the first argument, but I understand why it shouldn't — so as to remain consistent with the existing save_post hook.

I think the docs could be simplified to 'save_post_{post_type}' just so it looks less crufty.

Is there a rhyme or reason (as determined elsewhere in core) to have this filter specifically before or after save_post? The only other situation I can think of is admin_head-$hook_suffix firing before admin_head. Other than looking into that, I'm +1 commit.

[ocean90]

Replying to nacin:

Is there a rhyme or reason (as determined elsewhere in core) to have this filter specifically before or after save_post?

Seems like we should move it before save_post because the specific filter is mostly before the general. Examples:

update_option():

do_action( "update_option_{$option}", $oldvalue, $_newvalue );
do_action( 'updated_option', $option, $oldvalue, $_newvalue );

add_option():

do_action( "add_option_{$option}", $option, $_value );
do_action( 'added_option', $option, $_value );

set_transient():

do_action( 'set_transient_' . $transient, $value, $expiration );
do_action( 'setted_transient', $transient, $value, $expiration );

admin-header.php:

do_action("admin_print_styles-$hook_suffix");
do_action('admin_print_styles');
do_action("admin_print_scripts-$hook_suffix");
do_action('admin_print_scripts');
do_action("admin_head-$hook_suffix");
do_action('admin_head');

admin-footer.php:

do_action('admin_footer', '');
do_action('admin_print_footer_scripts');
do_action("admin_footer-" . $GLOBALS['hook_suffix']);

[ocean90]

save_post_{post_type} before save_post

[nacin]

Go for it.

[SergeyBiryukov]

16176.6.patch​ fixes a copy/paste error in the refreshed patches: $post_ID in line 2974 should be $post->ID.

[ocean90]

In 25050:

Introduce save_post_{$post_type} hook.

The hook is fired before the general save_post hook and has the same args as save_post.

props bmb, SergeyBiryukov, ocean90, fixes #16176.

[ocean90]

Replying to SergeyBiryukov:

Thanks Sergey!