Web Standards WordPress

Title, Caption, Alt Text, and Description: Harnessing the Power of WordPress Image Metadata

Images play an important role in web publishing, and WordPress makes it easy to add images to your content in several different ways. What you probably didn’t know is that taking a few extra minutes to fill in the “Attachment Details” for your images can improve their communicative value, create better user experiences for your visitors, and bring more people to your site.

In this article I’ll explain what the Title, Caption, Alt Text, and Description fields are all about and why they matter more than you think.

Every Image has its own Attachment Post

Screen grab of the Attachment Details fields in WordPress
The Attachment Details fields show up any time you add an image to a post or page

Let’s start at the beginning: When you add an image to WordPress, whether it be as a Featured Image (previously “post thumbnail”), an image in a post or page, or as a header image, you are actually creating a new Attachment Post. Once the image is added you can edit its Attachment Post by clicking the Media button in WordPress admin. This gives you a list of all the attachment posts associated with uploaded media items on the site.

Depending on your current theme you may also be able to access the Attachment Post page for the image from the front end of your site, and this attachment page may display some of or all of the meta data associated with the image.

Images and Attachment Posts can carry a lot of metadata

When you add a new image to a post you are prompted to add so-called “Attachment Details”. These attachment details are probably the most ignored and underutilized features of WordPress and if you learn what they are and how to use them you’ll never ignore them again:


The title is the only attachment detail required by WordPress. Title defaults to the name of the file but should be changed to a descriptive title of the image. This is the title of the Attachment Post for the image and just like a regular post the title will define the pretty permalink for the attachment post. You can also use the Title to search for images in your media archive.

In previous incarnations of WordPress the Title field was mapped to the optional HTML title attribute. This resulted in the title of the image appearing as a tooltip any time a mouse hovered over it. In the current incarnation of WordPress the title attribute for the image itself and also the optional image link are added separately. To do so you have to add the image to the post, then reopen it by selecting it and clicking the pen icon in the top left hand corner, and toggle the Advanced Options section of the Image Details modal window. Here you find Image Title Attribute as well as Image CSS Class (of which I spoke in a previous article), Open link in a new tab, Link rel, and Link CSS Class.

Screenshot of the advanced image options fields in WordPress
The Advanced Options under Image Details allow you to add title attributes to your images.


The caption is the text traditionally displayed underneath the image though the exact placement will vary depending on your theme. The caption is not tied to the attachment post but to where you choose to place the image in a post. That means if you use the same image in several different posts or several different places within a post you can have individual captions for each.

In WordPress captions are added using the shortcode which wraps around the <img> and optional <a> tags. This is why you can’t move images with captions in the visual editor but have to do it from the code end. For the image above the entire embed code complete with caption shortcode looks like this:

[caption id="attachment_2896" align="aligncenter" width="700"]
  <a href="" target="_blank" rel="attachment wp-att-2896">
      class="wp-image-2896 size-large" 
      title="Learn more about the Advanced Options for WordPress images" 
      alt="Screenshot of the advanced image options fields in WordPress" 
  The Advanced Options under Image Details allow you to add title attributes to your images.

It is worth noting that WordPress image captions can contain HTML including links.

Alt Text

The alt attribute or “Alt text” is mandatory for images on the web but is often ignored because it seems unnecessary. This is unfortunate because the alt attribute is both important and powerful.

The alt attribute is the text that displays when an image does not display. The general rule of thumb when applying alt text to an image is to describe in text what the image is communicating.

There are specific rules that govern how the alt attribute should be used:

  • If the image has communicative content (either says something or is illustrating something that has relevance to the content on the page) the alt text should describe the content either by repeating the text in the image or describing its content.
  • If the image is wrapped in a link the alt text should describe the target of the link.
  • If the image is purely for decoration and has no communicative value the alt tag can be left blank (alt=””)

People often think that the alt text is for visitors with accessibility problems. That is true, but it’s just part of the story: The alt text is there to describe image content and relate it to your overall content. While most visitors don’t see the alt text, search engines do and they index the images based on them. And as we move into a world of wearable devices that don’t always show images the alt text will become more important than ever before.

Bottom line: Always describe your images in the alt text field unless they are purely for decoration.


The Description field is probably the best kept secret of images in WordPress. If you add text to the description field that text will be stored as post content for the attachment post. That means if someone lands on the attachment post page for the image they will see the long description (provided the current theme supports it). To see how this works try clicking on one of the images in this article. You’ll be taken to the attachment page for that image where you see the image title, the image itself, the caption, and the description as post content. The attachment page in the theme I’ve built for this site also provides meta data that shows what post the image is associated with, a link to the original image size, and even navigation links to other images within the same post.

Once you’ve added an image to a post and you want to change or add to the Description you have to open the editor for the image Attachment Post. You can do that by going to Media in admin and finding the image or by navigating to the image on the front-end of your site and clicking Edit Media in the WordPress Toolbar. Though the Description field does not have the Visual (WYSIWYG) editor you can treat it exactly as you would any other post or page. It takes HTML and allows you to format the content to make it look like a regular post.

The Power of Metadata

Combined these text fields are a powerful feature that can be used to create better and more communicative experiences to your visitors and also bring new visitors to  your site. To see how let me give you an example:

Let’s imagine for the moment you are a wedding photographer and you are publishing a photo essay about a recent wedding. In the main post you add some images with basic captions and you describe these images with alt text that also includes your company name, words like “wedding photographer”, and the city you work in. When the post is published Google will index this alt text and people searching for wedding photographers in your city are likely to find your images during an image search.

You also add a standard WordPress image gallery to your post, but instead of using a lightbox to make the images “pop” up in the browser you redirect each image thumbnail to the respective attachment page for that image. Then when you add the images in you write a story for each of the images in the Description field.

Now when the visitor clicks on one of the images in the gallery she is taken to the attachment page where she gets to see a larger version of the image along with the added description. And again this description is indexed by Google. That means you can add the names of subjects in the images, detailed descriptions of products, services, locations, or the subject matter, or provide stories to go with each individual image for a truly unique experience. More than a boring image gallery you can create a photo essay – an immersive experience.

Another example of a good way of using these features is to share slides from a presentation. By adding the slides as individual images, adding comprehensive descriptions of each slide in the Description field, and linking your gallery to the attachment page you can provide far more information about your slides to your audience and make that information searchable on the web.

Start Using Your Attachment Details Today!

Now you understand what the attachment details are and how WordPress uses images and their metadata. The next step is to start using these fields actively to provide your visitors with better user experiences and get your content indexed in more places. I wasn’t joking when I said these are the most ignored and underutilized of WordPress’ features, and that also means if you start using them actively and getting the most out of them you will be way ahead of the competition. So what are you waiting for? Go set up proper titles, captions, alt texts, and descriptions for your images and report back!

Tutorials WordPress

Adding Borders to WordPress Images the Right Way – a.k.a. Why Inline Styles Have No Place In Your Posts

As with most updates to popular software the 3.9 release of WordPress has brought with it some controversy. In this case the point of contention is the removal of a little known feature that allowed the user to add borders and margins (vertical and horizontal “space”) to individual images right from within the image editor. The feature was removed and not surprisingly those that used and depended on it are enraged. WP Tavern has a great rundown of the story complete with links to forum posts so I’m not going to rehash it here. Instead I’ll show you how to add borders to images the right way, explain why inline styles are to be avoided whenever possible, and finally provide a suggestion on how theme developers can prevent this type of issue from happening again.

How to Add Borders to Individual Images the Right Way in WordPress

So, when you have an image, you want that image to have a border, and your theme doesn’t apply a border automatically, what do you do? You add some CSS. And that CSS needs to be added separately from the content. In other words no inline styles.

Depending on your level of skill this may or may not seem like a big deal. I’m here to tell you it’s actually super easy. Let’s say you know nothing about HTML or CSS or anything else. Here’s all you have to do:

  1. Install and activate Jetpack (the plugin)
  2. Go to Jetpack, find Custom CSS, and click the Customize button
  3. Create some new style rules

Customize CSS with Jetpack
Let’s say you want to add a black border. Here is the code required:

.border-black {
    border: #000 solid 1px;

Want a gray border instead? Here’s the code for that as well:

.border-gray {
    border: #b9b9b9 solid 1px;

With your new CSS rules in place you are ready to apply them to your image. To do so go to your post, find your image, click the edit button by hovering over that image, and in the edit window click the Advanced Options tab to open the Advanced Options.

Adding new CSS classes to images using the Advanced Image Option

From here all you have to do is enter the class name for your CSS rule (“border-black” for black, “border-gray” for gray) in the Image CSS Class field and save your image.

If you want to add multiple classes you can. Just separate them with a space. Also, remember to not put the dot (punctuation mark) in front of the class names. This is not necessary.

If you look at the image above you’ll see it has a black border. This border was added using the exact method described in this tutorial.

Edit: In the comments Caspar Hübinger points out you can also use the Simple Custom CSS plugin to add CSS to your site without adding all the bulk of Jetpack.


So what have we done here? First we created two new CSS rules that define a 1px border around any element that is either black or gray. Then we use the WordPress editor to apply those styles to our image through a class. And voila! The image has a border.

The key difference between this approach and that of adding the border with an inline style is that we can now quickly change the border on all images at once by editing the custom CSS. And since we used the Custom CSS function in Jetpack the border will persist even if we switch to a different theme.

Jetpack? You must be off your rocker Morten

At this point if you’re a seasoned WordPress pro you’re probably blowing a gasket over my recommendation of Jetpack. “Jetpack is huge and cumbersome and slows the site down and there are a million other better more awesome solutions etc etc etc.” And this is true. I am no fan of Jetpack. However we have to consider the end-user here: If  you are using the add image border function you probably do so because you don’t want to tamper with your theme or child theme. If that’s the case, Jetpack provides an easy way around the problem. Of course if you have the skills and the time you can add the exact same code to your child theme or custom theme you built from scratch, but this is not a workable solution for the majority of WordPress users. Jetpack is.

Inline Styles are Bad, Mmmmmkay?

Some will interject here and say that you can achieve the same thing by using inline styles. After all that’s what the old solution did and what the new Advanced Image Styles plugin does. Here’s some sobering web standards news: Inline styles is a non-starter. To understand why you need to understand how HTML and CSS interact and why inline styles have no place in WordPress content.

There are two main types of code that go together to create a website:

  • HTML
  • CSS

The HTML marks up the content and tells the browser or other reader how different parts of the content relate to each other. The CSS adds a presentational layer to that markup telling the browser or other reader how to display that content. This provides a clear separation between style and content and it works exceptionally well, especially in applications like WordPress where we can switch themes (and with them the CSS) of the content and see a global change in the appearance of the content without having to change the content itself.

Inline styles are an old leftover from the time when CSS was just being introduced and they work counter to the separation I explained earlier. An inline style allows you to place CSS code inside the tag of any element meaning that style only applies to this singular element. That’s what a function like add borders and space does: It puts presentational code inside the markup.

Why is this bad? There are many reasons:

  • The inline style will apply everywhere regardless of where you display the content.
  • The inline style overrides any CSS supplied by a stylesheet and interferes with media queries and other responsive approaches.
  • The inline style applies to one element only and cannot be easily repeated (ie it has to be applied to every single element).
  • The inline style does not allow us to make a global change to the style that applies to all elements at once.
  • The inline style is presentational code placed in the markup. This goes against current web standards and should be avoided.

There are very few cases where inline styles are appropriate. The only one I can think of is where you use PHP to inject a conditional background image into a specific element, but even there we have better ways of approaching the problem. Needless to say inline styles have no place in WordPress, and especially not in adding borders or margins to images.

But what about margins?

I’m sure you’re itching to point out that my proposed solution only addresses borders, not “space” or margins. And you’d be right. Of course you can use the same approach as before to add margins as well but I have serious reservations about this which I’ll explain in a few paragraphs. However, if you must tamper with the margins I’d make sure to add them as separate CSS rules. I’m willing to bet that if you are adding custom margins it is because the positioning of your images out of the box is not ideal. So essentially you are fixing a layout problem in the theme. Chances are you also add different margins depending on the image, but you tend to add the same set of margins over and over. In that case you create a new CSS rule for each of your margin scenarios and apply them as necessary the same way we applied the border.

As an example you could have this margin rule:

.margin-medium {
    margin: 0 1em 2em;

which adds a margin of 0px on top, 1em on left and right, and 2em on the bottom. Then to apply both the black border and the margin you simply enter “border-black margin-medium” in the Image CSS Class section for the image.

Now that you know how to do it I’m going to strongly recommend you don’t mess with the margins. This requires a bit more of an explanation:

The Problem

The problem at hand is not one of deprecated WordPress features nor of bad user behaviour. The cause of the outrage and frustration is that theme developers are not accounting for the user scenario where the user wants to add a border. When there is no option the user will find a new way of doing it outside of the theme and this is not ideal for anyone.

There are many reasons why you’d want to add a border. The most obvious one is if your image background color matches the color of your theme so there is no clear separation between the image and the main background. I’ve encountered this many times and this is why my themes ship with custom CSS to address this particular issue. More on that in a bit. Let’s first take a look at what happens when you add images to a post or page in WordPress:

When you add an image to a post or page in WordPress you also add some CSS classes to that image. The classes vary depending on the image size and alignment and other factors. A good theme has CSS rules that apply  to these classes and provide proper margin and padding for all images. And this is why messing with the margins is a bad idea:

In a good theme the designer and developer has made decisions about how an image is to be presented in relation to other content based on its size and alignment. That means margin has been added where required and removed where it shouldn’t be. If you go in and start adding or subtracting margins you are interfering with what the theme does out of the box and this can lead to crazy behaviour, especially when you switch to a new theme.

Here’s the thing: If your images jam up against text or other elements in your theme it is either the explicit decision of the theme developer that they do so or more likely the theme is not all it’s cracked up to be. Yep, I said it: If your images look wrong in context, your theme is likely not worth its salt and you should look for another one.

The Solution: A Unified Border Class Name Standard

There is an obvious solution to this issue that will allow users to do what they want (add borders to images) while ensuring cross-theme compatibility while avoiding the addition of plugin functionality like Jetpack Custom CSS or plugins that add inline styles: Create a unified border class name standard.

All theme developers should add a set of CSS rules targeting a pre-defined list of border classes the user can call when required. The list could look something like this:

.border-thin-black {
    border: #000 1px solid;

.border-medium-black {
    border: #000 3px solid;

.border-thick-black {
    border: #000 5px solid;

.border-thin-gray {
    border: #b9b9b9 1px solid;

.border-medium-gray {
    border: #b9b9b9 3px solid;

.border-thick-gray {
    border: #b9b9b9 5px solid;

In addition theme developers could make rules whose colors are set through the customizer with class names like .border-thin-custom. That way custom colors can be introduced as the user switches themes while the predefined colors stay intact.

Let your voice be heard

I know you have opinions on this. Don’t internalize your strife. Voice your thoughts, concerns, and opinions in the comments below and start a conversation.


The DDoS and the Damage Done

With this notification we would like to inform you that our in-house Website Performance Monitoring System (WPMS) has signaled that your account constantly uses a large amount of the server’s CPU resources. These excessive requests consume an abnormally high amount of CPU resources and endanger the overall performance of the server. Your account consume more then 55703.75 CPU seconds and 102195.00 CPU executions for the last 24 hours. (…) Unfortunately, your website’s server resource usage is not suitable for this server and that is why we will no longer be able to host it there.

This is the message that waited for me in my inbox when I woke up last Thursday morning (grammar errors and typos included). A quick visit to confirmed my panic: The site was down, replaced by a 503 error. Logging into my site admin panel I discovered the hosting provider had locked down my site banning access to any incoming visitors. And for good reason. A quick inspection of the resource logs showed something dramatic had happened during the night. Here are screenshots of the weekly stats and the execution log for the preceding 24 hours:

Weekly stats graph showing dramatic increase in activity
Weekly stats graph showing dramatic increase in activity
Executions log graph showing dramatic jumps in activity
Execution log shows extreme variance in activity caused by the server dropping in and out of service

Thus began what would become a 16 hour battle with arrogant and ignorant tech support “specialists”.

My Opinion WordPress

Why Post Formats Should Be Plugin Territory

Post Formats is arguably the most poorly defined and confusing feature of WordPress core both for developers and users. Post Format behaviour is inconsistent across themes and the guidelines for the feature are ambiguous at best. When the core developer team started work on a proposed Post Formats UI around this time last year they unwittingly went down a path that eventually led to a lengthy delay of WordPress 3.6 and the restructuring of how core features for WordPress are developed.

Currently Post Formats themselves remain as a core feature and there is sporadic talk of restarting work on the Post Formats UI. I question it’s valid claim as a core feature and propose a radical shift and a rethink: Redefine post formats and their function, draw up strict guidelines, and move the entire feature into a plugin.

The Post Formats Inception

From the original introduction in version 3.1 it was pretty clear Post Formats is a blogger-first feature introduced in large part to compete with Tumblr. WPTavern has a great write-up if you want further info on its background. The general idea was that a blogger should be able to easily publish a quote, a link, a picture, a video, and so on without having to go through the trouble of assigning categories and tags and structuring her content. And this makes sense if you are Automattic and you fear Tumblr may be a serious competitor to It may even make sense if you consider WordPress to be primarily a blogging application. But WordPress is not a blogging application – it’s a light weight CMS. And a large portion of WordPress users are not bloggers.

This begs a question: Should a bloggers-only feature be a core feature in WordPress?

A lack of definition

If you’ve ever used Post Formats you will know that pt what it means to apply a format to a post is largely unclear and entirely at the whim of the theme developer. This is exemplified in how different Post Formats work in the default Twenty Thirteen and Twenty Fourteen themes. This inconsistency can be traced back to the lack of a clear definition of what a certain Post Format is or should be. The breakdown of Supported Formats and Suggested Styling in the Codex article for Post Formats provides some general guidelines but the language is non-committal and ambiguous leaving ample room for interpretation. Take the Image definition as an example:

image – A single image. The first <img /> tag in the post could be considered the image. Alternatively, if the post consists only of a URL, that will be the image URL and the title of the post (post_title) will be the title attribute for the image.

This example outlines three wildly different user scenarios, all of which are more or less mutually exclusive:

  1. An image post should have one image, and one image only.
  2. An image post should have one or more images where the first image is considered the image.
  3. An image post should have one URL pointing to an image and the theme will wrap this URL in an <img /> tag and use the post title as the title attribute.

There are also many unanswered questions: Can an Image post have text content? Should the more tag be used? What content should be displayed in index pages and in the single post template?

But the biggest issue is what this ambiguity does to consistency:  If you use a theme that employs interpretation 3 and then switch to one that employs interpretation 2 or 1 you will have to reformat your content or end up with a sub-optimal user experience for the visitor (in this case providing an unlinked URL in place of an image). The same goes for other combinations, and this extends to all the different Post Formats.

From a design and development perspective this may seem like an attractive lazzis-faire approach, but for the user it is a setup for chaos. When the designer and developer are left to interpret the Post Formats as they please the end result is that the user cannot expect consistent behavior across themes when using the feature. Which is an excellent reason not to use the feature at all.

Interestingly this is not far from the reasoning Justin Tadlock uses for keeping Custom Post Types out of distributed themes: When the user can’t expect consistent behavior between themes, the feature should be a plugin that be applied independently of themes. I argue this is the case for Post Formats as well.

A solution looking for a problem

As I stated earlier the inception of Post Formats seems to have been a desire to make it easy to post single images, single videos, and other simple content to a WordPress blog. From my experience interacting with WordPress users of all skill levels this is not a typical usage scenario. While many use WordPress primarily as a blogging tool, few post the types of content that Post Formats seem to be intended for: Single images, videos, and audio clips with no text, single quotes, chat logs, links, and so on. The only justified and consistent use of Post Formats I’ve seen anywhere is on Matt Mullenweg’s own blog where he frequently posts Asides. In most other cases the format seems relatively irrelevant and the display goal could just as easily be met with standard layout techniques.

Furthermore Post Formats have no purpose for those using WordPress as a CMS. In fact, the proposed Post Formats UI with it’s ambiguous interface would be a major distraction and cause of confusion to many of these users. As for the type of content intended for Post Formats there are important SEO and RSS issues and questions of whether mass-posting of small pieces of content has merit.

One could argue the infrequent use of Post Formats is due to the lack of theme support and the feature being hidden away, but the whole concept of “QuickPressing” seems foreign and even detrimental to what I’ve observed as the typical user behavior. It may well be that the front-end editor in generates a lot of this type of posts and that Post Formats should be a primary feature on that service, but I have my doubts that a Post Formats UI will change the core behavior of self-hosted WordPress users in a significant enough way to justify its wholesale inclusion.

A Way Forward, as a Plugin

I propose a rethink of the concept of Post Formats and a removal of the feature from core and into a plugin. As it stands right now Post Formats is essentially a locked taxonomy developers can test against in conditional statements. There is no clear definition of exactly how the formats should behave, the user has no clear explanation of how she should use them, and there is a question begging to be asked about whether the feature is something the general WordPress user wants or needs in the first place.

To start the process a usage scenario has to be clearly defined and stated. That means answering four key questions:

  1. Who is the Post Formats user?
  2. In what scenario is using a Post Format better than a regular post?
  3. What does she expect from Post Formats in terms of new content and different display modes?
  4. When and where would she use Post Formats (From WordPress admin? As a browser bookmarklet? In an app?)

Based on the answers to these questions the goals and intentions of the user can be defined and the feature can be built to meet them.

To ensure ease of use and an informative user experience the Post Formats plugin will likely add a new panel to the post editor UI not unlike the proposed Post Formats UI. The panel should have clear instructions explaining the difference between Post Formats and the regular editor and when a Post Format is selected the UI should change to accommodate the information required for that format. This might mean adding new input fields for dedicated content or hiding existing fields in the editor or a combination of both. That way the ambiguity in the existing solution is eliminated, the user is provided with clear instructions about what to do, and the correct type of content is provided to be displayed on the front end.

On the development side baseline output behavior must be established to ensure the output from the Post Formats plugin is integrated into the output of the regular post content in such a way that the intention of each Post Format is preserved. This likely means placing any Post Formats meta content at the top of the post and pushing the regular post content down. It may also mean wrapping Post Formats meta with hooks so the content can be displayed separately from the main content in index pages and widgetized areas. If a theme developer chooses to create custom templates for the Post Formats plugin, the behavior of those templates must stay within the parameters of the guidelines. If the developer chooses not to ship custom templates the visitor should still have an enhanced experience in line with the intentions of the site owner.

By removing Post Formats from core and placing them in a plugin, establishing clearly defined usage scenarios and goals, and providing strict guidelines for theme implementation, the feature will turn into an optional enhancement for those that want it rather than a confusing and frustrating addition to an already complex admin panel experience. It will also allow the feature to evolve and change to fit the demands of the user in a way a core feature never could.

A lot of impressive work has gone into this feature and Post Formats has merit as part of the WordPress ecosystem, but the way it is currently implemented is not beneficial to theme developers, users, or those who visit their sites.

That is my opinion. I’d love to hear yours in the comments below.

More perspective on Post Formats

Much has been published on this topic. Here is an incomplete list for further reading:

Events WordPress

Empowering Women’s Voices in WordPress

WordPress Women

Let’s face facts: While the WordPress community is comprised of at least 50% women and attendance at WordCamps and WordPress Meetups is generally equally balanced, women are underrepresented as speakers and presenters. This is not unique for the WordPress community. The underrepresentation of women in leadership positions is a systemic problem in the tech sector and in society as a whole. What we as a community need to figure out is how to fast-track the process of equalization to make the people who represent us better represent the composition of our community. And that all starts with encouraging more women to stand up and be heard from the speaker podium.

Women Talking WordPress | A Workshop on Speaking at Meetups

Women Talking WordPress | A Workshop on Speaking at Meetups

Saturday, Mar 1, 2014, 1:00 PM

The Network Hub
422 Richards Street Vancouver, BC

20 WordPress Enthusiasts Went

Women Talking WordPress is a workshop for women who are thinking about speaking at WordPress events, such as WordPress Meetup and WordCamp. The focus of the workshop will be to help generate topics to give a talk on, boost your speaking confidence, and allow you to practice speaking in a safe space. At the end of the workshop you will have a few id…

Check out this Meetup →

In November of last year, before all the hoopla in the community took off, Vancouver WordPress developer and WordCamp organizer Jill Binder reached out to Vanessa Chu and I suggesting that the Vancouver WordPress Meetup Group organize a speaker workshop for Women. Like most event organizers Jill discovered that getting a representative number of women speakers at WordCamp Vancouver was surprisingly hard and she wanted to start workshops to get more women on the rosters of future events. This fitted in nicely with plans Vanessa and I were working on for more women speakers at the Meetup and so the work began.

After some initial discussions Jill, Vanessa, and Kate Moore got together and planned out the first of what will hopefully be a series of Speaker Workshops for WordPress women right here in Vancouver.

Women Talking WordPress | A Workshop on Speaking at Meetups is an all-women workshop with the goal to help the participants brainstorm ideas, create quality content, discuss the challenges and rewards of public speaking, and get valuable real-life experience talking in front of a crowd. If all goes as planned this workshop and others like it should foster a new group of women speakers ready for the podium and provide new role models for aspiring women speakers in our community and beyond.

The three hour workshop takes place at The Network Hub in downtown Vancouver on Saturday March 1st from 1pm to 4pm. The cost of attendance is $5 and the only requirement for attendance is that you identify as a woman and want to boost your public speaking skills. If that’s you, go sign up now and get empowered!

My Opinion WordPress

Will Flat-File Dethrone WordPress? Unlikely.

WordPress is out. Flat-file is the new wine. Or so the developer literati claim. I beg to differ. I also think these claims are an indicator of a serious problem with the open source industry: The people who develop Open Source applications are disconnected from the people who use their applications.

Flat-file vs WordPress: A 1 minute primer

If you’ve never heard of a flat-file before let me give you a quick primer: A flat-file is different from a “normal” CMS (like WordPress) in that it doesn’t use a database to dynamically generate pages. Instead it’s a hybrid model using JavaScript and other clever techniques to serve up individual or combinations of static files or pull content from content repository files (basically a spreadsheet or text file). The key here is flat-file solutions don’t need a database and usually don’t need PHP. (The historically savvy reader will now realize that flat-file CMSes are essentially static DWTs reinvented. That would be correct.)

There are some definite benefits to a flat-file (or what we old fogies call “static sites”) approach: You don’t have to rely on a complex server array for the site to work so your site won’t buckle under the sudden load of thousands of visitors, each page is an individual file so it will (at least in theory) load quicker, and you don’t have to deal with complex server management.

There are many flat-file solutions available and more coming online every day. This is after all the new wine for developers and everyone wants a taste. You have your CMS-style options like Ghost (originally proposed as a “simplified WordPress experience”), KirbyStatamic, and Jekyll – all of which have been lauded as “WordPress Killers“, and you have your externally hosted solutions like Harp (which uses DropBox as the file repository) and even DIY solutions that allow you to use Google Drive as the file repository. And you have services like GitHub Pages which let you use advanced developer tools to publish basic static websites.

And yes, I am aware there are a wide range of options here, that I omitted your favorite solution, and that my explanation is oversimplified. 

Ghost Face Killer?

When Ghost was proposed and then launched it was to much fanfare and celebration. Bold predictions were made of the imminent demise of WordPress due to Ghost’s simplified user experience and obvious appeal to bloggers. It’s safe to say these predictions did not correspond with reality. Why? Because setting up Ghost is not easy. In fact it’s quite complicated and requires a high level of expertise. Same with most if not all the other self-hosted flat-file CMSes. They may have a simplified file structure and user experience, but if people can’t figure out how to make them work, they won’t use them.

To curb this problem Ghost has launched a hosted for-pay service (though my theory is this was the plan all along) where you simply set up and pay for an account and start blogging. Which is no different from what, or Medium, or countless other hosted blogging services are already doing. So when flat-file becomes a hosted service the differentiation disappears.

“Kill your databases” they said. “It’ll be fun” they said…

One of the prime arguments for using flat-file is that you don’t need a database for most sites. It goes something like this:

“For a marketing site with 5 to 8 pages a database is just bloat. You’re better off just writing the code yourself.”

This is true in some cases, and if you are writing the code yourself you don’t need a flat-file solution either! However most sites today are not (or should not be) 5 to 8 pages even if they are marketing sites.

More than anything else the value of the web lies in the limitless potential for publishing. You don’t have to restrict yourself to a set number of pages or articles or images. You can publish as much as you want. And you should. The more quality content you publish, the more likelihood it will be seen, shared, and acted on. So when I see someone talking about a 5 to 8 page marketing site and the lack of need for a database my first question is “what about the attached blog?” There are very few cases I can think of where adding a blog with constant updates to a site would be a bad idea. In most cases adding such a blog can be a tremendous benefit to search and share traffic and the blog can even become the primary marketing tool. And once you have a blog and comments and other things you are moving into database territory. Sure you can use a flat-file CMS for this but it’s not really a good idea.

The Reality Distortion Field

I believe the emergence of the flat-file CMS has less to do with a consumer need than a developer desire to create something new and dethrone the current King of the Open Source Hill. While the argument for these solutions is that proper CMSes like WordPress are too big and too bloated for most users the alternatives they offer are more complex and don’t address the main appeal of WordPress:

What makes WordPress so popular, and the reason a lot of developers hate it so much, is that anyone can do it. You don’t need to understand Git or Markdown or Node.js or even PHP or MySQL to set up, configure, and publish content with your own self-hosted WordPress site. A complete novice with limited web browsing experience and a credit card can get a shared hosting account and publish content on a shiny new WordPress site within half an hour.

WordPress is a tool for everyone.

The flat-CMS tools touted so aggressively by developers on the other hand are developer tools built for developers by developers. Don’t believe me? Pick a random person off the street and ask them when was the last time they did a Git commit or wrote something in Markdown. The real world user of WordPress is not a developer. The real world user is someone wanting to share their thoughts, ideas, images, or art with the world in a simple and easy way.

When a flat-file solution uses Git commits or Markdown or “write your own HTML” as a marketing tactic you know all you have to know: This is not for the people, it’s for the developers who built it.

Rumors of WordPress’ demise are greatly exaggerated

WordPress is not dead or even on the decline. And flat-file solutions are not a threat to its position at the top of the Open Source Hill. The real threat to WordPress is actually WordPress itself, and this is something I’ll write more about in the future. While the flat-filers are wrong in their claim that flat-file is easier or better than WordPress, they are right in that WordPress is getting too complex and too heavy. For WordPress to continue its growth and eventual takeover of the entire published web it needs to slim down and become more modular so it can address the needs of an ever more diversifying user base. And those who build their businesses and reputation on WordPress need to realize kindergarten is over. We are not just playing at this any more. Serious business relies on WordPress and WordPress is serious business.

I would love to hear your thoughts on this topic. Are you running a flat-file solution? Have you abandoned WordPress for something slimmer? Leave a comment and pipe in.



Adding icon fonts to WordPress menus

Header menu of with font icon
Several people have asked me how I added the plane icon seen in the image above to the main menu of Here is a quick breakdown of my method so you can try this for yourself and add some font icon power to your WordPress menus.

Font icons are becoming all the rage for web designers and developers, and with good reason. They allow us to add scaleable vector-based icons to our sites with ease which in turn produce crisp and clear graphics on any screen at any size with minimal effort. And because these icons are fonts you can style their color, shape, and alignment the same way you style your regular text.

Step 1: Get your font icons

First you need some font icons to add to your site. There are several libraries available including the enormous Font Awesome and the more simplistic Genericons. And if you want to create your own custom icons you can use a service like IcoMoon or even roll your own.

A font icon kit consists of a set of common components: The fonts themselves, usually served up in TTF, OTF, and SVG flavors for cross-browser support, and a stylesheet with @font-face rule sets defining when and how the font will be used.

Technically the only thing you need to do to make a font icon kit active on your site is to call its stylesheet, but how exactly this happens depends on your chosen kit. Some like FontAwesome provide a cloud hosted service. Others require you to download the font kit and add it to your theme. In this example I’ll use FontAwesome and the BootStrapCDN option as outlined in the documentation.

To make the icon font active on the site we’ll enqueue it from functions.php in your theme or child theme:

 * Enqueue Font Icon Stylesheet
function yourthemename_iconfonts() {
	wp_enqueue_style( 'FontAwesome', '//' );
add_action( 'wp_enqueue_scripts', 'yourthemename_iconfonts' );

This injects the necessary style sheet code into your header file dynamically. The reason you want to enqueue the styles rather than just add them to your header.php file is that you may want to prevent the style from loading on certain pages and this can be done with simple conditional statements within the function above.

Step 2: Trigger an Icon using a style

The creators of these font icon kits have gone out of their way to make adding font icons as easy as possible. This includes providing you with a long list of different methods for adding the icons themselves. In most cases these methods are based on the simple principle of using a class to add a :before pseudo element that has a content declaration with the specific symbol that identifies the icon. If you’re not familiar with CSS that probably sounds like complete gibberish so here is an example of how FontAwesome declares the Twitter icon:

.fa {
	display: inline-block;
	font-family: FontAwesome;
	font-style: normal;
	font-weight: normal;
	line-height: 1;
	-webkit-font-smoothing: antialiased;
	-moz-osx-font-smoothing: grayscale;

.fa-twitter:before {
	content: "f099";

As you can see the .fa rule defines the FontAwesome font family and how any icon from this family will be presented and the .fa-twitter:before rule specifies the icon to be used. The genius of this method is the use of the :before pseudo class and the content declaration. This ensures that when a text-only browser accesses the content or the font doesn’t work, you won’t end up with some bizarre icon in its place. It’s not part of the content itself but instead added as a decorative element only.

Knowing this it should be clear how you trigger the icon: Simply add .fa and .fa-twitter to whatever element you want the icon to appear in front of and it happens automatically.

Adding CSS classes to WordPress menus

This process is easy in WordPress: Go to Appearance -> Menus, clicking on Screen Options in the top right corner, activating the CSS styles option, and adding the classes to the CSS Styles area for the menu item in question.

This adds the icon inline in front of the menu text in question. It also means the icon will not inherit the styling of the menu item (color, hover states, etc) and you may have to add extra styling to make it look like you want it to look in your regular stylesheet.

An alternative method

Adding HTML to a WordPress menu itemIf you want to add the icon as part of your menu item meaning it is styled and reacts the same as the menu text you can do so using a little known trick: You see the Navigation Label filed in WordPress menus accepts HTML. This means you can add the trigger code for the font icon right into the Navigation Label like this:

This places the icon inside the anchor tag and it becomes part of the active area of the link. Once the icon is added you will have to add some extra styling to your stylesheet to prevent it from jamming up against the text. In my example I added the icon to the right of the text so my custom style rule looks like this:

#access .fa {
	padding: 0 0 0 5px;

Your turn

Now that you know how it’s done it’s your turn to try it out on your own site. Like I said font icons are extremely powerful and can be used for all sorts of interesting things. Adding them as inline items in your menus is just one of an infinite number of possibilities. FontAwesome has a long list of examples of different inclusion methods and techniques for adding font icons into your site and more options are thought up every day. Once you see what is possible and realize the power and potential of this technique I’m sure you’ll get addicted. So go try this out for yourself, see how font icons can add some power to your own site, and tell me about the experience in the comments below!


Twitter oEmbeds broken – A Case for Bug Notifications in WordPress

If you’re using the oEmbed feature in WordPress to display Twitter updates in your posts or pages you may have noticed those nice looking Twitter bubbles have been replaced with a non-functioning link to the Twitter update in the last few days. This is not because your WordPress site is broken but because Twitter changed their API about a week ago thus breaking the feature in every WordPress site worldwide. The core development team has already fixed the problem and the fix was rolled out in the 3.8.1 update which should be hitting your site in an auto update shortly.

What you don’t know can hurt you

Chances are you were not aware of this problem, or if you knew of the problem you did not know the cause. Looking at Twitter and other social media (and my own inbox) it is clear most people automatically attribute Twitter oEmbed not working in their WordPress install to a problem either with WordPress itself or with a theme or plugin. Thus they spend hours trying to sort it out.

This is not the first time a core feature of WordPress has broken due to an external service changing, and it will not be the last. And that’s to be expected. What is not expected from a user perspective is the complete silence from WordPress (core team, people in charge, whatever you want to call it) itself about the issue. And this is one of those unfortunate things that sets open source apart from commercial software:

When something goes wrong there is very little chance you’ll be notified or get an explanation.

This phenomenon is historically valid – Open Source used to be something only a small group of highly motivated people dabbled in – and can be explained by the flat structure free-for-all nature of Open Source in general, but that isn’t an excuse any more. Open Source, and in particular WordPress, is now ubiquitous and most of the users are not highly motivated and prone to dig into the code or search Trac any time something goes wrong.

A Case for Bug Notifications in WordPress

What’s needed is a system through which users are notified when a systemic problem arises. There is already several systems in place that can be used – the update notification bar in admin, and the WordPress News widget on the Dashboard are ideal candidates – but it could also be built as a new feature. This feature should provide up-to-date information about known destructive or feature bugs like Twitter oEmbed not working or the ability to add header images from the Customizer being removed and relevant links with further information and any bug fixes on the books.

For this to work two things have to happen: The system needs to be implemented, and someone needs to be tasked with providing these updates.

A simple update like this would go a long way in reducing frustration and building trust with everyone using WordPress.



Building a WordPress Business WordPress

The Value of Time – How to Charge What You’re Worth

Last night I posed a question to my followers on several social media networks. It went something like this:

If I were to pay you to stand still and alone and do nothing for an hour, how much would you charge?

The responses varied from $40 to $800 but the majority landed at or around the $100 mark.

The purpose of the question was to find out what people think their personal time is worth when there are no other factors involved such as enjoyment, value, communication, relaxation, or learning. My theory, bolstered by this completely unscientific study, is that people value their time greatly but are willing to undercut themselves in the extreme when it comes to work. This is especially true for freelancers.

What should I charge per hour?

One of the first and most difficult questions facing a freelancer is how much to charge per hour. In most cases new freelancers come from previous employment in companies and the only gauge they have for hourly pay is their salary. Because of this and their general devaluation of the worth of their own time they tend to set the bar much too low and charge hourly rates that are unsustainable and irresponsible.

To guide you away from this pitfall and spark a discussion about what fair pay is for freelancers in web design and development and in particular WordPress let me present a model for calculating your hourly rate. Keep in mind this is not the only one and there are many people who have published content about this (check out the excellent course Running a Design Business: Pricing and Estimating at and Curtis McHale’s aptly titled book Don’t Be an Idiot for starters).

For the purpose of this article I define a ‘freelancer’ as a person working in web design and or development focussing on WordPress and/or Open Source with several years experience and education in the field. She runs her own business out of her home or a rented office space and is responsible for all business related activities including invoicing, contracts, accounting, hardware and software costs, and general office overhead.

Step 1: Set a base rate for your time

The process starts with finding a base rate for your time. This is where the question I asked above comes in: How much is your personal time worth to you in cash? If you could sell it to someone in hourly units, what would you charge? It is important that you set this rate based on your personal time (spending time with family, reading a book, watching your favourite show, doing your hobby) because if you think of it as work you will automatically devalue your time. More on that later.

Based on my unscientific query it appears the people in my social media circles value their time at approximately $100/hour. That seems to be a reasonable estimate.

Step 2: Set a value to your expertise

Next  you need to set a monetary value to your expertise. This can be done by asking a question:

Compared to a novice with zero experience, how much more is your hour worth?

This returns a dollar value. How exactly you reach that figure is up to you. Some say you should charge $5 per year of experience, some say you should charge $10 per year of school, some say you should charge on a scale from $0 (novice) to $100 or even $1000 (the best of the best). For the purposes of this article we can say you charge $5 per year of experience so with 4 years experience your expertise is worth an additional $20.

Step 3: Set a value to your speed and effectiveness

The more skilled you are, the faster you’ll work compared to your competition. This also means the more skilled you are, the fewer hours will be logged and the project will be completed quicker. Both of these elements need to be factored in to your hourly rate.

Start by asking a question:

Compared to your closest competition, how much faster do you work?

This returns a percentage. If you are 20% more efficient you’ll work 20% faster meaning you’ll log 20% fewer hours and will wrap up 20% sooner. This should at minimum be evened out and in most cases be charged as a premium (you work faster and that is more valuable). I think the premium on more effective work should be at least 20% giving us the following formula:

Your speed (%) x 1.2 (20%) = Speed Value (%)

So if you work 20% faster you’ll charge an additional 24%.

Step 4: Set a discount

The last step is optional and should be applied with great care: If you are just starting out as a freelancer or want to break into a new market you can opt to set a discount to your fees. This is tricky territory and needs to be done in a systematic way to avoid problems down the road.

The discount you set for yourself is governed by several factors including how much you can afford to cut your own rates, whether discounting your rates will devalue your services in the eyes of the customer, and whether discounting your services will undercut the competition and devalue the market as a whole.

This last point is important and you can see the real life implications of wholesale discounting in many creative fields including photography services and WordPress consulting: New actors have been using price as a competitive factor for too long and have driven the overall price down to the point that the general public have a false impression of the true cost involved in these services.

If you feel you need to set a discount for your hourly rate, you also need to set a firm plan for how to phase the discount out over time. Otherwise your discounted rate ends up being your permanent hourly rate.

A real life example

Let’s put this into practice with a real life example: Maiken (not her real name) is a seasoned designer and developer with 4 years experience building custom WordPress sites in an agency. Now she is breaking out on her own and needs to set an hourly rate for herself.

She starts out by setting her own base rate at $120 (she really likes to spend time outdoors and this takes more time than just watching TV or reading a book so she values her time higher than the norm). She has 4 years of experience and decides that’s worth an extra $20/hour. Because she is an extremely efficient coder she estimates her speed to be about 35% higher than her peers for a total Speed Value of 42%.

Putting it all together Maiken’s hourly rate calculation looks like this:

(120 + 20) x 1.42 = $198.8/hour

Justification for charging what you’re worth

At this point I’m pretty sure you’re thinking “$198.8 per hour? You’ve lost your mind Morten!” If you ask around you’ll find very few freelance web designers and developers who charge an hourly rate in this range, especially in the WordPress field. In fact you’ll find very few who charge an hourly rate over the $100 mark. That is alarming and indicative of a disconnect between what the work is worth and what the people who do the work think it’s worth. What’s needed here is a generous serving of perspective:

Freelancing is a business

Freelancers often think that because they are freelancers they should charge less than a full scale business. This is just plain wrong. A freelancer has the same expenses that a business does, just on a smaller scale. The fallacy happens because you don’t consider many of your expenses real expenses: If you work for a business you just do your job. If you work as a freelancer you do your job and you also do invoicing and accounting, procurement, licensing, legal contracts, HR management, maintenance, and cover overhead. You may outsource some of this to a 3rd party, be it an online service like Harvest for invoicing or Redbooth for project management, or by hiring a real accountant for your year-end taxes, but most of these costs are invisible to you – especially if you work from your home office.

To get a clear picture of what running your freelance business actually costs per month you need to do the math:

  • Hardware (computers, peripherals, bags, etc)
  • Software including licenses
  • Office expenses (printer ink, paper, notebooks, pens, etc)
  • 3rd party expenses (taxes, legal, medical, dental)
  • Office overhead (power, heat, maintenance)
  • Office rental (what would it cost you to rent an equivalent office in an office building?)

You’ll find that these costs easily run over $1200/month and usually a lot more. So if you are charging $20/hour you need to bill a minimum of 60 hours per month just to break even. That may not sound like much but ask any freelancer and they’ll tell you getting 60 hours of billable hours in a month is a real challenge.

And this doesn’t include all the other elements of your job like advertising, chasing leads, website maintenance, client pitches, meetings, project management, the list is endless. In a typical company all these things are handled by people. As a freelancer you do all these jobs and they all eat away at your available billable hours.

Freelancing and salary work are two different animals

When I meet people who charge $20, $40, or $60/hour for freelance work I always ask them how they came to that number. The answer is usually “that’s what I would get paid in a real job”. Based on what I just told  you it should be pretty obvious why this is just plain wrong. While you might get paid $25/hour in your “real job”, the company probably charges the client upwards of $250/hour for the work you do. That money is divvied up into business expenses, salaries for other employees in peripheral jobs, and profit for the owners. As a freelancer you need to do the same thing.

You are not a salary worker: You are a business owner. So charge what you’re worth.

People will pay what you’re worth

“But Morten, if I charge over $100/hour I won’t get any business!” you say. That simply is not true. You might not get the business of people looking to have a $600 website built, but you will get the business of people who actually know what a website costs. Charging more will more often than not increase your business and your success. And it also means you can take on larger and more time consuming projects and not have to worry about always landing new contracts. Charging more allows you to go after bigger fish. And think about it: Call a plumber to your house and she’ll charge you at least $150/hour plus travel time and materials. Why do you think your ability to build that plumber a website is any less valuable?

Let the games begin

The issue of charging what your worth is a hotly contested one and my approach is an extreme one. There are as many opinions on this as there are business owners and all those opinions can and should be heard. So I invite you to join the conversation in the comments below or in your own blog. If you do write an article of your own, let me know and I’ll link to it right here.

To wrap up I’ll give the final word to Grant Landram who responded to my query on Twitter last night with this observation:

Categories WordPress

WordPress Essential Training – fully updated course on

Learn WordPress with WordPress Essential Training with Morten Rand-Hendriksen from

Hot on the heels of the Start with a Theme: Twenty Fourteen course comes the release of the second course I recorded over the Christmas holiday: The full update of WordPress Essential Training for version 3.8.

My first ever course with was WordPress Essential Training back in 2010, and this new edition is the third remake of the course. The new course highlights new features in WordPress 3.8 and provides an updated approach to learning and mastering WordPress. If you want to learn how to use WordPress to its fullest, WordPress Essential Training is the place to start.

From the website:

WordPress powers millions of blogs and websites. Learn how to create your own with this powerful publishing platform. Staff author Morten Rand-Hendriksen will help you get the most out of the self-hosted version of WordPress and create feature-rich blogs and websites. Morten explains how to create and publish posts and pages; customize your site with themes, widgets, and custom menus; and extend WordPress even further with plugins. What’s more, Morten will show how to get more readers with social media sharing and comments, and adjust the settings that keep your site safe and secure.”

Topics covered include:

  • What is WordPress?
  • Installing and running WordPress
  • Publishing posts and pages
  • Using page templates
  • Inserting images, video, and other media
  • Editing posts
  • Changing themes
  • Installing plugins
  • Adding other users
  • Securing your WordPress site

Whether you’re new to WordPress or just want a refresher or  you want to get a clear picture of the changes found in version 3.8 you will find what you are looking for in this course. So go check out WordPress Essential Training and get your WordPress site started for the new year!

If you don’t already have a subscription you can get a 7 day free trial by following this link:


Categories WordPress

Start with a Theme: Twenty Fourteen – new course on

Learn how to use the Twenty Fourteen theme for WordPress in this course by Morten Rand-Hendriksen

Get the most out of the new Twenty Fourteen magazine-style theme that ships with WordPress 3.8 with my new course Start with a Theme: Twenty Fourteen. This new theme has a lot to offer if you know how to use it properly, and in the course I take you through all the features, functions, and weird side effects of using this theme.

From the site:

“All great WordPress sites start with a great theme. Twenty Fourteen is the default: a new, magazine-style theme with a heavy focus on images and content. In this quick course, Morten-Rand Hendriksen walks through the setup and configuration of Twenty Fourteen, and then helps you get the most out of advanced options such as the featured content grid or slider, custom menus and sidebars, and featured images.

If you’ve updated to WordPress 3.8 you have Twenty Fourteen installed already and it’s worth a good look. So go check out Start with a Theme: Twenty Fourteen and get your WordPress site started for the new year!

If you don’t already have a subscription you can get a 7 day free trial by following this link:


WordPress 3.8 post roundup

WordPress version 3.8 released Thursday December 12th at 9:35am PST and with it a series of articles written by yours truly went live all across the web. For the release we ( teamed up with a series of WordPress related blogs to get information out to a wide as audience as possible on what’s new in the update and why you should update right now. To avoid repetition each of the articles is unique and covers a different topic. I also jumped into the booth and recorded a First Look video showcasing the updates. That’s the video you see at the top of the article.

Here’s a roundup of the articles. Jump through the links to read the full texts:

WordPress 3.8 – What’s New and Why It Matters (

This week’s release of WordPress 3.8 named “Parker” after jazz legend Charlie Parker shows that the platform (and its developers) take this responsibility seriously and aim to further simplify web publishing for everyone. You can download it right now from or upgrade your existing WordPress site directly from the dashboard. 

Click here to read the whole article.

WordPress 3.8 Is Here With A Sleek New Theme Experience (Elegant Themes Blog)

Alongside the rest of the WordPress admin UI, the theme experience – or wardrobe if you like – has undergone a complete overhaul in the 3.8 release of WordPress, and the new design and functionality makes theme management and customization easier than ever before.

Click here to read the whole article.

WordPress 3.8: A quiet revolution ( blog)

Today’s release of WordPress 3.8 is revolutionary in the history of WordPress—and a clear sign of things to come from the popular content management system. Sporting a clean new interface, tons of new features, and a new development philosophy, the 3.8 release is a milestone for the WordPress community in many ways. We’re already hard at work updating our WordPress Essential Training course to reflect WordPress 3.8, but there’s a lot to notice in today’s release beyond just what ships in the code.

Click here to read the whole article.

What do you think?

Now it’s your turn. Have you updated to WordPress 3.8 yet? If so, what do you think of the new admin UI? And if you haven’t, what is standing in your way? I’d also love to hear your thoughts on the new Twenty Fourteen theme. Will you be using it? What do you think of a magazine style theme as a default theme? Leave your thoughts in the comments below.