Categories
WordPress

Simone 2.0: Custom backgrounds, sidebar position, RTL support, and more

After much ado Simone 2.0 is now live in the WordPress Theme Directory. The theme is cresting 50,000 downloads already and for the new version I decided to bake in some of the most requested new features.

Custom Background

Using the Customizer to change the background color in the Simone WordPress theme
Set a custom background color or background image in the Customizer

One of the standard WordPress theme features that were not available in the original version of Simone was custom background color and custom background image. This was a deliberate choice on my part because the way I designed the theme changing the background color and/or adding a background image made little sense. However after seeing several sites running Simone with custom backgrounds (usually added through child themes) I realized this omission may have been unnecessary.

Therefore, as of version 2.0 you can now set a custom background color and/or custom background image through the Customizer.

The custom background function only kicks in on index and archive pages and appears behind the white content boxes. For single posts and pages the background remains solid white throughout.

Sidebar Position

Setting the sidebar position in the Simone WordPress theme
Set sidebar position and content display in archives in the new Theme Options panel in Customizer

In 2.0 the Customizer has a new section called Theme Options. From here the site admin can change the position of the sidebar and the index content length. By default the sidebar appears hard right and will stick to the right hand side on larger screens. Since its launch users have requested the ability to switch the sidebar position to the left. As of this new release the site admin now has this option. The behavior is the same as previously: The sidebar sticks to the left-hand side regardless of screen width.

Index Content Length

Speaking of index and archive pages several requests were made to provide an option to select the length of content displayed on index and archive pages. The theme was originally designed to display the first post of the index and any archive page with a full-size featured image and the full content (unless truncated with the <more> tag) and the rest of the posts with a smaller image and the post excerpt.

In 2.0 a new option has been added to the Customizer under Theme Options to change the index and archive displays of all posts from excerpts to full content. This setting effects all archives as well as search results.

RTL Support

One of the goals I had when releasing Simone was to make it available and usable for as many people as possible. Part of this effort was to make the theme fully translatable through standard internationalization methods. Since its release 13 language translations have been added to the theme by community members. However, out of the box the theme only supported LTR languages.

As of 2.0 Simone now fully supports RTL languages and ships with translation files for Farsi. When an RTL language is activated all components of the theme are mirrored: The main and social menus are reversed and repositioned, the search bar is moved to the left, and all content is reversed. I am currently working on getting translations for other RTL languages which will be released in future updates.

Simpler Child Themes

If you are a reader of this site you know there is some controversy brewing over the recommended method for calling in styles from parent themes in child themes. This issue prompted me to change the way stylesheets are loaded in Simone to make it easier for the user to build child themes. With the help of Ulrich Pogson the stylesheets in Simone are now enqueued in such a way that a child theme automatically inherits the correct styles.

For child theme authors this means you no longer have to use an @include or the new wp_enqueue_style() code to pull in the original stylesheet. All you have to do is create a style.css file and add the standard child theme header and the parent theme styles are loaded in the background. The child theme styles will automatically override both the main stylesheet and the layout stylesheets for right sidebar, left sidebar, and no sidebar.

To deactivate the parent theme stylesheets all together or individually you can do so by adding wp_dequeue_style() functions in the child theme functions.php file as in this example:

 <?php
 add_action( 'wp_enqueue_scripts', 'dequeue_parent_theme_styles', 11 );
 function dequeue_parent_theme_styles() {
   wp_dequeue_style( 'simone-parent-style' );
   wp_dequeue_style( 'simone-layout' );
 }

Simone is for You!

Simone is quickly becoming a popular theme in the WordPress Theme Directory, in no small part thanks to the support it’s gotten from the accessibility community. Now it’s your turn to take the theme for a spin, check out the new features, and show me what you can do with it. And if you have ideas for improvements or future additions, let me know either in the comments below or by submitting an issue on Github. As you can see from this release I listen to the users and update the theme to fit your needs. Simone was built to be used and I want you to be able to use it for what you want. So go get started!

Categories
WordPress

Challenges with the new method for inheriting parent styles in WordPress child themes

