A metabox for your layout options

It’s no surprise I can be vocal when I am reviewing a theme. Many know that I’ll spurt out what I end up seeing in a lot of themes. There is one thing that really does drive me crazy though and that is when people copy and paste code to their theme without actually knowing how the code actually works.

One file that has really been rather popular is using a metabox in order to choose the layout of the post or page. That’s great. I love that ability but then again who doesn’t love having that control? I think what drives me bonkers is that this code is super predictable before the file is opened. The file adds two actions. One to add_meta_boxes and the second to the save_post hooks. Great! Very super simplistic and hard to mess up, right?

I created a gist with the name of the theme changed. The code is the same that I’ve seen in many other themes though. From authors who have several themes in the repo to new authors to the repo.

One of the first things that you may notice is the use of two globals.

global $post, $deargodwhy_sidebar_layout;

First there should be no reason for that and second those hooks pass the $post object. We’ll look at the first one: add_meta_boxes

Using the developer resources as a guide we see that the hook for adding metaboxes uses two arguments. The post type and the post.

do_action( 'add_meta_boxes', string $post_type, WP_Post $post )

The first one being the string of the current post type and the second being the WordPress post object. Now, what’s super cool about that is that we can now register a metabox in any post type we want and it does on every post type if we don’t pay attention to what we are doing. There is also one more hook we could potentially use in order to use a metabox in only one specified post type. That hook is add_meta_boxes_{$post_type} and the developer docs does explain it a little better. For example, if you wanted to add a metabox to only your EDD downloads, you could do something like:

add_action( 'add_meta_boxes_download', 'jmc_download_extra_metaboxes', 10 );
function jmc_download_extra_metaboxes( $post ) {
	// Do our magic here.
}

In order to now add our metabox we do need to use the function add_meta_box() so let’s take a look at how that function is used.

add_meta_box( $id, $title, $callback, $screen = null, $context = 'advanced', $priority = 'default', $callback_args = null )

Now, if you want to take a closer look at what each one of those parameters actually does then I suggest you take a look over the developer docs. It is well worth your time if you really want to understand how to create a better user experience and understand how WordPress creates those.

Another thing I wanted to look over was the save_post callback being used. The biggest issue is the use of the foreach() loop.

foreach( $deargodwhy_sidebar_layout as $field ){  
        //Execute this saving function
        $old = get_post_meta( $post_id, 'deargodwhy_sidebar_layout', true ); 
        $new = sanitize_text_field( $_POST['deargodwhy_sidebar_layout'] );
        if ( $new && $new != $old ) {  
            update_post_meta($post_id, 'deargodwhy_sidebar_layout', $new );  
        } elseif ('' == $new && $old ) {  
            delete_post_meta( $post_id,'deargodwhy_sidebar_layout',  $old );  
        } 
     }

The reason is it is creating an unnecessary loop. The only thing that needs to be checked is the value being input and to make sure that it is a valid option. A quick change to the code and we have:

if ( ! empty( $_POST['deargodwhy_sidebar_layout'] )
	&& in_array( $_POST['deargodwhy_sidebar_layout'], array( 'right-sidebar', 'no-sidebar' ), true )
	) {
	update_post_meta( $post_id, 'deargodwhy_sidebar_layout', $_POST['deargodwhy_sidebar_layout'] );
}

Knowing those things we could make changes to the file and not only will we have a better understanding of how WordPress creates metaboxes but we have a file that doesn’t pollute the $GLOBALS with info that we only use in one place. If you look at what those changes were in the diff, you will see that not a lot was changed. It only looks that way since I removed a lot of the linting errors.

Video: WordPress template hierarchy

Earlier today I had some time to make a quick video. I have written about the template hierarchy before and I’m sure there are tons of other resources available out there. This justs adds to that ever-growing-list. The reason it drives me crazy is because of that front-page.php file that I see every so often or when I see a theme that uses the Template Name: Front Page in order to create that static front page.

The thing is that the front-page template is meant to be used once. On the FRONT PAGE. Why would you want that page to be in other pages? This is what irritates me most about that.

Anyway, enjoy, don’t, up to you. As for me I’m heading out to get some sculpting tools.

Theme Review tips, tricks, and take aways

WordPress theme reviews are:

  • Fun
  • Entertaining
  • Demanding
  • Awesome
  • Time consuming

There are more but those are the ones that came to mind first. The last one is the one I really want to focus on the most and there is a reason for it. Recently, the review team posted a call to tips on theme reviews. I chimed in and now I feel a little more compelled to expand a little more on my personal site.

I’ve been doing reviews for quite some time and have got quite a few reviews under my belt. Currently about 2,600 that have my name attached to them. Yeah. Safe to say I’ve looked over a lot of code over the years. I have loved every single moment because I love knowing that I have helped out not only one person but an entire community by doing what I do. I am looking forward to being able to make more videos down the road to help others.

So, onward!

Tips

The biggest tip really is get your testing environment setup. My review setup is a little odd. I use Windows 7 as well as OSX 10.9.5 with VVV, Variable VVV, and the development subversion repository to test all themes. Yes, I like to live dangerously. The plugins I use are:

