[wp-trac] [WordPress Trac] #48747: WP_Customize_Setting doesn't clean up after itself
WordPress Trac
noreply at wordpress.org
Fri Nov 22 22:55:34 UTC 2019
#48747: WP_Customize_Setting doesn't clean up after itself
--------------------------+------------------------------
Reporter: jon81 | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Customize | Version: 3.4
Severity: minor | Resolution:
Keywords: needs-patch | Focuses:
--------------------------+------------------------------
Changes (by dlh):
* keywords: dev-feedback has-patch reporter-feedback => needs-patch
Comment:
Replying to [comment:5 jon81]:
> I think what Weston suggested would be the way to go if possible, have
filters added when needed, rather than in the constructor.. that way I
could presumable remove a setting in the `customize_register` hook before
any filters have been added.
True enough. But, it would come with some backwards-compatibility
challenges, I think. For example, the `remove_all_filters()` approach
would no longer work as early in the Customize bootstrap process as it
does now if the setting filters were added later.
How about, at least, describing this gotcha in the docs for the
`remove_*()` methods? I'm thinking it could say exactly what's in the
ticket description: that removing a construct from a manager doesn't
destroy the class instance or "tear down" its filters. Would you be
interested in writing a patch for that, @jon81?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/48747#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list