[wp-trac] [WordPress Trac] #32103: Multidimensional Customizer settings (options & theme mods) are not scalable

WordPress Trac noreply at wordpress.org
Mon Oct 5 18:38:23 UTC 2015


#32103: Multidimensional Customizer settings (options & theme mods) are not
scalable
-------------------------------------------------+-------------------------
 Reporter:  Air.                                 |       Owner:
     Type:  defect (bug)                         |  westonruter
 Priority:  normal                               |      Status:  accepted
Component:  Customize                            |   Milestone:  4.4
 Severity:  normal                               |     Version:  3.4
 Keywords:  needs-testing needs-unit-tests has-  |  Resolution:
  patch                                          |     Focuses:
                                                 |  performance
-------------------------------------------------+-------------------------

Comment (by westonruter):

 Replying to [comment:32 Air.]:
 > As I said in this bug report I have checked that in other places in
 Wordpress you use more unique IDs for filters like
 > {{{
 > add_filter( 'option_nice_theme_settings[setting3]', 'function' );
 > }}}
 > , but not in this case. BY unique I mean adding part '''[setting3]'''
 >
 > I still didn't see any answer why couldn't we switch to same more unique
 IDs here also?
 > Wouldn't this solve most part of issue?

 No, unfortunately. Assume there is a `sidebar` option that contains
 `width` and `height` keys. You then register a multidimensional setting
 `sidebar[width]` for that option, and a corresponding `number` control.
 Inside the theme, the way that you access the sidebar width is via:

 {{{
 $sidebar = get_option( 'sidebar' );
 $width = $sidebar['width'];
 }}}

 You can see here that the filters only apply at the root level. There is
 no facility to make a call like `get_option('sidebar[width]')`, and so
 there's no filter like `option_sidebar[width]` to apply.

 So we have to filter the settings at the root level, which currently in
 Core causes a problem because there are many filters added for the root
 value as you identified. So the approach that [attachment:32103.wip2.diff]
 takes is it only adds one filter for the root value, and then caches the
 root value and any previewed modifications.

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


More information about the wp-trac mailing list