WordPress Sidebars as Menus: Part 1

Thoughts on a different way to manage and store WordPress Sidebar Widgets.

Okay, fine, not all widgets are used in sidebars. I’m going to use sidebar here to make my life simpler and trust you know what I mean. After reading Trac 17979 and Jane’s post on Wherefore Art Thou, Widgets? I had some thoughts.

Right now, when you switch themes, if the sidebar doesn’t match a new sidebar area, the widgets get dumped into ‘Inactive’, which makes if difficult if you want to switch themes for testing. Kbitzing on this on Twitter, like we do a few of us started kicking around ideas, most of which the UI team folks in dev-chat had already gone through.

My first draft was pretty straight forward:

But then Jane pointed out:


Which is true. I have over 20 available widgets here, and that list would get pretty damn long. While a list of checkboxes strikes me as less pretty, you would be easier able to manage this:

In either case, you’d want the widgets ‘box’ where they’re listed to be scrollable. I’m fairly sure you could make an auto-resizing box that grew and shrank by height depending on how tall your window is and then allow for scrolling the rest of the way.

At this point, we’ve reached the end of my practical knowledge. I know that menus are stored in the wp_posts table as a custom post-type called nav_menu_item. And then the actual data is over in the wp_postmeta table, where the post_id is the same as the ID from the posts table, and the _menu_item_* settings are where the magic happens.

Post Meta Menu Example

On the other hand, widgets are stored in the table wp_options and not in the same way. They’re in one master field sidebars_widgets which stores all your information for widgets, which ‘sidebar’ they’re in, active or not. Each individual widget stores itself in widget_NAME.

Widgets in the DB

Clearly it would be a bad idea to attempt to save the widget data in post-types, so we’d have to have some way to reach back and get the data. But if it were possible to toss the sidebars_widgets data over into the posts table, then they’d be brought over when you ran an export/import of your site much like menus are, which would make moving people off of MultiSite and over to their own site a heck of a lot easier, wouldn’t it?

This is as far as my thinking takes me, but it’s something I’d love to play with.


  1. Instead of a big Sidebar Locations box in upper left, what if you made location an element in the Sidebars themselves (Primary, Test)? A nice touch would be to have a diagram of templates/sidebars that lights up on hover and lights up the sidebar list that goes with it.

    • In a first pass, I was (obviously) copying the look and feel from Menus directly. I’m not sure how you’d want to balance the huge change from the current UI experience for Widgets, and my feeling was if it looks like something else they already know and are comfortable with, it be as drastic a change. The big space makes more sense when you think about menus, though, and less with widgets (then again, I’ve often had my complicated PHP widgets open in a text editor to tweak and then paste back in). Maybe flip it around and put the ‘Sidebar Widgets’ box on the right, above the ‘view’ of the user defined Sidebars, assuming they’re all single column like they are today, and then use the left side as a double wide list of more compact widget boxes.

      Though to your point, a dropdown under the name (next to ‘Delete’) for ‘Available areas’ would be Even More Compact.

      The light-up would be awesome. ๐Ÿ˜€

    • That’s what I was thinking – selector in the widget area itself. I’m trying to imagine how the view would change (or not change) on theme switch, though., given the way it behaves now. I also feel like the widgets screen still needs to have the descriptions or else it’s a little bit cryptic, especially with non-default widgets. Need to get responsive right this time around, too!

      I LOVE the idea of a visual guide to where the sidebars are. Makes me think of Stephanie Leary’s layout fiddling with IDs: http://sillybean.net/downloads/widget-admin-ui-altered-with-ID.png (Trac ticket #18334: http://core.trac.wordpress.org/ticket/18334 – some other cool ideas there, too.)

    • How would that work with Text Widgets, though, and other multi-sidebar widgets? I mean, I have about six text widgets in my three sidebar areas. You’d have to have the dropdown in there.

    • I suppose I’d say whichever was most recent as far as the “Previously” text goes. I’d also say that changing it in the current theme would not wipe it out for the previous theme, but rather that it would just get reinstated if you were to go back to that theme (and maybe still tell you what you were using it for in the last theme). I could see myself using the same widget groups for very different locations depending on the theme, so I’m not 100% on wanting to name them. Actual mapping is a hard sell for me as well; I’m not quite sure I believe in it.

      Consistency, though. Always a good goal, but the menus screen isn’t perfect, either. The thing I need in menus now is a way to send something to the top.

    • I’m thinking the visual change could be as “simple” as http://cl.ly/2z0u0r400j0Y040O210Y (knowing that nothing is ever actually simple)

      On theme switch it could map/reassign or else unassign and mark as such without losing the widget area completely. Something would have to be done to make sure that a user gets yelled at (and can’t) assign multiple set ups to one area. There would also probably have to be some kind of delete button/link (e.g. clear) for a given widget area and *maybe* even an unassigned widget area holding cell, much like the one for inactive widgets.

    • I don’t know WHY I was thinking in the WIDGET and not in the Sidebar ‘section.’ A sign I need sleep. That image totally helped! Thanks, Helen!

      I’m mostly liking the idea of naming the areas yourself because not all themes name sidebar areas in ways that my brain likes — Footer 1, Footer 2 and Footer 3 make less sense to me than Left footer, right footer and middle footer. Then when you ‘lose’ your area on a theme switch, you at least know where you were putting that Widget Area (widget group? Darn it Sidebar!).

      You’d need a ‘unassigned sidebar’ area for the possible multiple sidebars, though, yeah, and a way to know which sidebar was which.

    • Oh hmmm that’s a good point; due to mapping, you may not know or remember what the sidebar was for previously. Maybe there could be a little piece of text in the sidebar area above the widgets saying “Previously: [former name]” if applicable. I also like the whole name-it-yourself thing, but I wonder if it’d be an annoying extra step for the average user. It’s actually one of my least favorite parts of nav menus; I almost always end up just naming them the same as what the theme calls them.

      The other thing I’m contemplating now is how an area would be added for each widget area in a theme for a user to drag stuff into if other areas already exist. I wouldn’t expect a user to have to create a new area and then assign it so much as a bunch of pre-assigned areas should show up on theme switch like it does now.

    • There isn’t really a perfect fix, but ‘consistency’ should count for something ๐Ÿ˜‰

      If you’re going to have ‘items’ (menus or sidebars) reused between themes, then you’ll want to store that data in a logical way for the LCD (lowest common denominator) to know what they were doing. Which is why as annoying and multi-stepped as Menus are, they do work well once you set them up. Mine are named clever things like ‘Top Nav’, ‘Lower Nav’ and ‘Footer Nav’.

      โ€œPreviously: [former name]โ€ is interesting. How would that work in the various scenarios pitched in the IRC log that preceded the poll though is interesting. If I go from 2010 to 2011 to Hybrid and back to 2011, which ‘Previously’ gets used?

    • what if you made location an element in the Sidebars themselves (Primary, Test)?

      But that’s entirely Theme-dependent, isn’t it? I’m really starting to love Mika’s mock-up here, because it essentially implements Widget “sets”, that can be applied to Theme-defined locations, in a way that is completely analogous to Navigation Menus.

      If I’m understanding you correctly, though (and perhaps I’m not?), in order to implement correctly, all Themes would have to standardize on dynamic sidebar locations (i.e. names).

      A nice touch would be to have a diagram of templates/sidebars that lights up on hover and lights up the sidebar list that goes with it.

      A good idea, but something else that will require buy-in from Theme developers (unless the core devs can come up with some auto-magical way to determine page layout and dynamic sidebar locations). Also: where would this diagram live (i.e. in the mock-up above)?

    • If Iโ€™m understanding you correctly, though (and perhaps Iโ€™m not?), in order to implement correctly, all Themes would have to standardize on dynamic sidebar locations (i.e. names).

      Which ‘you’? Not me, cause my thought is the sidebar ‘locations’ are defined by the theme (as they are today). You, the end user, name your sets however you want (so I may name my ‘Main Sidebar’ set ‘Primary with login code’) and apply it to a location.

    • “You” in this case is Jane. ๐Ÿ™‚

      And re-reading it, I think I may have been misunderstanding her, re: this:

      what if you made location an element in the Sidebars themselves (Primary, Test)?

      As I read that now, I’m thinking she’s referring to a “theme_location” parameter in the register_sidebar() array and/or the dynamic_sidebar() array, analogous to the “theme_location” parameter in register_nav_menu()/wp_nav_menu()?

      If so, then yeah: we’re on the same page, and I love the idea. My only question is: why can’t the “id” parameter that already exists be used for this purpose?

      The idea of making “sets” of Widgets, that then get applied to dynamic sidebars is simply brilliant. It pretty much eliminates all of the current problems, and your mock-up demonstrates how it can be used to eliminate most of the current UI/UX issues with the Appearance -> Widgets screen, as well.

      The only bit of information seemingly lost is the Widget description – but surely that can be implemented via tooltip, or something?

  2. Sidenote: I hope incorporating the visual editor into widgets is on the to do list somewhere.

  3. I, too, like where this is going. But.. I feel that if we are to really overhaul this whole widget thing, we need to look at the bigger picture. Not just optimize the Widgets menu, but also think about how can select which widgets to have on which post / page.

    But again, I like where this is going.

    • I imagine that a total overhaul would have to be the goal of an entire release (Jane would know off the top of her head, but I think yesterday she mentioned they did this for 2.8). Widgets per Page is ‘functional’ as a plugin right now. We need one for Menus too, and in both cases, it’s a complex mess.

      My off the cuff thought is ‘Make it a screen option on the post/page/category edit page. “Menus to use:” and “Sidebars to use:” and assume ‘default.” Hide it by default so the newbies don’t get overwhelmed. That’s something I’d really want to see speed metrics on though before really considering. It feels like something that would slow down every page generation since it has to check ‘Which menu?’ and that could clog up the tubes.

    • There are plugins for that, I know. I’ve been building a bunch of really large websites lately that required a lot of variation of widgets per page. Having to change some of the content of a ‘page’ in the editor and some other part of that same page in the widgets section is just not helping me sell the “WordPress is a full blown CMS” as much as I would like to.

      And to be honest, having more than 30 widgets per widget area is a bit clunky as well. Not just for the client ๐Ÿ˜‰

    • I know that Jane mentioned per-page widgets as a priority (maybe in IRC?), but we’ll have to wait until after the core team meet up to see what they decide on as goals.

      I could see things getting really messy on screens as you add these options, though. It puts into perspective why it takes so long to work through solutions for these ideas – seems like UX is often the hardest part to “solve”. Responsive admin could help, though – can’t stop thinking about it!

Comments are closed.

%d bloggers like this: