I’ve been working on a new theme, which will be applied to this site after all the others, and because of the way I have created it I have had to call a lot of the hooks manually. For example, I am not using the template tag the_content, instead I am using apply_filters( ‘the_content’ , $this->post->post_content ); inside a function. This has made me think about the types of filters and actions we should expect to see in plugins.
There are conceivably three things that I might want to override with someone else plugin:
These can be achieved in a few different ways.
Assuming the data is retrieved using standard WordPress functions then being able to filter an array of default values before the query goes ahead should do the trick. This would allow plugins to be expanded to do things that weren’t originally intended.
Using callbacks to process data, and then filtering the name of that callback would allow significant parts of a plugin to be overriden; for example:
[php]
$callback = apply_filters('my_plugin_function_callback',array($this,'myfunction'));
$returned_data = array_filter ( $input , $callback );
Finally, using templates to output content, checking the current theme to see if there is an alternative template in the theme folder, and sending the template path through a filter before hand would give maximum flexibility.
How difficult or easy all this would be very much depends on the plugin. My question is whether we should built in this way and more importantly whether we should expect plugins to be as configurable as the core itself.
In my next post I will write a plugin that uses all of these techniques, and then modify it with a second plugin to demonstrate the benefits of this.
(__)
`
Configurable Plugins | WP FUN
[...] should plugins should be written to be as extensible, if not more, as the core WordPress code; i.e. should we expect a plugin to be written with the expectation that someone will write a plugin to fur… I promised an example so here it [...]