Introduce action hooks inside of do_meta_boxes()

[nikolov.tmw]

Background:
I want to add new fields to a meta box registered by a plugin. In this particular case, the plugin made it easy(I can filter the parameters passed to add_meta_box()), but even if it didn't, I can still modify the meta box in question.

To make this more abstract, let's assume that I want to actually add something to a WordPress metabox( the Page Attributes one for instance ). In order to achieve that, I'd have to do something like this:

<?php
function myplugin_add_meta_boxes() {
    remove_meta_box( 'pageparentdiv', 'page', 'core' );
    add_meta_box( 'pageparentdiv', __( 'Page Attributes', 'myplugin' ), 'myplugin_render_pageattr_meta_box', 'page', 'side', 'core' );
}
add_action( 'add_meta_boxes_post',  'wpse39446_add_meta_boxes' );

function myplugin_render_pageattr_meta_box( $post ) {
    page_attributes_meta_box( $post ); ?>
    <p>Some more information/options about page attributes</p>
    <?php
}

That will work just fine, until another plugin(or the theme) decides to do the same thing. Since I don't think there is an easy way to keep track of changes to meta boxes(and therefore be aware of someone else changing things around), it would now be a matter of which piece of code used a later priority(or registered it's action hook later on during execution).

Possible solutions to that problem:

• Create your own meta boxes in the first place. Fair point, but I believe that in some cases being able to add more code to an existing meta box would be useful(and the better approach).
• Have core and all plugins add their own action calls. While this has the benefit of a better implementation(since some plugins wrap their code in additional div tags, that add tabs, or other visual elements), it means a lot of work would have to go into it(plus, it's more than likely that very few plugins would do that).
• Add two new action hooks before and after the call to ​call_user_func($box....

I'm proposing the third solution as it would give reasonable flexibility, while reducing the chances of code collisions. It would also be easiest to implement, without a negative impact.

The patch would be pretty straight-forward, but I'd like to get some opinions on the topic first.

[MikeHansenMe]

Anyone want to write a patch for this? @nikolov.tmw?

[jtsternberg]

This is a duplicate of https://core.trac.wordpress.org/ticket/31559.

[DrewAPicture]

#34675 was marked as a duplicate.

[DrewAPicture]

Duplicate of #31559.