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.

Hello,

please add new theme under Full support:

http://mtomas.com/1/tiny-forge-free-mobile-first-wordpress-theme

I see the example is just for a complete post ( more or less single.php i guess ? ), what about frontpage templates ?

i think we should get more examples for this so people won't get confused on where they should put the hooks

http://themecheck.org found a mix of \r\n and \n line endings in file tha-theme-hooks.php.

Just a thought/idea to help make this idea more palatable to theme developers already using their own hook system / architecture. Using an example snippet:

/**
* Semantic <header> hooks
*
* $tha_supports[] = 'header';
*/
function tha_header_before() {
do_action( 'tha_header_before' );
}

I suggest adding to the tha-theme-hooks.php code a commented out line after each function to hook the THA supported hook into an existing theme's hook, for example:

/**
* Semantic <header> hooks
*
* $tha_supports[] = 'header';
*/
function tha_header_before() {
do_action( 'tha_header_before' );
}
/** Change 'existing_theme_hook_before_header' to something more appropriate */
// add_action( 'existing_theme_hook_before_header', 'tha_header_before');

This works in practice but I will leave it to you to decide if you want to make it obvious to others. Of course, this would also be unique for each theme that implements this idea.

I plan to add something like this as an enhancement plugin for my latest theme.

Howdy!
It seems that there was some traction for THA, but it appears that it didn't gain the necessary momentum. I'm 2 years late, but I'd like to help out in any way I can if necessary.

I'm currently working on a starter theme (releasing it today or tomorrow), which I intend to use to build 26 free WordPress themes. I'd like to make them all support THA because this does seem like a really good idea to me at the moment.

So - my question is this -
Why is there in traction in Theme Hook Alliance? Can we fix that?
Before I commit to implementing this in my starter and all the themes - I'd like to know whether it actually is a good idea or it only seemed to be a good idea at the time.

If it is still a good idea - I think there are a lot of things that we can do to promote THA to theme and plugin developers.

Hi guys,

Can you please consider to add proper versioning to this project and adding code releases please?

From what I can see, this project is still in 1.0-draft version for couple of years, but if I hadn't checked the whole code now I wouldn't know that there were new tha_content_while_before/after and tha_entry_content_before/after actions. These were missing from my version, although I couldn't really check as my version is 1.0-draft which is the same as the live version here still...

Could you please improve this and add a new releases too?

Thanks for considering!

Also, can I ask, is the tha_current_theme_supports function required to be declared in the theme or is this for plugin developers mainly (only)?

Regards,

Oliver

THA currently includes four tha_entry_* hooks. What would you think of adding hooks for entry header, content and footer? For example when using HTML5 markup, I could have an <article>, and inside that a <header>, a <section class="content"> and a <footer>. I would propose six additional hooks:

• tha_entry_header_before
• tha_entry_header_after
• tha_entry_content_before
• tha_entry_content_after
• tha_entry_footer_before
• tha_entry_footer_after

In the theme I'm currently developing (Schemata) I named these a little differently: I have schemata_article_before (which is basically like tha_entry_before, schemata_article_header_before, schemata_article_content_before and schemata_article_footer_before, and of course the same for *_after (I do not use *_top and *_bottom at the moment, but I would definitely like to adjust things, however I need six hooks like the above in my theme).

I'm curious about your opinions.

Hey, I just wanted to let you guys know, I've got a starter theme I'm building that makes use of THA. Would love to see it listed in your Repo, if you don't mind. Here's the link: https://github.com/digisavvy/some-like-it-neat

Just wanted to share with everyone that THA's hooks have full support in the OpenHook plugin for WordPress, which allows every hook to be customized (with HTML, PHP, and Shortcodes) directly within the WordPress administration panel.

My hope is that this spreads the word about THA and that more themes will implement its hooks.

https://wordpress.org/plugins/thesis-openhook/

Consider this scenario:

1. Theme declares support for "all" tha-hooks.
2. New tha-hooks added.
3. current_theme_supports('tha-hooks', 'new-hook-type') still returns true, as long as the value "all" is present - see https://github.com/zamoose/themehookalliance/blob/master/tha-theme-hooks.php#L95

Any thoughts on adding filters to the arguments of get_template_part() to allow template parts to be selectively overridden? For example:

get_template_part( apply_filters( 'tha_template_part_slug', 'content' ), apply_filters( 'tha_template_part_name', get_post_format() ) );

This should allow child themes (and potentially plugins?) to specify exactly which template parts should be loaded under different circumstances.

I believe the hooks names before_header and tha_header_before are incorrectly listed with parentheses in the README.md

before_header() and tha_header_before()
at
https://github.com/zamoose/themehookalliance#what-if-core-adds-some-or-all-of-these-filters

A Composer dependency shouldn't automatically run any code. The autoloaded tha-theme-hooks.php file calls add_theme_support() and add_filter(), which have not been setup if calling the Composer autoload.php file at the top of a wp-config.php file. The end result of this is a fatal error and inability to use this library with WordPress projects that utilize the Composer autoload functionality.

There are two possible solutions to this issue:

1. Remove the autoload property from the composer.json file. Loading the code would then require an include.
2. Wrap the add_theme_support() and add_filter() functions in a class that could be instantiated later. The class constructor would need to add a callback on the after_setup_theme hook which would then run the setup code.

Thanks for the project and I hope more people use it and we create an standard.
But, current a old theme of my editor, but on maintenance and also active in many WP installs, supports not the tha and this was fine for my clients with this install to easy to add different features, small one, without child themes.

Naybe you will link this repo to the theme in your readme.
https://github.com/bueltge/Documentation
Thanks

One of the most important template locations for which a standard hook is needed is post content; primarily, allowing for injection of code/content after the post content.

I would recommend any/all of the following template locations for consideration:

post_meta
post_title
post_content (or post_entry or whatever)

Or, using the existing entry nomenclature, perhaps:

entry_meta
entry_title
entry_content

...with _before and _after variants for each.

http://yoast.com/standard-wordpress-theme-hooks/

The idea for it actually comes by Yoast. But I also think that would be very useful:

The tha prefix on all the hooks is kinda like a branding, and many people I know wouldn't like to see something like this in their own themes (except when it's wp).
So why not use a constant for that, like in the linked post?

WP_THEME_NAMESPACE could be the name, and each theme developer would have to define this variable (in a conditional statement to allow child-theme developers to override it if they choose to replace all the hooks). In the file tha_theme_hooks.php a fallback (also in a conditional statement of course) could be placed which would then hold the name tha.
This change would not make any functional difference, but I think more people would be using it.

I would happily make a pull request for that, but first I would like to hear about what you think.

While THA currently provides a nice basic set of theme hooks, for some common theme features there is not an obvious choice to use among the existing hooks. Case in point, breadcrumb trails. While one could assume they belong within tha_header_bottom, tha_header_after is still a valid location, as are a few other places. This ambiguity makes it difficult for plugins to hook into the correct spot (have to start making bad assumptions).

It would be nice to have something like tha_breadcrumbs (preferably a filter). While a call to it could be placed directly within a theme (via something like tha_breadcrumbs()), the way I see it being used is within a function that hooks into an already existing THA hook (such as tha_header_after). Hence why I called it a "Meta" hook.

This was spawned by the discussion between Ryan and Brian on the WP Candy Podcast Ep. 34.

What about standardized hooks for admin panels for a given theme?

It would be nice to tag a new release for the composer repo on Packagist.org to use. This should allow composer to cache the specified version locally instead of having to request it every time it's installed/

Also, if you'd like to be added as the maintainer I can transfer it over to you. Right now I'm the maintainer, but I can't set up auto update service hooks because I don't have commit access to this repo. https://packagist.org/packages/zamoose/themehookalliance

After using THA for a while, there are two hooks that I think should really be added. Right now there's no hook for within the actual "content" area of an entry. This makes hooking the the post content along with other post elements a little tricky as it needs to be done with priority juggling and choosing whether or not the content goes on the top or bottom.

The other missing hook is an after endwhile hook. Sometimes you need to hook content after the
<?php while ( have_posts() ) : the_post(); ?> part of a loop but before the endif check to see if the loop actually contains post data.

I know there are some old proposals to add more content-specific hooks and things like that, but so far I think these are the only two that can actually cause a problem because they are omitted. Related to #7 and #9

Hey,

Wanted to check if I got this right. Is this how sidebar hooks are meant to be used?

Instead of define( 'THA_HOOKS_SUPPORT', true ); you/we could do add_theme_support( 'tha-hooks' ); etc.