During the past month or so a new method for inheriting parent styles in WordPress child themes has been established, replacing the old method of importing parent styles with an @import call in the child theme style.css file.

The new method involves enqueueing first the parent and then the child style.css file through a functions.php file in the child theme.

While at first glance this seems a valid and much improved approach, further testing has uncovered an inherent flaw in its logic: The new method makes several assumptions about the scenario in which it would be used that make it hard to use and prone to failure.

The current (new) method is described as follows in the Codex:


<?php
add_action( 'wp_enqueue_scripts', 'enqueue_child_theme_styles', PHP_INT_MAX);
function enqueue_child_theme_styles() {
    wp_enqueue_style( 'parent-style', get_template_directory_uri().'/style.css' );
    wp_enqueue_style( 'child-style', get_stylesheet_uri(), array('parent-style')  );
}

The Theme Handbook describes a variant of this same approach:


<?php
function get_parent_theme_css() {
  wp_enqueue_style( 'your-child-theme-name', get_template_directory_uri() . '/style.css' );
}
add_action( 'wp_enqueue_scripts', 'get_parent_theme_css' );

In both cases one important assumption is made: That the parent theme has one main stylesheet with the filename “style.css” and that it does not use any other stylesheets. This is not a realistic situation, and in cases where the parent theme relies on stylesheet dependencies it can cause some serious issues.

What happens

First, let’s look at each of the examples and see what happens:

In the Codex example we set up an action that hooks onto the wp_enqueue_scripts event and calls in a function. The function contains within it two calls to enqueue first the parent theme style.css file and then the child theme style.css file. This results in the parent theme style.css file loading first, then the child theme style.css file, and you get page markup where new styles added to the child theme style.css file will override the parent theme styles. This is as intended and in line with how things worked with the @import function. This works as long as all parent theme styles are contained within a file called “style.css” which as we will see in a bit is not always the case.

The Handbook example sets up the same way but only calls the parent theme style.css file. Because of how WordPress works, this overrides the inherent logic and prevents the child theme stylesheet from loading. As a result any style change added to the child theme style.css file will not take effect making changes to styles through this file unavailable. This is likely an omission in the documentation so not worth dwelling on further.

The Problem of Dependencies

Now for the problem: As indicated above not all parent themes operate with a single style.css file that contains within it all styles. In many cases themes use a series of stylesheets to achieve optional layouts or other effects. These are normally enqueued as dependencies to ensure everything is added in the correct order.

Take this example: A theme ships with two layouts, right sidebar and no sidebar. To achieve this without cluttering up the style.css file with two different sets of layout styles the theme developer has separated out the layout styles in their own stylesheets under a dedicated folder. This is common and the recommended approach in the _s starter theme.

To get it all to work in the parent theme we have something like this:


<?php
// Create function to enqueue styles
function themename_scripts() {
  // Register main stylesheet with the handle 'themename-style'
  wp_register_style( 'themename-style', get_template_directory_uri().'/style.css' );

  // Test for nosidebar template or no sidebar and select correct layout stylesheet.
  // Layout stylesheet is enqueued with the label ‘themename-layout’ and made dependent on 'themename-style' above
  if (is_page_template('page-templates/page-nosidebar.php') || ! is_active_sidebar( 'sidebar-1' )) {
    wp_enqueue_style( 'themename-layout' , get_template_directory_uri() . '/layouts/no-sidebar.css', array('themename-style') );
  } else {
    wp_enqueue_style( 'themename-layout' , get_template_directory_uri() . '/layouts/content-sidebar.css', array('themename-style') );
  }
}
add_action( 'wp_enqueue_scripts', 'themename_scripts' );

The function above is typical and straight-forward: When the parent theme is loaded a test is run for the current layout condition and based on its result one of the two layout stylesheets are enqueued. These stylesheets are made dependent on the main style.css file which has been registered with the handle “themename-style”. When a page is loaded the dependency (style.css) is loaded first,, then the layout styles.

This means for the theme to display properly with the correct layouts it is the layout styles that are called, not the style.css file.

Now consider the proposed approach in the codex: Here the child theme explicitly calls for the main stylesheet – style.css. That means when a child theme is activated the layout styles are not loaded!

