Ticket #4280 (reopened enhancement)

Opened 1 year ago

Last modified 2 weeks ago

Allow to constrain widgets being displayed on certain page types only

Reported by: torbens Assigned to: mufasa
Priority: normal Milestone: 2.6
Component: Administration Version: 2.2
Severity: normal Keywords: needs-patch
Cc:

Description

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.

Attachments

sidebar.gif (25.4 kB) - added by Jairus on 05/17/07 17:50:39.
Screenshot of SBM's display options
widgets-idea.PNG (20.6 kB) - added by Otto42 on 09/21/07 17:49:03.
Widgets UI idea
widgets.png (13.8 kB) - added by Jairus on 09/27/07 17:38:17.
Interface for beta per-page/post implementation
widgets-display.png (16.1 kB) - added by spikeyslam on 02/24/08 20:37:15.
Widget display options (needs tab interface)
display-filter.jpg (30.1 kB) - added by spikeyslam on 03/18/08 20:53:51.
Display Filters, more condense than checkboxes
SidebarModule.tar.2.gz (17.5 kB) - added by mufasa on 03/28/08 03:11:52.
Modified again with fixes.
SidebarModule.tar-1.gz (17.5 kB) - added by mufasa on 03/31/08 02:47:34.
SidebarModule.tar-1.2.gz (17.7 kB) - added by mufasa on 04/09/08 03:07:47.
SidebarModule.tar.gz (17.7 kB) - added by mufasa on 05/01/08 03:41:14.
Files Updated 1 May 2008

Change History

05/17/07 13:53:17 changed by rob1n

  • keywords set to needs-patch.
  • owner changed from anonymous to andy.
  • milestone changed from 2.3 to 2.2.1.

+1.

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

(follow-up: ↓ 3 ) 05/17/07 14:00:48 changed by 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.

(in reply to: ↑ 2 ) 05/17/07 14:08:20 changed by Jairus

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

(follow-up: ↓ 5 ) 05/17/07 15:58:40 changed by 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.

(in reply to: ↑ 4 ; follow-up: ↓ 9 ) 05/17/07 17:46:29 changed by 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.

05/17/07 17:50:39 changed by Jairus

  • attachment sidebar.gif added.

Screenshot of SBM's display options

05/17/07 17:51:26 changed by Jairus

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

05/17/07 18:38:38 changed by foolswisdom

  • milestone changed from 2.2.1 to 2.3.

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

05/17/07 19:34:04 changed by 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".

(in reply to: ↑ 5 ; follow-up: ↓ 10 ) 05/18/07 00:26:24 changed by 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...

(in reply to: ↑ 9 ) 05/18/07 14:10:11 changed by 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.

05/28/07 20:46:20 changed by charismabiz

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

09/05/07 20:03:44 changed by foolswisdom

  • milestone changed from 2.3 to 2.5 (future).

(follow-up: ↓ 14 ) 09/21/07 17:48:50 changed by 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.

09/21/07 17:49:03 changed by Otto42

  • attachment widgets-idea.PNG added.

Widgets UI idea

(in reply to: ↑ 13 ) 09/27/07 17:37:18 changed by 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)

09/27/07 17:38:17 changed by Jairus

  • attachment widgets.png added.

Interface for beta per-page/post implementation

(follow-up: ↓ 16 ) 01/04/08 20:00:00 changed by 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?

(in reply to: ↑ 15 ) 01/18/08 17:18:22 changed by 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.

(follow-up: ↓ 18 ) 02/24/08 20:36:20 changed by 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)

02/24/08 20:37:15 changed by spikeyslam

  • attachment widgets-display.png added.

Widget display options (needs tab interface)

(in reply to: ↑ 17 ) 02/24/08 20:43:00 changed by 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...

03/18/08 20:53:51 changed by spikeyslam

  • attachment display-filter.jpg added.

Display Filters, more condense than checkboxes

03/27/08 03:51:29 changed by mufasa

  • owner changed from andy to mufasa.
  • status changed from new to assigned.

03/27/08 04:02:32 changed by 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.

03/28/08 02:20:18 changed by 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

03/28/08 03:11:52 changed by mufasa

  • attachment SidebarModule.tar.2.gz added.

Modified again with fixes.

03/31/08 02:47:34 changed by mufasa

  • attachment SidebarModule.tar-1.gz added.

04/03/08 16:34:27 changed by 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 ! :-)

04/03/08 16:37:43 changed by 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 :-)

04/04/08 10:30:49 changed by 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

04/04/08 10:33:52 changed by sharebrain

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

04/09/08 01:52:50 changed by 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.

04/09/08 03:07:13 changed by mufasa

  • status changed from assigned to closed.
  • resolution set to fixed.

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)

04/09/08 03:07:47 changed by mufasa

  • attachment SidebarModule.tar-1.2.gz added.

04/09/08 03:22:17 changed by mufasa

  • milestone changed from 2.6 to 2.5.1.

04/09/08 03:24:29 changed by Nazgul

  • status changed from closed to reopened.
  • resolution deleted.
  • milestone changed from 2.5.1 to 2.6.

05/01/08 03:41:14 changed by mufasa

  • attachment SidebarModule.tar.gz added.

Files Updated 1 May 2008

(follow-up: ↓ 31 ) 05/01/08 03:45:21 changed by 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.

(in reply to: ↑ 30 ) 05/05/08 19:03:58 changed by spikeyslam

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