An interesting discussion has popped up on WordPress Trac about making it easier for plugins to insert content before/after the post is displayed.
Currently, plugins add features to the the_content hook, which is problematic. Some of these things are sharing icons, related posts, author bio boxes, and much more. The problem is this tends to get rather ugly, especially with some theme designs. Most of the time, the things that plugins add are shown before the post meta or pagination links when using multi-paged posts.
This issue has been around for years. I’m happy that there’s at least a discussion happening about ways to overcome it. If you’re a theme developer, I encourage you jump in if you have a fresh idea.
I wanted to take this discussion to another level though by fully explaining and further refining my comment on the discussion and why it will work for this situation as well as similar situations in the future. Since some of this isn’t directly related to the ticket, I wanted to kick start a discussion on the overall problem.
The problem
Right now, plugins only have a few places where they can reliably hook content into themes. Sometimes, the hooks that are available aren’t ideal for the scenario. The problem is that WordPress can’t simply introduce a ton of new hooks for themes to start using because it takes a long time for standards to form.
Themes are also vastly different from one another. Therefore, it’s hard to standardize some things while also allowing complete flexibility. Some things, such as displaying a post, all themes must do, so there are some areas that are easier to standardize upon than others.
A solution for themes
Assuming something is decided upon and hooks are added before/after a post is displayed, what happens when we run into this problem later with another area? My solution seeks to handle this too.
The idea is that WordPress would have some predefined “template hooks” that themes are strongly recommended to use, at least until they eventually become a standard. Themes would need to register support for this feature and choose the hooks their templates support.
Suppose the first two hooks are the aforementioned before/after post hooks. Themes would simply add this to their functions.php to register support for these hooks:
add_theme_support( 'template-hooks', array( 'before_post', 'after_post' ) );In the theme templates, such as index.php, the theme would simply have something like the following.
<?php do_action( 'before_post' ); ?>
Post stuff would go here.
<?php do_action( 'after_post' ); ?>This method would solve the immediate problem with before/after post hooks to some degree as well as provide a method if we need additional template hooks in the future.
If you don’t like the idea of theme authors dropping do_action() into their theme templates, accompanying template tags such as before_post() and after_post() can be easily arranged.
A solution for plugins
If themes were using this proposed method, plugins would be able to easily check if a theme supported a certain hook and fall back to something else if not.
Sticking with the before/after post hooks, a plugin would need something similar to the following code to add content to the post area.
if ( current_theme_supports( 'template-hooks' ) )
$hooks = get_theme_support( 'template-hooks' );
if ( isset( $hooks ) && in_array( 'after_post', $hooks[0] ) )
add_action( 'after_post', 'example_plugin_function' );
else
add_filter( 'the_content', 'example_plugin_function' );Is this an ideal solution?
Probably not. There’s not perfect solution for this situation. It’s something that will need to be widely adopted and might take a while to work. Whatever solution is decided on will leave plugin authors doing if/else checks in their code.
Another benefit (or problem) with my solution is that we don’t need to change code in WordPress core for it to work. Themes and plugins can actually take advantage of this now.
There are tons of ideas right now. Do you like my proposed method? Or, do you have a better solution?
And this is another example of something I’ve really never had to worry about, considering Hybrid and Devpress have always made this sort of thing simple.
I have been dealing with TwentyEleven some recently where I couldn’t choose the theme / framework, and I’m realizing how good I normally have it with hookability / modularity.
Thinking through this from a
DOM-centric point of view, it would be nice if one could register a function on a specific$postobject property name. At least with themes, this would standardize/sync the post filter/event model with the$postobject model.As a grossly simple example, when
$post->post_contentis accessed in the WP internals, instead of accessing it directly, it would be passed as an argument to a function that would execute any functions listening to thepost_contentevent and then return the result to the WP internals. This would abstract the filter/event model in a way that would scale with the$postobject.For
$post->post_contentspecifically, it would make sense to do this inget_the_content(), since this is the final endpoint before it is returned to a theme. It would be tedious to decide on the endpoint for each property, but it would be a great system.Just thinking out loud.
And I could missing a ton of red flags.
Justin, it looks great and i even can think one step ahead. Imagine that plugin developers, when those template-hooks will be supported, will give for plugin users opportunity to choose where plugin will output its content.
Evene maybe it could look like this in theme functions.php:
add_theme_support( ‘template-hooks’, array(
‘before_post’ => array(
‘screenshot’ => get_bloginfo(‘template_directory) . ‘scr1.png’),
‘after_post’ => array(
‘screenshot’ => get_bloginfo(‘template_directory) . ‘scr2.png’), )
);
in ‘screenshot’ (not obligatory) would be provided url of screenshot of place in theme where plugin content will be outputed. then plugin developers could at plugin’s settings page show this, to help user to choose where to show aoutput
I like the idea. It makes sense to me.
Justin,
For this idea to work there needs to be a central repository where theme and plugins authors can go to find which hooks have been introduced.
What are your thought on the Theme Hook Alliance effort? Seems to mirror your thinking on the subject.
I’m not big on the
tha_prefix. That’s one thing holding me back from getting involved with that. If I’m going to prefix my hook names, it’ll be with the name of the theme because that’s the current standard practice. What I’d like to see is a list of reserved hook names for themes backed by the core WP team whether they’re supported in core or not. That way, we can get rid of prefixes for hooks, which is the major hurdle we’ll have to overcome at some point in the future.I like the direction it’s moving though by creating standardized hooks.