The quarrel for theme content

If you follow the theme review you know what I’m talking about. If you don’t let me give you brief glimpse of what I am going to talk about.

For as long as I can remember being in the review team, there has been an issue of themes not being allowed to do certain things. One of which is “creating content.”

If you know how WordPress themes work, that’s awesome! If you don’t let me try to explain a little bit with a simile. A WordPress site is very much like a car. It has an engine, a rear-view mirror, a body, some seats, and some wheels. Many of those can be replaced, switched, altered and tailored to suit your needs. If you wanted to go off-roading you get a different suspension, different tires maybe a radio just in case. Now, where do themes fit in this?

Themes can be like the paint or color. It makes it so you can stand out, be seen or blend in, depending on what you want. The paint doesn’t add an extra mirror, an extra wheel, or bells or whistles. It showcases your car. Simply that.

That’s the short story of it.

A look way back

In order to look forward we also have to look back. I’m talking way back to when the review team was first created. I wasn’t around the community but I am sure there are some that will remember this and smile:

The review process is intended to catch technical issues and ensure that new themes conform to modern web standards and WordPress standards. Theme reviewers may also provide some feedback on aesthetics, but users of the theme gallery will have an opportunity to provide feedback on the design after the theme is available in the gallery.

That is a quote from the Theme Review codex page from June 11, 2010. Yes, I did say way back. A few months pass and the page does start to get more and more informational to not only reviewers but authors as well. The process is outlined, the scope of the process, how to become a reviewer, and some general guidelines in theme development are beginning to take place. Awesome!

In August 2010, the Theme Unit Tests are added. This is a very pivotal and important part and I cannot emphasize this enough. There is a reason for this and I’ll talk about that a little later.

For now, let’s keep going down memory lane.

Let us jump to May 27, 2015. A post on the WP Tavern got quite a few comments about a guideline that had been set for several years but was now being “enforced.”  The rule in question is:

Themes are required to define the presentation of user content, and must not be used to define the generation of user content, or to define Theme-independent site options or functionality.

This was added to the codex guidelines on March 8, 2012. So, for the last four years this rule had been in place and never really defined and rarely brought up by others in the review community. At least in translation. You see the review team is made up of people from all around the world. India, England, Chicago, Canada. A lot of it can be left up to interpretation as well and that’s when things can go wrong.

The current issue

Currently we are faced with a lot of themes that add extra things to a user’s site and that makes it hard to switch to a new theme – for some. This can be something so simple as a section that has an image and some additional text. What many reviewers like to call: pseudo-post types. Even the current requirements states:

The theme options should not be pseudo custom post types and save non-trivial user data. Non-design related functionality is not allowed

Very wordy and a little hard to follow for some, right? I consider myself fairly smart when it comes to certain things but I had to read that several times to fully understand it. It makes sense when you explain it but when you try to be concise with limited words, you do lose some of the meaning.

Think of it this way. What information can the theme get, or what data is available to show and actually show it. Very much like the car’s paint or style.

Let’s say you wanted to showcase the wheels. The theme won’t replace them, it merely coats the rims in a brighter color than the body to emphasize them. The paint is not creating an extra antenna, or an extra head light. It emphasizes what the car has. And that is what a theme should really do.

The biggest take-away from the first iteration is:

Themes are required to define the presentation of user content

The content issue

Okay, I did say I was going to mention the unit test. I left this for last because it ties together the car simile. It is the interior of the car.

When creating a theme, it is the user content that is displayed. Let me say that again.

When creating a theme, it is the user content that is displayed.

The theme unit test is useful for not only reviewing a theme but creating as well. Now, I know there may be a few people who say the current demo is stale, I agree, but if you want to change it act upon it. You can’t remove a thorn from your foot by simply dismissing it. You have to actually do something about it.

There is a meta ticket that has been around for nearly the same amount of time. It was created three years ago and still not resolved. If you want to change it, join in.

