[wp-hackers] Programmatic Widget Handling
emoya at tribune.com
Wed Oct 20 18:33:45 UTC 2010
Seems you may have misunderstood what "add_widget" does in my plugin. It does not add the widget to a sidebar (although such an additional feature would be very simple to add, I think) - rather in merely adds it to the internal list of widgets under the control of the plugin.
The benefit for us in this regard, is that we don't have to change which widgets are in our source control depending on which environment we are releasing to. The specific reason I just explained -sure- is not the most common, however the general ability to make a widget activate and deactivate, including the built in default widgets seems to a fairly basic and generic feature.
Of course, if something like the functions I have created would be added to the existing API, they probably wouldn't need to be configured the same way - it may or may not even need an equivalent of add_widget if this were in core. The reason for the way it works now, is because for my to able to independently turn on and off a widget, without removing the code and without necessarily deactivating plugins (not to mention the default widgets), I need to take over control of the widget registration process. That's exactly what I do. If I were to do this by modifying core I would do it much differently. If there were interest in having this added to core, I would start changing directions and think about it that way
In regard to limiting widgets to specific sidebars, I agree that its probably best if it were something that was part of the register_sidebar() function. I wont be doing it that way however, since I am not patching core, I am writing a plugin to do what core doesn't. So much in the same way I might incorporate the constraint into register_sidebar, I will have to incorporate it into add_widget() (which functions as the register_widget for my widget control plugin.
Simple control features I think widgets need.
1. Activate/Deactivate, similar to the way you can with plugins
2. Constraints. Ability to limit a widget to work on certain sidebars, both inclusive and exclusive logic.
3. Role/Capability-based access using/modifying widgets. (Possibly equally as needed, but probably more difficult to implement)
For number 3, obviously widget developers can create there widgets with capability-based conditions in place - but whats really needed is for the users of any widget to be able to say certain widgets are off-limits to certain users.
On 10/20/10 1:08 PM, "Jeremy Clarke" <jer at simianuprising.com> wrote:
On Wed, Oct 20, 2010 at 2:02 PM, Moya, Eddie <emoya at tribune.com> wrote:
> We need to have this sort of constraint available. This I think I can do.
> In fact I only have not added it because other priorities have taken up my
> time. I am fairly certain that creating a way of having logic where it only
> loads in a sidebar named "sidebar1" for example. I think the quick (less
> elegant) solution will be to let users add the widget to whatever sidebar
> they want, but simply have that widget not work if the constraint is not
FWIW I think the use-case you're dealing with is probably outside the scope
of the much more general API that should be in core. Limiting what widgets
can go in what sidebar may also be a use-case the API should handle, but
that would probably do better to be part of the register_sidebar() end of
things rather than the suite of functions that would allow adding of widgets
into sidebars with PHP (other features that would be nice in
register_sidebar() would be limits on the number of widgets that can go in
and the ability to randomize their order).
Obviously you are adding widgets programmatically for some reason, so even
if this theoretical new API didn't account for your constraints, it would
let you focus only on those parts of your problem rather than having it all
mixed together in your workaround class.
Jeremy Clarke | http://jeremyclarke.org
wp-hackers mailing list
wp-hackers at lists.automattic.com
More information about the wp-hackers