Themes can wreck havoc on master pages since by default theme styles are called after regular SharePoint styles. Depending on your changes, themes may leak through via changing styles you did not, or if you used the Alternate CSS property in Master Page Settings to call your custom styles. The Alternate CSS is called along with those regular SharePoint styles (via the CssLink tag in your master page) and the theme is called after that.

When you have a custom master page, the master page is stored in the content database. When you add a theme, SharePoint adds a meta tag to the master page right before the closing HEAD tag, thus rendering any styles you specified as defenseless against the applied theme. The meta tag looks like this:

<meta name=”Microsoft Theme” content=”ThemeName 1011, default” />

If your design requirements include creating a matching theme for your site, you can create the theme and master page in tandem so you don’t have conflicting styles. But if you have to create the theme after the fact, you will spend extra time fixing issues the theme causes for your site with the custom master page. And if you do create them in tandem, your theme may cause you extra grief, and you may want to follow this solution anyways to avoid that.

If the theme is only there to brand application screens (_layouts) you can choose to remove the Theme tag from the master page, then the theme will only apply on application screens and your custom master page and site will not be affected. Doing this will work, and will bring you to the issue that Randy discovered. Randy mentions using a Feature to deploy the master page to the server, and I certainly agree with that recommendation. But if that is not feasible for your situation, you have some options.

First, the order of how you do things. If your theme causes issues:

Open the custom master page in SharePoint Designer (SPD).

Go to the site and apply the theme.

Return to the master page in SPD and remove the theme tag (<SharePoint:Theme runat=”server”/>). If you have been messing with applying themes, go ahead and check for a theme meta tag right before the closing HEAD tag. If you find one, remove it.

Save the master page.

Go the site and check it out, you should have themed application screens and non-themed site pages.

If you have to mess around and try out different themes, be sure to open up your custom master page first in SPD. As you mess around your site pages will be affected. Once you settle on a theme or finish your testing, go back to SPD and save the master page. No need to make any changes. SPD will re-save the clean version of the master page in the content database and wipe out any meta tags SharePoint added for the theme.

Going forward you will still face this potential issue if anyone has rights to update the theme. You can avoid this by removing the other themes from the theme picker screen (if you need help with this, check out this section of this post and instead of adding template blocks, remove all the ones you don’t want). This works because SharePoint will only add the meta tag if you change a theme. Once set and no options for change, your master page will be preserved.

If this isn’t an option for you, really restrict who has access to change themes, go back and make your theme compatible with your master page, or deal with what may happen when the theme changes. Sorry I don’t have a better answer. It may be possible to create a Feature that requires moderation for theme changes.

In case you are wondering, you can move the Theme tag in the master page above the CssLink tag, but that will only help you stop a theme from changing your stuff if you remove the meta tag SharePoint places in the master page. Moving the theme tag doesn’t bypass this issue.

My ending advice would be, while in development keep your master page open in SPD before and while you mess with themes so any saves you do will remove that meta tag. And if you can, use a Feature to deploy custom master pages on production servers.