If you are a theme author, I implore and challenge you to download as many dummy content files as you can get your hands on. Use that as your starting point and find a way to display it all without resorting to adding an extra text input field.

Why theme documentation matters

Creating WordPress themes can be fun. Sharing them with everybody is even better. What happens when those users then ask you how to do something? Often times what is the simplest task to you may seem like a trip to Mordor for others. You don’t always know the person’s knowledge base when you share your theme. They could be a developer that began using BASIC when it was first introduced, or a person who has just picked up a book on how to build a website using WordPress.

What’s cool is we can meet both those worlds in the middle. One way is by using code comments. Code comments can make it easier for not only yourself but others to know what exactly the code is doing. A good example of this is the comment block below, taken from the wp_get_theme function:

 * Gets a WP_Theme object for a theme.
 * @since 3.4.0
 * @global array $wp_theme_directories
 * @param string $stylesheet Directory name for the theme. Optional. Defaults to current theme.
 * @param string $theme_root Absolute path of the theme root to look in. Optional. If not specified, get_raw_theme_root()
 * 	                         is used to calculate the theme root for the $stylesheet provided (or current theme).
 * @return WP_Theme Theme object. Be sure to check the object's exists() method if you need to confirm the theme's existence.

Yes, it can look like a lot of information but not all your code has to be as robust as that. You can use simple documentation and still do just the same. While that does go for some developers, we cannot forget those that just want to use the theme and are possibly afraid of code, or don’t know how to code. Great! This is where other forms of documentation come in handy.


There are other forms of documentation that you can use to your advantage. A few I like are:

  • Videos
  • Images
  • Readme file

Please note, images and videos may not always be view-able by all so you may have to take that into consideration on your path to documentation bliss. Now, let us explore those a little more.


I love me a good video. A video tutorial, that is. Now, your theme does not have to have a step by step video on how to setup every single option, or possibility your theme offers but you do want to have some of the basic, and perhaps most common things. A few examples are installing the theme, accessing your theme options, showing how to setup possible social links, or even using page templates. You don’t have to have audio but it does help. There are several programs out there that allow you to capture video and create video screen casts.


Yes! Images can make a huge difference for many. Even better when they move. I am talking about gif images. They can be a great way to showcase a few steps without having to create a two minute video to show how to access extra options. If you have an image editing program it can be used to highlight what you want in order to emphasize parts of the image.

Readme File

The basic and standard file you need to include. Okay, that’s just me saying it but I’m sure there are more people who would agree with that statement. This is the part that really irks me because you can include some basic steps that can go a long way. A great example is setting up social link profiles. There are several ways of creating those and not all themes follow a standard. It is nice to know where to look and how to use it.

== Setting up social links ==
1. From Dashboard go to Appearance
2. Click Customize
3. Go down to Social section
4. Type username or ID ( depending on network )

Looks fairly simple, right? It can be for some but there may be others that may still get confused. Okay, we covered a simple setup but what happens when a user gets what they feel is an unexpected result?

What do I mean by this?

Let’s say the theme has a menu location at the bottom and you only want it to display one level of menu items. They may open a support request, thread, ticket, whatchumacallit, or what ever system of support you are using and ask why it isn’t showing all the menu items. This is where your theme’s documentation can come in super handy and essential. If it is a design choice then it should be stated in the documentation. A good way would be something like:

=== Limitations ==
* Featured images should be minimum 600 pixels wide and 400 pixels tall for best results
* The `footer-nav` menu location, by design, only displays one level of menu items
* The `ad-loc-1` widget area is only used in the page template `fullwidth-ads`
* If pages do not have a featured image set, the chosen header image will be used

Yes, even what sounds -or seems- strange is super helpful to the user of your theme. Knowing what the best size for an image is useful, just like knowing the right size of tire for your car or bicycle.

So please, please make sure you are documenting for not only yourself but for your users as well.

Temporary look change

Yes. Until the end of the year this site will be rocking the 2016 default theme that is under construction. Yes, you read it right. It looks vastly different from the last theme. I may switch it out after the new year but until then, this will be the look.

Next steps

Down the line I will be making a few changes of course to sort of suit the needs but for the most part it will be for testing purposes. I want this site to be a guinea pig a little bit if you hadn’t noticed.

In the coming days, I’ll be creating a child theme so I can expand upon the theme and perhaps break it along the way.

This will be fun!

What makes a good WordPress theme

I’ve been reviewing themes for quite some time and over the course I’ve learned a lot about the good parts, the bad parts, and the in betweens. All these themes have a few things in common. What I like to call guiding principles. I think of them much like I do the principles of design; simple rules to making a WordPress theme.

We all have our take and this is mine:

  • Error free
  • Follows core implementation and best practices
  • All around user-friendly

Just three things. Sounds a little crazy but it is true. I’ll explain each one a little more.

Error Free

Yes, error free. This includes CSS, JavaScript, HTML, and PHP. Now, that sounds simple right? It can be. What I mean is not just those. I also mean WordPress related errors. Believe it or not, there are times when WordPress does throw out some errors.

If you know, or follow, WordPress development, you know there are a few things to look for. Four functions and one setting can do a lot of damage. The _deprecated_* functions, _doing_it_wrong, and define( 'WP_DEBUG', true ) can create a very bad experience for not just users but end-users as well. Clearly we would like to avoid all of these things when possible. There are times when some things are not possible but you can prepare for some.

Yes, there are times when CSS/HTML may create an error but it could be caused by a user inputting arbitrary HTML/CSS in some form or another so that takes less precedence. The ones to be super mindful of are JavaScript, PHP and the WordPress related ones because as a theme author you can control this. You can do this by using an alpha version, beta version and release candidates. There is a plugin that allows you to do this: WordPress beta tester. It is a great and powerful plugin for themes and plugins to take advantage of. You know the best part about it? It’s FREE!

Best Practices

Yes I said it. The thing to remember here is that those can change. Much like core does and has. To elaborate, a theme should be able to be switched without the user even having to worry about losing any content. A theme makes the design decisions. No, I don’t mean a user can’t change colors or even a layout but it does mean that it should have only the needed options. Minimalist if you will.

A good example of this would be the Twenty Fifteen theme. Yes, I am linking to it because it has a great color scheme selector. Notice that it doesn’t have options for specific things the theme has. There are some that use the customizer for link colors, header title changes and simple things that a CSS plugin can do or even a child theme. Yes, a child theme. Any theme can have a child theme. If it makes it hard to create one, odds are you may have to rethink a few things.

As I mentioned there should be no reason for a user to lose any content. What this means is as a theme author, you have to think about what is being saved to the database. What things can be migrated when a user wants to change from Theme A to Theme B or Theme D.

Yes, that can feel limiting but let me give you an example of this. You buy an iPod – yes, they still exist – but you had a Sony mini-disc player – yes, they too, still exists – and you want to transfer all your music to the new iPod. Well, the Sony player used a different format for saving those songs you loved so much. Yes, Nicki Minaj, Alice Cooper, Aerosmith, Beethoven, and that Blues Clues theme you wanted to transfer over won’t play because they are in a different format. You’ve created more work for not only the user but a terrible experience as well. You’re going to tell your friends the iPod doesn’t support this and can’t do this and that and all because the mini-disc player ( your theme ) didn’t follow a standard of MP3.

Yes, it does seem a little off to mention that but think about what the next theme author will have to explain. You may be the next theme author that explains why their slider isn’t showing up in the right place.


And I mean FRIENDLY! Okay, now that the sugar has somewhat worn off, let me explain a little more. A theme is child friendly and plugin friendly. What do I mean by child friendly? Simple.

WordPress has a great way of making themes and making those changes without a user having to lose a lot of those changes. A great way of course is through a plugin. Another is a child theme. What’s amazing is that a child theme overrides the parent theme when it comes to template files. If you don’t understand those terms, please read the provided links. It will make sense once you do. I’ll be waiting.

Okay, now, I also mentioned plugin friendly. What does that mean? There are tons of plugins, and I mean tons of plugins. The way some plugins integrate with themes can be a hassle and there are several ways of doing that too. Some use a template tag, some use an action hook, a filter hook, and some use classes. What’s the best? The downside is I don’t have the exact answer but I can show you a quick way of making it easy for not only plugins but themes to take advantage of it. Using do_action and apply_filters.

Yes, WordPress has a great way of making sure that your theme does not create fatal errors. Using those two will not only make using child themes a lot friendlier for your users but plugins as well. Worse case scenario is that a plugin doesn’t use the right name for the hook or filter and it doesn’t work. Simple fix. Let’s make a quick example:

// somewhere in the header.php file
$col_count = absint( apply_filters( 'jc_column_count', 4 ) );

<div class="col-<?php esc_attr( $col_count ); ?>">

What is super amazing is that a child theme or plugin can filter that. This was also mentioned a long time ago by Andrew Nacin. It is a great read and it does amaze me how many still haven’t adopted this.

The last bit I would like to go over is what may be a super important part for the user of a theme. The documentation. Yes, documentation. Even something so simple as how to set up a social menu can be tricky for a new person. When I say user I do mean both the developer and the site’s user. They may not always be the same person. Remember, you are thinking externally here.

Working with the WordPress Customizer

Recently the Theme Review Team chose to make the customizer as the format of creating theme options. I love it! Yes, I was in favor of it. I have my reasons. I know there are some people that still don’t fully grasp the customizer and most likely won’t. All good! Some take a little more time than others; I know I do sometimes with certain things.

How it works

Okay. This little post will deal with customizer settings, controls, sections and panels. Yes. At the time of this writing the WordPress version is 4.2.1 with 4.3 just beginning. In the following I will make an attempt at giving you ( the reader ) a little more insight into how the WordPress customizer works and what is available within the customizer.

In order to understand the customizer a little more I dove into the core code. I asked myself a simple question, “when and where is it being created?”

Funnily enough it is done in one simple function. _wp_customize_include. It is a callback function that is hooked to plugins_loaded. Yes, I went ahead and looked up a lot of the code for you. What’s pretty cool is that in order for the customizer to work it needs five files. Yes, five. To a degree 7 but the other two are the customize.php and class-wp-customize-widgets.php files. For the purpose of this post I’ll only really dive into the five customizer ones.

Let’s look at the function:

function _wp_customize_include() {
	if ( ! ( ( isset( $_REQUEST['wp_customize'] ) && 'on' == $_REQUEST['wp_customize'] )
		|| ( is_admin() && 'customize.php' == basename( $_SERVER['PHP_SELF'] ) )
	) )

	require( ABSPATH . WPINC . '/class-wp-customize-manager.php' );
	// Init Customize class
	$GLOBALS['wp_customize'] = new WP_Customize_Manager;

The key thing to remember is when you are creating your options, you are passing an object. The $wp_customize global object to be a little more specific. As you can tell from the function above, you are creating an instance of the WP_Customize_Manager and setting that as the $wp_customize global variable that can be accessed by using:

global $wp_customize;

Looking at the __construct method, it loads the needed files and adds a few filters and hooks in order for the magic to happen. Totally awesomesauce!

Boom! We have our customizer! Great! But how do we add stuff?

Adding things

In order to add our theme options we have to hook to the right place. The codex has a great explanation on this, though currently it is missing a section on how to add panels. Yes, you can add panels in order to make your theme option logic make some sense for a user.

So, in order to add things we need to know how, right? Right! What’s pretty neat is that the customizer does this with built in methods. Yes, it is very object oriented. One of the other reasons I like it. There are four methods that will help in creating a great customizer experience.


I say customizer experience because as a developer you will have to think about the logic of your theme options. That’s great and all but what actually starts it all? The part that we hook to in order to start our theme options is the customize_register hook. This is done from within your theme by using:

add_action( 'customize_register', 'my_theme_customize_regiter' );
function my_theme_customize_register( $wp_customize ){
	// Theme settings/options code goes here
// or if using a class
add_action( 'customize_register', array( 'My_Class_customize_register', 'register' ) );
class My_Class_customize_register {
	public function register(){
		// Theme settings/options code goes here

Got it? Cool! Let’s keep moving! Let’s break down each method a little more.

The methods

What’s super cool is that the customizer makes it super easy to create a theme option experience. It does this with four different methods. Let’s take a look at each one and what each one has to offer.


The first one we will look at is the settings. In order to create a theme option in the customizer we use the $wp_customize->add_setting method. It takes two arguments. The first one is the ID of the setting and the second is an associative array. It looks a little like:

$wp_customize->add_setting( 'theme_option', array(
	'default' => '', // The default setting
	'type' => '', // can use 'theme_mod' or 'option'
	'capability' => '', // generally 'edit_theme_options'
	'transport' => '', // can use 'refresh' or 'postMessage'
	'theme_supports' => '', // internally used in customizer
	'sanitize_callback', // the callback before setting is saved to database
	'sanitize_js_callback' => '' // used for the JS value
	) );

You don’t have to use all of them. The ones that matter most are the default, option, transport, and sanitize_callback arguments. The reason option is one that matters is in the way it will save the options into the database. The sanitize_callback matters because it runs before the setting is saved to the database so you have to make sure to sanitize it. The transport value can be important if you want the page to do a full refresh or if it will be AJAXified.


The next one to look at is the $wp_customize->add_control. This is what the user will see. Much like the add_setting it, too, we have to pass two arguments. The first one being a unique ID, and the second being an associative array.

$wp_customize->add_control( 'option_control', array(
	'label => '', // label for the control
	'description' => '', // description of the control
	'settings' => '' // the setting 
	'section' => '', // core ones are: 'title_tagline', 'colors', 'header_image', 'background_image', 'nav', 'static_front_page'
	'type' => '', // core ones include: 'checkbox', 'radio', 'select', 'textarea', 'dropdown-pages', 'text'
	'choices' => array(), // associative array of 'value' => 'option user sees'
	'priority' => '', // the higher the number the lower it will appear from the top
	'input_attrs' => array(), // associative array of 'attr' => 'value'
	'active_callback' ='' // based on preview context
	) );

So, we have a few options with the controls. Cool, right? What’s even cooler is that there are few others to use. You can also use WP_Customize_Image_Control, WP_Customize_Upload_Control, WP_Customize_Color_Control, and WP_Customize_Media_Control. They just require a little extra code.

$wp_customize->add_control( new WP_Customize_Media_Control( $wp_customize, 'media_control', array(
	'label' => 'Image selection',
	'description' => 'Choose an image',
	'settings' => 'default_value',
	'section' => 'random_slider'
) ) );


Great! Now that we know how to create a setting and a control, we can look at how to create a section to hold those settings. You’ll notice I’m using settings and options a little interchangeably. As stated earlier you can choose how to save things to the database. The theme_mods or option. How you do it is up to you. Now, let’s look at how to create a section, shall we? This too, like the previous two takes two arguments. A unique ID and an associative array.

$wp_customize->add_section( 'my_section', array(
	'title' => '', // the title of the section
	'description' => '', // description of the section
	'priority' => '', // the higher the number the lower in the customizer from the top
	'capability' => '', // default setting is 'edit_theme_options'
	'panel' => '', // if none it will show on main panel
	'active_callback' => '' // based on preview context
	) );

Simple and fairly straight-forward, right? What’s pretty cool too is that you can use the active_callback to your advantage. For example if you wanted to show a certain section only a widgetized area was being used. You could use a callback like:

// in the customizer
'active_callback' => 'widgetized_cb'
// later on in the code
function widgetized_cb(){
	return is_active_sidebar( 'primary' );


Pretty awesome right? See where some of that logic can come into play? Great! Now you know how to add settings, controls, and sections. We can finally take a look at the final one: panels!

What’s super awesome is that this, too, uses two arguments. A unique ID and an associative array. Notice a pattern here? Let’s look at the available ones:

$wp_customize->add_panel( 'my_panel', array(
	'title' => '', // the title for the panel
	'description' => '', // short description of the panel
	'priority' = '', // the higher number, the lower from the top
	'active_callback' => '' // based on preview context
	) );

As you can see not a lot for the panels – yet. The customizer is constantly being worked on in core. There are a lot of things you can do to make it better if you want to help out.


Okay, this is the part where things really come together because it deals with JavaScript. You remember in the add_setting there was an option for transport? If you want to create live previews without the entire page being refreshed, you set it to postMessage. In order for it to take place you will have to include a little JavaScript. I would highly recommend using a dedicated file for this. All you have to do is hook to the right place and enqueue it.

add_action( 'customize_preview_init', 'my_theme_preview' );
function my_theme_preview(){
	wp_enqueue_script( 'my-theme-js-preview-file', get_template_directory_uri() . '/js/my.customize.preview.js', array( 'customize-preview' ), '', true );

From there your JavaScript file would include something like:

wp.customize( 'setting_id', function( value ) {
	value.bind( function( newvalue ) {
		// do things
	} );
} );

Final thoughts

So there you have a slight crash course on how the customizer works and what options are available to create a good theme option user experience. There are a few little tricks and things you can also do, so go ahead and explore the core code and find out! You’ll be amazed at what you will find.

My gripe with widgets

Yes, I don’t like widgets. Okay that is not entirely true because I am using a few but it’s not what I’m referring to. What I’m referring to is when themes include widgets.

Themes that include widgets for contact forms, testimonials, group -or team- members of a company. Dare I say it? Newsletter widget. Cue dramatic music. Yes, I am referring to most of those. The reason I hate them is because you lose it once you switch a theme. It reminds me of the shortcut icons I see being used by a lot as well. It does drive me up a wall.

Up a wall, you say?

Yes. The reason for that is because there are dozens, and dozens of plugins that can do it and possibly do it better. Some things are not meant to change. The shortcut icon ( favicon ) should be one. In my opinion some widgets should be the same way. I make an exception only because I know there is at least one theme that unregisters core widgets and includes their own extended version of that widget. You still lose that functionality ( keyword right there ) once you make a switch to a new theme.

I know you may be asking and even wondering what argument, or arguments, could be made. Well, some people never change their themes. True. The thing to remember too is that even down the road they may just think about changing that theme. It will be a bad experience once they change that theme and lose the widget(s) they had.

There are some that are purely aesthetic and add to the theme’s experience but should that be the end all to turn to for widget design, functionality? I don’t know but it does seem a little strange that I haven’t seen many themes proclaiming support for certain widgets.

Start a trend

Yes, it would be nice. At least to see some theme authors supporting more and more plugins or specialized widgets. I mean after all that is what the description is for or even the theme’s documentation, right?

Why a theme’s changelog is important

Having some history is a good thing and knowing what changes were made and why is even better. That is one of the reasons that I love seeing a changelog when I look in a theme’s folder. Supposing they have one.

Not all themes are created equal

It’s true. When I speak of themes I generally refer to the themes submitted and maintained in the repository. I don’t mean those that you buy either. I don’t like to because I feel you pay for a certain level of not just support but dare I say care? I don’t know. Just two slightly different areas to me.

The reason I bring this up is because in the middle of making a change to my current project at hand I wanted to know why I chose to use a specific method and why it wasn’t working. At least on my working copy of the project. I tried to think back on what changes I had made and realized I hadn’t kept track of any changes; let alone major ones.

It reminds me a bit of history class. Military History to be exact. Yes, I took that class in high school. It was fun and a neat class to take. I learned a bit about why you use certain strategies and when. Kind of see where I’m getting at? Tactics, planning and thinking ahead were all at play. I just didn’t really think about it at the time. That and documentation. I didn’t do that part.

A little flashback

Over a year ago I came across two trac tickets. #45 on the WordPress meta side and #22810 on the core side. The downside is that is hasn’t had a lot of attention. ( That needs to change ). Personally I think it is a step in the right direction for themes. Users, end-users and developers alike. The reason is of course to keep track of what changes were being made and why. A good thing to look at and know so things won’t break and if they do you’ll have an idea of why and what to look for.

A good example is WordPress core itself. If you checkout the timeline it shows you what changes ( if you look at the changesets ) are made to the project itself. It’s a great reference point to keep if something breaks down the road. One reason I’ve liked using some form of version control is because of that.

Many themes I’ve come across could benefit from this because they make a lot of changes.

A long road ahead

Yes, there is a lot to be done when it comes to themes and better practices. I think a changelog is good one to have. It’s a lot easier when you are using a version control system. Just append the commit message to the file and you have your changelog. Do keep in mind that is one way of doing it, there are others.

I think this may be the bigger hurdle to get over. The formatting of said changelog. I’ve seen more and more that link to a github repository of all the commits, which can be good if you have an internet connection and a reliable one at that.

If you feel like that changelog needs to happen then please go and comment on the tickets. Create a patch. Do something about it.

Keeping count of reviews

I hate posting this but I have to do it; sort of a status check for myself. To see where I stand and where I can be better. We all do it. I choose to do it publicly.

I can’t recall when I said I wanted to have my review count to be at 500 by the end of the year but I did. What review count you ask? Theme review of course. Since the beginning of the year I wanted to allot more time to reviewing and helping release more themes.

I can’t help it, I like to help when I can. It hasn’t been easy for me only because of the way I try and balance work and everyday life at the moment. I get home from work and I just want to review more themes when I should be sleeping.

As of this writing the tally is around 330 themes that I’ve looked over and read just about every single line of code. There are some that I glance over but for the most part I read all the code and of course look for key things when it comes to new themes.

I’m glad I’m keeping a good pace so far and will try and post an update when I finally reach that 500 theme mark.

Regenerate all the things!

HTML formSo, I’ve been dabbling with WordPress for some time and I have loved every bit of it. I even helped a few people along the way. Learned many things and met and talked to many more. Every day I do feel like I am learning something new. Whether that is how to


a certain file, how to remove certain things, how to style and just how to do more things in a different fashion.

It has been amazing! I think the biggest thing taken from all of this is that I need to start sharing a bit more. So I’ll begin with a simple plugin that I feel just about any person using WordPress should at least try out.

That plugin is: Regenerate Thumbnails

But why?

Yes, I know WordPress already has a way of creating custom thumbnails but what if you don’t want to click on several photos. What if you just installed a new theme and the images are looking all funky? What happens when you have to resize and you have hundreds of images? I know I have several photos in my library and don’t always have the time to go to PhotoShop and readjust every single image. Who does?

I know I don’t always have that time. What the plugin actually does is go through the entire


folder and regenerates all the thumbnails.


Yes. Often times when you set a featured image on a post a theme handles the sizing of the image. Some don’t touch it at all and some alter the dimensions to better fit the overall design. While I know that very few companies will actually change their site’s theme it is a very important thing to keep all elements of a site united.

I am sharing this for those that have blogs and are changing the theme every so often and for developers that like to try to break themes.

So by all means, go and try it out. You will not be let down either way.