[theme-reviewers] Unregistering default widgets

Fri Jun 1 14:49:16 UTC 2012

On 01.06.2012, at 16:39, Chip Bennett wrote:

> I agree with this. Themes should not be *removing* core functionality - including core Widgets. Modifying/enhancing that functionality is a different - and should be an acceptable - matter.

Absolutely, as long as they're registered as their own Widget. See it as part of Theme name-spacing.

On 01.06.2012, at 16:35, Edward Caissie wrote:

> hmm ... let me try a different approach:
> 
> Deregistering core widgets should only be done if an enhanced version of that exact widget is registered that includes *all* of the original widget's functionality; otherwise just register a new *required theme-specific* widget.

But even then, the core Widget does not need to be deregistered. The only argument in that direction came from Chip: "Having two Widgets with equivalent functionality is redundant and confusing, and adds to the already crowded/poor UX of the Appearance -> Widgets screen"

> BUT, what happens when the theme is deactivated? Are these newly registered theme-specific widgets deregistered and the original core widgets re-registered?

I'd say so. But they won't be carried over to the new Theme obviously, as they go with the old one.

> On Fri, Jun 1, 2012 at 10:19 AM, Philip M. Hofer (Frumph) <philip at frumph.net> wrote:
> The important question is if you see a reason why they shouldn’t.  Not if they shouldn’t, but why they shouldn’t.   There is a valid reason why jquery shouldn't be deregistered.  Hence why it’s a guideline not to.

Yes, the reason is to ensure a consistent user experience across Themes.
I agree, there are (probably) no technical repercussions like when deregistering jQuery. Except for Plugins trying to modify core Widgets maybe

> 
> 
> On Fri, Jun 1, 2012 at 10:19 AM, Philip M. Hofer (Frumph) <philip at frumph.net> wrote:
> The important question is if you see a reason why they shouldn’t.  Not if they shouldn’t, but why they shouldn’t.   There is a valid reason why jquery shouldn't be deregistered.  Hence why it’s a guideline not to.
>  
> America put into effect over 40,000 new laws this year, 39,999 of them you will never know until you’re in court defending yourself.  
>  
> I’m not a fan of “no tolerance”, it takes a lot away from creativity and possibilities of implementation.   Especially when implementation doesn’t effect anything.
>  
>  
>  
> From: Konstantin Obenland
> Sent: Friday, June 01, 2012 7:09 AM
> To: theme-reviewers at lists.wordpress.org
> Subject: Re: [theme-reviewers] Unregistering default widgets
>  
>> This is one of the favorite features of many of my theme users.
> 
> What is? Your custom Widgets, or you deregistering core widgets?
>  
> Again: My point is not that you shouldn't register custom widgets, I just don't see a reason for Themes to disable core Widgets.
>  
>  
>  
> On 01.06.2012, at 15:49, Justin Tadlock wrote:
> 
>> I've been de-registering core widgets and registering custom widgets to replace them for years without any user problems.
>> 
>> De-registering widgets should not cause issues with core code.  Core provides the built-in functionality to do the de-registering.
>> 
>> This is also not a niche use-case.  This is one of the favorite features of many of my theme users.  Most of these users just have a regular blog with nothing particularly niche about it.  They just like to have some level of control over how widgets are output, which is what all my themes provide.
>> 
>> On 6/1/2012 7:59 AM, Edward Caissie wrote:
>>> 
>>> I'm leaning very strongly towards *not* de-registering core widgets ... add as many (as reasonable) theme specific/custom widgets you want, but I agree too much work has gone into insuring widgets remain between themes. I would expect de-registering them to cause issues with the core code.
>>> 
>>> If this conversation was in regards to a non-repository theme I probably would not see any issue as it would then likely also be a niche use-case which typically is not the guiding principle behind a theme released to the repository.
>>> 
>>> 
>>> Cais.
>>> 
>>> 
>>> On Fri, Jun 1, 2012 at 8:42 AM, Konstantin Obenland <konstantin at obenland.it> wrote:
>>> For what it's worth:
>>> By extending the core widget and registering the extending class, you can overwrite methods of the core widget class: https://gist.github.com/2851784
>>> But honestly, I think that's even worse, because now they look like a core widget but behave differently :)
>>>  
>>> Sorry, but I still don't buy in. :) Aren't we here on the functionality side of Presentation vs. Functionality? Where is the line between deregistering a core widget and removing an image size (for the lack of a better example)?
>>> Core worked so hard on providing the ability to retain Widgets on Theme switch - and then the widgets themselves are gone...
>>>  
>>> Konstantin
>>>  
>>>  
>>> On 01.06.2012, at 14:25, Chip Bennett wrote:
>>> 
>>>> Because having two Widgets with equivalent functionality is redundant and confusing, and adds to the already crowded/poor UX of the Appearance -> Widgets screen. :)
>>>>  
>>>> Chip
>>>> 
>>>> On Fri, Jun 1, 2012 at 7:08 AM, Konstantin Obenland <konstantin at obenland.it> wrote:
>>>> @chipbennett:
>>>> You're referring to Oenology, right?
>>>> Why are you deregistering the core Widgets, rather than just adding your custom ones? :)
>>>>  
>>>> @Frumph
>>>> What benefit does it have? Why not just add custom widgets to the existing ones?
>>>> I think it would affect user experience, as they might expect certain core widgets to be there, and all over sudden they're gone or their behavior changed.
>>>>  
>>>> Konstantin
>>>>  
>>>>  
>>>> On 01.06.2012, at 14:00, Philip M. Hofer (Frumph) wrote:
>>>> 
>>>>> Q. Does it affect any plugins or other stripends if someone did deregister and reregister their custom widgets? 
>>>>> A. No? (can’t think of any)
>>>>>  
>>>>>  
>>>>>  
>>>>> From: Chip Bennett
>>>>> Sent: Friday, June 01, 2012 4:43 AM
>>>>> To: theme-reviewers at lists.wordpress.org
>>>>> Subject: Re: [theme-reviewers] Unregistering default widgets
>>>>>  
>>>>> Actually, I use this. Mainly due to a lack of a better work-around (though I'm open to ideas). I needed to modify the container markup slightly, to implement the "show/hide" links for the Widgets. Rather than simply forking the core Widgets as *new* Widgets, I deregister the core Widgets, and then re-register my modified versions. 
>>>>>  
>>>>> I don't mind using a different approach, if anyone has a good suggestion. I mainly just don't want to load jQuery just for such a simple effect.
>>>>>  
>>>>> Chip
>>>>>  
>>>>> On Fri, Jun 1, 2012 at 3:19 AM, Emil Uzelac <emil at themeid.com> wrote:
>>>>> I am pretty sure that this would be considered as "locking" the core functionalities and not really sure what would be the reason and scenario when author would unregister default widget and replace them with Theme-specific. If this is not in review and I can't find it either, well it should be for sure. Good eye Konstantin!
>>>>> 
>>>>> My 2c!
>>>>> 
>>>>> Emil 
>>>>>  
>>>>> On Fri, Jun 1, 2012 at 3:08 AM, Konstantin Obenland <konstantin at obenland.it> wrote:
>>>>> Hi all,
>>>>> 
>>>>> I didn't find documentation on whether it is allowed for Theme authors to unregister default widgets.
>>>>> Is it?
>>>>> 
>>>>> Thanks,
>>>>> Konstantin
>>>>> _______________________________________________
>>>>> theme-reviewers mailing list
>>>>> theme-reviewers at lists.wordpress.org
>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>>  
>>>>> 
>>>>> _______________________________________________
>>>>> theme-reviewers mailing list
>>>>> theme-reviewers at lists.wordpress.org
>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>> 
>>>>>  
>>>>>  
>>>>> _______________________________________________
>>>>> theme-reviewers mailing list
>>>>> theme-reviewers at lists.wordpress.org
>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>> _______________________________________________
>>>>> theme-reviewers mailing list
>>>>> theme-reviewers at lists.wordpress.org
>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>> 
>>>>  
>>>> 
>>>> _______________________________________________
>>>> theme-reviewers mailing list
>>>> theme-reviewers at lists.wordpress.org
>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>> 
>>>>  
>>>> _______________________________________________
>>>> theme-reviewers mailing list
>>>> theme-reviewers at lists.wordpress.org
>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>> 
>>>  
>>> 
>>> _______________________________________________
>>> theme-reviewers mailing list
>>> theme-reviewers at lists.wordpress.org
>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> theme-reviewers mailing list
>>> theme-reviewers at lists.wordpress.org
>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
> 
> 
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
> 
> 
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
> 
> 
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20120601/0db177d1/attachment-0001.htm>