The biggest reason for this article is that I’ve been trying to make a final decision on how one (or multiple as the case may be) of my plugins will be developed. Other plugin developers might also find this discussion useful in helping them make decisions.

The example plugin

I want you to have an example of what I’m asking you to discuss, so I’ll give you a few details on the plugin(s) I’m developing. It is a set of extensions to how comments are handled in WordPress. Some of these extensions include:

• Moderate all non-Enlish comments.
• Automatically delete spam on a schedule.
• Turn on/off comments for specific post types by default (like with posts).
• Moderate all trackbacks and pingbacks.
• And more.

The plugin currently has several options like the above. Basically, it’s just an extension to the “Discussion Settings” page in the WordPress admin. It’s easy to see how some users might only want to use one or two of those settings rather than all of them.

Advantages of a single, multi-task plugin

The following is a list of some of the advantages to running a single plugin:

• You only have to run one plugin. Many people live in fear of running “too many plugins” because it might somehow break their site. Realistically, running too many large or poorly-coded plugins would be more of a problem. While you can’t really have too many plugins, this fear from users is something to consider.
• Fewer things to manage. No one likes to update plugins every day. The more plugins you have, the more likely you’ll have to update them frequently. Having to only update a single plugin instead of several is easier.
• Fewer translation files. Translators would only have to update and maintain a single translation file for one plugin as opposed to multiple translations for multiple plugins.

Advantages of multiple, single-task plugins

The list below is some of the advantages of using several plugins.

• You don’t have to load code you don’t need. Using mini plugins means that you only have to load and run code that you absolutely want. With a single plugin, there may be several parts of the plugin that you don’t want to use.
• There’s generally fewer bugs. Less code in a plugin means there’s less chance of bugs arising. It also makes it easier to find and fix bugs more quickly. Thus, allowing plugin developers to quickly get out new releases when they’re needed.
• Fewer database options. With multiple plugins, sometimes you don’t need an option at all. The plugin simply works. With a single, large plugin, each setting might need to be enabled/disabled.

What are your thoughts?

Think about the example plugin I mentioned early in the post. If I allowed you to make the final decision on whether you’d like to see this developed as a single plugin or multiple plugins, which would you choose?

Now, think about the plugins you currently have installed on your site. Are there some that you’d like to see broken down into smaller plugins that only handled specific tasks?

Are there any other advantages or disadvantages you’d like to share?

Currently, plugins add features to the the_content hook, which is problematic. Some of these things are sharing icons, related posts, author bio boxes, and much more. The problem is this tends to get rather ugly, especially with some theme designs. Most of the time, the things that plugins add are shown before the post meta or pagination links when using multi-paged posts.

This issue has been around for years. I’m happy that there’s at least a discussion happening about ways to overcome it. If you’re a theme developer, I encourage you jump in if you have a fresh idea.

I wanted to take this discussion to another level though by fully explaining and further refining my comment on the discussion and why it will work for this situation as well as similar situations in the future. Since some of this isn’t directly related to the ticket, I wanted to kick start a discussion on the overall problem.

The problem

Right now, plugins only have a few places where they can reliably hook content into themes. Sometimes, the hooks that are available aren’t ideal for the scenario. The problem is that WordPress can’t simply introduce a ton of new hooks for themes to start using because it takes a long time for standards to form.

Themes are also vastly different from one another. Therefore, it’s hard to standardize some things while also allowing complete flexibility. Some things, such as displaying a post, all themes must do, so there are some areas that are easier to standardize upon than others.

A solution for themes

Assuming something is decided upon and hooks are added before/after a post is displayed, what happens when we run into this problem later with another area? My solution seeks to handle this too.

The idea is that WordPress would have some predefined “template hooks” that themes are strongly recommended to use, at least until they eventually become a standard. Themes would need to register support for this feature and choose the hooks their templates support.

Suppose the first two hooks are the aforementioned before/after post hooks. Themes would simply add this to their functions.php to register support for these hooks:

add_theme_support( 'template-hooks', array( 'before_post', 'after_post' ) );

In the theme templates, such as index.php, the theme would simply have something like the following.

<?php do_action( 'before_post' ); ?>

Post stuff would go here.

<?php do_action( 'after_post' ); ?>

This method would solve the immediate problem with before/after post hooks to some degree as well as provide a method if we need additional template hooks in the future.

If you don’t like the idea of theme authors dropping do_action() into their theme templates, accompanying template tags such as before_post() and after_post() can be easily arranged.

A solution for plugins

If themes were using this proposed method, plugins would be able to easily check if a theme supported a certain hook and fall back to something else if not.

Sticking with the before/after post hooks, a plugin would need something similar to the following code to add content to the post area.

if ( current_theme_supports( 'template-hooks' ) )
	$hooks = get_theme_support( 'template-hooks' );

if ( isset( $hooks ) && in_array( 'after_post', $hooks[0] ) )
	add_action( 'after_post', 'example_plugin_function' );
else
	add_filter( 'the_content', 'example_plugin_function' );

Is this an ideal solution?

Probably not. There’s not perfect solution for this situation. It’s something that will need to be widely adopted and might take a while to work. Whatever solution is decided on will leave plugin authors doing if/else checks in their code.

Another benefit (or problem) with my solution is that we don’t need to change code in WordPress core for it to work. Themes and plugins can actually take advantage of this now.

There are tons of ideas right now. Do you like my proposed method? Or, do you have a better solution?

Theme developers, please stop bundling shortcodes in your themes that replace basic HTML.

I seriously doubt the Shortcode API in WordPress was built to do things like this. I also propose that using shortcodes in this manner is hurting the theme development community, hindering users’ ability to learn, and creating long term issues that cannot be easily fixed.

An example shortcode

To provide a model in which to present my argument, I’ve created an example shortcode called [note]. There are many shortcodes like it, but I’ll use this as the basis of this discussion. Its purpose is to highlight some text to make it stand out from a post’s normal content.

To use this shortcode, I created some example text in my development install and wrapped it with opening [note] and closing [/note] shortcode tags. In the post editor, it looks like the following:

[note]Hong Kong Phooey, number one super guy. Hong Kong Phooey, quicker than the human eye. Hong Kong Phooey, number one super guy. Hong Kong Phooey, quicker than the human eye.[/note]

That looks eerily similar to something something else many other people use around the Web: HTML. I’ll get to that shortly though.

The following screenshot is what the content looks like when the post is viewed on the front end:

This seems like a brilliant idea. Users wrap some text in a simple-to-use shortcode called [note] and magic happens! They have a cool new design for their text. What could possibly be wrong with that?

Problem #1: The “lock in” effect

Users, here’s what theme developers are not telling you: By using their theme’s shortcodes, they are essentially locking you into using their themes forever.

Let’s take a look at what happens when I switch to another theme that doesn’t have the [note] shortcode. The following screenshot is what the text will look like on the front end of the site.

As you can see, the pretty design for the text is gone and ugly shortcodes are left within the post content. It’s simple enough to delete those shortcodes in a handful of posts, but it’s a huge problem when users have 100s of posts that use this shortcode.

Users either have to figure out a solution to this problem or stick with using the theme. Niether of those options are user friendly.

Problem #2: Replacing basic HTML

HTML and CSS are not hard to learn, especially for something as basic as this. Rather than defining shortcodes, theme developers should define CSS classes for users to use within their posts. There are several benefits to doing this:

• No “lock in” effect as described earlier.
• Provide a way for users to learn some of the basic tools of the Web.
• Allow various elements to use a class, making for more semantic markup.
• No PHP required to create useless shortcodes.

Instead of the [note] shortcode, create a .note class and drop some simple CSS in your theme’s style.css file. The following is all the code it takes to create a “note” box:

.note {
	padding: 25px;
	font: normal normal bold 13px/25px Arial, Verdana, sans-serif;
	color: #0a5e7a;
	border-top: 1px solid #5ea6bd;
	border-bottom: 1px solid #5ea6bd;
	}

Here’s the great thing: you can use this with any HTML element your heart desires (e.g., paragraphs, lists, headers). The following is just a few example uses of the .note class within the post editor.

<p class="note">This is an example paragraph.</p>

<h2 class="note">This is an example header</h2>

<div class="note">This is an example box you can add several elements within.</div>

I have to believe that anyone smart enough to use WordPress has the capacity to learn how to use the class attribute within an HTML element. It’s possible that I’m wrong, but I have a lot of faith in my fellow WordPress users.

The counter-argument

The only possible argument I can think that theme developers can give is that it’s easier for users to figure out shortcodes than basic HTML. It’s a stretch, but I’ll allow the argument.

Let’s suppose [note] is easier to use than <p class="note">. Maybe there’s something inherently easier about using a [ and ] than < and >. Maybe the latter scares some folks off.

Assuming this argument has any validity, there’s still the problem of the “lock in” effect. The easiest solution to this problem is to create a plugin so that users can carry their shortcodes with them from theme to theme.

If you create a theme with custom shortcodes, do your users a favor and create a plugin that allows them to use their shortcodes even when they switch themes. Or, better yet, someone please create a massive plugin with all the known HTML-replacement shortcodes and end this madness.

Seeing an end to the problem

I previously wrote about this issue in the WPCandy’s 2011 theme predictions article. My fear is that this discussion will fall on many deaf ears and the trend will continue.

So, I have a promise to make. I will personally write the required CSS and fix this shortcode problem for any user that signs up for a support membership at Theme Hybrid. I will never lock you into using only my themes and will provide a way around problems like this. I encourage other theme developers to take similar steps.

One of the things I hate the most about news or magazine themes for WordPress are their extensive options pages to handle the front page of the site. I’ve always thought this could be more flexible and more intuitive for the end user.

The idea is to use a custom taxonomy to handle the display of things on the front page of the site.

A typical news theme layout

Before getting any deeper into this subject, take a look at the following image. It is an example of what the front page of a news theme might look like. I’ll use this as an example throughout the rest of the article.

The current state of news themes

In the image from the previous section, there are three front page areas: feature, images, and column. Generally, news themes have a settings page that allows you to select a category to display posts in specific areas on the front page. So, you would most likely select a category for each of those sections.

What this means is that you typically have to create a “feature” category to handle your featured posts and maybe even create new categories for the other sections. Other themes just have variations of this basic idea.

This is poor design and doesn’t make for a great user experience. It doesn’t put the power in the user’s hands.

Using a taxonomy instead of a settings page

Rather than having a settings page to control which categories and so on fit within certain blocks on the front page, consider using a custom taxonomy. This way, the user can select where a post would appear while writing the post itself. This seems to make more sense from the user’s perspective. And, it doesn’t force users to use categories to determine how their site content is displayed.

The following screenshot is an example of what this could look like on the post editing screen.

You could even make this custom taxonomy public, allowing for featured post archives, nav menu items, and so on. There’s plenty of room for innovation in this area.

What do you think?

If you’re an end user, does this type of system make more sense to you? Or, do you prefer a theme settings page in which you must select a specific category to handle the display of the front page?

As a theme developer, do you think this system would work better? If so, what types of areas do you think would be standard in news themes (I’d like to come up with a good default list)?

I welcome alternative ideas too. I haven’t seen a whole lot of innovation in this area in the past couple of years.

The idea of parent/child themes became popular because it allowed the parent theme to be updated while keeping customizations intact within a child theme. That system works great. The problems begin when a child theme is updated. Users tend to want to take advantage of the update, but they can’t upgrade because they’ve made customizations.

Essentially, we’ve just added another layer to the preexisting problem.

But, that’s not where the real problem is at. The problem is confusion over what frameworks, parent themes, and child themes are. Users aren’t to blame for this confusion. Theme developers are at fault here (even me), and I’m going to attempt to clear things up.

Advanced parent themes are not frameworks

I’m going to avoid calling any other “framework” themes out and tell you that my own Hybrid theme is not a framework, at least not in the traditional development framework sense. It’s an advanced parent theme. Admittedly, I’ve called it a “framework” before because I’ve just been following the crowd.

What should we call the Hybrid theme? Simple. It’s a parent theme.

One thing we should definitely not confuse are the terms “framework” and “parent theme.” These two are not interchangeable. That’s where a lot of the confusion stems from.

What is a theme framework?

This is the question I most wanted to answer because I’ll be releasing a framework for theme developers soon (see below). But, I can’t do that with all this confusion floating around the community.

A theme framework is a set of conventions to use for developing WordPress [parent] themes.

