WordPress, the Unknown User, and the Need for Research

We are constantly asked “when will X feature be built” or “why isn’t X plugin integrated into the core”. The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use.

This definition of the 80/20 principle is the guiding philosophy behind WordPress core development. Build solutions that benefit 80% of the users, and allow the remaining 20% find good extensions (through plugins and themes) that solve their use cases. It’s a great philosophy, and the 80/20 rule is used in pretty much every discussion about WordPress features. There’s only one problem:

We know nothing about the 80%. In fact, we know nothing about the 99%. And that’s a problem.

The 1% of the 1%

WordPress is developed by a large group of dedicated volunteers that spend a large part of their daily lives working to maintain and improve the most popular publishing application on the web. And their tireless work has lead not only to the growth and dominance of WordPress on the web, but to web publishing, and web design and development, being democratized and made accessible to the masses.

In its success, WordPress now reaches far beyond the borders of the WordPress “community”, defined as those who contribute to or at least follow WordPress development and discussions on a regular basis. And it is in this “outside” group we find the average WordPress user – the 80%. These are the people who build millions of WordPress sites that never touch the community: They don’t go to WordCamps, they don’t read WP Tavern or PostStatus, they don’t know about the local Meetup, and they probably don’t know that WordPress and are two very different things.

It is these people – the majority user of WordPress – the application should be built for. And in discussions about future development, it is these people we refer to when we use the 80/20 rule. But like I said, we have almost no data about them. We know little to nothing about how they use WordPress, how they interact with the UI, what makes sense to them, what confuses them, what they miss, what they want, etc.

While some work has been done with user testing, and we have anecdotal data about the user from automated systems, we have no authoritative body of data to turn to for the hard questions. So we guesstimate based on our own experiences and end up making decisions based on ourselves – the 1% of the 1%.

Of course, we could say that it’s up to the user to reach out through forums or support to voice their opinions. I think that’s too dismissive. If our goal is to build a platform that works for everyone, we need to at least define who this “everyone” is and what they want. And to do that, we need to get to know them.

Gathering Data on the Average WordPress User

At WordCamp US 2015 I had several conversations with people from various strata within the WordPress community about this: How do we gather data about the average WordPress user?

In-app surveys and outreach is one option, but it is likely to meet heavy resistance and will undoubtedly get turned off or ignored by the majority of users.

I think a better option is an active approach: Invest in data collection on a grand scale, and start a WordPress research project.

I can see you shaking your head and rolling your eyes right now, but hear me out.

WordPress is in a unique position in the world: We have the largest user base of any CMS on the web, we have the broadest spectrum of adoption, and we are distributed across the entire globe. In short, the WordPress community is an unprecedented untapped data opportunity. What if we leverage this position to kickstart a large academic project?

Here’s what I’m imagining: The WordPress community, through sponsorship, crowdfunding, or other means, creates an academic trust that puts out a call for research proposals. The stipulation is that any proposal must include large scale user testing and data collection across social strata, national, and ethnic lines, and that all raw data must be released back to the WordPress project under an open source/creative commons license. The WordPress community would then provide financial support for a selection of academic projects through the trust to give researchers the means to dig into our community and gather data.

This would hopefully result in two things: Actual data about the WordPress user and a better understanding of the WordPress community, and serious research around WordPress to bring our open source project legitimacy in the wider context of academia including social, political, and data sciences.

This is just high level thinking at this point, but I think it could work. What are your thoughts?

This post was spurred on by Josh Polloc’s The Typical WordPress User. You should read it. 

My Opinion WordPress

On Trust and Opacity

Yesterday Tom McFarlin published an important article titled The WordPress Community (A Comedy of Drama, Ego, Oligarchies, and More). If you work with WordPress or the WordPress community, it is mandatory reading and worth some serious reflection. Tom shines a light on some of the darker parts of flat-structure communities and asks poignant questions about communication, language, and leadership among other things. There is a lot to latch onto here and I have no doubt there are many articles being written in response as I type this out.

Here I want to focus in on a small part of this conversation and contribute my own perspective on something I think lies at the heart of much of the conflict Tom addresses: Trust and Opacity.

The Customizer and the Pyre

In WordPress, like any grassroots political organization, the level of conflict and partisan strife increases with its size and power. WordPress is now so big and powerful that I’m surprised we’re not starting to see breakout groups and organized factions trying to exert their will on the overall project. This is likely due to the spirit of Open Source, and we should count ourselves lucky that it has not happened. Yet.

However, there are clear signs of fracture within the community, exemplified by the furious anger directed toward the Customizer and the team that works on it.

Long story short, the Customizer (which moves many of the theme customizing features into a preview panel for direct experimentation and application) has always been controversial because it does not fit every use case. For the release of WordPress 4.3, the Customizer will be extended to include the Menu Editor (and here it’s important to note that the original Menu Editor view will remain in the admin panel). This inclusion has caused a vocal and often aggressive response that at times devolves into personal attacks on named contributors in the project.

There are people in the WordPress community who hate the Customizer with a passion, and they want to have it their way: Burn the Customizer. With Fire.

The common argument can be paraphrased thus:

“I/my clients don’t use the Customizer. Its inclusion goes against what I/my clients need and therefore has no place in WordPress.”

When work continues unabated in spite of this opposition, the objectors feel like their concerns are being ignored by whomever is calling the shots, they get angry, and sometimes lash out. This is neither new nor surprising. But it is disappointing, especially when it devolves to personal attacks, or even worse, sexist remarks and verbal assaults. These things do not a healthy community make.

