WordPress.com Moves to Standardize Theme Support for Site Logos

WordPress.com introduced a new site logo feature today with the goal of standardizing the way themes present logo upload. When it comes to data portability, you’re usually out of luck with logos. Ordinarily, when you change to a new theme, you lose your logo. Each theme developer has a different way of incorporating logo upload, but it’s not portable across themes.

The new site logo feature allows you to optionally display the site’s title and tagline along with the logo, which will automatically appear on any of WordPress.com’s supported themes. All future themes will come with the site logo feature and WordPress.com developers are working to add support to previously released themes.


As WordPress.com moves to standardize theme support for site logos, the rest of the WordPress ecosystem may soon follow suit. The Jetpack team is considering adding the site logos feature into the mix after getting it running on WordPress.com, making it possible for self-hosted WordPress sites to enjoy logo portability. The availability of a standardized site logo plugin would improve data portability across the board, whether it comes through Jetpack or another community-supported plugin. It would also help theme developers everywhere to be more efficient when building products.

Brian Krogsgard recently published a piece proposing that WordPress.com and Jetpack should lead the way toward standardizing custom post types so that users can easily move from theme to theme without losing data.

But if you have a post type for a portfolio, or testimonials, or staff bios, or something more generic, it could be a great thing to standardize so that different themes could support the same post type, which would result in better transitions for users from theme to theme.

Standardizing CPTs also helps theme developers create designs that can be used with any number of third-party extensions. Two plugins may use the same prefix to create testimonials and the user has the option the select the one he thinks is best.

Standardizing theme support for logos is in that same vein. If you hope to be able to use this feature with self-hosted WordPress themes, keep an eye on Automattic’s site logos repo to see where it goes. If theme developers can make it easier for users to move from theme to theme, they’re likely to stick with WordPress and redesign more often.


14 responses to “WordPress.com Moves to Standardize Theme Support for Site Logos”

  1. Re: adding the functionality to JetPack.

    Wouldn’t it be better to add a standardised method of adding logos in WordPress core itself, instead of relying on a plugin by a private company (that uses that plugin to generate revenue)?

    Something like add_theme_support( ‘custom-logo’ );

    • Came here wondering about add_theme_support( ‘custom-logo’ ) and was severely disappointed to hear that once again we are being pushed towards Jetpack for what should be core WP features. In fact, this seems to be happening at an alarming rate.

  2. I would love to know how their solution (and Jetpack’s, when and if that transpires) handles retina displays. We’ve hit this roadblock in our theme development before, because just using an image control leaves a lot to be desired on high res screens.

    I see this as a natural fit for WordPress core (more so than the post types discussed over on Post Status), with themes enabling it using add_theme_support() as Gary suggested.

    • The difference is that the header image support is more for banner style images. It has a few extra settings like being able to set how the image will be positioned, whether it’s repeated, etc — not really things that are necessary for a logo. Plus, sometimes it may make sense to have both a header image and a logo.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: