Changes between Initial Version and Version 1 of Ticket #32103, comment 21
- Timestamp:
- 10/03/2015 01:43:02 AM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #32103, comment 21
initial v1 2 2 > #34132 was marked as a duplicate. 3 3 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.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 themes still using the old Settings API, and there are a lot of them, and many of them have a lot of options. 5 5 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, no tmatter how many settings are included in the interface. 6 or 600, it should be fast and quick.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, no matter how many settings are included in the interface. 6 or 600, it should be fast and quick. 7 7 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.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 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. 9 9 10 10 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. … … 12 12 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. 13 13 14 At this point, I suspect that the only solution that will give satisfactory performance isto 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.14 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. 15 15 16 16 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. 17 17 18 I'm a believer now, and if it worked right, the new option interface I've buildwould 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.18 I'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. 19 19 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 t heme.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 team. 21 21 22 22 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.