Theme update and a mad dash to fix broken stuff

So Museum Core was pushed live to the WordPress.org repo today. Of course I immediately switched my blog from the Twenty Fourteen theme I was testing to Core because, you know, it’s my freaking theme. And immediately I ran into some issues. If you are using Core and experience any of these, here are the fixes. Also, if you’re using Core and you find new issues, be sure and let me know in the comments or in the theme’s support forum.

Notifications appear twice

I’m also using my Notifications plugin. I thought I was clever by adding support for multiple possible action hooks in the plugin. Maybe I was. However, I was also a bit too clever in adding support for multiple possible action hooks in the theme. This resulted in both the body_open action and the before action being found by the theme in the Notifications plugin and resulted in the notifications displaying twice. That’s not good. I guess I was being a bit too clever.

I pushed out an update to the Notifications plugin that removes support for the body_open and before actions (effectively removing the native support for Twentytwelve that I added) in favor of the Theme Hook Alliance tha_body_top action. In theory at least, the Theme Hook Alliance actions will become more canonical and used by multiple themes so, while I’m removing native support for Twentytwelve, I’m actually adding support for any of the themes that currently do support THA hooks and Twentytwelve, if the theme authors decide to add THA hooks into it. If you are using Core and Notifications together, please update your action hook under the <body> to this:

<?php do_action( 'tha_body_top' ); ?>

Icons don’t display

Museum Core 2.0 removes all the image icons that were previously in the theme and replaces them with the icon font, FontAwesome. FontAwesome is — as it sounds — awesome, and using it with the Bootstrap 3.0 support that is the foundation of Museum Core was a pretty easy decision. However, after updating my theme, none of the icons (which appear at the bottom of the posts) were displaying. I thought there was some caching issue or maybe the font files never downloaded in the update. But, checking all that, came up empty. Finally, I found the issue.

I’m also using the Better WordPress Minify plugin, which minifies all your javascript and css. Well the FontAwesome CSS is already minified, so I suspect that trying to concatenate and re-minify an already minified CSS file made something go wonky and it just wasn’t working at all. The solution was to turn off CSS minification and everything works fine now.

(By the way, that cool little flag thingie up there, that was created using FontAwesome using a recipe from their site…here’s the code:)

<span class="icon-stack pull-left icon-4x"><i class="icon-circle icon-stack-base"></i><i class="icon-flag icon-dark"></i></span>

(Note, if you do this in WordPress, you’ll need to put all the code on a single line, no breaks — otherwise the WordPress editor will interpret those as line breaks (<br />) and it will break the cool stacking effect. Also note that I’m using icon-dark on the flag instead of icon-light as is suggested here since the font color is already light.)

Download Musuem Core!

Now that I’m done with my rant, please, please PLEASE go download Museum Core RTFN and tell me what you think. I tried to make it as flexible as humanly possible and I’m pretty satisfied that the result is something that’s both usable as a theme framework or a theme that allows you to tweak almost every aspect of it right from the Theme Customizer. Again, if you run into any issues, please let me know.

Making theme options modular

Today I submitted version 1.1 of Museum Core to the WordPress theme repository for review. Originally this was going to just be a simple update with some bugfixes, but I had thought of a way to make it easier to build child themes that include some options settings from the parent theme (Museum Core) without having to include all of the options from the parent. It started out with this ticket I created on GitHub.

Now, the ticket evolved from that first sketch of an idea, and I ultimately abandoned the concept of using actions and remove_action to change what options get used. But the current approach is, I think, a pretty powerful way to approach theme options development so that things can be reused or abandoned in child themes and it isn’t something that I’ve seen other people doing. (To be fair, this is actually what’s described in the WordPress Codex, but I haven’t seen it in action on very many theme options pages, or any tutorials talking about how one would go about writing a theme options page, so I thought it was worth writing about.) And it reduces my entire theme options down to this code:

So let’s take a look at what we’re doing in ap_core_do_theme_options

First of all, I’ve pulled out all the code and put it into a new file called option-setup.php. This handles all the stuff that was previously where the _do_theme_options function is now but everything has been pretty drastically rewritten. First we have ap_core_do_theme_options which looks like this:

If you’ve tried or are currently using Museum Core, you’ll already know that the theme options page sports some tabs. So the first function we’re calling in _do_theme_options is the tab setup. This is a pretty straightforward function that just spits out the html needed to set up the tabs. The real meat is in the next three functions. We won’t look at every single function, we’ll just dig into the main highlights so you get an idea of what’s going on. Let’s peek at ap_core_general_settings which handles the, wait for it, general settings tab.

ap_core_general_settings looks an awful lot like ap_core_do_theme_options, with a bit of HTML thrown in to set up the table that’s going to hold the actual options. That uniformity is intentional, the idea is that you can swap functions in and out however you want. You can use your own modified version of ap_core_general_settings in your child theme, or you can do away with the tabs and just put all your options straight into ap_core_do_theme_options. Or you can mix and match options from the various settings tabs and create your own tabs, it’s up to you. Let’s take a look at what an individual option looks like now.

