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

 I'm not trying to be sarcastic. I will admit that it is difficult to
 understand all the consequences of trying to implement a custom type. I
 will look at your example, but I have no confidence that I will be able to
 make this work.

 But I still do not get any impression that you understand my diagnosis if
 the real issue here, or that you intend to fix it for 4.4.

 This is NOT all about me. It is about potentially hundreds of other themes
 using more than 50 or so options. The current implementation means that
 there are N*N operations going on when only N are needed. You can see it
 now in existing themes where the preview refresh takes several seconds
 when it need only take 1 or 2 seconds. Multiply this by tens of thousands
 of people using these themes and plugins, and we area talking about days
 and days of real people's wasted time waiting for the preview to refresh.

 I feel a moral obligation as a professional computer scientist to see that
 this problem is fixed and done right. I don't know all the other details
 of how all the rest of the code works, nor what other issues need be
 solved.

 I know everyone is a volunteer. I appreciate that. My themes, Weaver II
 and Weaver Xtreme, were recently rated as the #12 and #21 most used themes
 on all WordPress sites hosted by GoDaddy. I have a lot of users. I WANT to
 use the customizer. I apparently will not be able to do this until 4.4
 because I can't continue development in a way that allows others to test
 it.

 And I the only feed back I've gotten is that 600 options are too many, and
 what else could I expect other than problems, and that I'm being
 sarcastic. Bitter, perhaps, but not sarcastic.

 So, this is a serious issue. I have discovered the real problem, and hope
 that you understand the seriousness of what it means. I don't know your
 programming background, but every indication I get is that who ever (and I
 don't assume it is you, but it could be) developed the method of forcing
 every option to be run through N filters on the get_option filter
 resulting in N*N calls ever understood what was really happening, and
 never gave performance a second thought.

 And I really must say that the early responses to the slowness issue in
 this ticket really fail to provide any real solutions. They seem to be a
 bit of "Oh, let's try this or that" without really getting at the heart of
 the matter, which turns out to be the multiple instances of filters. All
 the rest is merely noise.


 I apologize if I'm pissing you off, but this is not a personal matter, nor
 am I trying to attack you personally. I'm just trying to attack the real
 problem, and get it solved for me and hundreds of other users of the
 customizer. I don't want to see 4.4 come out, and still see the N*N issue
 and the speed problem unsolved.

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