[wp-trac] [WordPress Trac] #55121: classic widgets with no settings won't show up in 5.9

[WordPress Trac]

#55121: classic widgets with no settings won't show up in 5.9
----------------------------+----------------------
 Reporter:  joncampbell     |       Owner:  (none)
     Type:  defect (bug)    |      Status:  closed
 Priority:  normal          |   Milestone:
Component:  Widgets         |     Version:  5.9
 Severity:  normal          |  Resolution:  invalid
 Keywords:  has-patch php8  |     Focuses:
----------------------------+----------------------
Changes (by jrf):

 * status:  reopened => closed
 * resolution:   => invalid
 * milestone:  5.9.1 =>


Comment:

 @peterwilsoncc While I appreciate what you are saying, it is not
 WordPress' job to be forgiving for **''every single type of developer
 error''**.


 To quote my previous comment:

 > So, I've dived in to try and understand how this error can ever really
 happen in the first place.
 >
 > `$instances` is set via a call to `$this->get_settings()` and that
 method already does a check for `$settings` being an array or instance of
 one of the supported classes.
 >
 > This error then, can ''only ever'' occur if a plugin/theme would
 overload the `Widget::get_settings()` method and doesn't have the same
 safeguards in place, or, as was the case in #33442, people overload the
 `Widget::update()` method but ''do not return the `$new_instance` (or
 `false`)''.
 >
 > In both those cases, IMO, this is very much a case of plugins ''doing it
 wrong'' and not something WordPress should "fix" in the WordPress Core
 code - other than possibly adding a `_doing_it_wrong()` notice, but to be
 fair, that would be overkill, as the `Widget::get_settings()` method
 basically already does the validation and if people overload methods, they
 should at least comply with the expected return type.
 >
 > WordPress should not cater or facilitate unlimitedly to ''plugins doing
 it wrong''. IMO with this now being a fatal error in PHP 8.0, there is now
 a good argument to change it back to `isset()`.


 The search you did on WP Directory shows 20 plugins affected, 1 with 4000
 installs, 1 with 1000, 8 with less than 500 installs and 10 with 0
 installs.

 So realistically there are less than 6000 sites affected and of those,
 most won't be running PHP > 7.4.

 I've checked the first few plugins on wp.org and most have been abandoned
 effectively (no update for > 3 years), so adding a ''doing it wrong'' to
 the WP code still wouldn't have any effect.

 If anything, feel free to report the bug in the support fora of the 10
 plugins with installs, but this is not something which should be accounted
 for in WP.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/55121#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform