Widgets don't know the widget area context they're in

[ruud@…]

If you have a widget in a widget area (both on the admin side and front-end side) it does not know in which widget area it is in.

Use cases for this would be:

• custom filtering and/or styling on the front-end of a widget based on its location.
• having some editor options turned on/off based on widget-area.

[ruud@…]

Related ticket: #14686

Possible solution: add widget area arguments/data into the widget instance would allow widget developers to use it in their widget code.

[ruud@…]

Patch to add widget area information to widget instance

[anonymized_14009747]

Just checked this; patch adds an array with the arguments including the id of the current sidebar it is in.
Also successfully tested in the theme customizer.

[westonruter]

I think it would be better to add the widget ID to the $args passed into the callback instead of adding it to the $instance which is supposed to reflect the stored database value.

[ruud@…]

Replying to westonruter:

I think it would be better to add the widget ID to the $args passed into the callback instead of adding it to the $instance which is supposed to reflect the stored database value.

Hi Weston, thanks for commenting on this ticket.

I too was contemplating if $instance is the proper place for storing this data. Another choice is to use the widget Object itself ($this). Neither place seemed fitting so I opted for the $instance. The thing being that its current sidebar location does say something about this particular instance..

As far as I know those are the two places you I would look for this sort of data if I want to use it from the widget display view and admin view.

What do you mean with adding the widget ID to the $args?
How does that help the widget determine in which sidebar the widget is currently in?

[ruud@…]

Another thought: how about a widget being able to request its current sidebar via a new function?

[westonruter]

I was confused when I first responded to this, so please disregard my comment about $args.

Replying to ruud@…:

Another thought: how about a widget being able to request its current sidebar via a new function?

You can actually find out which sidebar a widget belongs to by adding the following to a widget's update, form, or widget callbacks (any method of the class extending WP_Widget):

$active_sidebar_id = null;
foreach( wp_get_sidebars_widgets() as $sidebar_id => $widgets_ids ) {
        if ( in_array( $this->id, $widgets_ids ) ) {
                $active_sidebar_id = $sidebar_id;
                break;
        }
}

Beware of using this in the admin, however, since widgets can be dragged around to other widget areas.

[ruud@…]

Hi Weston. Your suggestion is valid indeed.
I know we can leverage the widget callbacks to obtain the widget area information, that's how we currently implemented it for our use case.

However, I think this is perhaps not common knowledge and adding some additional information to the $instance seems rather harmless and opens up possibilities in an easy way for widget developers.

So to get more to the point on this: is it your opinion that because a developer can achieve this via alternative routes it should not go into core? Or is the way (by adding it to the $instance variable) not right?
Don't get this the wrong way, I just want your opinion on this and I personally don't know what should or shouldn't go into core, and on what grounds we can make a decision on this as well.
I mean: should we focus on light weight code, or on ease of use, or on ??

Thanks.

[westonruter]

Replying to ruud@…:

I mean: should we focus on light weight code, or on ease of use, or on ??

Yeah, it's a good question. I think that the logic shared above would make sense as a new method on the WP_Widget class itself. This would make more sense than adding it to the $instance I think. So the widget callbacks could do just do something like $this->get_sidebar_id().

[DrewAPicture]

Replying to westonruter:

Replying to ruud@…:

I mean: should we focus on light weight code, or on ease of use, or on ??

Yeah, it's a good question. I think that the logic shared above would make sense as a new method on the WP_Widget class itself. This would make more sense than adding it to the $instance I think. So the widget callbacks could do just do something like $this->get_sidebar_id().

+1 for the method method

[ruud@…]

I can follow this logic too. Besides a get method, the widget Class should also get a set method right?

I'm thinking a method name something along the lines of:
get_sidebar_context();
set_sidebar_context();
both using an array of information (some array as the $args array from the patch), in that way any known sidebar context information can be stored and retrieved from the widget object.

Furthermore the comments with these functions could(should?) reflect the fact the information may have been altered by dragging the widget from one sidebar into another (in the admin).

I'm not exactly sure how the admin-ajax methods come into play here.

[ruud@…]

How about dropping 'sidebar' in favor of 'widget-area'? What's the general verdict on this?

get_widget_area_context();
set_widget_area_context();

[westonruter]

Replying to ruud@…:

How about dropping 'sidebar' in favor of 'widget-area'? What's the general verdict on this?

get_widget_area_context();
set_widget_area_context();

While “sidebar” has been replaced with “widget area” in the user-facing admin pages, the term “sidebar” is still used exclusively in the WordPress API, so I think it should be used here too.

class WP_Widget {
        /* ... */
        public function get_sidebar_id() {
                foreach ( wp_get_sidebars_widgets() as $sidebar_id => $widgets_ids ) {
                        if ( in_array( $this->id, $widgets_ids ) ) {
                                return $sidebar_id;
                        }
                }
                return null;
        }