Skip to:

Opened 5 years ago

Closed 5 years ago

#6747 closed defect (bug) (fixed)

Notice: Undefined index: max_groups

Reported by: slaFFik Owned by: boonebgorges
Milestone: 2.5 Priority: normal
Severity: normal Version:
Component: Groups Keywords:


While adding a Groups widget via customizer using 2015 theme got this notice:

Notice: Undefined index: max_groups in ...\wp-content\plugins\buddypress\bp-groups\bp-groups-widgets.php on line 92

Attachments (1)

6747.patch (505 bytes) - added by slaFFik 5 years ago.

Download all attachments as: .zip

Change History (9)

#1 @slaFFik
5 years ago

WordPress 4.4-beta4-35649, BuddyPress 2.4.0

#2 @slaFFik
5 years ago

The same for BuddyPress trunk.

5 years ago

#3 @slaFFik
5 years ago

  • Keywords has-patch added

#4 @DJPaul
5 years ago

  • Milestone changed from Awaiting Review to 2.5

Thanks for the patch. We'll review it soon (we need to find out why this isn't set when coming from the Customizer in case we need to fix something else).

#5 @boonebgorges
5 years ago

I've done some research here (my first time figuring out how the Customizer works with widgets). It looks like the "problem" is this. When adding a widget via widgets.php, an AJAX request is performed that involves serializing the widget control form ($widget->form()) as part of the POST payload, and then running it through $widget->update() on the server. So WP_Widget classes can safely assume that, by the time widget() is first run (ie, the markup is generated), the form() elements will have been processed at least once. This is a de facto technique for enforcing a widget's "default options".

When adding widgets via the Customizer, the form -> update() routine is not run. (It *does* run when saving widget options in the Customizer, after the widget has been added.) It seems to me that this is a bug, or at least a shortcoming, of the Customizer's Widgets implementation, which is in part due to some serious shortcomings of the WP Widgets API. I've brought it up with the Customizer team to get their thoughts.

In the meantime, I think we (and all WP plugin authors!) need to be aware that the method responsible for generating widget markup, widget(), must be self-sufficient. That is, it should be able to be called without expecting anything to be in the database. Something 6747.patch is a cheap way of doing it. We might also consider sweeping through our widget classes and defining some defaults in a more standardized way - maybe in a default_args() method - which can be used both in form() and in widget().

#6 @slaFFik
5 years ago

+1 pizza for @boonebgorges for diving into this that deep and +1 for something like default_args() for all BuddyPress widgets.

#7 @boonebgorges
5 years ago

  • Keywords has-patch removed

See #6754 for the larger project. For the time being, let's get rid of the notice.

#8 @boonebgorges
5 years ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from new to closed

In 10384:

Make sure that max_groups is always defined in group widget.

This prevents a notice from being shown when the widget is added in the

Props slaFFik.
See #6754.
Fixes #6747.

Note: See TracTickets for help on using tickets.