Allow to constrain widgets being displayed on certain page types only

[torbens]

The only real added value of the Sidebar Modules (SBM) plugin right now is the possibility to customize, which widgets are to be displayed on which pages (setting at Sidebar Modules/<Module>/Module's Options/Display On).

With this you are able to highly customize your sidebars even down to a single post's page.
It might also make sense to define sidebars per category a post is in.

However, it makes the most sense to have different sidebars on the Homepage, different static pages and posts pages.

[rob1n]

+1.

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

[charismabiz]

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.

[Jairus]

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

[Otto42]

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.

[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.

[Jairus]

Screenshot of SBM's display options

[Jairus]

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

[foolswisdom]

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).

[Jairus]

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".

[torbens]

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...

[Jairus]

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.

[charismabiz]

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

[Otto42]

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.

[Otto42]

Widgets UI idea

[Jairus]

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)

[Jairus]

Interface for beta per-page/post implementation

[silver25u]

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?

[Jairus]

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.

[spikeyslam]

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)

[spikeyslam]

Widget display options (needs tab interface)

[torbens]

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...

[spikeyslam]

Display Filters, more condense than checkboxes

[mufasa]

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.

[mufasa]

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

[mufasa]

Modified again with fixes.

[sharebrain]

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 ! :-)

[sharebrain]

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 :-)

[sharebrain]

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

[sharebrain]

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

[mufasa]

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.

[mufasa]

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)

[mufasa]

Files Updated 1 May 2008

[mufasa]

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.

[spikeyslam]

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

[DD32]

Patch based on attached files;

[DD32]

attachment 4280.diff added.
Patch based on attached files;

• Patch attached based losely on the attached archive
• Changes some short tags <?= to full PHP
• added array typecasting to a check which was creating notices on the dashboard (get_option() was probably returning false.. So adding them is just a stop-measure, It didnt fix the root cause)

[DD32]

Oh, Also, A few strtolower()'s came out in that patch, I'm not sure if they should've been kept or not, Commonly happens when the other files are out of date(stale).

Patches/Diffs solve those problems, For more info on patches see this: ​http://codex.wordpress.org/Submitting_Bugs => "Patching Bugs" or this article on how to create Patches: ​http://asymptomatic.net/2005/12/03/586/how-to-patch-wordpress

[ryan]

The UI is still insane. If we wanted checkboxes we would have done this at the launch of widgets. The sidebars for each page type need to be separate. Someone needs to do the hard work of coming up with a good UI.

[DD32]

The UI is still insane.

That was my initial thought too when i saw the UI, Could become very convulated with a large ammount of posts for example, The functionality would be nice, But it really needs a nice UI for it, I cant personally see many other options than checkbox's, But i'm sure there's got to be a better way :)

[nonletter]

Replying to DD32:

The UI is still insane.

hey ryan
here's my
​proposal for interface that uses actual widget implementation

[nonletter]

Replying to ryan:

... If we wanted checkboxes

yes... no checkboxes in ​this version

[nonletter]

all i na page - no checkboxes widget manager

[Jairus]

nonletter, I'm not sure that UI would scale well to large (1000+) numbers of pages.

[DD32]

A new theme i'm designing will work best with blog related widgets only showing on the blog pages, and certain other widgets on pages & the homepage, The way i've achieved it for myself is to register multiple sidebars;

for example: "Left Post Sidebar" & "Left Homepage Sidebar".

in theme's function.php:
add_action('init', 'theme_sidebars');
function theme_sidebars() {
	register_sidebar(array(
					'name' => 'Left Posts sidebar',
					'id' => 'left-posts-sidebar'
					));
	register_sidebar(array(
					'name' => 'Left Home sidebar',
					'id' => 'left-home-sidebar'
					));
}
in sidebar.php:
		$sidebar = is_home() ?
					'left-posts-sidebar' :
					'left-home-sidebar';
		dynamic_sidebar($sidebar);

Thats all good, Except I now have the problem of certain widgets being tied to only being on one sidebar(ie. Meta & search).

So, In order to achieve that, I added this to my themes functions.php:

add_filter('option_sidebars_widgets',  'theme_filter_active_widgets');
function theme_filter_active_widgets($value){
	global $sidebar, $theme_widget_backup;
	if ( ! empty($sidebar) && is_admin() ) {
		foreach ( (array)$value as $key => $bar ) {
			if ( $key != $sidebar ) {
				$theme_widget_backup[ $key ] = $bar;
				$value[$key] = array();
			}
		}
	}
	return $value;
}

add_filter('pre_update_option_sidebars_widgets',  'theme_filter_active_widgets_update');
function theme_filter_active_widgets_update($newvalue){
	global $theme_widget_backup;
	if( ! empty($theme_widget_backup) )
		foreach( (array)$theme_widget_backup as $key => $value )
			$newvalue[$key] = array_merge( (array)$newvalue[$key], $value);

	return $newvalue;
}

In short, It hides whats on the other sidebars from the widgets admin, Allowing me to add widgets to multiple sidebars without any trouble, I could've rewritten the widgets from scratch, but that seemed a waste of time. (Note: The update filter is from a patch i just submited: #7233)

Its not the best solution, But it sure beats having checkbox's on every widget :)

So for the UI, What i thought of was each sidebar having another drop down below it, Selecting the "View" that the widgets will belong to, eg, "Posts", "Post", "Homepage", etc..

[mufasa]

Replying to ryan:

The UI is still insane. If we wanted checkboxes we would have done this at the launch of widgets. The sidebars for each page type need to be separate. Someone needs to do the hard work of coming up with a good UI.

I use widgets all the time. While I have been editing my widgets to display on certain pages I keep getting little visions of what I really want and what would be better and I have come to the conclusion that maybe we are all looking at this the wrong way.

I think that my brain is trying to tell me that we need to be able to select what widgets to add to a page when adding that page. As opposed to assigning widgets to pages from the widgets page - which now seems to me as counter intuitive.

Using checkboxes to display what widgets are available in a post or page seems to make more sense. It is far more managable than trying to display thousands of pages in a list from the widgets page.

If you had more than one sidebar there could be a drop down just like DD32 suggests.

[mufasa]

New fix to make work with WordPress 2.6

[jairus]

Replying to mufasa:

I think that my brain is trying to tell me that we need to be able to select what widgets to add to a page when adding that page. As opposed to assigning widgets to pages from the widgets page - which now seems to me as counter intuitive.

I agree with this. In the implementation of per-page widgets we have (that I posted screenshots of, some time abo), each page has a 'click here to edit the widgets' which brings you to a widget drag/drop page specific to the page you were just creating/editing. (I'll post code soon, after a bit of cleanup.)

As we're saving per-page widget layout/settings, checkboxes don't work very well, which is why we have the full widget interface per-page.

[mufasa]

Replying to jairus:

Replying to mufasa:

I think that my brain is trying to tell me that we need to be able to select what widgets to add to a page when adding that page. As opposed to assigning widgets to pages from the widgets page - which now seems to me as counter intuitive.

I agree with this. In the implementation of per-page widgets we have (that I posted screenshots of, some time abo), each page has a 'click here to edit the widgets' which brings you to a widget drag/drop page specific to the page you were just creating/editing. (I'll post code soon, after a bit of cleanup.)

As we're saving per-page widget layout/settings, checkboxes don't work very well, which is why we have the full widget interface per-page.

I like it - and unlike before now I understand your image. My only thought would be that these options should not take the user to a new page. I think it would make more sense if it were to open in a thickbox window. I'm trying to minimize page loads here - and time.

I would propose a TinyMC icon to open this? Unless somebody has a better idea...

If you email me the code or upload it I can do the thickbox stuff?

[nonletter]

Replying to mufasa:

I'm trying to minimize page loads here - and time.
I would propose a TinyMC icon to open this? Unless somebody has a better idea...
If you email me the code or upload it I can do the thickbox stuff?

disagree. TinyMC is mostly contextual to post and pages content. Custom widgets are sidebar's stuff. Can we also imagine a list in this popup where we can duplicate the sidebar layout to more pages/posts? Global actions are mandatory to save user's time.

[mufasa]

Replying to nonletter:

Replying to mufasa:

I'm trying to minimize page loads here - and time.
I would propose a TinyMC icon to open this? Unless somebody has a better idea...
If you email me the code or upload it I can do the thickbox stuff?

disagree. TinyMC is mostly contextual to post and pages content. Custom widgets are sidebar's stuff. Can we also imagine a list in this popup where we can duplicate the sidebar layout to more pages/posts? Global actions are mandatory to save user's time.

I agree re the Global Actions. For instance I would like to be able to add the same widgets to all the subpages of the parent page - this would save me plenty of time.

The thing is I don't have the time to do this until somebody else uploads the interface design.

[janeforshort]

Postponing until 2.8 due to timing of design delivery.

[strider72]

GUI suggestion:

You can create Widget "Sets" that you can name. On the widgets page you can set which Widget Set shows on the main blog page or on individual posts.

On particular pages, you can assign a Widget Set (similar to setting a Page Template).

How to handle scaling? Well, if you make a Widget Set named "Page-xx", where xx is a number, then that Set is by default the Set that shows up for Page with ID of xx, and it does NOT show up on the drop-down list on Edit Page where you select a set, *unless* you are on page xx.

That is, if I make a Widget Set named "Page-4", then when editing the Page with ID of 4 it's set to that Widget Set (though I can pick a different named set if I like). When editing Page with ID 3, the named sets show up in a drop down; but I do NOT see the "Page-4" set on that drop-down, because that only shows up for Page 4. Sets with any other naming show up on the drop-down for all pages and can be selected for any page.

Thus, specific pages can have a set made just for that one page, but those one-off sets don't clutter up the GUI for all the other pages. If you have a set that you want to use on multiple pages, you make a regular named set and can assign that via drop-down to as many pages as you like.

[murky]

This can be done *right now* by assigning a different sidebar ID on each page.

The trouble with this is that some widgets cannot be re-used on different pages. This seems quite arbitrary.

The other issue is that when changing themes, widgets can 'get lost' - so it'd be nice to be able to tie a widget setup to a theme choice, and then clear all widgets on a new theme, of copy widgets from one theme to another (rather than assume that the current widget choice is good for all themes - as if I move from a theme with one sidebar to one with multiple widgetable locations the current system is a real pain).

[jairus]

We've completed coding on our per-page-widget implementation, we're just doing some final testing now, and we should be able to put the code up within a week. We hit a massive issue with some 3rd party plugins, and had to re-write most of it from scratch to make it future-proof.

From a functional point of view, the way it works is almost the same and pretty straightforward. Every page and every post has a "click here to edit this page's widgets" box on the edit screen, which brings you to a drag-and-drop widget-editing page. (I agree that a thickbox would be better here.)

All of your widget settings -- including your individual widget options -- are saved and presented for that page/post only. That way if you have a widget (like a Flickr box) that you want to present different content on different pages, it works. There's an inherit from parent option too, so groups of content can all have the same widgets.

(We briefly tried the 'sets' idea last month but it really confused our testers, so we went back to the per-page idea.)

This has been written as a plugin, but we would love to see any part of it end up as core functionality. Is there a will to have anything like this end up in wordpress proper?

[draca]

Replying to jairus:

We've completed coding on our per-page-widget implementation, we're just doing some final testing now, and we should be able to put the code up within a week. We hit a massive issue with some 3rd party plugins, and had to re-write most of it from scratch to make it future-proof.
...

Is this change also addressing the ability to use a widget in multiple sidebars? A theme I'm working has a few sidebars and I'd like to be able to re-use arbitrary widgets on multiple sidebars. The per-page approach is feeling more challenging to maintain when pages are not all in a clean hierarchy where properties can be inherited from a parent. As I'm understanding it, this strategy is imposing an organizational hierarchy that might not be desired by the site.

With respect to allowing widgets to appear in sets, isn't this essentially what sidebars provides but maybe not to the same level of user customization sans coding? Except widgets can't be put into multiple sidebars unless they are coded to allow it.

There seem to be two use cases: one widget instance with multiple references and multiple instances of a widget (each with one or more references).

Is the widget code begin generalized such that widgets can be treated more like an object and references to a widget can either be new or existing instances? (What if I wanted the same arbitrary text widget on a collection of pages?)

This has been written as a plugin, but we would love to see any part of it end up as core functionality. Is there a will to have anything like this end up in wordpress proper?

I'd certainly like to see the ability to have widgets treated as re-usable objects make it into the base. I expect it would reduce defects in widgets to move this type of support into the base and out of the custom widget implementation. It would also eliminate the need for tickets like #4588.

[Denis-de-Bernardy]

shouldn't we close this one as invalid? there are several plugins that do this already.

[Denis-de-Bernardy]

patch is hopelessly out of date, and the ticket has been ignored for over 2 years. suggesting wontfix or invalid.

[nonletter]

Replying to Denis-de-Bernardy:

patch is hopelessly out of date, and the ticket has been ignored for over 2 years. suggesting wontfix or invalid.

Agree (sadly). Also the K2 sbm plugin has been abandoned.

[ryan]

This will eventually happen in core, but it's still a release or two away.

[voldemortensen]

Reopening this for consideration

[phpbits]

Hi Everyone,

How about using this plugin I've created? ​https://wordpress.org/plugins/widget-options/ . I hope the UI looks perfect for everyone. Thanks!

Cheers,
phpbits

[audrasjb]

Hi,
Closing as wontfix again because it's plugin territory