On Trust

Underlying the vitriolic assaults on the Customizer lies a lack of trust; in contributors; in leadership; in the community. To many, even those involved in WordPress contribution, it can appear as if there is a hidden “inner circle” of leadership in the community – a WordPress Illuminati if you will – that calls the shots. And to some, that imagined group may appear to be running an agenda that goes counter to their interests:

“I don’t use the Customizer. Its inclusion goes against what I need and therefore has no place in WordPress. Even so, someone has decided it must be there in spite of my objections. Clearly there is an imbalance of power here. My voice does not seem to matter.”

What we have here is a classic case of mistrust. When questions are asked about the expansion of the customizer, the answers are forthcoming (again, paraphrasing here):

  • User testing and research shows that the Customizer is better understood by the average user.
  • The Customizer provides a better user experience.
  • Users appreciate the ability to see their changes in real time in the real site before publishing it live.
  • Users often voice frustrations when having to switch back and forth between back- and front-end and experiment with things like menu ordering on their live site.
  • Etc.

The response to such statements are questions like “Who are these users?” or “Who did these tests?” or “That doesn’t fit with my experience.” or “I don’t care. It is not what my clients want.”

Again, this is about trust. When presented with valid (if unsubstantiated) reasons, many opposed to the idea of the Customizer (or any other controversial feature, like auto-updates of plugins) have trouble trusting those that who make the decisions.

“Who are these people, and who gave them the power to decide what’s best for me and my clients?”

This is a problem, and it is one that every grassroots political organization has to face at some point. People want their way. And when they don’t get their way, even if they are in a minority position, they will fight tooth and nail to impose their will on the rest of the organization. Sometimes that is a good thing. Most of the time it is a problem.

On Opacity

Much of this distrust stems from the relative opacity of meritocracies. On the face of it, meritocracies are as open and transparent as is possible, but in reality they are only open and transparent if you are actually taking part and observing the day-to-day goings on.

I spend most of my time working with and researching WordPress, and even I can’t speak with much authority about how a release lead is picked or who the next core contributor will be. I can make an educated guess: Release leads are picked from core contributors based on skill, availability, and willingness to take on the responsibility. Core contributors are promoted based on the quality of their previous contributions. In other words, a meritocracy.

But who picks the Release lead? And who promotes core contributors? That is a question left unanswered, and I think this is where the idea of this mythical “leadership group” stems from.

Like a cascading waterfall, the transparency of meritocracies is made opaque by the volume and force of information that runs through it.

From the outside it appears there is a group that is in charge of WordPress. It is not listed anywhere, it is not elected, it is not given a mandate, it just is. And when a controversial decision is made (like adding the Menu editor into the Customizer), it is easy to imagine a group of evil faced conspirational dictators sitting around a table discussing how to screw the community over by moving everything into the Customizer.

Which is total nonsense.

I know some of these people, and some better than others. I’ve observed their work, observed their interactions with the community, observed their dedication to the project and their relentless pursuit of making WordPress better for all who use it. What I’ve found is that the people who sit atop of our meritocratic pyramid are humble, dedicated, and fiercely passionate about what they do. They also think far ahead – as in far ahead – to what is coming down the pipe in the next several years. They have my trust because I see my thoughts about WordPress and its future in theirs. But that’s just me. I can also see how someone who disagrees with them would feel like their project was being run by a dispassionate group of dictators who hand down decrees like the emperors of times past.

Trust and Transparency – Leadership and Vision

I mentioned grassroots political organizations earlier, and I firmly believe that WordPress is a grassroots political organization in all but name. But that’s not the topic of my current argument.

Regardless of how you define it, the WordPress community can learn a lot from grassroots political organizations. Like I said, the problems we are facing are not unique, and they have been solved before.

Our problems with trust and opacity are both symptoms of the very essence of what makes WordPress (and Open Source) great: Flat-structure meritocracies. At some undefined point, the machine grows so large that it becomes hard for anyone to see what is going on unless they dedicate all their time to this pursuit. As a result, those who find themselves in lower levels of the meritocratic pyramid start feeling disenfranchised and ignored by those higher up and they eventually start rocking the structure and consider moving their blocks elsewhere.

The way this is solved in grassroots political organizations is through the introduction of clear leadership structures and a clearly defined vision and path forwards. This is a colossal project that causes conflict and controversy, but the result is always the same: A structured democratic system that actually works.

Can this be done in an Open Source project like WordPress? Impossible to say; it has never been tried on anything this scale. Is it a good idea to try? I’m not sure.

What I do know is if we pretend everything is OK and brush the problems under the carpet, conflicts will fester and grow until they cause a major split.

So what do we do? I have two preliminary suggestions:

  1. Make the leadership of the WordPress project public record. The immediate response to this suggestion will be “but there is no leadership”. Seriously. That is not true and we all know it. Meritocratic leadership is still leadership. By explicitly listing the current Release Lead, core contributors, and most importantly other people with decision making power, people can clearly see who is in charge and where to direct questions.
  2. Create a public long-term vision for WordPress. This one is going to be a real challenge. The vision of WordPress currently is too vague and haphazard. There is a lot of ground to cover between “democratize publishing” and “80/20 rule”. Is WordPress primarily for the average user or for enterprise? What is the goal of WordPress once we reach 25% market share? Who should drive the bus? Where do we go from here? Should WordPress be a leader in web standards and accessibility? Should we get involved in the W3C? A community of our size needs direction. Otherwise everyone will go their own way and people will be left flailing or feeling like they are not being heard.

