Otto, thank you for your insight. I didn't mean to imply that that there is something wrong with your work, as I was only trying to detail my reasons for writing this plugin instead of using any of the existing solutions. Sorry if it did sound that way.
I completely agree with you that plugin authors are doing wrong by not supplying widget output, but nobody can't blame them, because it is the nature of open source -- you either use it, improve it or create your own.
At the same time it is obvious that plugin authors would make the world of WordPress a better place by taking that extra hour to actually create widgets for their plugin (if applicable, of course), instead of asking users to install an extra plugin.
Taking your suggestion, I will definitely try to write a tutorial for the plugin authors to explain how easy it is to add a widget, and will provide a few templates as well.
For me the confusing part while writing this (my first) plugin was when to use the register_sidebar_widget and add_action hooks. It took me days to figure out how to pass additional variables to the function defined at register_sidebar_widget without making an extra call to get_option.
Now, regarding the "limitations" of this idea -- to use only one function call and not allow PHP execution.
- I think that the function hooks provided by the plugin authors should never require users to supply variables derived from the WordPress core (like
$post->ID), as they all are available to the plugin itself. Moreover, $post->ID is not even available outside the post loop, which makes it more complicated for an average user. It would be much better to ask the user for a simple argument, like $whichpost = 'this', or $whichpost = 'next'. The plugin should do the work of finding which post ID it is that the user wants.
- It is hard for me to image a situation when the plugin would need multiple function calls to generate the output for a widget, if written correctly. In fact, it depends only on the number of variables that the widget has to consider to generate the desired output. In WordPress, all the dynamic information is available to plugins. Information required from the user is really very minimal.
Therefore, I think that the functionality of CFW plugin is not limited if the function hooks of the plugin it uses have been written with flexibility and usability in mind.
Finally, I would like to explain why the option to turn off widget wrapper is valid and sound from the perspective of presentation (theme) authors and content creators (widget authors). It is important to note that this options is turned off by default, and that there are in fact two options: (1) to turn off only the title, and (2) to turn off the title and the wrapper.
It is assumed that people wouldn't normally want to do it (therefore the defaults), but in special cases it might useful. Widgets can be used outside the sidebars, if the theme allows, and it probable that such an option may be required for more advances users/websites, while the average users may simply ignore it.
It doesn't break the theme by default and it behaves just like the author of the theme has intended for a widget to behave. That is the most important thing.
kasparsd
