Thanks, MichaelH. That’s close, but not quite.
Dynamic Widgets basically lets me restricted which widgets get displayed on which pages, but doesn’t change the functionality of a widget.
Widget Logic lets me change the functionality of a widget but only as far as replacing its content, but you still have to make a callback function. And this is more easily done without this widget by editing your theme files. You can edit your sidebar.php file and tack something in at the top like:
add_filter('dynamic_sidebar_params','filterWidget');
function filterWidget($args) {
switch($args[0]['widget_name']) {
case 'Meta':
case 'Categories':
case 'Pages':
return 0; //hide widget output
break;
case 'Links':
//display new widget replacement output
echo '<li class="widget"><h2 class="widgettitle">Links</h2>Hello world</li>';
return 0; //hide previous widget output
break;
default:
//echo "<br /><br />";
//print_r($args);
//echo "<br /><br />";
return $args;
} //end switch
}
The above code hides the Meta, Categories, and Pages widgets, but then takes the Blogroll (aka Links) widget and replaces its content entirely.
So, it’s through the add_filter() call on the dynamic_sidebar_params that I am going to be able to rebuild the default gadgets with replacement code. It’s fairly easy to rebuild the Archives, Recent Posts, and Recent Comments plugin logic with one that restricts by category. But rebuilding the Calendar and the Tag Cloud takes a bit of work.
Anyway, my problem is solved because I think this is the best approach. I mean, if one writes code that goes directly against the native SQL API in their plugin, it will work today, but will be a rocky road in the upgrade path potentially, especially as we approach the dramatic changes of WP 3.0 coming down the road. It’s best to try and remain within the codex as much as possible to provide the best upgrade path for your theme or widget, in my opinion.