These are my thoughts. Take them at face value from someone who has experience working with grassroots and political organizations. There are solutions here. They may not be mine, they may not be yours, but if we work together we can find them, and our community will be better for them. The only thing we can’t do is pretend everything is OK and tighten down our blinders.

Epilogue: The Customizer is a Good Thing. Accept it and Move On!

For completeness, I should voice my opinion on the Customizer controversy:

The arguments for the permanent inclusion of the Customizer are, from my experience, valid and in line with the independent research I’ve done on the matter. The average WordPress user benefits greatly from the ability to preview their theme changes before taking them live. The inclusion of the Menu Editor in the Customizer will be a massive improvement to the WordPress User Experience and will take frustration away from millions of users. 

Yes, there are edge cases (typically large business and enterprise installations) where the Customizer is not ideal, but because WordPress is Free Open Source Software, an enterprise site is worth no more than a blog nobody ever visits to the project itself. All sites are created equal. So even though the need of an enterprise site to not have the Customizer seems to carry more weight than the need for millions of bloggers to have it, in reality it is the bloggers that matter. WordPress is powerful because of the millions of people who use it to throw their thoughts, feelings, hopes, and desires onto the web with abandon. The big business that chooses WordPress to back their online publications is the exception that proves the rule.

Responsive Images WordPress

WordPress, Responsive Images, and Dynamic Image Sizes

This is an addendum to my article WordPress Image Handling in a Responsive Images World. If you haven’t done so already you should read it to get the background.

Responsive Images in WordPress Core opens up a previously unattainable opportunity for the application to allow theme (and plugin) designers and developers to take control over image sizes. This would produce better designs, better user experiences, and a better impression of WordPress as a whole from its users. To get there the way images are added to posts and pages needs to be reworked. I wrote about the theory of what I think needs to happen to implement Responsive Images in WordPress yesterday in the article WordPress Image Handling in a Responsive Images World. Today I want to provide some practical ideas in the form of a thought experiment of how the image insertion task could be handled in this new reality, from hereon out referred to as the “Responsive Images World”.

The Problem (Current)

Right now, if you create a new post or page in WordPress and insert an image, you get to choose the size of that image: Thumbnail, Small, Medium, Large, or Original. These sizes are not just names: They are displayed alongside physical pixel sizes set by WordPress defaults or by you if  you changed the settings manually.

Once the image is inserted, the size you picked for it becomes a physical restraint, and that physical restraint will persist if and when the theme is changed.

Presently when an image is added to a post, the image size is permanently defined at insertion. If the theme is changed, the image stays the same size.

The Opportunity (Future)

In the Responsive Images World, when you insert an image, you get to choose the size of that image: Thumbnail, Small, Medium, Large, or Full Width. These sizes are not just names: They are displayed alongside percentage values that control the container width of the inserted image in relation to the main container of the current theme. These widths are defined by the theme designer and/or developer.

Once the image is inserted, the size you picked for it is a variable that changes with the currently active theme. For one theme a Medium width image may be 40%, for another it may be 60%. When the theme is changed, the actual image container size will change with it to realize the vision of the designer.

In the Responsive Images World, image sizes are defined by the theme and change depending on what theme is currently active.

How it could work

Given the premise set out in my previous post about the implementation of Responsive Images, here’s how Dynamic Image Sizes could work in the Responsive Images World:

As we do today, when a new theme is created, the developer sets a $content_width value to specify the maximum allowed width of content displayed in the theme. This becomes the maximum width of any inserted image.

In addition, the developer sets the parameters for the default image sizes using a function similar to add_image_size() called add_default_image_size():


  add_default_image_size( $name, $css_width, $display_width ); 

The sizes to be defined would be thumbnail, small, medium, large, and full_width

The parameters created by the add_default_image_size() function define the CSS width of the image in percentages and the displayed max-width of the image in pixels. $css_width is passed to the Image Size drop-down in the UI to indicate to the user how large the image will be. $display_width is passed to the Responsive Images function to dynamically populate the last value in the sizes attribute for images inserted with this size.

The result will be that the user selects an image size (eg “medium”) and the theme developer decides what actual size that image is when displayed in the theme. Because of Responsive Images and the $display_width parameter set by the theme and linked to the sizes attribute, the theme will always work with the browser to use the ideal image file from srcset based on the actual displayed size of the image, not the maximum width set by $content_width or the viewport.


There is an obvious challenge here that requires a substantial shift in how WordPress outputs code in the browser and may cause some significant issues with caching: WordPress post (and page) HTML is stored as more or less persistent content in the database. That includes any <img> tags. However, because the sizes attribute is a presentational element embedded in the raw HTML of the page, with this new approach WordPress has to populate this value dynamically on load based on the size parameters set in the theme. In a situation where the HTML is cached this will cause problems.

Another issue: What happens if a user manually resizes an image with click-and-drag behaviors in the editor? I have no answers for that one yet, but I am sure there is an obvious answer hiding somewhere.

Responsive Images WordPress

WordPress Image Handling in a Responsive Images World

Note to the reader: This post falls under the umbrella “Morten thinking out loud”. You have been warned.

This is the first of a 2-part article. Be sure to read the 2nd part WordPress, Responsive Images, and Dynamic Image Sizes once you’re done.

The colorful light show in the underground passageway in Chicago's O'Hare Airport