Active plugins

Extra plugins

As you can see I use quite a few plugins and each serve their own purpose. The extra plugins are not always active when I conduct my reviews. I only activate them when I want to try to break the theme or see if it does break.

A great tip is to always look at how core does things. Knowing how core works helps you out in knowing when a theme is creating too much content or even when it comes to explaining to an author how to better improve their theme.

Tricks

Now, the browser is Chrome and my editor of choice is Brackets. I got used to working with it and haven’t tried much else. Was never a fan of IDEs because I grew up looking at the markup in Notepad. Yes. Notepad. We all started out somewhere. I do like using the “Find in Files” feature and regular expressions to looks for certain things within the theme. I setup a few rules so it doesn’t search certain files or folders though the folder restriction is when I’m looking for core code and inline documentation.

regex-search

That’s great and all but that doesn’t really show much else. When I post a comment on the ticket and let the author know I often use one of two methods of letting them know what is still in need of fixing. The first template outlines the requirements and I bullet out what in particular needs to be addressed.

= Required =
Note all required items that theme needs to fix before theme can be approved

== a11y ==

== Code ==

== Core/Features ==

== Plugin Territory ==

== Documentation ==

== Language ==

== Options/Settings ==

== Styles/Scripts ==

= Recommend =

The second:

= Required =

=== header.php ===
* missing translation [L4,l6,L10]

=== functions.php
* plugin: `add_filter( 'show_admin_bar', '__return_false' );` please remove

= Recommend =
* The red on the navigation makes it a little hard to read some of the menu items, consider a darker shade or use a lighter text color

I have always liked using the second method because it forces me to go file by file. That is the reason it can take a long time to review a theme. Even more when some include frameworks. That’s files and folders to look over.

Take-aways

The biggest gain, of course, is that I’ve learned a lot about how WordPress works and how themes are created by many.

One theme reviewers point of view

How to begin? Well, back in 2012 I took the plunge and began my first theme review. It was a great experience because I got a chance to not only learn something but give back as well. I was already looking at themes because I love design. I wanted a different theme for my site and wanted to learn how to create themes. Of course, at the time there was only one in-depth tutorial on creating WordPress themes.

I’ll skip ahead a little bit and get to the part that may be juicy for some. After some time I was able to assign my own themes to review. This was a different time. The capabilities have changed a little over time. The process has – to a degree – changed. Some parts for the better.

Now, what I’m going to share may startle a few and rattle a few cages, but I’m okay with that. Reason is because I know I’m not alone when I feel this way. The process has slowed down too much. What used to take a week is now months. It’s not that reviewers don’t have time, it’s not that we don’t have the people, or the know-how. A lot of it is because there is so much to look over.

Today, I began to think about what needs to be looked over by one person. Yes, one person does a review of one theme. Then an admin looks over and sets the theme live. This process is being worked on.

Now, as I said, I actually counted all the requirements that need be addressed before any theme can be made live. Let’s count them by the sections they are listed:

  • Code: 6
  • Core functionality/features: 11
  • Presentation/Functionality: 1
  • Docs: 1
  • Language: 4
  • Licensing: 4
  • Naming: 2
  • Options/Settings: 4
  • Plugins: 2
  • Screenshot: 2
  • Security/Privacy: 4
  • Selling/Credits/Links: 2
  • Styles/Scripts: 6
  • Templates: 4

Wow! That is a lot to look over, right? Looking at the core functionality and features is a daunting one. Eleven items! Eleven! Add them all together and you have fifty-seven requirements that a theme must meet in order to meet the standard and pass. Now, that does not include the accessibility audit if a theme has the accessibility-ready tag listed. Yes, that too has a few requirements that need to be addressed.

So you can kind of see why it can take some time to conduct a theme review.

The other part is the time frame. Theme reviewers give up to a week for the theme’s author to submit a revised version of the theme with all the fixes. Does it always happen? No. A lot of the non-approved themes are because they didn’t reply in time or didn’t submit it in time. It does happen.

The downside is that some will submit a revised version on the last day before the “deadline,” and the process can then be resumed. The reviewer will look over the changes and make note of any missing requirements. As you can see the time can add up. As that happens, new themes are being submitted and sort of left there without a review.

You can see how they can quickly add up. Currently the wait time to have a reviewer assigned is about seven weeks. You read it right. Seven.

One thing that may make it faster is closing a ticket if the theme does not meet half of the requirements. Okay, great but not all themes have that many issues, correct? It is possible but how many are there that do?

Or perhaps not approve the theme if it doesn’t meet all the security and core requirements? Makes more sense to do something like that, right? At least then we can focus a little more on teaching about better practices and posting on the make blog about theme development.

Don’t get me wrong, this hasn’t stopped me from reviewing themes at all and it won’t. I just wanted to share a different point of view on an ever-evolving process.

The case for no upsell

Today I ran into a bit of an internal debate. This is something that has driven me crazy for the longest time and this time I’m speaking about it.

Having an “upsell” theme in the WordPress theme repository. Quite frankly, I’m tired of it. Not only is it more code to look over but an inconvenience to the user. A commonality is the phrase:

This option available in PRO Version.

It does get linked to the site where they can purchase the theme. I don’t like it. Often times it is because that’s all the setting/control has. If I wanted to look at dummy controls I’d go to the toy store and just play with the toys and never purchase a thing. It is like window shopping for themes only with a banner over the window.
pro-versionAs you can see from the image, it is pointless to even have a pro version with nothing to control. I will never understand that. It is like having a car radio button that does nothing.

Yes, I made that comparison. It really is pointless.

I know there are some out there that may already be wanting to ask how to upsell the theme instead then. Simple. The theme’s about page.

Yes, themes can have them and should have them. What I don’t like is that there are several that link to just a demo site. What’s the point? Yes, I understand you want to demonstrate what the theme can do but what I’m more interested in is what the differences are between the free version and the premium/pro/ultra/supreme/deluxe version you are offering.

When I look to purchase a new camera I look for the information about the camera; I’ve already seen what it can do, I want to know more. What size sensor, what type of sensor, pixel density, lowest ISO, highest ISO, what accessories I can purchase for it, just to name a few.

So, if you are a theme shop in the WordPress theme repository, I urge you to drop all your upsell things that do nothing. You are hurting your users by subjecting them to unusable options.

My review process

Earlier today I made a screencast of how I review themes. This is not my entire method. There is a lot more involved. The things I didn’t do are make the comments in the ticket, assign the ticket, go over any sanitation/validation or comment on some core functions that can be used and may be used incorrectly.

In the ticket I will often try to link to documents that relate to how to correct the issues. There are times when I’ve see the theme author in previous reviews, so for the most part I try to link to the same resources. The main ones I link to are the codex, developer pages, and the theme review required page. Yes, I try to link when I can.

As you can see and hear from the video there are some things that I’m – personally – a huge fan of. I have my reasons. I hope this serves as a quick glance of what at least one theme reviewer goes through when it comes to doing theme reviews.

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 WordPress.org 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.

My 500 and counting

The beginning of the year I promised myself that I would try to review 500 themes by the end of the year. I finally managed to reach that point and was super ecstatic about it that I just had to tweet about it:

Yes, a tweet. Just one tweet. And I even went ahead and made another little challenge for myself for the next goal: 750. No timeframe for that just yet but I am happy I completed the 500 and am making some good traction for the next goal.

Since making that little challenge to myself a few things have changed. One of which is that I am now able to push themes live as well as others. Makes for reducing the queue a little easier and tolerable in my point of view. There are a few other things but I’ll leave that for another post and another time.

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.

Mistakes will happen

This is a bit of a touchy subject since I know I’ve done this before. After all I am only human.

What happened

Here is a bit of background information. The last two weeks I’ve only done a handful of theme reviews. I’m a little upset by it. Part of that reason is because I see some themes that have a lot of potential but are a little restricted by the guidelines. Granted those were already put in place long before I even started reviewing themes.

I know you’re probably going to say that I’m overreacting a little. Maybe I am. But with good reason. I hate being the bad guy.

Seriously

No, I really do. I hate to have to do my job and give people bad news. Apparently I’m really good at it since nearly all my co-workers ask me to break the news to everybody that our store is closed and they have to get out. Unfortunately when it has to be done, it has to be done.

Fast forward a little

The last two days I’ve been lucky enough to look over about four themes. Sad to say that only one of those actually met standards. The others weren’t so lucky. They had a few mistakes that were not seen the first time around.

Like I said, “I hate being the bad guy.”

I had to break the news to the developer that the theme didn’t meet the guidelines and as it stood the theme couldn’t be approved. Of course, the developer asked why now. I simply apologized and told him that mistake happen, sometimes code is overlooked.

Right then and there all I kept wondering was how were these things missed?

Seriously. How??

Flashback

I can recall my first review. I felt like I was going to screw it up so badly. Fear of failure got to me. I skimmed over the code, ran through the paces of how I felt the test should go and made a decision on whether or not to approve the theme. I was younger back then and not as wise. I admit it.

Honestly, it did feel a little daunting. Knowing that a theme I reviewed and approved would be used by thousands of people all over. How can you not fear that.

Now, what brings me to the point I want to make is the last 48 hours. In those hours I saw two themes that had custom post types being registered. I mean really?

Yes. Custom Post Type.

A huge reason to not approve a theme. It is generating content. Once the person changes themes they lose all those things. Why would a developer want to do this? Why, I ask you. Why?

So here is a quick break-down of what I often tend to find are missed:

  • Translation
  • Meta boxes
  • Post types
  • Favicons
  • Social links
  • License for bundled resources

Interesting list, right? Some of those things are simple to fix like the license issue. The others require a little more work if you already have a theme approved. In particular the post types. Yes, those include sliders, portfolio, gallery, items, shopping cart like things that are being registered by the theme. Things that are better suited for plugins. As for the meta boxes, that would depend on how they are being used but I do see one slip through from time to time.

So, if you are a theme developer think about these things when you submit your next theme or want to share it.