A possible (but not user friendly or uniform) solution

The problem described above is caused by the assumption that the parent theme uses the style.css file as its only stylesheet and ignores other circumstances like a theme that uses dependencies. To solve this problem the approach must be changed to something like this:


<?php
function enqueue_child_theme_styles() {
  wp_enqueue_style( 'child-style', get_stylesheet_uri(), array('[parent_theme_name]-style') );
}
add_action( 'wp_enqueue_scripts', 'enqueue_child_theme_styles', PHP_INT_MAX);

In this example we are enqueueing only the child theme stylesheet and making it dependent on the parent theme stylesheet stack in whatever way that is set up. This preserves any dependencies in the parent theme and provides the correct ordering of all stylesheets. The problem of dependencies is solved, but this solution puts the onus on the child theme author to know what stylesheet is “in control” of the parent theme and know what its label is. That means tunnelling into the parent theme functions.php file and finding the correct enqueue function – something requiring a level of skill previously not needed for building child themes. As a result the threshold on getting started with building child themes and eventually themes becomes much higher than it used to be.

Moving forward

The change in recommendation about how to inherit styles from parent themes brings up important questions about the role of child themes in the overall training philosophy of WordPress. Some would argue increasing the difficulty level of creating child themes as this new approach does is a good thing because it takes away some of the “hand holding” that in some cases leave users with the ability to do things they do not fully understand. On the other hand increasing the difficulty level also makes entry into the space and non-destructive customization of themes harder, something that goes against the original reasoning for introducing child themes in the first place.

As I see it we need to provide a simple and consistent approach to creating child themes and inheriting parent theme styles that does not require this in-depth understanding of how WordPress themes work. To facilitate this a new function or filter could be created to get parent- and child theme stylesheets queued up correctly.

In the end there are only three scenarios in play here that need to be made available:

  1. Child theme only uses its own style.css file. No inheritance.
  2. Child theme loads parent theme styles as they are loaded in the parent theme and then loads its own style.css file to add / override styles.
  3. Child theme only uses parent theme styles and is built to add other features that do not include CSS.

And this means the new function or filter would only have to do one of three things:

  1. Load only the child theme style.css file
  2. Load the full stack of parent theme stylesheet files as they are loaded in the parent theme, then the child theme style.css file
  3. Load only the full stack of parent theme stylesheet files as they are loaded in the parent theme

How exactly this function or filter would be built should be handled by developers wiser than myself.

Categories
AMA

Q&A: Child theme bloat and when to build a new theme

I got these questions from a lynda.com viewer earlier today. They are fairly common so here are the questions and my answers. Keep in mind that everyone who works with WordPress or on the web in general has strong preferences one way or the other, so if you disagree with anything I say, leave it in the comments and let’s discuss!

Now for the questions:

I wondered if I could trouble you to ask just two broad/philosophical questions regarding child-themes? These are pretty “general interest” questions….

  1. If it includes a lot of CSS/template files, does a child theme eventually slow down the loading of a site? It seems that it would, since the child theme is overriding the parent theme, not replacing it. Is this true?
  2. At what point should I be taking a theme (like twentyten or other) as a starting point and build my own theme, rather than building a child theme? It seems that, at some point, if one overrides much of the original theme, there seems to be less benefit gained from parent theme updates etc. and an increased risk of having a really bulky site. (Though I’m not sure I’m experienced enough to build a complete theme quite yet without missing something important – like security etc.)

I’d be really interested to hear your thoughts, if you have a couple of minutes to share them.

Thanks, Jodi

Child Theme Bloat

A child theme doesn’t really bog down the site any more than a regular theme, even if it is completely rewriting all of the parent theme. Let me break it down for you:

If you use @import or another method to load the original stylesheet, then you are loading two stylesheets, but WordPress stylesheets are relatively small and uncomplicated so it’s not that much of a tax on the server. If you roll your own styles entirely, you are just loading one stylesheet.

The parent theme functions.php file will always load along side your child theme functions.php file, but again these files are relatively small so the tax is negligible.