Consider the image above. Depending on your screen resolution and size, the image file you are looking at will be different from the file you’d look at on a smaller or bigger screen. This is thanks to Responsive Images. And it’s really cool. That said, we have a ways to go before this new technology can truly improve WordPress and the sites it runs. And I think a large part of that work is rethinking how WordPress handles images behind the scenes. That’s what this article is about.

Responsive Images are rapidly approaching as a standard, and the RICG team are doing continuous work on a plugin that adds responsive images functionality to WordPress sites today. With any luck we’ll see the plugin baked into WordPress core in a future release and all WordPress sites will serve up responsive images out of the box.

In this article I’m not going to talk about the responsive images implementation being worked on in itself; the work being done by the group is stellar (you can follow along in the Github repo and the Slack channel) and some of the best minds in the business are working on improving the implementation. Instead I want to present some ideas about how responsive images in WordPress can change (and improve) the modality of image handling for theme and plugin developers as well as the end-user.

Status Quo: Fixed Image Sizes

Image size selection in WordPress
Image size selection in WordPress

One of the features that makes WordPress an ideal platform for introducing responsive images is its current handling of fixed image sizes:

When an image is uploaded to WordPress the application generates a series of scaled down versions of that image in addition to the original (provided the original image is larger than each of the sizes):

  • A square thumbnail (defaults to cropped 150 x 150px)
  • A medium image (defaults to max width and/or height of 300 x 300px)
  • A large image (defaults to max width and/or height of 1024 x 1024px, typically limited by theme settings)

These default sizes can be changed from admin panel under Settings -> Media, but few users touch these settings.

When the user adds an image to a post or page in the editor they can select from any of these sizes along with alignment settings to scale and position the image as desired.

The image is added with a standard <img> tag that calls in the image file for the selected size and carries with it width and height attributes to correspond with the selected size.

Theme and plugin authors also have the ability to add additional image sizes through the add_image_size(); function. This is typically used to display specific image sizes or crops in specific regions on the site, most commonly Featured Images. For brevity and to limit the scope of this article I won’t bring this into the equation.

Responsive Images Change Everything

This all works well for static images, but as we move to responsive images we have the opportunity to rethink what happens when images are generated and added to the content.

Currently the RICG Responsive Images plugin hooks in to the existing Add Media functionality and alters the HTML output of the added image to include srcset and sizes attributes. What used to look like this:

  class="alignnone size-large wp-image-1717" 

Ends up looking like this with the plugin:

  class="alignnone size-large wp-image-1717" 
  srcset="http://[]/wp-content/uploads/2015/06/DSCF2539-300x200.jpg 300w, 
          http://[]/wp-content/uploads/2015/06/DSCF2539-700x467.jpg 700w, 
          http://[]/wp-content/uploads/2015/06/DSCF2539-735x490.jpg 735w, 
          http://[]/wp-content/uploads/2015/06/DSCF2539-368x245.jpg 368w, 
          http://[]/wp-content/uploads/2015/06/DSCF2539.jpg 4896w"
  sizes="(max-width: 4896px) 100vw, 4896px"

The problem here is that because the RICG Responsive Images plugin knows nothing about the displayed size of an image, the sizes attribute has to use the max width of the image itself coupled with the width of the viewport to figure out what image file to load. As a result, if you have a gigantic image like the one in the example, and you display it on a gigantic screen or one with high resolution, the full size image (4896px wide) will load even if the displayed size is only 800px.

What we have here is a clash between old methodology and new technology. And it stems from the fact that WordPress is still an image classicist. but in a Responsive Images world it needs to be a modernist.

The solution, simple in theory and complex in execution, is for the image size drop-down to specify the sizes attribute rather than the image file size. And that sizes attribute should be controlled by the theme.

Let me explain.

New Modalities

What’s interesting about Responsive Images is that rather than thinking about images as fixed-size entities displayed in a responsive landscape we can start thinking about them as responsive containers with images inside.

Currently when you add an image to a responsive site you are in reality setting up a container and displaying the image within that container. Because the site is responsive that container will have a max-width (either specified in the container itself or constrained by an ancestral container) and will flex and resize depending on the size of the viewport. The image served up is instructed to fill the width of the container and shrink the height proportionately.

To ensure bandwidth isn’t wasted, tools like WordPress offer the user image sizes to choose from when adding an image to a post or page. These sizes in turn hard-code the maximum width and height of the img element to the size of the image.

In a Responsive Images world this makes no sense.

With Responsive Images we should only be specifying the size of the container through CSS and the sizes attribute. The browser is responsible for picking and displaying the correct image file based on the available space and display resolution. The physical size of the image, as specified in the img element is irrelevant (and should be omitted entirely imo).

This means when the user picks a size, they should not be picking a size based on the available generated files, but rather a container size based on the sizes specified by the theme developer. And if the user changes the size of the container with click-and-drag behaviors, that change should be reflected in the container through the sizes attribute.

Brave New Responsive World

This has some compelling (and quite disruptive) implications:

First of all, there is no need for the customizable Small, Medium, and Large image file sizes any more. At least not in terms of available sizes of images to be added to the site. Instead WordPress could generate some standardized sizes for small, medium, and large displays behind the scenes without ever telling the user about them. Granted, cropped versions for thumbnails and Featured Images still need to be made, but again the sizing of these can be left to a standardized function within WordPress.

Secondly, this allows theme developers (and to a degree plugin developers) to incorporate image sizes of in-post images into their designs. Because we don’t have to think about the physical size of the image any more but instead the size of the container, theme developers should be able to specify these sizes (Small, Medium, Large, whatever) in the theme and it is these container sizes, reflected in CSS and the sizes attribute, that are offered up to the user as options when an image is added.

