Making functions out of do_action?

[mindctrl]

Are there benefits to using functions that call do_action versus just agreeing on a set of hook names and using do_action( 'hook_name' )?

With the functions, if something happens and the hook function file isn't included, the site bombs with a white screen php error. With just do_action, that doesn't happen.

[Cais]

I use a file_exist check on 'tha-theme-hooks.php' then write the bridging add_action calls to match the THA hooks (via their relevant functions) to my theme hooks. Yes, it would be a problem if there was no conditional check and the THA hooks file was not included but it was the most optimal way for me to add support versus using the actual specific THA hooks.

Note: I have included the THA project files to provide attribution for their work (as well as a note in the theme 'readme.txt.' file).

[chipbennett]

The advantage of using template-tag reference functions to the do_action() calls is that it makes the hook location much more easily extensible, both for existing Theme custom hooks, and for future potential core template action hooks.

[mindctrl]

Thanks @chipbennett. Can you give an example? Trying to wrap my mind around it.

[chipbennett]

@mindctrl sure, here's the example I used in Issue #11:

In the template, I call oenology_hook_content_after(), which is defined as follows:

function oenology_hook_content_after() {
    do_action( 'oenology_hook_content_after' );
}

When I incorporated THA, I simply dropped in the corresponding THA function:

function oenology_hook_content_after() {
    do_action( 'oenology_hook_content_after' );
    tha_content_after();
}

Note that if/when core adds template hooks, this approach makes it easy to add the core hook, as well:

function oenology_hook_content_after() {
    do_action( 'oenology_hook_content_after' );
    tha_content_after();
    wp_content_after();
}

[mindctrl]

@chipbennett thanks for the example. It helps me think about it. I'm relatively new to all this.

It seems like the main benefit to using functions this way (with this not in core) is for backwards compatibility with existing themes. But can't that be worked around by attaching do_action to the existing theme's function/hook?

In your example:

function oenology_hook_content_after() {
    do_action( 'oenology_hook_content_after' );
    tha_content_after();
    wp_content_after();
}

could be:

function oenology_hook_content_after() {
    do_action( 'oenology_hook_content_after' );
    do_action( 'tha_content_after' );
    do_action( 'wp_content_after' );
}

and that would cover the backwards compatibility in existing themes?

If the theme hook "do_action function" (ex: wp_content_after ) isn't pluggable in core, you can't add to the function itself like in your example, but you can attach additional actions to the hook. I think?

I'm still trying to wrap my head around it, and still don't see a benefit to wrapping the hook standards inside functions other than it possibly helping a little with adoption - and that's likely negligible unless theme devs are reading core. Otherwise they get the info from the codex and direction from usage in bundled themes.

Am I missing something? I probably am.