WordPress Sidebars as Menus: Part 3
Who knew I’d be making a series of posts!? Part the Third is all about ‘per page sidebars.’ Inspiration struck as I was finally able to visualize how I’d want it to look, and it’s stupid simple.
First and foremost, it’s hidden by default in the Screen Options. This is important, since while I totally agree to use decisions, not options, this is something people need options for, but at the same time it is not something everyone will use. The fact that there aren’t more plugins that do it is paramount in that deduction. I know of two, after all, and one requires you to think. A lot. And while thinking isn’t bad, when you’re new, you want things to be straight forward and make sense. As subjective as that can be.
My idea is that by default, you use the default sidebars. Assuming you’ve defined them as I detailed out in my previous post, let’s play pretend…
Assumptions
- I’m using the TwentyEleven theme with the following widget areas: Main Sidebar, Footer Area One, Footer Area Two, Footer Area Three, Showcase
- I’m using a Static Front Page
- I want a special sidebar only on that static front page
- My theme uses a reasonable number of sidebars (i.e. 10 or less)
- I’ve already setup my defined sidebar sets as follows:
- Primary (for use on Main Sidebar)
- Showcase
- Footer left (for use on Footer Area One)
- Footer middle (for use on Footer Area Two)
- Footer right (for use on Footer Area Three)
- Front Page Footer Left (for use on Footer Area One on the static front page only)
What’s that!? Front Page Footer Left? How ever will I define that? Where do I define it? If I only want that sidebar set (Chip, that’s for you) to show up on one page, I could either figure out how to select a page on the Widget/Sidebar editor, or I could do it on the Page Editor. For the purpose of this post, we’re doing it on the page.
Why? Well, it’s a split decision, and without any studies to back it up one way or the other, I suspect that people think ‘You know, I wrote this page, and I want a special sidebar here.’ and not ’I wrote this special sidebar and want it to show up there on that page.’ My use of this/that and here/there were very purposeful. You think about the sidebars you want while you’re on the page they’re intended for. Therefore, you should define the sidebars on that page. The same argument could be made the other way, I’m aware of this. Just go with me for now.
We go to edit the page and first turn on manage sidebars 1:
That gives me a brand new post meta box:
See why I said ‘reasonable number of sidebars’? This could get way out of hand, way fast. You may also note that they all default to … (Default). Well go back to my other idea of having a selection of where to use a sidebar and this makes sense. If you define a sidebar area back there, then that’s the assumed Default sidebar. When you want a specific page to have a totally different sidebar, we should store this information on the page, not in the sidebar/widget like we do today with Widget Logic, etc.
I can use the drop down boxes to show all the available sidebar sets:
Boom. I’m set for this page.
However. This doesn’t solve a big problem: What if I want a special sidebar for specific categories or archives? I’m still doodling on that one, but my first thought is what if certain ‘names’ were reserved. So if I made a sidebar named ‘categories’ it would automagically be used for categories, working on the same concept of the template hierarchy. All things being equal, it defaults to what you picked on the Widgets page.
By the way, these are the original doodles:
Notes:
- You can now see what other options I have going on. ↩
So, as with the rest of the series: I love this!
(Caveat: using the Site Front Page as the example “page” is slightly problematic, given the special-case handling of the Front Page by WordPress. It is probably easier to visualize the concept in terms of a “normal” static Page, or a single blog post.)
The other thing I’d like to throw into the mix is allowing Theme developers to specify which dynamic sidebars are intended to be per-post configurable. It is common practice for a Theme to register dynamic sidebars specific to the blog posts index, or the archive index, or search results page, etc. These dynamic sidebars would not benefit from this per-post functionality, and exposing them to per-post configuration would only introduce unnecessary confusion for the end user.
So, I would propose adding an argument, such as ‘per_post’, to the register_sidebar() argument array, like such:
register_sidebar(array(
// Human-readable name
‘name’=>’Sidebar Column Top’,
// Sidebar ID, passed to dynamic_sidebar() call
‘id’=>’sidebar-column-top’,
// Human-readable description
‘description’ => ‘Top, full-width sidebar in two-column layout’,
// Opening Widget wrapper
‘before_widget’ => ”,
// Closing Widget wrapper
‘after_widget’ => ”,
// Opening Widget title wrapper
‘before_title’ => ”,
// Closing Widget title wrapper
‘after_title’ => ”,
// Sidebar is per-post configurable
‘per_post’ => true
));
If ‘per_post’ is ‘true’, then WordPress will expose the dynamic sidebar in the Post custom meta box; otherwise, it will remain hidden.
Also, standard templates (Archive Index pages, etc.) having analogous custom Widget sets is an entirely different scenario, and my initial thought is that such functionality should probably be left to Plugins, so as not to detract from the effort on implementing Widget sets functionality, improving the Appearance -> Widgets admin page, and implementing per-post sidebars (oh, how I wish “dynamic_sidebar()” had been named something a bit more… inclusive, like “widget_area()”).
Huh. So kind of ‘lock down pre-defined sets that your theme comes with’? I can see why, as a theme dev, you’d want that (and more as a designer for someone’s site). As the end user, I think I’d ask for my money back. I’m personally opposed to anything that removes my ability to make the ‘decisions’ that are default (i.e. what widgets go where). Which is part of why I detest that CPTs are per-theme right now
I want to bring ‘em with me to the next theme and diddle there!
I think you’re looking at this a bit… askew. My point isn’t to limit what end users can do, but rather to ensure meaningful end-user decisions.
If a Theme only has one dynamic sidebar, and that dynamic sidebar is called in all template files, then it would make sense for that dynamic sidebar to be per-post configurable.
However, if a Theme registers separate dynamic sidebars for separate template files, then for the dynamic sidebars that aren’t output on single posts (or static pages), it doesn’t make any sense to display those dynamic sidebars in the per-post configuration.
All I’m talking about is providing a way for the Theme to communicate to WordPress which dynamic sidebars are per-post configurable (because they are output on single posts/static pages), and which ones aren’t (because they’re not output on single posts/static pages).
It has nothing to do with “locking down” dynamic sidebars (I can’t fathom why a Theme developer would even want to do that, considering the inherent purpose of dynamic sidebars in the first place). But even if that were the end result, changing the behavior is only a Child Theme away.
By the way, CPTs don’t have to be per-Theme. They can be registered via Plugin. The Theme just needs to know about them, so that it can use them somehow. This is actually an ongoing discussion among the Theme Reviewers. I view CPTs in the Theme to be a potential form of Theme lock-in; unfortunately, we don’t have a lot of great alternatives.
I’ve not yet seen a theme that uses sidebars the way you’re describing though I can envision it….
Part of the reason I’m avoiding talking about the actual code in these posts is that it’s not there yet
I like to bake an idea so it’s visual. As we know from the whole meta box/widget debacle the names of ‘things’ are complicated and confusing 
Okay, so in my example above, there actually isn’t a ‘main sidebar’ in a single post, so you’re saying we should make sure WP knows ‘Hey, no main sidebar here.’
Furthermore, if Theme Bobby sets up a sidebar specifically for pages, but not posts, then WP should again know “Don’t let people pick values for sidebar ‘page side’ on posts.”
God, that just gave me a headache…. I think … if I was a theme that did that, I’d want an override to toss in my functions to disable the per-post/page/etc customization of sidebars then… Just remove the post-meta-box entirely and let my theme do the work.
Looks great Mika, well done! I’m interested in seeing what you come up with, let’s call it “overriding sidebars” in category archives, tag archives, custom taxonomy archives, author archives, date archives and search results. Good luck and keep the good stuff coming!
Extending my ‘category’ concept, I suppose the next step would be ‘tag-‘ for the sidebar set name, and then that gets called.
Or if WordPress really wanted to get in on this, have it be an option on the Categories page. When you set up a category, you can decide what sidebars to use.
I’m not sure I like the idea of mixingTheme-specific options with non-Theme-specific data, such as what (I think?) you’re suggesting for configuring category archive index page sidebars on the edit-category screen. Then again, custom post meta – especially in this case – is Theme-specific.
But even then: how will WordPress know which dynamic sidebars to override, and which ones appear on category archive index pages? That’s really the biggest issue I see.
Again, we could use a register_sidebar() array key, but building on ‘per_post’ would get unwieldy. Perhaps we need something like ‘context’, where the values could be an array, including any/all of “single”, “page”, “singular”, “archive”, “category”, etc., with the default value being “all” (or whatever).
And now I get it!
Yeah, that makes sense. “This sidebar can be used on: posts, pages, cpts, all…” and the default is to be used on ‘All’.
Your method and screen shots pretty much match what the Genesis Simple Sidebars plugin already does
For those (like me) who have never used Gensis – http://www.studiopress.com/plugins/simple-sidebars
That’s a great solution for the categories. Stash that box on the cat edit page. The only thing it’s missing is archives.
The code in that plugin could obviously be expanded to cover any missing areas (date and author archives), and generalised to look for all registered sidebars (i.e. not be Genesis-specific).
I guess my point is, that you’ve worked hard and come up with what appears to be a pretty similar solution to a general problem that some of us have been using with a framework for a while now – the code is out there…
Oh, you didn’t hurt my feelings. I think it’s cool someone else did the code already. I mean, I may be able to find a metric ton on the net to hep people, but I’d talked around on Twitter and no one mentioned this, so I just ran with the ball.
I’m very happy Genesis did this. I like those guys at StudioPress. Oh Rennnnniiiiiiiicks.
I totally love this! Thanks!