Work is already being done in the RICG Responsive Images plugin to allow theme developers to customize the sizes attributes for images and in an ideal world I think this should become the new standard.

Finally, and this is where things get really interesting imo, there is an opening here for the possibility of doing away with image cropping all together, moving instead to cropping through CSS clipping. Because of the nature of Responsive Images as interchangeable sources, cropping can produce a large number of extraneous files, but all this is based on the old image-file-has-to-fit-container mentality from the pre-responsive images era. Since the concern now is only the container inside which the image is placed, there is no reason why a developer can’t specify positioning and crop factors using CSS, thereby not only eliminating the need for generation of cropped images, but also allowing for new and interesting behaviors like dynamic responsive cropping and user-controlled cropping on an image-to-image basis.

Overhaul Required

If  you’re with me so far one thing should be abundantly clear by this point: This change will require a complete overhaul of how images are handled by WordPress. And this overhaul is actually in progress through the work of the RICG Responsive Images team and the ImageFlow team. I’ve mulled about this to members of both teams for some time and I hope that with this post we can start the conversation in earnest and put some meat on these bones.

It is quite possible that I am off on a path into the wilderness here and that what I’m proposing is not feasible, but I am convinced this needs to be explored. Responsive Images are a fundamentally different animal from regular old images, and they require a whole new way of thinking. Trying to cage them in the old modalities of image sizes makes no sense. It is time to rethink everything. I propose we start here.


robots.txt might be ruining your Mobile-Friendly Ranking with Google

Sometimes our computers try a little too hard to help us and end up hurting us instead. In Norwegian we call it a “Bear’s Favor”. Such may be the case with your robots.txt file and Google’s upcoming Mobile-Friendly Ranking.

Test your site

An unstyled WordPress page
Screenshot of without styles applied. Decidedly mobile-unfriendly

If  you haven’t done so already, head over to Google’s Mobile-Friendly Test page and enter your URL. If all is well and you’re running a responsive theme you should get a nice green all-clear sign meaning you won’t be penalized for mobile unfriendliness. However, there is a good chance your site will fail this test even if it is responsive because your robots.txt file is blocking your themes folder.

If so you’ll see something like the screenshot to the right.

If this is what you see your site will fail the mobile friendly test because your content is too wide, all your links are too close together, and everything is totally out of whack. Which is true.

Check your robots

The great thing is once you’ve run the test and failed, Google will provide you with directions to check what’s going on. What you need to do is go to Google Webmaster Tools and check your robots.txt file. Once on the page, enter the URL to your theme stylesheet (http://[]/wp-content/themes/[themename]/style.css) and see if it’s being blocked. If it is the tool will highlight the line in robots.txt that is blocking the stylesheet.

Fix robots.txt

Fixing robots.txt is relatively easy. If you are not using an SEO plugins you may have to FTP or SSH into your site and change the file manually. If you are using Yoast’s WordPress SEO plugin you can edit robots.txt directly by going to Tools -> File Editor.

Remove the offending line of text (probably Disallow: /wp-content/themes/), save the file, and go back to Google’s Mobile-Friendly Test page. Run the test again, the new robots.txt file will kick in, and you’ll see your site displayed in the preview with your styles and JavaScripts applied.

Easy as ?


Plugins, Automatic Updates, and the Average WordPress User

The fallout over the automatic update of Yoast’s WordPress SEO plugin shows the WordPress community is suffering from a severe case of Developer Goggles.


Yesterday (March 11th, 2015) Joost de Valk released a security update to the popular WordPress SEO plugin, currently running on over 1 million WordPress sites around the world. The release came after a responsible disclosure by Ryan Dewhurst of the WPScan team that detailed a significant and serious vulnerability in the plugin that could allow a hacker direct access to your database.

In the immediate wake of the update several hosting companies specializing in WordPress started either updating hosted sites with the plugin automatically or put in place safeguards to prevent hacker incursions.

Automatic Update

A few hours after the initial release the team started rolling out an automatic (“forced”) update to all sites running the plugin. This means if  you are using the WordPress SEO plugin you are now running the latest a secure point-release version whether you updated it manually or not. In other words your WordPress site is safe.

While not entirely unprecedented this is a rare occurrence. Reportedly such automatic plugin updates have happened only about 5 times:

Since version 3.7 WordPress itself has automatically updated whenever a security release has been published. There has also been a lot of talk in the community about instigating similar automatic updates for themes and plugins, much of which has been met with strong resistance.

The Fallout

In the wake of the automatic update many WordPress developers and community contributors have voiced concern, anger, even outrage.

Nick Haskins summed up much of the concerns quite nicely in his post “On Automatic WordPress Updates“:

An update, is an update, and WordPress automatically updated a 3rd party plugin without my consent.

This constitutes a breach of trust, plain and simple.Nick Haskins

Haskins notes in an update to the post that the wording on the Codex page about automatic updates has been updated to clearly state that “Automatic background updates currently only happen for plugins and themes in special cases (determined by the API response)” and provides an example of how to permanently disable all automatic updates.

However, this Codex update does not diminish the core of the criticism of the update. The reason many developers are upset is that an automatic update of a plugin blurs the line between “self hosted” – as in autonomous – WordPress and “managed” WordPress. Haskins cites examples of plugin updates crashing sites. Others cite examples of plugin updates changing core functionality or behaviors without notice.

All of these are great arguments, but they run counter to an oft overlooked reality of the WordPress community: We, the people who develop and talk about WordPress on a daily basis, are not the typical user. We are the WordPress One Percent. And automatic updates are not for us. They are for everyone else.

Developer Goggles and the Real WordPress User

WordPress development runs on what’s known as the 80/20 principle. In this context it means anything that is done with WordPress core should be of benefit to 80% of the users. It would be hard to argue that a significant security update like the one released for WordPress SEO does not pass this test.

Though I don’t have any numbers I would venture a guess that the vast majority of WordPress users a) never read WordPress news, b) never monitor conversations about WordPress security issues, and c) rarely if ever check to make sure their plugins and themes are up to date. In fact every time there is a new full release of WordPress or major update to a plugin I get hundreds of questions by Twitter, Facebook, and email from regular users about whether it’s “safe” to update. In the real world many WordPress users are deathly afraid of any update and are clinging to ancient installs with out of date themes and plugins because they are worried an update may take their site down. Jeff Chandler posted some telling stats about this in his aforementioned, and strangely prophetic, article about the need for automatic plugin updates.

There are also a large number of WordPress users who have no idea whether a particular plugin is installed. In many cases the plugins are installed by the contractor they hired to build their site, and once the site is built they are left to maintain it. A warning about a security update would go unnoticed by them unless someone called or sent an email, and even then it is not certain that they would know how to or even have access permissions to run the update.

With this in mind it is clear the outrage over the automatic rollout of a significant security update to a popular plugin is one that only makes sense if you wear pretty thick developer goggles. The update is not for the WordPress Literati – it’s for the people we build WordPress for: The blogger, the small business owner, the people around the world who have something to say and want to say it without having to become a professional web developer in the process.


We can talk until the cows come home about whether all plugins and themes should be auto-updated. But the more important conversation we need to have is about how we define the typical WordPress user and how we serve them best. Let’s be honest here: If you are reading this you are in the WordPress 1%. And WordPress, for better or worse, is not really built for you.


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:

 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!


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:

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:

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:

// 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:

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.


A Sneak Peek at WordPress 4.0 with Morten Rand-Hendriksen (recorded)

Earlier today I did a live Hangout for about WordPress 4.0 and WordPress in general. Check out the video above and go to the Hangouts page to join the conversation.

Image Editing WordPress

Building a New Image Editing Experience for WordPress

If you’ve been paying unnaturally close attention to the goings on of the WordPress universe you may have noticed my name popping up in a post on Make WordPress UI about a new project to create a better image editing experience for WordPress. As the post explains Siobhan McKeown has put together a team that will be working on a new feature plugin to reimagine, redesign, and redevelop the image adding and editing process in WordPress, and that team includes yours truly.

So, to start off my contribution to this project I’m writing this post to provide my initial thoughts on what image editor in WordPress could look like as well as reflections on images in our culture, the different scenarios in which images are added in WordPress, and what the process of adding these different types of images should look like.

I would very much like to hear your thoughts on this and solicit your participation in this project as we move forward. WordPress is for the people who use it and your opinion about how image editing should be is vital for the process to be successful.

Image Editing as a First Rate Citizen

One of the primary goals for this process is to make image editing a first rate citizen of WordPress. Currently the option to edit an image is hidden under a text link in the Add / Edit Media modal. In the future rendition of this modal image editing should be part of the process with a prominent place in the modal.

The Transformed Role of Images

In my interactions with students from, Emily Carr, BCIT, and all the other places I’ve spoken about and taught WordPress I’ve learned that of the many features in WordPress that don’t work the way users expect and/or want the image adding and editing experience ranks pretty high. There are many reasons for this, and many of them have nothing to do with WordPress but rather how our thinking about digital images and their place on the web has changed over the last few years.

Whereas the taking of images used to be something confined to a dedicated device (a camera) and the editing and adding of images involved complex and expensive software, we now live in a world where a large majority of the population carry a high resolution camera in their pocket. And that camera has software built in to not only edit but publish the images taken through an endless variety of channels.

How images are consumed has also changed: Once an image is published the viewing public can typically interact with it by liking it, sharing it, commenting on it, and even republishing it. There are also tools available that treat images embedded in larger contexts (images supporting articles or displayed in galleries and slideshows) as individual items that can be interacted with and shared outside the context they were presented in (Pinterest’s browser extensions and note taking apps like Evernote are examples of this phenomenon).

Image editing itself has undergone a transformation with the introduction of RAW image data and editing. The original image file can now be changed an infinite number of times and render an infinite number of versions without the image data itself being altered. The actual changes happen in separate layers – be that associated files or through filters and frames – while the original is left intact. While this is currently the realm of image editing applications like Photoshop and Lightroom, advances in web technologies means we will soon have similar capabilities through new HTML elements and CSS filters.

All this is new and evolving and demands a complete rethink of the role of images in the context of published materials:

  • What is the intended role or purpose of an image when presented on the web?
  • Are images to be considered objects in their own right separate from the context they are presented in?
  • And if so, should the viewer be able to interact with the image outside the context it was presented in?

There are also technical considerations that need to be addressed:

  • Is the original version of the image important or should the cropped / edited version of the image be considered the actual object?
  • Does editing of an image belong in a dedicated application or in the context of the publishing application?
  • Should the editing of images be destructive (changing the original file), iterative (generating a new file), or visual (happening in separate layers without touching the file)?

WordPress has for the most part clear and definite answers to these questions, but they are largely based on a time we no longer live in. As technology and behavior changes we need to revisit these questions and redefine the role of images in WordPress and how the people who use WordPress can get the most out of their images.

