[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