Allow to constrain widgets being displayed on certain page types only

+1.

This is really the only reason I'm still hardcoding my sidebars.

To clarify a bit, I believe the OP is trying to suggest "page-specific widget layouts for each page".

For example: -page/post A has widgets RSS, Google Search -page/post B has widgets Google search -pace/post C has widgets Blogroll, RSS, Google Search

And each page/post has the drag-droppable widget interface.

+1 - A widget system as described by charismabiz is a great idea.

Actually, I think the original post is suggesting some sort of extra config tab that every widget has, which defines where it appears.

So alongside the normal config button on each widget, another button appears. You click it, and get a "Display On" sort of menu. Then you can choose to not have this widget display on, for example, category archive pages. Or single post pages. Or search result pages. Or Page pages. Or whatever, the ability to choose by type of page is the important bit here, not to have every page have it's own drag/drop stuff. That would be extra confusing, IMO.

The original post is referring to SBM's ability to choose on a per-page and per-post level which widgets you have available. If I have five pages (or posts), I can choose Widgets A B and C for Page 1, B and C for 2, D and F for 3, etc....

I agree it would be a good idea to have a per-category display toggle, but the advantage of SBM is its per-page and per-post granularity.

Screenshot of SBM's display options

I added a screenshot of how SBM's display controls work, to show the level of granularity.

SBM: Wow, that seems like a backwards experience -- maybe works around a technical limitation. It would make more sense to me to consider it at the sidebar level. All views share the same sidebar(s), or change a particular view's sidebar(s).

I agree that the interface is backwards. From a usability point of view if you wanted a page to have a specific set of widgets, you'd choose that on the page itself -- which is what I think charismabiz was describing when he said "each page/post has the drag-droppable widget interface".

Replying to Jairus:

The original post is referring to SBM's ability to choose on a per-page and per-post level which widgets you have available. If I have five pages (or posts), I can choose Widgets A B and C for Page 1, B and C for 2, D and F for 3, etc.... I agree it would be a good idea to have a per-category display toggle, but the advantage of SBM is its per-page and per-post granularity.

This is how I meant it in the first place.

However, I do agree that the SBM UI for this funtionality pretty much isn't nice at all.

One idea would be to allow definition of an arbitrary # of widget profiles for the different sidebars at the Widget config page. Next step would be to assign default profiles to the different types of "pages":

• Homepage
• Archives
• Single Post
• Search Results
• Static Page
• Error Page

This is somehow similar to SBM, only that you do define the assignments on a per-profile-basis and not on a per-widget-basis. To get back the ability assigning specific sidebars to specific pages or posts, one could define additional widget profiles and assign them directly on the editor admin page of the specific post/page.

Not sure if this is what Jairus wanted to say.

Nice thing about this is that the widget configuration for standard users who only want the same sidebar anywhere is still as easy as in v2.2. They'd only have one single (default) widget profile assigned to all pages...

Replying to torbens:

One idea would be to allow definition of an arbitrary # of widget profiles for the different sidebars at the Widget config page. Next step would be to assign default profiles to the different types of "pages": * Homepage * Archives * Single Post * Search Results * Static Page * Error Page

That would work -- the way I was thinking about it was more of a cascade than a set of assignments: You'd have your main widget layout (as you do now). Then, if you wanted, you could set a widget layout specifically for pages (or posts, if you prefer), and all pages would inherit that layout . If you wanted to do category-specific widgets, you could set a layout for a category, and all pages in the category would use that layout. Finally, you could set a layout on the individual page (or post), which would override any higher-level layouts. (I'm assuming that the average WP users is familiar with how cascading properties work.)

Either way would work, really. The only issue I see with a profile/snapshot based set of widget layouts is that I suspect it would be more difficult to work into the page/post editor itself, which means that if you want to change the widgets on a page while you're changing the page, you need to go somewhere else to accomplish it. It makes more sense to me to keep all page-related properties associated directly with the page, rather than assigning widgets or layouts to specific pages (as SBM does).

Honestly, it's the feature itself that I'd like. Whatever form it ends up taking, we'll still have a much more flexible platform than we have now.

The feature could be stored like the current widgets, except in a new table with one row per column.

How about this for a UI idea? (See attached PNG file)

It would pretty much follow the Template Hierarchy. The "Default" would be the home page. When you clicked any of the extra tabs to edit that page, you'd get an exact copy of the default if no custom setting for that type of page already exists, or the custom sidebar for that type of page if it does exist. All the pages other than the default would have a button to "remove customizations" for that sidebar page, in order to fall back to the default or archive or whatever applies.

Seems like the simplest way to do it to me.

Widgets UI idea

So, on the 'Static Pages' page (as an example), would that be the widget layout page for all static pages, or would it let you choose which static page you're laying out -- or both?

I've been working on an implementation of per-post and per-page widgets that I have functional, but there's no functionality for categorys/authors/errors/etc. Right now, you access the layout page from the page/post edit screen itself, and there are inheritance options present. (See attached)

