[wp-hackers] Programmatic Widget Handling
emoya at tribune.com
Wed Oct 20 16:52:56 UTC 2010
Interesting this coming up now. Recently I "finished" writing a plugin that adds a control mechanism to widget, much like we handle plugins. I wouldn't call it complete (and there is no actual GUI yet) - but its sufficient at the moment to allow us to easily modify active and inactive widgets for the various environments we have.
With it, I can currently create default settings. A list of widgets which the plugin automatically takes control of and can immediately have them enabled or disabled.
I have it setup so that a widget that isnt in the defaults needs to be "registered" with the plugin. The plugin then takes control of the widget in terms of its registration with the core widget API.
/*this will also look trigger __autoload to inteligently
search for the plugin file if its not locally available in the plugins custom directory */
Add_widget comes with optional flags that allow the widget to be immediately enabled, and to pass custom paths. Once the plugin has control over the widget, its a simple step to have that widget enabled/disabled (activated/deactivated). It also includes an ability to "delete" the widget - although this only actually removes it from the list of widgets the plugin is controlling.
And of course...
$widget_pack->reset_defaults(); // for those "oops's"
As mentioned above, there is also has a special directory where the plugin will take control over any widget in that directory. (something like how the plugins are automatically detected by wp), although the use of that is limited since that part is a bit buggy.
Beyond building a much needed interface for it (possibly modeled partially after the plugin page) - my next step was going to be setting up more granulated controls to allow for permission settings. So only certain roles or capabilities could have access to certain widgets (for example, the oft misused "Text Widget"). However I ran into siginificant difficulty in figuring out how to have a widget turned on, but not show in the widget page AND still show up on the page if it was set up by a different user - so I just kind of scrapped that.
Really at the moment its just an api, and a simple one at that. Not exactly what was brought up, but its germane in that there is a lot lacking in terms of configuring widgets - and certainly these are some basic control features I think wordpress widgets needs to have.
On 10/20/10 10:54 AM, "Peter Westwood" <peter.westwood at ftwr.co.uk> wrote:
On 20 Oct 2010, at 16:48, Jeremy Clarke wrote:
> On Tue, Oct 19, 2010 at 5:04 AM, Peter Westwood
> <peter.westwood at ftwr.co.uk>wrote:
>> It sounds like what you need is a comprehensive widget management api!
>> The best way to get this is to work through the current widget code in
>> wp-admin/widgets.php and try and abstract it out into an api which that code
>> can use and your plugin can use.
>> Submit this as a core patch and once it is included you will have an api to
>> base your plugin on.
> WP needs this badly. Among other automation-related uses it would be great
> if themes could define initial widgets for their widget zones in
> functions.php rather than having hard-coded alternate content (which
> confuses users who go to Appearance > Widgets and see nothing there to
> explain what's already visible on the site).
http://blog.ftwr.co.uk | http://westi.wordpress.com
C53C F8FC 8796 8508 88D6 C950 54F4 5DCD A834 01C5
wp-hackers mailing list
wp-hackers at lists.automattic.com
More information about the wp-hackers