Images and How We Use Them

The first and most important question that needs to be answered is how people use and want to use images within WordPress. The challenge here is that there are as many answers as there are people using the application. Even so we can hone in on some general scenarios that are common and can be addressed:

Single Images

Images can be the main item or even only item of a publication. In this case the image will often be edited before upload and the publisher will want the display of the image to stay true to the original. Single images can be accompanied by text but this text is secondary.

While adding these images as Featured Images makes sense from a social sharing perspective, the way Featured Images are handled within WordPress removes control from the publisher so she is more likely to add the image in the editor.

Grouped Images

Not to be confused with galleries, grouped images are added within the editor for more control. Like single images the publisher will likely do all editing prior to upload and care about positioning and display.

Currently there is little support for this usage scenario within WordPress.

Image Galleries

Galleries can be displayed as primary elements (the focal point of a publication) or as secondary or supportive elements. The publisher can choose positioning, display mode (columns, layout, etc) and on-clicked behavior.

Link to Attachment Page is the default option for image galleries in WordPress, but the Attachment Page template is an oft ignored feature of WordPress themes. This leads to inconsistent behavior and often forces the publisher to turn to plugins to display images in a visually pleasing and easily understandable way. The Attachment Page has tremendous value for publishers if the image is displayed along side the image description (content of the media post) but this requires theme support.

Images in Context

A common use of images on the web is as contextual elements. Images are placed throughout text as illustrations or further information. These images can contain image captions and link to other publications, larger versions of themselves, or their respective Attachment Pages.

The publisher utilizing images in this role is likely different from the one publishing Single Images. Here image editing is likely to be expected from WordPress itself, and that editing will be expected on a per-instance basis (the edit only affects the current iteration of the image). For images in context the publisher wants tight control of display, position, and behavior.

Featured Images

The evolution from Post Thumbnails to Featured Images and now images shared on social media has produced a new role for images and new complications for publishers: The Featured Image is handled as a stand-alone object that can be called along side other elements of a single publication and displayed independently in templates. This takes control of cropping, display, position, and behavior of the image out of the hands of the publisher and leaves it to WordPress itself and the theme designer / developer.

For publishers who seek tight control over how images are cropped and displayed this is a non-starter, but these publishers are often forced to use the feature anyway to ensure control when content is shared through social media.

Reimagining What Image Editing in WordPress Could Look Like

As this process begins, here are my preliminary ideas on what the image editing experience in WordPress could look like. Keep in mind these are my initial thoughts and they cannot be taken as anything other than ideas. In other words this is not a list of new features you can expect to see in WordPress in the near future but rather a list of features I think we should explore as we move forward.

When an image is added or given focus in the editor it should be displayed as true to final size as possible and retain proportions within the editor. All editing should happen on this image to allow the publisher to preview the result before saving.

There is precedence for this work process established by apps like Instagram, Twitter, Facebook, and Flickr, and these behaviors and user interactions have become expected from users. There is also precedence in WordPress: The ability to rotate, reflect, and crop images already exists and new features could be an extension of this same functionality.

In WordPress core new features should be limited to basic editing (contrast, lightness, black & white, standard color filters) and endpoints should be left open for plugin developers to add additional filters and editing functionalities.

Image Editing Within the Content Editor

In addition to editing and managing images through the Add / Edit Image modal window some limited editing should be available from within the content editor. In particular this could include positioning (none, left, center, right) and link-to. These capabilities would appear on hover within the editor and allow contextual WYSIWYG editing in a way we don’t have currently. This type of editing will become more important when work on front-end editing nears completion and publishers move away from the back-end editor.

The Image Adding and Editing Algorithm

While the scenarios above are not complete they provide us with a basic guideline for future development of image adding and editing in WordPress. The scenarios can be grouped into three different objectives:

  1. Adding images to posts
  2. Creating image galleries
  3. Defining Featured Images

The commonality between all of these is the optional ability to edit the images once uploaded. They are also sequential: 2 and 3 rely on 1, and in most cases a Featured Image will be selected as the last step when and if a gallery is created.

Within the Add / Edit Image modal

Looking at images as elements added to a post or page for the first time (as opposed to images selected from the Media Library) we can construct a common algorithm for all three objectives:

  1. Uploader is opened
  2. One or more images are selected and uploaded
  3. Each image is edited (cropped, rotated/mirrored, filtered, sized)
  4. Metadata (title, alternate text, caption, description) is added for each image

From this point on the procedure changes for each objective:

For single images and images displayed in groups:

  1. Image positioning (none, left, center, right) is selected
  2. Size is selected
  3. Link to is selected

For galleries:

  1. Images to go in gallery are selected
  2. Gallery is organized
  3. Captions are added to each image
  4. Title of gallery is defined (grid with column number, slideshow, other)
  5. Type of gallery is selected
  6. When-clicked action is defined

For Featured Images:

  1. Image is assigned as Featured Image
  2. Cropping option akin to cropping of header image is opened to allow the publisher to control crop (this should possibly happen for each Featured Image size).

For existing images in the Media Library the process will be much the same with the main difference that the editing in step 3 can be reapplied and only affects the new location of the image (non-recursive editing).

Share Your Thoughts, Join the Conversation, Help Shape the Future

As I said in the beginning, this is all about you, the people who use WordPress. The true value of Open Source lies in the community and its ability to contribute to and build the solutions they use. Your input matters and we want to hear it. Share your thoughts, ideas, and concerns about the current and future image editor in the comments below or on Siobhan’s post over at Make WordPress UI. And if you feel that simply commenting isn’t enough, you can join the team!

