WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 19 months ago

#30387 closed defect (bug) (wontfix)

Theme customizer section vanishes if code is inside is_admin() block

Reported by: Latz Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.1
Component: Customize Keywords: close
Focuses: administration Cc:

Description

Theme customizer: If I surround the add_section() and add_setting() functions with an is_admin() condition, the new section is not displayed. If I remove the is_admin() condition, everything works fine.

WordPress 4.0 didn't show this behaviour.

I've added s screencast and an example plugin to illustrate the problem.

Attachments (2)

ctest.php (612 bytes) - added by Latz 2 years ago.
Example plugin
customizer.mp4 (507.3 KB) - added by Latz 2 years ago.

Download all attachments as: .zip

Change History (8)

@Latz
2 years ago

Example plugin

@Latz
2 years ago

This ticket was mentioned in Slack in #core by latz. View the logs.


2 years ago

#2 @westonruter
2 years ago

  • Keywords close added

I think wrapping the add_section call in is_admin is incorrect anyway. The call merely should be done inside of the customize_register action. Since the Customizer preview executes in a frontend context, any calls wrapped by is_admin aren't going to fire regardless. This means your settings aren't getting registered in the preview either. It doesn't matter for settings though, since they get synced into the preview once the Customizer preview loads anyway. But sections can now be contextual to specific URLs, and for this to work the add_section mustn't be conditional upon is_admin.

#3 follow-up: @Fab1en
2 years ago

I have the same issue because I include the customizer files in my theme only if is_admin :

if(is_admin()) {
    require_once(dirname(__FILE__).'/customizer/title/register.php');
    require_once(dirname(__FILE__).'/customizer/background_gradient/register.php');
    require_once(dirname(__FILE__).'/customizer/post/register.php');
}

If that is a bad practice, it should be mentionned in the Codex.

This was also very hard to debug because controls are added to the customizer panels, but hidden later with JavaScript.

#4 in reply to: ↑ 3 @Latz
2 years ago

As mentioned above it's a new behavior since 4.1. I'm going to add a note as soon as 4.1 is public.

#5 @westonruter
2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I've updated the Codex with the note: http://codex.wordpress.org/Theme_Customization_API#Developing_for_the_Theme_Customizer

It's a best practice already to not wrap Customizer logic in is_admin().

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


19 months ago

Note: See TracTickets for help on using tickets.