Change name of global for wp_customize instance

[mattonomics]

Currently, the WP_Customize instance is assigned to $GLOBALS['customize']. I believe this should be prefixed with "wp_". I know this is a bit picky, but it seems to be more in line with the WordPress naming conventions and I don't believe there will need to be any other changes made aside from one line in wp-includes/theme.php

PS Let's see if I can generate a correct patch this time :)

[scribu]

+1

[CoenJacobs]

+ 1 on this patch. Fully agree.

Shouldn't this be done with all/more $GLOBALS indexes (currently 138 times) in trunk?

[nacin]

I've had this queued up locally, just haven't committed it yet.

Wondering if we should move this to being a static instance inside the WP_Customize class and avoid the unnecessary global. So,

new WP_Customize;

And:

public static $instance;
function __construct() {
     self::$instance = $this;
     .  .  .
}

Simple, effective. Allows for WP_Customize::$instance.

[scribu]

Won't that get weird when you replace WP_Customize with your own instance? (If you can't replace it with your own instance, what's the point of having an instance at all?)

[nacin]

Replying to scribu:

Won't that get weird when you replace WP_Customize with your own instance? (If you can't replace it with your own instance, what's the point of having an instance at all?)

WP_Customize is basically just a namespace. In that situation, $this is convenient, more so over a group of static methods. At the moment, WP_Customize is final. Even if it weren't made final, we could do something to avoid instance overwriting.

Ultimately, getting the instance from WP_Customize just isn't needed in common practice. You'd only need it if you need to unhook something. So it's good to provide a basic interface. But we don't need to go crazy with it. Whatever works, I'm happy with.

[scribu]

Replying to nacin:

WP_Customize is basically just a namespace. In that situation, $this is convenient, more so over a group of static methods.

Why is it more convenient? Because you don't have to declare all the properties you set? Because it's a more familiar syntax?

If it's a poor man's namespace, then use it as such. $this is only useful for dynamic dispatch, when you have a hierarchy of classes.

[nacin]

You can pass $this to an action in a more dynamic fashion, no? Such as customize_register.

[scribu]

Since there can only ever be one instance, you can do it just as well with a static method:

add_action( 'customize_register', array( __CLASS__, 'register_controls' ) );

And to unhook it from a plugin, instead of:

remove_action( 'customize_register', array( WP_Customize::$instance, 'register_controls' ) );

you could do:

remove_action( 'customize_register', array( 'WP_Customize', 'register_controls' ) );

[nacin]

In [20600]:

Initialize the WP_Customize class in a prefixed global. props mattonomics. fixes #20465.