Standard Naming of Hooks in Themes

[dcole07]

Hooks in themes are a great idea. Plugins can add their code in without making users do any copying and pasting. People it also safe guards changes to the theme, because your not editing core theme files. I can go into this more if need be.

What I want to do is create (an optional) standard for having hooks in themes. To popularize this, the default themes that come with WordPress should include these hooks. As more themes start using hooks in their themes and use the same hook names as everyone else, plugins and what not can start doing to WordPress themes as they did with WordPress.

I've asked some theme enthusiasts, as well as some popular theme developers, and they generally agree that these hooks should start out with theme_, use before / after instead of above / below or pre / post, use underscores in place of spaces, and be descriptive.

I'm going to take ownership of this ticket and create the patch. Feel free to voice your thoughts.

[dcole07]

As suggested by azaozz, ​http://core.trac.wordpress.org/ticket/10334#comment:8 "The proper way to fix this would be to standardize the hook name and location and add it to the Default and Classic themes."

[Denis-de-Bernardy]

yawn... there are so many hooks in themes already... I truly fail to see the point.

there already are loop_start, loop_end, the_post, the multitudes of hooks in the template tags, the widgets and their lot of hooks, wp_head, wp_footer... you're not seeing them in theme files, but they're definitely around.

suggesting wontfix, personally.

[dcole07]

Replying to Denis-de-Bernardy:

yawn... there are so many hooks in themes already... I truly fail to see the point.

I still think there are some key locations that are missing hooks. If you take a look at themes like Thematic and Hybrid, they have hooks that address more locations and allow for most custom-ability without having to edit core theme code. Currently theme don't have enough basic hooks, besides the ones you mentioned, to hook into. Were now seeing more themes get bloated with "theme options", because plugins can't add the functionality without asking the end user to copy and paste code into their theme. I think we need to look into the future and think about how plugins could extend themes. I also think we should not blow of this idea without consider the potential demand for hooks in some additional key areas.

[Denis-de-Bernardy]

Let me guess. They also have some kind of custom.php file? That sounds... sooooo Semiologic 2.0 (= 2005). I'm "impressed" by their innovative spirit.

Joke set aside. Tried it, used it for well over 2 years on my end. Abandoned it, and was very happy to do so.

[dcole07]

This ticket isn't advocating a custom.php file, which is a bad idea if your using the automatic updater, but it's also a bad idea because it lacks in organizations.

I'll put together a list of hooks I think would improve themes and put it up for debate. I don't think making the average person dig through theme source code is the way to go in order for plugins to function correctly, yet I don't think we need to add 100 more hooks.

[Denis-de-Bernardy]

Yaya, it's perfectly clear you want new hooks. I was merely mentioning how these hooks ended up used in practice when theme authors add them.

Quite frankly, having gone through this myself, and having maintained a template that had tons of hooks at one point while keeping other themes in mind for my plugins, the only hooks I've ever wished was present on all installs were a wp_header hook immediately after the body tag. Then again, they can easily be replaced by hooking into wp_head.

The remaining bonus hooks in themes you're wishing for, are really just a convenience for end-users who don't understand the WP internals. Yet, I can tell you with reasonable confidence that there almost always is a non-obvious hook that can be used in a way or another.

Adding to this, my key finding -- if any -- was that having too obvious hooks in a template was bait for end-users to try to use them, for all sorts of things that they shouldn't even be trying. The last thing you want is Joe six-pack's mom requesting help in a support forum in order to code a php function. I speak from experience here, too -- I've helped hundreds of them, and dealing with them is not fun *at all*.

The most important point to keep in mind, though, is that a lot of themes don't go as far as adding the wp_footer() call. If we add a half dozen more such things, you're guaranteed that plugins will advertise themselves as being click and do nothing things -- but the reality is going it's going to be chaos in the support forum because they still have to do something.

[Denis-de-Bernardy]

Here, have a look at two themes I wrote, and see how things have evolved:

old -- ​http://www.semiologic.com/media/software/sem-theme/semiologic.zip

new -- ​http://www.semiologic.com/media/software/sem-reloaded/sem-reloaded.zip

Note the complete absence of hooks in the second one. It took me an awful lot of time to reeducate users.

[dcole07]

Replying to Denis-de-Bernardy:

Note the complete absence of hooks in the second one. It took me an awful lot of time to reeducate users.

Inserting code manually is a bad idea in so many ways. I think it's clear we don't want just anyone doing that. Having hooks creates problems because plugins actually use them, but theme authors don't care enough to add them or something. So what's a solution to this problem? The current way is far from perfect IMO... It seams like we have to put the burden on someone, who should it be? End users? Plugin developers? Theme Developers? Were currently putting in on End users, because plugins are making end users copy and paste code in manually. (Not to mention the other side effects of them doing that.) A solution is not to force plugin developers to come up with some obscure way of adding code in automatically. It's clearly not working now.

[junsuijin]

Replying to dcole07:

Replying to Denis-de-Bernardy:

Note the complete absence of hooks in the second one. It took me an awful lot of time to reeducate users.

Inserting code manually is a bad idea in so many ways. I think it's clear we don't want just anyone doing that. Having hooks creates problems because plugins actually use them, but theme authors don't care enough to add them or something. So what's a solution to this problem? The current way is far from perfect IMO... It seams like we have to put the burden on someone, who should it be? End users? Plugin developers? Theme Developers? Were currently putting in on End users, because plugins are making end users copy and paste code in manually. (Not to mention the other side effects of them doing that.) A solution is not to force plugin developers to come up with some obscure way of adding code in automatically. It's clearly not working now.

What's wrong with using widgets for most of the things plugins want to insert into themes? Widgets have been greatly enhanced and simplified with 2.8. If the plugin wants to insert something in an area that is not accessible by a dynamic sidebar, then there is likely already a hook to place it correctly anyway (such as at the end or beginning of posts, etc). If plugin developers provide widgets and options to hook onto any other areas they wish to modify in a theme, I don't see any real reason to make any standardized hooks that aren't already included.

[dcole07]

If there are work-a-rounds to inserting code any where within a, then maybe we should include functions in core, so plugins can use them without having to think it up for themselves.

How could someone insert code into the page div, before (or after) the header div, and at the same level as the header div?
How could someone insert code into the header div?

[Denis-de-Bernardy]

Replying to dcole07:

How could someone insert code into the page div, before (or after) the header div, and at the same level as the header div?
How could someone insert code into the header div?

And then, how can you be sure a theme has a header at all? Not all do.

Even if they did, there are so many possibilities here that a generic hook simply cannot work. What happens when a plugin tosses in some clunky code into a theme's header that wrecks the layout. It will happen. (I even happen on the default theme with sidebars: add a <div style="clear: both"> in the sidebar, and giggle at the mess.)

Now, imagine we introduce a dozen more hooks in locations that are inconsistently named and styled from a theme to the next. Sadly, it's just asking for trouble...

[dcole07]

This problem doesn't effect me, because I know how to program and only use my own self created themes, so I will not fight to the death for this. It's seam that this the best answer and there really isn't an out cry from end users for this theme & plugin incompatibility problem to be fixed, so I'll close this and move on.

[dcole07]

I need an edit button here in Trac... I make typos every time.

*It's seam that this not the best answer...