Categories WordPress

Simone and Building WordPress Themes from Scratch Using Underscores

Over the past few weeks two major releases took place, and now it’s time to talk about them:

First, the new free WordPress theme Simone announced my re-entry into the free WordPress theme space. If you’ve been following me for a while you know I’ve released free WordPress themes before and you may also know that I pulled them all last year because I wanted to bring my themes up to current standards. Simone is that and more. Which I’ll get to in a bit.

Secondly, my biggest course to date titled WordPress: Building Themes from Scratch Using Underscores was released, and with it subscribers can now learn how to build their own WordPress themes to be standards-based, accessible, responsive, and content-centric.


So why am I announcing both these releases with one blog post you ask? The answer is simple: The course, WordPress: Building Themes from Scratch Using Underscores, shows you how to build your own version of Simone, the theme that was released at the same time. Yes, that’s right: The course walks you through the entire process of designing, developing, and building the theme that is now free from the WordPress Themes Directory.

Now that you know why, let me tell you a bit more more about both the course and Simone.

Building Themes from Scratch Using Underscores

WordPress: Building Themes from Scratch Using Underscores - a course

One of if not the most requested future course I’ve been asked to build at was a course on developing themes from scratch. Every week I get emails, tweets, Facebook messages, and messages on this blog asking about how to go from a design or an idea to a full-fledged functioning WordPress theme. So as 2014 began I started working on a new and expansive course that did just that: Took a design and built a full-fledged WordPress theme from scratch.

During pre-development of the course I decided merely building a theme for show wasn’t enough. I wanted the course to go beyond showing basic practices to show the process of building a shippable product. And to top it off I also wanted the end result to be accessible, translatable, responsive, and in accordance with the latest design and development patterns and standards. The result was the theme named Simone which will be covered later.

For the course I decided to use _s (Underscores) as the baseline. Building a WordPress theme from scratch from scratch makes no sense and _s is in my opinion the best starter theme available and the one all developers should be using. Considering its popularity there is scarcely any expansive documentation on how to use _s to build WordPress themes so I built the course as a deep-dive into the _s theme as well as the process of building themes from scratch. Whether you are an aspiring developer or a seasoned pro with experience with _s I am certain you will find a wealth of useful information in the course that will help you utilize the theme in a more effective way and build better, more responsive, and more accessible themes in the process.

Which brings me to Simone itself.

Simone – a Free, Responsive, Accessible, Content-first WordPress Theme

Simone - a free, responsive, accessible WordPress theme from Morten Rand-Hendriksen

My first thought when designing Simone was to find new solutions to the old problems faced by theme designers and developers: Where do you place the sidebar so it doesn’t interfere with the content? How do you make menus accessible? How do you incorporate social media links in a consistent way? How do you make the theme truly responsive? And easy to read on all screens? And easy to customize?

Starting with a clean slate I made a series of decisions: The theme should meet accessibility guidelines, the content should be in the center of the screen whenever possible, featured images should be responsive, the user should be able to add a social media menu using the standard menu manager, and the grid should be broken to utilize the space available on larger screens.

The result was something I have yet to see anywhere else (yes, I should receive an award for being humble): A theme that puts the content (literally) front and center and locks the sidebar to the right-hand side of the screen. This feature is only really visible on very large screens and it is one that I hope will be adopted by other theme developers in the future. With Simone the visitor is not forced to turn her head to the left to read the content on large screens, and the sidebar never interferes or fights for the reader’s attention. All as it should be.

The theme is full of advanced features:

  • Control of the header background color and link colors
  • Option for adding a header background image or displaying just an image as the header (or displaying no header at all)
  • Optional social media menu in the main menu area that shows social media icons based on the URLs each menu item is pointing to
  • Pagination navigation on index pages
  • Responsive featured images using the <picture> tag
  • An optional author box on single posts and author index pages (triggered by filling out the Author Bio field)
  • Optional integration with the WordPress SEO plugin to add social media links to authors from the Author Profile page
  • Pull quotes and pull images that break out of the content grid when the screen width allows it
  • Dynamic font sizes that change according to the window width
  • Accessibility standards throughout
  • HTML5 captions and galleries
  • and much more

You can get a full rundown of the features and functionalities of Simone by checking out the dedicated page for the theme.

Simone is for Everyone

Simone was built to be used, shared, changed, and evolved. To that end you can get the theme either by building it yourself while following the WordPress: Building Themes from Scratch Using Underscores course at, by downloading it directly from the WordPress Themes Directory, or by downloading, forking, or contributing to it on GitHub.

If you have any additions, features, or alterations you want to add or want me to add to Simone you can either submit an issue, a feature request, or a pull request on GitHub. The theme is in constant evolution and development and I will evolve it in accordance with what you the user wants. Speak up and ye shall be heard!

Over to you!

Now that you’ve been introduced to Simone and WordPress: Building Themes from Scratch Using Underscores, I want to hear what you have to say both about the theme and the course. Say your piece in the comments below and let’s get the conversation going!

Accessibility My Opinion WordPress

The accessibility-ready Tag Should Be Required for All WordPress Themes

When was the last time you tried navigating your WordPress site using only the keyboard? Chances are you never have, and if you do you are likely to have a sub-optimal experience at best. The alarming reality is only a handful of WordPress themes (and thus WordPress-powered sites) meet basic accessibility guidelines. This is not OK. I’m issuing a challenge to the WordPress community:

Accessibility should be a requirement for all WordPress themes.