[wp-trac] [WordPress Trac] #33440: Deprecated PHP4 style constructor warnings make debugging hard
WordPress Trac
noreply at wordpress.org
Sat Aug 29 00:14:41 UTC 2015
#33440: Deprecated PHP4 style constructor warnings make debugging hard
------------------------------------------------+--------------------------
Reporter: McGuive7 | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting
Component: Widgets | Review
Severity: normal | Version: 4.3
Keywords: has-patch 2nd-opinion dev-feedback | Resolution:
| Focuses:
------------------------------------------------+--------------------------
Comment (by McGuive7):
@jorbin: good question. No way to guarantee that `WP_Widget()` won't be
called statically, but it seems like this same issue would arise for the
vast majority of the WP_Widget class's methods, most of which also include
calls to `$this`. So can you think of a reason why `WP_Widget()` might be
particularly likely to be called statically?
A quick search across all core files for the following strings doesn't
yield any results that would indicate this method is getting called
statically in core:
`::WP_Widget`
`WP_Widget`
That said, I could easily imagine a scenario in which a plugin might call
the method statically for any number of reasons, well-coded or not :)
Not to overcomplicate things, but it'd be easy enough to detect if the
call was made statically, and only proceed when that's not the case with
something like:
`isset( $this ) && get_class($this) == __CLASS__`
(http://stackoverflow.com/questions/1858538/how-do-i-check-in-php-that-im-
in-a-static-context-or-not)
Seems like possible overkill for what may be an unlikely scenario, but
does this seem worth doing to others? Any other considerations I'm
missing?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/33440#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list