[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 wpweaver):

 Replying to [comment:18 westonruter]:
 > #34132 was marked as a duplicate.

 Sorry to reply again, but I simply must emphasize the absolute seriousness
 of this issue. If you are not aware, the WordPress Theme Review theme has
 REQUIRED that ALL themes use the Customizer. My theme may be somewhat
 unique, but I recently completed a survey of theme still using the old
 Settings API, and there are a lot of them, and many of them have a lot of
 options.

 As they convert to Customizer, this unacceptable SLOW preview issue will
 become more and more of a problem for lots of themes. It simply is not
 acceptable for the preview to EVER, under any circumstances, to take more
 that a few seconds, not matter how many settings are included in the
 interface. 6 or 600, it should be fast and quick.

 This is now a REQUIRED feature for ALL themes, and the themes are at the
 heart of WP in many ways. It may happen that my them pushes the limits on
 the number of options, but I must say that even with 600 options, the
 Customizer makes it possible that the user literally only need to know
 about 20 important things. When in use, the interaction is brilliant. But
 I am having to develop just one small section at a time. I am using
 postMessage for about 95% of the settings, but just the load of the
 Customizer is taking over 20 seconds from a very fast server when I have
 most of the options enabled. And I have quite a few more, so I suspect
 this will never run with the current state of things.

 While PART of the issue MAY have been multiple calls to sanitize, I've
 done some investigation, and I believe the problem is MUCH deeper, and
 involves multiple generated calls to get_option, and the settings must be
 unserialized each time. The whole process is generating thousands and
 thousands of calls to the built-in functions and filters.

 While this might be logically nice, it doesn't work. And since this is a
 require interface now, it is not okay that it works only for some themes
 that don't push it with the number of options. It has to work even for
 over a thousand options.

 At this point, I suspect that the only solution that will give
 satisfactory performance is 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.

 I know machines are fast these days, but designing an exponentially
 increasing access time to handle these options won't work even on fast
 machines.

 I'm a believer now, and if it worked right, the new option interface I've
 build would be totally fantastic. As it is, it is not useable in the
 least. An improvement of 30% isn't enough. It needs a 95% improvement.

 Sorry to rant, but this is serious, and it needs to be moved to the
 highest priority possible given the requirements of the theme review
 theme.

 I will be more than happy to test things, and even provide a current copy
 of my theme that is taking forever to refresh if that would help.

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