If you make any other template files in your child theme (header.php, index.php, new_cusom_file.php) these will be loaded in place of or in addition to the parent theme files. In other words you’ll never load both the parent theme and the child theme template file and then only display the contents of one of them.

Themes from scratch

As for when you want to build a theme from scratch, that’s a bit more complicated to answer. I build all my themes from scratch because I want full control over everything. I always work from custom designs created to match client or project criteria and rarely start off with something that can be easily built from an existing theme. I’m also obsessed with clean code, standards, and modern approaches so building from scratch every time allows me total control and room to always stay on the bleeding edge of what is being done.

If you design a site from scratch and want it to do specific things, building a theme from the bottom up is often a better idea. But, if you find a theme that already has the majority of what you need, customizing it with a child theme is a lot quicker and easier and will make upkeep easier to handle.

If you want to build your own theme from scratch there are many places you can start. I personally like to start with as little interference as possible so I use a highly personalized version of the _s (“Underscores”) theme. _s is about as stripped down as you can get and to use it you have to do a lot of work, but you also have complete control.

If that’s too stripped down for your tastes there are other great themes to start with including Toolbox. Some developers prefer starting with frameworks like Responsive, WP Fondation, WP Bootstrap, or others, but I think these are colossally overloaded and end up bringing a whole new range of complications.

I have no perfect answer for you on this one. My best suggestion is to master the art of the child theme and then take those skills and apply them to a starter theme like _s.

Hope that helps!

Categories
Lynda.com Tutorials

A bugfix for WordPress 3: Building Child Themes on lynda.com

With the update of WordPress to version 3.4 came some important feature improvements that changed the way certain key components work. This includes how the header image and background functionality is implemented. This in turn means the old methods of making changes to these elements suddenly don’t work any more.

The Issue

This change has made a previously well functioning component in my WordPress 3: Building Child Themes course on lynda.com non-functional.

In movie 2.3 I instruct the viewer to redefine the height and width of the header image using the following code in a child theme functions.php file:


<?php
define( 'HEADER_IMAGE_WIDTH', apply_filters( 'twentyten_header_image_width', 980 ) );
define( 'HEADER_IMAGE_HEIGHT', apply_filters( 'twentyten_header_image_height', 224 ) );
?>

Unfortunately with the new implementation of the header image function, this no longer works. A new filter function is needed.

The Fix

To get the result you want without messing things up in the process, a modified version of the code above is necessary. So, to resize the header image in a child theme of Twenty Ten you use the following code:


<?php
function tnc_header_width($width) {
	$width = 980;
	return $width;
}

function tnc_header_height($height) {
	$height = 224;
	return $height;
}

add_filter( 'twentyten_header_image_width', 'tnc_header_width' );
add_filter( 'twentyten_header_image_height', 'tnc_header_height' );

?>

An Update is Imminent

We are hard at work rolling out an update to the course to bring it in line with the new version of Twenty Ten. Until then, just use the code above and everything will work fine.

Categories
Lynda.com Tutorials

WordPress 3: Building Child Themes – new course at Lynda.com

LEGOs used as illustration for the WordPress 3: Building Child Themes course on lynda.comChild Themes are by far the easiest way of creating a new look and introduce new functionality to a WordPress powered site. By creating a WordPress child theme you get all the benefits of the parent theme while gaining the ability to create custom styles, custom layouts and custom functions just for you.

In May 2011 I went to Ventura, California to record my new course WordPress 3: Building Child Themes for lynda.com. The course takes you through the entire child theme building process – from picking a parent theme to creating new styles and layouts, customizing and adding menus, sidebars and footers, integrating the Featured Image (post thumbnail) functionality throughout the theme and even adding custom jQuery functions. Here’s a sneak preview:

The course and its materials were created to make it easy for everyone to get started customizing WordPress sites and comes as a direct extension to my WordPress 3 Essential Training course (also available from lynda.com). Although the course uses the Twenty Ten theme as the parent theme all the code samples and techniques demonstrated can be used to build child themes from any other theme.

I’m very excited to announce this new course and I hope you like it too. If you’re not already a member of lynda.com you can get a 7 day trial membership by visiting lynda.com/trial/rand-hendriksen.

Go forth and start child theming!