This is the second in a series of posts documenting the creation of Theme Friendly.
Day 1 Screenshot
Most of day one was spent planning and implementing the data structure for the new site. As you can see, I didn’t do too much work on the design:
Data Structure
One of the greatest challenges in attempting to build a theme review site in just one week was to create a data structure that would be simple enough to build quickly, but complex enough to hold all the data I wanted to include. I started off by creating two new custom post types:
- Theme Authors
- Theme Reviews
The “Theme Authors” custom post type only records a few details, such as website URL and location, so I’ll just move on to discuss the more complicated “Theme Reviews” post type.
The “Theme Reviews” custom post type holds the individual theme reviews. Since I won’t be writing a commentary on each theme (just recording theme data), I removed the WordPress editor from the backend and added 3 custom meta boxes.
The first meta box has input fields for basic theme details such as URL, price, license, etc. It also has a select list to specify the theme author. This select list is automatically generated based on all the the authors in the “Theme Authors” custom post type.
The second meta box has three text areas to hold the output generated by the Theme Check plugin. The Theme Check plugin doesn’t categorize it’s output, so I have to manually edit it and remove any duplicate error messages. I then can group these messages into three groups: theme requirements that a theme fails to meet, warnings that a theme generates, and recommendations for theme improvements. The three textareas mentioned earlier hold these three groups.
The third meta box has checkboxes to record issues with the theme that the Theme Check plugin doesn’t handle. These issues have to be checked manually. They include things like: HTML Validation, Javascript errors, features that should be reserved for plugins, support for built in WordPress classes, ARIA landmark support, unwanted image overflow, etc.
Finally, there are a number of custom taxonomies to record things like which features, plugins, page templates, and layouts are supported.
Implementation
I want all the theme and author data to remain independent of the theme that I will be using, so I needed to implement these features outside of the theme itself. I started out by creating separate plugins for each custom post type, but I quickly realized that much of the code used to do things like display meta boxes and sanitize input data was duplicated. Combining them into a single plugin allowed a significant reduction in the amount of code used.
The other thing that really saved me time when adding multiple custom post types and numerous custom taxonomies was the code generators provided by Themergency. The custom post type generator and the custom taxonomy generator are both top notch and I would highly recommend them to anyone looking to add custom post types or taxonomies to a project.
What’s next?
The next article in this series will cover the single theme review page on the front end. To be notified when it is posted, or to be the first to find out when Theme Friendly launches, sign up for the Theme Friendly newsletter.
Also, if you are a theme author and would like your theme to be reviewed, please contact me.
Why not use Pods?
While I’ve heard some good things about Pods, there are a few reasons I chose not to use it.
1. When possible, I like to work directly with WordPress and its APIs to reduce dependencies and to keep my WordPress skills sharp.
2. I didn’t want to take the time to learn a new system. The demo video itself is over 20 minutes long!
3. I had already written quite a bit of code for other projects that I could simply reuse here. When possible, I like working with my own code because I know what it does, and if I need support, I know who talk to :]
Have you used Pods? How did you like it?