That’s got a bit more heft to it. But it’s still pretty basic. All I did here is pull the table row from the original theme-options.php and added it to this function. I’m using output buffering to store all the php/html as a variable and echoing the variable at the end which is what gets sent to the function calling this function (in this case ap_core_sidebar_option). I’m also calling the defaults and options from the database so our values are loaded and stored. This is done ad nauseum for each setting, so each setting gets called separately and can be isolated, grouped, cut out, whatever as needed by a child theme.

So what happens when I want to build a child theme and use some of these options? Here’s an example:

First what I’m going to do is start with a new theme options function. I’m keeping the 3 tabs from Core, but I’m adding a 4th tab. Since Core only supports 3 tabs, and I’ll need to set up the title for the fourth tab, I’m doing my own tabs. We’ll start by setting up the tabs. Remember, you don’t have to use the tabs at all; if you just want all of your options on the Theme Options page, you can just cut out the tabs function and then they’ll display normally, one on top of the other.

The two things that are changed are highlighted by the fact that the textdomain (‘museum-core’, ‘my-theme’) has changed. We don’t need to change the textdomain of the other tabs, because, assuming the text was translated in a language file, those would already be covered by the existing translation in Core — only the new translation strings need to be added (of course, none of this is necessary, really, if you don’t care about localization of your child theme). We changed “Typography & Fonts” to “Font Stuff” and added the fourth tab, “Custom Tab”. So far, so good. This is what it looks like:

20120511 8bgrj593pymrskawg7me5dky7y.medium Making theme options modular

Now that we’ve got the tabs, and we’ve added the options pages that we’re pulling from Core, it’s time to create our new settings page. We’ll do this really minimally and just add one option. We won’t add a bunch of function calls (although we could), we’ll just put our option straight into the new my_custom_theme_settings function. It looks something like this:

Now, in order for this to be actually functional, we’d need to define some new options for our theme so we could store them in the database, this is just meant to be an example and illustrate how we’re able to still pull functions from the parent theme and mix them into our custom theme functions. Here’s what that new tab looks like:

20120511 gjd8g2p9m9dw3a397wykaxw78g Making theme options modular

To summarize, what I’ve got is a modular way of calling individual settings that can be swapped in and out at will and replaced with custom settings (or not) however you want. If you have any thoughts or questions, feel free to post in the comments. If you’d like to dig into the source files, you can grab the latest version of Museum Core from GitHub. You can also take a look at the complete code from this tutorial on GitHub. And if you want to take a look at the files on your computer and hack them up, you can download the source files used to create the child theme in the screenshots here.

One theme to rule them all

If you follow us on Twitter or Facebook, you may already know that we recently released our first theme to the official WordPress repository.  It’s called Museum Core.

Museum Core is the product of over a year of development.  A solid foundation built on responsive design, HTML5 and CSS3, with a theme options page that is secure and flexible.  It also supports localization into any language you want.  In less than a month, it’s already been downloaded more than 3,000 times.

Core marks the beginning of our shift in scope for Museum Themes.  Rather than maintaining dozens of different themes independently, all themes, past and future, will become child themes of Core.  Additionally, we’ll be using Core to build WordPress versions of our most popular and favorite Blogger templates — we’ve already released WordPress versions of Grandma’s Hat Box and dear Audrey, and more are on the way.  Soon all our themes will be driven by the powerful Core framework, while maintaining the same level of customization options they currently offer.

Exciting things are coming in the next few months for Museum Themes.  For now, here’s our promo video for Core and some more information about what it supports.

Here’s a list of some of the features in Museum Core:

  • customizable sidebar (left or right)
  • full posts or excerpts on main blog page and archive pages (excerpts support post thumbnails)
  • customizable footer text (no hard-coded author credit)
  • five typeface options for 3 different locations (headings, body and alternate) with an eye for international language support
  • customizable link colors via an easy-to-use color-picker
  • custom favicon
  • optional support for Twitter hovercards
  • responsive design that supports smaller screens and mobile
  • supports all WordPress post formats with different layouts optimized for each
  • internationalization support.  Complete Polish translation in 1.0.9 courtesy of anemoone.

 

New look for jazzsequence.com (again…)

So, the jazzsequence.com redesign is still on (or at least planned), but I figured, since I just got a theme hosted in the WordPress.org themes repository, I might as well make it, you know, my theme so that at least one person is using it live, right? So here it is: Museum Core. I’ve also disabled WPTouch so if you’re looking at it in a mobile browser, you can see it in all its responsive glory.

I’m really excited about this theme. Not just because it’s badass and not just because I spent over a year developing it. Those things, too. But because…wait, no, it’s pretty much because it’s badass. I learned a lot through the whole process, particularly the theme review process, and it took over a month of revising and revising to get this (my first (accepted) submission to the repository) actually hosted on WordPress.org. It’s no small feat. It requires dedication, the ability to take criticism, and willingness to adhere to WordPress’ (high) standards. I don’t say that to pat myself on the back. I say that because it’s effing hard. Okay, yeah, and to pat myself on the back. A little bit. But possibly WordPress says it best on their page about why you would want to host your themes on WordPress.org:

The goal of our themes directory isn’t to have every theme in the world, it’s to have the best.

That’s their words, not mine. I certainly wouldn’t call my theme the best. But it’s damn fine (if I do say so myself) and I’m going to stand behind it and show it off for a little bit by making it the theme for my website. I’m allowed to do that. If you want to download it, go get it here: Museum Core.