Yes, that’s a bit vague, but frameworks can exist for all kinds of different purposes. This can be something like an elegant template engine (Carrington Core is really good for this) or a set of helper functions for more quickly building a theme.

It is not a theme though. You can’t simply drop it in your WordPress themes directory and expect it to work.

Frameworks are for theme developers. They offer a set of standards (or whatever features) for theme developers to use in creating their own themes. They’re a set of functions/features created to aid development.

What is a parent theme?

Nearly all WordPress themes are parent themes. Only those called “child themes” are not parent themes.

Theme developers create parent themes for users to download and install on their sites. My Hybrid theme is, without a doubt, a parent theme. Parent themes should house the theme design, functionality, and the templates required for running the theme in WordPress.

You can use a framework to build a parent theme, but the framework is not a parent theme itself.

What is a child theme?

A child theme is something users should be creating so that they can customize the look and functionality of their site. The child theme inherits all of its functionality from a single parent theme.

When a theme developer creates a child theme, things become problematic because that child theme might eventually need an update. If you’re a theme developer and are building a child theme with a 20kb functions file and five or six custom templates, I can assure you that you’re doing it wrong. I’ve even had to tell myself this.

What you should really be creating is a parent theme. Child themes from theme developers should be nothing more than a stylesheet and a few functions. This idea of releasing advanced child themes just creates the same problem child themes were meant to solve: upgradability.

I’ve got over two years of experience at this point in dealing with parent/child themes if you need a reason to take my advice on this.

How frameworks work

Confused yet? Let me break this process down for you and explain how it should work.

• Frameworks come packaged within a single folder.
• Developers drop the framework folder into a new parent theme and load the framework.
• Users create a child theme based on the parent theme to house their customizations, allowing both the framework and parent theme to be updated.

Here’s a diagram for reference:

Users should only ever have to worry about creating a child theme. This will allow them to make modifications without losing them when the parent theme is updated. They shouldn’t have to worry about all the other stuff.

As you can see by now (I hope), the question of grandchild themes has been completely averted because theme developers shouldn’t be adding advanced functionality (that might need future updating) within child themes.

Doesn’t Hybrid break these rules?

The Hybrid parent theme doesn’t break the rules. A couple of the child themes? Definitely. If I could afford a time-traveling machine (and if they existed), I’d zip back a year or two and turn a couple of those child themes into parent themes instead. We all have to learn from our mistakes, and I can freely admit that I’ve taken the wrong route on occasion.

So, I’m going to give you a real-world example of everything I’ve been talking about and how it could’ve been avoided with one of my own themes.

Hybrid has a child theme called Hybrid News. This child theme has a few extra features that make it more advanced than its parent theme. One good example of a problem was when WordPress 3.0 launched with a new menu system (which I love). The Hybrid News child theme has an extra navigation menu that’s not present within its parent theme.

The problem: How do you upgrade the Hybrid News child theme to use the the new nav menu system for its extra menu?

You certainly can’t expect users to upgrade the child theme and lose all of their customizations. To solve this particular problem, I wrote a tutorial on making the switch to the new system. But, it was just a way to avoid the larger problem at hand.

The solution should’ve been: Make Hybrid News a parent theme. This would allow it to be upgraded and users to keep their customizations intact.

If you’re a theme developer with a lot of advanced child themes, you may be thinking that you’ve got this problem all figured out. You may have already come up with plenty of nifty solutions for avoiding these types of problems. But, no one can foresee what new things will come in later versions of WordPress to conflict with those solutions.

Introducing Hybrid Core: A theme framework

Last year, I mentioned that I’d release Hybrid Core to the public for download. Unfortunately, that release never came out. I wanted some more time to perfect it, which turned out to be around a year worth of extra time.

Hybrid Core will be a theme development framework for use by other theme developers. What this means is that any theme developer will be able to download this and build parent themes with an awesome framework behind them. Yes, I’m essentially giving you the keys to the Theme Hybrid kingdom.

Hybrid Core is currently packaged within my Hybrid parent theme. It is used to handle the “logic” behind how the theme runs. Theme developers will be able to load this framework and build themes using the set of conventions provided by the framework. All of the HTML, CSS, and extra functionality will be left up to you.

In the next month or two, I’ll be putting the finishing touches on this. I’m still moving some stuff around that’s specific to the Hybrid parent theme and getting it out of the way.

It’d be awesome to see many great themes built off this framework. It’s a project that I started building in June 2008, so a lot of work and testing have been put into it. The next theme I build will be a parent theme based off it, so you’ll have a good, working example of how to use the framework.

Just in case you were wondering if building a “grandchild” theme is actually possible, the answer is no, at least not by default. And, I hope to never see the day it happens.

The issue: Before WordPress 3.0 was released, a small piece of code was added to the WordPress core that changes all instances of “Wordpress” (notice the lowercase “p”) to “WordPress” in areas where content is shown on the site. We’ll get to the details in a bit.

I tried hard to stay out this debate because I’m fairly certain I made a vow to myself to stay out of these types of arguments. But, I’ve got a few opinions on this one that I can’t just keep to myself. And, as someone that is considered a leader within the WordPress community, I feel responsible for communicating with that community on this issue.

It’s spelled “WordPress”

WPCamelCase.com says so, and I’d never question an entire site dedicated to the proper spelling of a single word.

On a more serious note, these are not proper:

• Wordpress
• wordPress
• wordpress
• Word Press
• word press
• wordress
• WoRdPrEsS

Coming from an English and journalism (especially journalism) background, I feel a strong need to hack into the site of anyone that misspells WordPress and correct it for them. Fortunately, I don’t know how to hack people’s sites, have just a smidgen of self control, and respect the rights of others.

Why is there an issue?

Matt Mullenweg wrote a filter function called capital_P_dangit() that correctly capitalizes the “P” in misspellings of WordPress where the “p” is lowercase. It may seem like a minor thing, but there are several issues at hand.

• The code literally breaks things like URLs on some sites. For example, suppose you installed WordPress in a /Wordpress directory. That would cause all kinds of trouble with things like images.
• This function is effectively changing what people write, and WordPress should not have editorial control over the content of anyone’s blog.
• The code was committed to WordPress without a Trac ticket, so it wasn’t left open to community discussion beforehand.
• Matt’s responses seem to dismiss the very community of people that help make WordPress what it is.

Following the discussion

I cannot accurately represent all of the discussion that has happened to this point. I highly recommend that you read the discussions provided by the below links if you want all the details.

• “Wordpress” being turned into CamelCase “WordPress” breaks URLs
• Putting the P in WordPress: WP Hackers
• Automatically Correcting the WordPress Mistake
• Wordpress -> WordPress in core?
• MattPress Egomania
• “Wordpress” to “WordPress” filter
• A Fuss About Nothing
• CapitalP.org

Breaking URLs

If nothing else, this issue must be addressed. In fact, this bug was brought up in a bug report before WordPress 3.0 was released. Yes, before.

The resolution set for this bug: wontfix.

A new ticket is now open for discussion and resolutions. Mark Jaquith has at least created a patch that should fix this issue.

Don’t change my content

The real issue is not the bug; it’s the display of content that people didn’t write. Sure, the cases where people actually intend to misspell WordPress are rare, but that’s besides the point.

The point is that the content is yours, and you should be able to write anything any way you see fit, including “WordPress.”

If you want to debate that last statement in any way, I suppose you can try all you want, but I can’t think of a single reason why a piece of software should be able to control the output of my words without consent.

We’re talking about principles here, and changing what people write in this manner goes against everything I believe in. I simply refuse to allow this on my site.

One of the reasons I use WordPress is because of its philosophy on community, openness, and freedom, which fits along nicely with my own personal philosophy about most things in life. The idea that a piece of software could infringe upon those values is what bothers people.

What about emoticons and auto-paragraphs?

What about apples and oranges?

This line of reasoning keeps getting brought up in the debate.

If you think the forced spelling of a word and the opt-in process of converting smileys and basic word-processing are one in the same, there’s no convincing you there’s an issue. You may as well stop reading now.

Why don’t you build a plugin?

According to Matt Mullenweg, a plugin should be built:

As I said before, you are in /complete control/ of your site. It’s a single line to remove a filter. If you don’t like the filter, vote with your feet or with a plugin.

Vote with your feet? This type of remark represents one of the biggest issues in the WordPress community. Attitudes like this can bring down entire empires.

I completely agree with the plugin idea though. Building plugins to gauge community interest in certain features and making the decision to include these plugins in core code based on statistics is a great idea.

As pointed out by Jeff Chander, it just so happens that someone made a plugin nearly three years ago that does the same job as capital_P_dangit(). It’s called Ozh’ Correctly Spell WordPress.

At the time of writing, this plugin has received a grand total of…wait for it…338 downloads!

As flawed as that argument is, a new plugin has been created called Remove Wordpress to WordPress Filter that disables the capital_P_dangit() functionality. Funnily enough, its number of downloads will likely surpass the other plugin within a week or two given its current rate of adoption.

But, since we’re voting with plugins, there’ll be 16 other plugins that will disable this filter soon enough. All of my plugins will have this bug fix added to them in their next updates.

There’s two things that will make me reconsider this decision and remove this from my plugins:

• The capital_P_dangit() function is removed from the default filters or made to be opt-in.
• An outcry of arguments from my plugin users to remove it. Some of us listen to our users, even when we disagree with them.

Since some folks have missed the point of this last argument, which I thought was clever (though I’m a bit biased), I must inject a note here to interrupt the flow of this article. No, I don’t actually intend to update all 16 of my plugins to try and prove a point. The entire point is to show how irrational such an action would be.

How to remove the capital_P_dangit() filter

You can either install the Remove Wordpress to WordPress Filter plugin or add the below code to your theme’s functions.php file.

remove_filter( 'the_title', 'capital_P_dangit', 11 );
remove_filter( 'the_content', 'capital_P_dangit', 11 );
remove_filter( 'comment_text', 'capital_P_dangit', 31 );

Listen to your community

I’ve only seen a handful of people that agree this function should be in WordPress. It has been met with harsh opposition. The people arguing to remove this function are people we need in the community. They’re plugin developers, theme developers, contributors to core code, and evangelists for the WordPress platform. These are the people that continue making WordPress better.

Don’t alienate them.

Are these people only a vocal minority of WordPress users? Certainly. However, these people speak for a larger amount of users. For users without the knowledge of mailing lists. For users without the understanding of how Trac works. They are the people that interact with the majority every day. They are the voice of the majority.

Don’t let their voices go unheard.

When I’m asked how I got to the point I’m at in the WordPress community by upcoming developers, the best response I can give them is: It’s the little things that matter. If you’re not taking care of them, then the big, grand things you’re doing will only get you so far.

What are the little things?

The little things are usually things that WordPress does that slightly irritate me. They don’t irritate me enough to switch platforms, but they are things that I wish were different.

I’ll show you an example of just what I mean with two pictures of the same comment using different themes. See if you can find the major difference (i.e., the little thing) between the two.

The first is from the default WordPress theme:

The second is from the development version of my Hybrid theme:

Notice the difference?

The default theme displays the title text of the edit link for a pingback as “Edit comment,” which is standard for WordPress. The Hybrid theme displays “Edit pingback” instead.

Why make these little changes?

At this point, you may simply think I’m crazy for changing “comment” to “pingback,” but the example is hardly the point.

What’s more important is that I would’ve likely had a user come along one day and ask, “How can I change ‘Edit comment’ to ‘Edit pingback’ for the pingback comment type?” Rather than having to explain how to do this or even coming across the question at all, it’s already done.

An equally valid reason for doing so is that this is simply how I want things done on my personal blog. And, when I code something that benefits me, it’s easy to give that back to the community.

Those little things do matter

While you may not take things as insanely far as I have in my example, it’s important to recognize how these seemingly insignificant things can help you and your users. For example, this can translate into fewer support questions or become marketing points for your plugins/themes.

Attention to detail is the extra thing you should bring to the table, and end users always appreciate it when the details are covered.

The problem with providing backwards compatibility is twofold:

1. Users continue using old versions of WordPress.
2. We have extra code to worry about.

Force users to upgrade

With the recent security scare that targeted older versions of WordPress, blame is being thrown around left and right, from everyone to users to the WordPress developers. While staying updated with the latest version of WordPress isn’t going to make your site 100% secure, it will make it secure from known security exploits.

By providing backwards compatibility in our plugins/themes, developers are partly responsible. We’re giving users an excuse to not upgrade. Obviously, developers are not to blame for people not upgrading their sites, but we can do our part in helping them stay secure by not supporting older versions of WordPress.

How do we not support older versions? Some things are simply going to be backwards compatible because they require no new WordPress functions, so we can’t do anything about those plugins. The best thing to do is to use new WordPress functions as they become available and are useful to your plugin or theme.

Why would you want to support older versions of WordPress? There’s no point in doing so.

Get rid of code you don’t need

Maybe you really don’t care if users’ sites are hacked from staying on an older version. That’s fine. Another valid reason for keeping with the latest WordPress trends is that you don’t have to check for functions.

How often do you use the function_exists() and/or the class_exists() functions?

If you’re checking if a WordPress function exists, you’re doing so because you’re supporting older versions. Do yourself and your users a favor and just call the function. If it breaks a user’s site, tell them they need to upgrade. Maybe even take a moment to explain the benefits of upgrading to them.

Provide the best possible themes and plugins

The WordPress developers have done about all they can do to make sure people upgrade, but we should take a bit more initiative as developers within community, the people that end users actually interact with. By forcing users to upgrade, we’re helping them stay secure.

Before writing this post, I tried to think of valid reasons to provide backwards compatibility and only thought of one, and that’s the crossover period between major version upgrades. This period should last about one month. This gives users ample time to upgrade and provides support for people with WordPress MU.

I’m certainly open to other ideas about how plugin and theme developers can get more involved in the security of their users’ sites. Feel free to leave your thoughts on how they can.

Now that the project has seen some success, it’s time to give the directory a much-needed upgrade.

When the theme directory launched, Joseph Scott wrote:

With the success of the plugins directory, we’ve wanted to have those same benefits in a theme directory.

But, the theme directory is missing some key components of the plugin directory.

What needs to be added to the theme directory

Uploading a theme right now is easy, but there’s a barrier that we don’t have with the plugin repository. With plugins, you simply type the name of your plugin, description, and optional URL. Once that’s done, you’re given access to the Subversion repository (usually within a day). You can upload and/or update your plugin at any time within 15 minutes.

With themes, you must upload a zip file and wait for someone to approve it within a day or so. This is done on the first upload and every update.

What happens if you made a mistake and want to fix it? You can’t update it in 15 minutes on the repository. You have to repeat the upload process and wait for it to be approved again.

Another useful thing missing is the ability to add custom sections to the theme’s page through the readme.txt file, which is also a plugin repository feature. Imagine how beneficial it would be to users if theme authors could add installation instructions and a FAQ to each theme’s page.

Quality control and Subversion

Subversion access allows us to quickly and easily update plugins. Plus, it helps us keep track of different versions. Judging by Scott’s post, I’m not sure Subversion access has ever been planned for themes.

We’ve gone through great lengths to make this as painless as possible for theme authors. You don’t need to know anything about Subversion.

To be perfectly honest, I’d rather not use a theme created by someone that couldn’t figure out how to use the Subversion repository. And, this sounds like a bit of a cop-out.

It seems they’re really telling us that they want to control the flow of themes through the site. They want to make sure themes carry that GPL license. Make sure they have all the suitable CSS classes and other such things that themes require.

There’s nothing wrong with a bit of quality control on the theme directory. In fact, I expect it.

Maybe the missing link is trust

There are better ways to control the quality of themes being shown on the site. For example, we could allow users to flag themes (plugins too) as breaking the rules or as not being good enough for the directory.

Theme authors have gotten a bit of a bad rep over the years. We first had the sponsored links predicament back in 2007 and the more recent purging of over 200 themes from the directory.

Basically, themes have been used to game the system.

One would think we’d be past that point. Allow the community to deal with the things that shouldn’t belong. Things of the past are hurting those of us trying to play by the rules now.

I really just want Subversion access

I’m not sure of the real reasoning behind the differences of the plugin and theme directory. I suspect it’s either that theme authors are seen as being too dumb to use Subversion or there’s no trust. If the former, I am deeply offended. If the latter, we need a better system.

It just feels like I’m stepping back into the Dark Ages anytime I need to update my theme on the repository.

What are your thoughts? Should theme authors be given the same access as plugin developers? Or, should the system stay the same? Are there any specific features you’d like to see added?

Also, has anyone heard any news on whether child themes are/will be allowed?