[wp-trac] [WordPress Trac] #56431: Fatal Error on Update Page When a Plugin's Icon is Not Set

WordPress Trac noreply at wordpress.org
Tue Aug 8 13:35:34 UTC 2023


#56431: Fatal Error on Update Page When a Plugin's Icon is Not Set
-------------------------------------------------+-------------------------
 Reporter:  scott.deluzio                        |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Upgrade/Install                      |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  needs-patch needs-testing dev-       |     Focuses:
  feedback reporter-feedback                     |
-------------------------------------------------+-------------------------

Comment (by hellofromTonya):

 In re-reading the description:
 >if there is a plugin whose icon is not set, a fatal error is generated,
 and no plugins are listed in the update section.
 >
 >PHP Fatal error: Uncaught Error: Cannot use object of type stdClass as
 array in /wp-admin/update-core.php:509

 How does a "plugin whose icon is not set" become an object, rather than an
 empty / not set value?

 Replying to [comment:9 costdev]:
 > Hey @hellofromTonya! The issue is the `icons` property. If an extender
 messes up and uses an object, this will cause a fatal.

 * Is it a matter of a developer setting the `icons` property to an object
 (i.e. instance of `stdClass()`?
 * Or is something to do with what happens when its "icon is not set" that
 it gets set to a `stdClass()`.

 The difference matters as the first question is the developer doing it
 wrong but the second question may be an issue in Core itself.

 >Normally we'd tell extenders to do it right and we'd move on. However, if
 I installed Plugin A 1.0.0 and version 2.0.0 mistakenly uses an object for
 its icons, then without that version even being installed, it can cause a
 fatal on WordPress sites.

 Hmm, I see. Recovery from such a state requires help from the host or a
 developer. If a guard is added to avoid the fatal error and the inability
 to recover through the updates or plugins screen, then I think this needs
 thought around:

 * Should the update fail?
 * How should the user and developer be alerted to the "doing it wrong"
 issue? Feedback is still needed to inform of the problem.

 Before implementing a change, I think an understanding of how `icons`
 property can be an instance of `stdClass` is needed.

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


More information about the wp-trac mailing list