WordPress.org

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #32103, comment 21


Ignore:
Timestamp:
10/03/2015 01:43:02 AM (5 years ago)
Author:
wpweaver
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #32103, comment 21

    initial v1  
    22> #34132 was marked as a duplicate.
    33
    4 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.
     4Sorry 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 themes still using the old Settings API, and there are a lot of them, and many of them have a lot of options.
    55
    6 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.
     6As 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, no matter how many settings are included in the interface. 6 or 600, it should be fast and quick.
    77
    8 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.
     8This 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 theme 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 tp easily access all of them. 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 initial load of the Customizer preview is taking over 20 seconds from a very fast server when I have most of the options included. And I have quite a few more, so I suspect this will never run with the current state of things.
    99
    1010While 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.
     
    1212While 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.
    1313
    14 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.
     14At 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.
    1515
    1616I know machines are fast these days, but designing an exponentially increasing access time to handle these options won't work even on fast machines.
    1717
    18 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.
     18I'm a Customizer believer now, and if it worked right, the new option interface I've built 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.
    1919
    20 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.
     20Sorry to rant, but this is serious, and it needs to be moved to the highest priority possible given the requirements of the theme review team.
    2121
    2222I 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.