0

I've added several customisation options to my theme, and I'm (trying to) use the active_callback argument with $wp_customiser->add_section().

In the first instance, this appears to be working just fine. The active callbacks that I am using are is_search, is_archive and is_single, so I'd expect for those sections to be hidden when I initially enter the customiser.

However, when I actually view any of those templates relevant section does not appear.

Below is an example of my code, what am I missing?

$wp_customise->add_section('section_template_single' , array(
    'title'             => __('Single Links', $this->text_domain),
    'priority'          => 10,
    'panel'             => 'panel_templates',
    'active_callback'   => 'is_single'
));

Update

I have no plugins active on the site, and console (both Firebug and Chrome Developer Tools) reports no JS errors.

I was running version 4.4-rc1 but now I'm on the full blown release of 4.4.

Based on comments pointing me to this post, I have updted my code but the problem persists.

Updated instance of $wp_customise->add_section() -

$wp_customise->add_section('section_template_single' , array(
    'title'             => __('Single Links', $this->text_domain),
    'priority'          => 10,
    'panel'             => 'panel_templates',
    'active_callback'   => array(&$this, '_check_is_single')
));

Active callback function -

public function _check_is_single(){
    return is_single();
}

By outputting the result of the active callback, it appears as though the customiser is only actually referencing it on page load, and not on every subsequent page load within the <iframe> displaying the site preview.

2 Answers 2

2

The is_single template tag takes an optional parameter and therefore does not work for an active callback. Try this instead:

function callback_single() { return is_single(); }

$wp_customize->add_section('section_template_single' , array(
    'title'             => __('Single Links', $this->text_domain),
    'priority'          => 10,
    'panel'             => 'panel_templates',
    'active_callback'   => 'callback_single'
));

You also have "wp_customise" instead of "wp_customize."

Source: http://ottopress.com/2015/whats-new-with-the-customizer/

4
  • Thanks, but that still doesn't work. And I use $wp_customise because I'm English, and that's how we spell customise - personal preference.
    – David Gard
    Dec 8, 2015 at 14:59
  • In fact, it appears as though the customesier only checks the active callback on initial load, and that when navigating through the site in the customiser it is not checked again.
    – David Gard
    Dec 8, 2015 at 15:07
  • You might have a compatibility issue with a plugin or theme. I tested in my local environment and it worked as expected with twentyfifteen. I'd try deactivating plugins to rule them out and also check for console errors. To me it sounds like a JavaScript issue since it works sometimes but not all the time. Here's a paste of my code if it helps. Dec 8, 2015 at 19:16
  • No plugins are active and no JS errors are reported. I've updated my question to reflect this.
    – David Gard
    Dec 9, 2015 at 10:36
0

After much hair pulling, swearing my mum would be shocked with, and some totally acceptable man-crying I finally found what the issue here was.

As mentioned in my updated question, no JS errors were reported by either Firefox (Firebug) or Chrome (Developer Tools), but the issue was to be found within a custom JS script.

In short, I have a navigation menu that is hidden whenever the user clicks anywhere away from the menu. In the first instance I was using 2x event handlers to ensure that the page reacted in the way I desire -

  1. Detect a click anywhere within the document and hide the menu
  2. Detect a click within the navigation menu and stop propagation of the event, thus ensuring that the click event handler described above is not triggered.

So the issue was this -

this.navigation.on('click', function(e){
   e.stopPropagation(); 
});

Once I'd discovered the problem I set about finding an alternative method, which shockingly lead me to this Stack Overflow question that recommends users seeking similar functionality implement this exact solution. Simple, yes, but as described in the most accepted answer there most certainly are unintended consequences to using that one little line of code.

So, following the link in the most accepted answer, I've now updated my code (below if anyone is interested) and thankfully the customiser is now working as expected.

/**
 * Handle clicks away from the navigation menu
 * Ignore clicks within the navigation menu, unless it's within the 'Search' box
 */         
$(document).on('click', function(e) {

    if(!$(e.target).closest(t.navigation).length    // The click is anywhere outside of the navigation container...
        || $(e.target).closest(t.search).length){   // ...or within the search container nested within the navigation container...

        if(t.navigation.hasClass('open')){
            t.navigation.removeClass('open');   // Remove the 'open' class from the navigation element
            t.menuButton.toggleClass('active'); // Toggle he 'active' class on the menu button element
            t.subMenu.css('height', '0');       // Set the height of the sub-menu to 0
        }

    }

});

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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