Opened 9 years ago
Closed 9 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: | |
Cc: |
Description
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)
Change History (9)
#2
@
9 years ago
The same for BuddyPress trunk.
#4
@
9 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
@
9 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
@
9 years ago
+1 pizza for @boonebgorges for diving into this that deep and +1 for something like default_args()
for all BuddyPress widgets.
WordPress 4.4-beta4-35649, BuddyPress 2.4.0