[wp-hackers] Programmatic Widget Handling

[Moya, Eddie]

I'd like to add to what I said yesterday that, the point of the whole discussion is not the features of the plugin I am building, rather that there is a lot of missing functionality for widgets, from an API perspective as well as from an end-user admin-panel perspective. In some cases the need for admin-panel functionality can be remedied by a plugin, but first we need an underlying widget api robust enough to give developers that flexibility.

Also, my previous explanation about how I managed to limit the appearance of a widget to a specific sidebar through various CSS hacks, was meant to illustrate the existing difficulty of doing something that really should be fairly simple. It was _NOT_ meant as a suggested permanent solution.  That's "NOT", with a capital "N.O."

Just wanted to clear that up, since I got a response from some one thinking I meant the CSS hack should be implemented into wp somehow.

--
Eddie Moya
Applications Developer
Tribune Technology



On 10/20/10 2:50 PM, "Eddie Moya" <emoya at tribune.com> wrote:



On 10/20/10 2:06 PM, "Jeremy Clarke" <jer at simianuprising.com> wrote:

> I might have been confused because that is something that is easy to do with
> the existing api:

Thing is, as I said, what I have is basically a really simple api, what is needed is an interface. So that this can b done without needing to write a new custom_widgets_init each time, and without hardcoding widget names. Of course, since what I have does not have a GUI yet, yes it basically mimics part of what your describing. The intent has always been to add an interface to this though that has no hard-coded widget names.



> If someone can edit a sidebar then having widgets that they can't edit will
> mean there are parts of the sidebar that they can't change. This seems
> pretty user-unfriendly to me, and I don't even want to start thinking
> through all the logic you'd need to handle to make it work well.

Agreed, the logical mayhem I ran into just trying to come up with a plan of action for this is the reason I "scrapped it" as I said before. Still, it seems that some way of limiting access to a widgets based on users capabilities would be a very valuable addition. The way this might be handled or accomplished is obviously up in the air. Nonetheless, its not a leap of crazy logic to say that it would be useful to have users with ABC capability be able to edit Sidebar_X, but not have access to Some_Important_Widget, while still giving that access to certain other users.

As far as it not being user-friendly, that all depends on presentation of course and making sure there isnt unexpected background behavior going on. I envision a locked widget might just be permanently collapsed, undraggable, and have a little padlock on it to indicate its been locked. Easier said than done though.



> I'd tend to think that you should instead limit Widgets/Sidebars access to those you can
> trust with the content of the sidebar.

Are you saying there is a way to do this already? If not an alternative to the aforementioned - this would be a great feature  of its own. Something like this combined with what I listed as #2 - the ability to add contraints to a widget in terms of which sidebars it can/cant be used with - might together solve some of what is needed for #3. However, this would not be ideal, since it would leave the entire affair dependant on the number of sidebars built into a theme - rather than just giving admins the ability to control access to widgets directly.


--
Eddie Moya
Applications Developer
Tribune Technology



_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers