[theme-reviewers] Unregistering default widgets

Philip M. Hofer (Frumph) philip at frumph.net
Fri Jun 1 14:19:37 UTC 2012


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20120601/49e35e1d/attachment.htm>


More information about the theme-reviewers mailing list