Interface for beta per-page/post implementation

Looks like a lot of people are trying to re-invent the wheel here. Some people may conceptually not like that SBM was widget based, but its usability was not hard at all and granted maximum granularity. You create a page and then pick where you want it to display. A different system would be akin to writing a post and then going to the exact opposite of WP to pick its category. You set visibility where you create/manage the object. Moving to per Page/Post based sounds good but then you get the problem of then having to create a second location to manage per category/type(post,page,error) widgets. Managing those situations from a specific page/post doesn't work conceptually. Yes, it would be great if there was the option on each page/post to pick the widgets for it, but it should be a "second" location to the main widget admin section. Keeping conceptually similar makes the most efficient sense (it also seems logical and not backwards to me). There is no need to re-invent entire new sections of WP to handle this (like the proposed screencaps attached above) People like SBM (hence its addition request to WP) so why go around re-inventing it when it works efficiently?

The problem with having a widget admin section which you choose what pages elements display on (instead of the options being on or linked from the page itself) is that it makes it impossible to store different widget option values for each page/post.

IE: On page 10, I want to display the RSS feed widget, and show ABC News. On page 11, I want to display no RSS feed. On page 12, I want to display the RSS feed widget, and show CBS News.

If you have a layout-based options page where you use a checkbox to select which pages a widget displays on (like SBM), there's no way to have the widget behave differently on different pages.

If you have a page/post-based options page which you choose what widgets are present on that page, you can give each page its own widget properties without any difficulty.

The ability to set display options on specific posts/pages is overkill. I think the basic query states would suffice:

Posts Page (is_home)
Front Page (is_front)
Archives (is_archives)
Single Posts (is_single)
Pages (is_page)
Search Results (is_search)

Widget display options (needs tab interface)

Replying to spikeyslam:

The ability to set display options on specific posts/pages is overkill. I think the basic query states would suffice:

I agree it is overkill for specific posts. However, it is definitely NOT for specific pages.

In fact, it does make a lot of sense since I still use SBM for this purpose. For instance, I want to have different RSS feed widgets related to the context of specific pages...

Display Filters, more condense than checkboxes

We have almost finished this: http://trac.wordpress.org/attachment/ticket/4280/widgets-display.png

We just need to tweak a few more statements and then we're done.

We are not going to make the display filter because I cannot afford to commit any more time to it. Somebody else can do that.

I will attach a modified widgets.php file here that you can swap with the existing widgets.php file.

I have uploaded something that works. It would be great if somebody else could volunteer to enhance / tweak the CSS so that it looked more like the UI design provided by pikeyslam :P

Modified again with fixes.

Hey mufasa .... wow... that is really great! tahnk you so much for that ... now i have implemented that to my wp 2.5. and i get some errors.

Warning: array_keys() [function.array-keys]: The first argument should be an array in /wp-admin/includes/widgets.php on line 251

Warning: Invalid argument supplied for foreach() in /wp-admin/includes/widgets.php on line 252

Warning: Invalid argument supplied for foreach() in /wp-admin/includes/widgets.php on line 255

I just wanted to let you know :-) Thx aagain ! great work .... and i bet this will be helpful ... and i mean really helpful ! :-)

sry its me again ... i have seen that this error just apperas when you first load the page ... when you save the widgets and then do a reload the errors are gone :-)

hey mufasa,

i fixed it roughly: just adding (array) in front of the variables so the function assumes data to be an array and won't drop an error. fixing needed on lines 251 and 255 - file attached.

Starting Line 249

			<?php
				$widget_display_options=get_option('widget_display_option');
				$widget_dipslay_array=array_keys((array) $widget_display_options);
				foreach($widget_dipslay_array as $widget_display) {
					$display_checked[$widget_display]="checked='checked'";
				}
				foreach ((array) $widget_display_options as $widget_display_key=>$widget_display_on) {
					if (!is_array($widget_display_options[$id_format.'-display'])) {
						$all_checked='1';
					}else{

Ending Line 258

sorry - forgot: it's wp-admin/includes/widget.php

Thanks for that. We're making a few more changes now - there were a few things that annoyed me. I want all the posts & pages to be unchecked by default. And I want to add labels so I don't have to click on the checkboxes. And I also want to add an uncheck all + check all links.

This should be done sometime later today.

Then all it needs is somebody to volunteer to make it look pretty - like in the images.

Back soon guys with new working files.

Hi Guys. I think we've nailed it - I modified the look a little too. So we don't need a volunteer now ;)

The only problem now is that the labels don't work in firefox so you have to click the checkbox if you want to select things. If somebody else wants to fix the lables then we would appreciate it.

Its been fun - the latest files are now uploaded.

Ciao,

Dan M (contact via www.instinct.co.nz for more info)

Files Updated 1 May 2008

We just fixed a bug with the "check all" checkbox in the add to post box. It was also checking boxes in other widgets - a big no no.

@mufasa: Can you create patch files? (svn diff)