Make WordPress Core

Opened 15 years ago

Closed 15 years ago

#9152 closed defect (bug) (fixed)

Custom header from theme A used when previewing theme B

Reported by: viper007bond's profile Viper007Bond Owned by: westi's profile westi
Milestone: 2.8 Priority: normal
Severity: normal Version: 2.7
Component: Themes Keywords: has-patch needs-testing
Focuses: Cc:

Description

As reported by Matt.

If you're using theme A and set a custom header via the standardized API (i.e. a background image and text color) and then preview theme B on the theme switcher, the settings from theme A are used. Once you actually switch themes though, it works fine and uses the settings from theme B.

The problem stems from get_current_theme() returning theme A even when previewing theme B.

function get_theme_mod($name, $default = false) {
        $theme = get_current_theme();

        $mods = get_option("mods_$theme");

        if ( isset($mods[$name]) )
                return apply_filters( "theme_mod_$name", $mods[$name] );

        return apply_filters( "theme_mod_$name", sprintf($default, get_template_directory_uri(), get_stylesheet_directory_uri()) );
}

Still working on a solution to this (i.e. telling WordPress it's using theme B during the preview or something).

Attachments (3)

9152.patch (1.4 KB) - added by Viper007Bond 15 years ago.
9152.2.patch (1.4 KB) - added by Viper007Bond 15 years ago.
Previous patch wasn't properly returning mod options for theme being previewed, now it does
9152.3.patch (1.0 KB) - added by Viper007Bond 15 years ago.
Always display the default header when previewing a theme

Download all attachments as: .zip

Change History (12)

@Viper007Bond
15 years ago

#1 @Viper007Bond
15 years ago

This patch seems to do the trick. It hacks the theme header mods option to return the mod settings for the theme being displayed rather than the actual current theme.

@Viper007Bond
15 years ago

Previous patch wasn't properly returning mod options for theme being previewed, now it does

#2 @Viper007Bond
15 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

#3 @matt
15 years ago

Cool.

#4 @westi
15 years ago

  • Milestone changed from 2.9 to 2.8
  • Owner set to westi
  • Status changed from new to assigned
  • Version changed from 2.8 to 2.7

#5 @westi
15 years ago

Could you point at a theme that uses this for testing purposes.

#6 @Viper007Bond
15 years ago

I used the "ambiru" and "benevolence" themes from the WordPress.com theme SVN for testing purposes.

#7 @westi
15 years ago

Just did a quick test of this - not enough time to investigate further but it looked like the preview was still showing the image text colour from the active theme.

#8 @Viper007Bond
15 years ago

Ooooh, I think I just realized what the problem is. The theme you're previewing doesn't have a custom header, does it?

If not, that means get_option('mod_PreviewTheme') returns false. That makes the filter not kick into effect and abort the get_option('mod_CurrentTheme').

Looks like rather than showing the previewed theme's custom header when previewing it, we'll have to display just the default version of the theme at all themes.

@Viper007Bond
15 years ago

Always display the default header when previewing a theme

#9 @ryan
15 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [11061]) Always display the default header when previewing a theme. Props Viper007Bond. fixes #9152

Note: See TracTickets for help on using tickets.