0

Currently I prefix all of them:

$wp_customize->add_panel('themename_panel', $args);

$wp_customize->add_section('themename_section', $args);

$wp_customize->add_setting('themename_setting', $args);

But I'm wondering is this necessary?

1

Short answer:

Yes.

WordPress is a system that allows for many parts and custom configuration, WP_Customize_Manager::add_setting() fits perfectly into that.

But you're not the only one trying to customize this specific WordPress instance, so are all the (activated) plugins and themes. To make sure, you don't overwrite another functionality and your own does not get overridden, prefixes are usually the way to go.

The mentioned function is a perfect example, as all it does do is

$this->settings[ $setting->id ] = $setting;

Now when Plugin A does

$wp_customize->add_panel('panel', $argsA);

and theme B has this code

$wp_customize->add_panel('panel', $argsB);

With which arguments is panel created?


Of course using prefixes doesn't really solve this problem. So I personally like to use classes and namespaces when possible, to make the chance of collisions even smaller. However, in this case it does not seem possible.

The convention is that you use a prefix that describes you (company name, nickname, ...) as to reduce the risk of someone choosing the same prefix as you

  • So a plugin can add sections and panels as well as themes do, right? What about settings? or the option theme_mods_themename, I think it is theme specific, can a plugin add its settings to it? – Edward Feb 26 '18 at 11:14
  • Usually any code (plugin, mu-plugin, theme) can do anything, I don't know of any specific restrictions – kero Feb 26 '18 at 11:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.