[wp-trac] [WordPress Trac] #32103: Customizer sanitizes data multiple times when options are served as Serialized Settings

[WordPress Trac]

#32103: Customizer sanitizes data multiple times when options are served as
Serialized Settings
-------------------------------------+-------------------------------------
 Reporter:  Air.                     |       Owner:  westonruter
     Type:  defect (bug)             |      Status:  accepted
 Priority:  normal                   |   Milestone:  4.4
Component:  Customize                |     Version:  3.4
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  administration,
  reporter-feedback                  |  performance
-------------------------------------+-------------------------------------

Comment (by westonruter):

 Replying to [comment:21 wpweaver]:
 > At this point, I suspect that the only solution that will give
 satisfactory performance will be to quit using the standard get_option
 calls and the filters, and build a cache that is refreshed only once.
 Perhaps saving the changed options back to the option DB can be done that
 way, but dynamically replacing the options really should be done once and
 only once.

 This is, in fact, close to the original approach I was taking in
 [attachment:32103.wip.diff], except it was focusing on caching the
 previewed values and updated values. It wasn't focused on the initial
 values, which seems to also be a problem as you've made VERY clear.

 Having 600 settings and controls is indeed very extreme, so you shouldn't
 be surprised that you've encountered a scalability problem, which does
 indeed need to be fixed and it is my goal to fix for this current release
 cycle. However, it will not be fixed until WordPress 4.4 is released and
 so you're going to need to come up with a different solution in the
 meantime since your situation is so DIRE indeed.

 It seems like your best bet in the interim is to register your theme's
 multitude of settings using a custom setting type (not `theme_mod` or
 `option`), or by creating a new subclass of `WP_Customize_Setting`, and to
 then handle their value, preview, and update operations yourself in an
 efficient way (using a cached array) which bypasses entirely the
 performance problems in the `multidimensional` routines.

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