Quantcast
Channel: Justin Tadlock
Viewing all 153 articles
Browse latest View live

Lowercase p, dangit!

0
0

If you haven’t been following the latest hot debate in the WordPress community, you’re in for some news. If you have been following it, you’re probably in a fiery rage, given up all hope in the “community” aspect of this community project, or are just sitting back laughing at the rest of us.

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.

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.


Frameworks? Parent, child, and grandchild themes?

0
0

One question that crops up every once in a while from my theme users is how to create a WordPress grandchild theme. Most of the time, a user asks, “How do I update my child theme? Do I need to create a grandchild theme?”

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:

Theme structure when using a framework, parent theme, and child theme

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.

Rethinking how news themes work

0
0

As I was working through the post and taxonomy chapter in Professional WordPress Plugin Development and checking out the new post formats feature for WordPress, a light bulb turned on in my head. I wanted to change how we think about news themes.

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.

Front Pages News Areas

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.

Custom taxonomy for news themes

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.

Predictions on WordPress themes in 2011

0
0

Several developers and community members predict what the future holds for WordPress themes in 2011. You can find my predictions mixed in with the bunch.

Dealing with shortcode madness

0
0

At some point in the past year, a disturbing movement has been growing in the WordPress theme development community. If you’ve ever looked at a few themes from Theme Forest, you might have noticed this horrible trend. This isn’t just a Theme Forest issue though; it’s a problem that’s growing in the theme development community and must be eradicated.

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:

Note shortcode screenshot

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.

An unrendered shortcode

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.

A better way for plugins to hook into theme templates

0
0

An interesting discussion has popped up on WordPress Trac about making it easier for plugins to insert content before/after the post is displayed.

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?

One multi-task plugin vs. several single-task plugins?

0
0

Recently, I’ve been giving a lot of thought to the debate over whether it’s better to develop larger plugins that handle many related tasks or smaller, mini-plugins that handle extremely specific tasks. There’s merit to both arguments, but I wanted to give my readers a chance to discuss this and help me come to a decision about how I developer some of my future plugins.

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?

Proposal for widget-only plugins in the repository

0
0

For some time now in a few WordPress circles, there have been discussions on being able to find plugins that are nothing but a standalone widget. I even wanted to set up a “widget store” back when I was working for DevPress. That idea was never fully fleshed out. But, I’d still like to have a way to install just widgets.

After hearing this discussion on one of the WPCandy podcasts last night (forgot which one), I started thinking of solutions. Now, I would like to propose some changes for the WordPress plugin repository.

Step #1: Get plugin developers involved

WordPress.org has no real mechanism in place to let us see plugins that are just a widget. Therefore, I propose that the community step up and make this happen. With that in mind, I’m unofficially declaring the widget-only tag be used in all plugins that are only a widget.

How would you add this to your plugin?

All plugins in the repository are required to have a readme.txt file with some important information the repository needs for setting things up. Let’s take a look at the readme.txt file a widget-only plugin of mine called Query Posts (yes, it needs some update love).

=== Query Posts ===
Contributors: greenshady
Donate link: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=3687060
Tags: widget, pages, posts, sidebar, page
Requires at least: 3.0
Tested up to: 3.0.1
Stable tag: 0.3.2

There’s a line for “Tags” that allows plugin authors to input tags for their plugins. So, to update my plugin, I’d change the line to the following.

Tags: widget-only, widget, pages, posts, sidebar, page

If you’re a plugin developer who has some widget-only plugins, would you use this tag?

Step #2: Make widget-only plugins visible to users

We need to get some support from the higher-ups to put a link to the widget-only tag somewhere on the front page of the plugin repo.

Users need a way to easily find widget-only plugins. Most of them won’t know about this tag, so just having an easily-discoverable link could help tremendously.

Steps #3,4,5,…: See where it takes us

Let’s not get ahead of ourselves just yet. I’d like to see some support put behind this proposal before we start making huge plans. There are some questions that need to be answered first, such as how popular this feature will be and whether users actually like standalone widgets.

But, folks like me can always dream for now. ↓

Screenshot of standalone widgets in WordPress backend

Update: Looks like the movement has begun.


Blackballed at WordCamps

Move over UI team

0
0

I want to start this article by thanking the people who put their time and effort into keeping the WordPress admin working. It’s not easy, and I’m glad I’m not one of the people doing it.

But, let’s face it. WordPress’ admin is cluttered and complicated for many people. It’s a miracle that the folks who work on it have been able to keep it together all this time.

I have a roommate who uses WordPress to run his blog. However, I have a part-time job simply teaching him how to use it. And, it’s been three years since I first set him up. He’s not the brightest of fellows, but when I envision what WordPress should be like, I imagine WordPress.org featuring a picture of him with his testimonial — So easy, a hick from Alabama can use it!

Over the past few years, WordPress has taken on a lot of new features. However, the downside to adding new features is that you must squeeze them in alongside the existing features. The new features are nice, but the WordPress admin has put on a few pounds. It’s time to trim the fat.

The great thing about WordPress is that you can change something when you don’t like it. You can take steps to unclutter the edit post screen. You can build a custom color scheme to make your admin prettier. Or, you can build a full-blown admin theme.

Lately, there’s been a rising trend toward a simpler admin. Admin themes might just be one part of the equation to getting there.

Why admin themes?

Because they’re cool.

When developers create something new, it’s generally to solve a problem. Admin themes can solve the following.

  • Give users more options for what their WordPress admins can look like. Wouldn’t it be awesome if theme developers were also releasing custom admin themes to go along with their regular themes?
  • Improve the WordPress UI. With more options available, it will get more people involved in the core WordPress UI. It will also present ideas to the UI team that maybe they haven’t thought of.

With that in mind, let me introduce you to a new admin theme.

DevPress Dashboard

Over the past month or so, I’ve had a chance to talk with Tung Do about WordPress admin themes. I’ve also been a test dummy for the past week while he perfected an awesome plugin that reshaped everything about the WordPress admin.

This is one of the most beautifully-designed admin themes I’ve seen in a long time. It makes the clutter of the admin seem much more freeing. I don’t know if it was just refreshing to see something new or if it’s just that damn nice, but I’m a fan.

The following is a screenshot of the “Dashboard” screen of the DevPress Dashboard plugin’s default design. You can view more screenshots on the plugin’s page.

Screenshot of the DevPress Dashboard plugin

The only thing I might see that could keep this plugin from gaining traction is that you must be a member of DevPress to access it. I’d much rather see a default plugin + theme combo for free with additional commercial designs. Even still, the plugin alone is worth the price of membership at DevPress.

Shameless self-promotion: DevPress themes are built off my Hybrid Core theme framework, so you’d be getting an awesome deal by joining the site.

Where does WordPress go from here?

For others to build beautiful admin themes, WordPress has a little shaping up to do.

First and foremost, inline styles halfway down the admin pages need to be moved into an external stylesheet where possible. It’s extremely tough trying to write custom CSS when you’re hitting roadblocks like inline styles.

Another thing we need as plugin developers is even easier ways to build stuff in the admin. The better tools we have to create things in a standardized fashion, the easier it is to style these things. The goal should be to standardize as much as possible.

Take a look at how easy it is to build theme customizer options. That’s straight up theme developer crack. I’ll take more of that, please.

Stop building custom-designed admin screens

Theme and plugin developers, please start using the tools available to you. I have yet to figure out what’s so hard about using the built-in Settings API. If you follow the rules, the rest of us can do some truly awesome stuff.

For theme developers, everything you need is there. I’ve never seen a theme settings screen that required anything more than what’s available via the Settings API. If it does, I’m 99.9% sure that you’re doing something you shouldn’t be doing in a theme. Besides, who wants to build theme options pages anymore now that we have the theme customizer?

For plugin developers, there are situations where you need more robust admin screens. Gravity Forms immediately comes to mind. However, for the vast majority, what you need is built in.

If you have a scenario that core doesn’t handle well, propose it on WordPress Trac. Submit a patch. Get involved.

More admin themes

I’d love to see more WordPress admin themes in the future, but it might be a brutal slugfest with non-standard plugins/themes and WordPress itself. Although, I believe WordPress core will eventually get there.

If you’re interested in developing admin themes, hop over to the Admin Themes repository on GitHub. It’s a little project I’m building to make it easy to build and use custom admin themes. It’s in the extremely early stages, so don’t expect much yet.

And, if you’re interested in getting involved in the WordPress UI, head over the the UI blog and see what you can do to help.

Term meta and post relationships in the future?

It’s legal but unethical

0
0

Some people in the WordPress community are still trying to hold on to that last shred of proprietary licensing. That idea that their code shouldn’t be shared with others. That it’s wrong to use their creations freely.

The thing that really irks me is that people are using open source in name only. They stamp a GPL license on their code to appease the community leaders. Then, they proceed to call anyone who uses that code “unethical” if it’s not to their liking.

You’ve probably heard a few of these other words thrown around too:

  • immoral
  • disrespectful
  • dishonest
  • stealing

This has been an ongoing theme in the WordPress-o-sphere for a while. It’s time to stop this nonsense.

The latest “scandal” has been about WPAvengers. I have my issues with that site and how the owners are going about things, but I don’t consider what they’re doing with the code unethical in the least.

This post isn’t about WPAvengers though. Many of the reactions to this story just brought back some feelings I’ve had for a while about commercial theme/plugin providers and their followers in the community.

Principles of open source

Before moving forward, we have to look at the four core freedoms that provide the foundation for open-source software.

  1. The freedom to run the program, for any purpose.
  2. The freedom to study how the program works, and change it so it does your computing as you wish.
  3. The freedom to redistribute copies so you can help your neighbor.
  4. The freedom to distribute copies of your modified versions to others.

These freedoms are essential. They’re not trivial things. Not just WordPress, but the Web as we know it today would be a much different place without this foundation.

If you’re a WordPress plugin/theme developer, any time you call someone unethical for exercising one of these four core freedoms, you’re doing a disservice to both the WordPress and open-source communities. I consider it in bad taste and unethical in and of itself to say such things.

You gave me permission

A “license” is merely a means of giving permission. When you license your code under an open-source license, you’re giving anyone who gets a copy of your code the permission to excercise the four freedoms above.

Others do not need additional permission to use your code. You’ve already given it to them for that purpose. That’s the reason licenses exist. They’re a method of giving permission.

Please stop saying people “stole” your code if they’re using it under the license in which you placed on it.

Get over it

People are going to take your code. I don’t care what license you have it under. If you put it under an open-source license, you told them that it was okay.

There seems to be at least two different camps people belong to when it comes to using their code.

  • Those who are happy.
  • Those who are angry.

I’d argue that the last group is highly detrimental to the community. If you’re angry about people taking your code and excercising any of those four freedoms, it’s not good for your health. That’s too much stress and wasted time on things that are of little consequence. You’d be much happier and productive if you put that focus and energy into creating cool stuff with WordPress.

I recommend joining the first camp. Embrace those people who are using your code. If you decided to fork my theme framework (fork), I might even write a nice blog post about you. I can’t tell you how many times people have passed code fixes/features back upstream to me when they’ve forked something of mine.

It’s all about the atmosphere. When we get angry about these things, we create a toxic atmosphere, one that isn’t good for anyone.

If we start changing how we view the use of our code, we start changing how the system works. We build better tools for working together. We build a stronger community around our products.

Embrace open source

WordPress itself was built on open source software. It is a fork of b2. The very rock upon which WordPress is built is the GPL, a license which keeps those four freedoms intact and has helped WordPress become the content management system that it is today.

Those of us in the commercial WordPress ecosystem must understand what this means because it can change how we do business. But, it seems to me that many people are still holding on to those ideals of proprietary software in an open source system. While I have nothing against closed-source software, it’s not what WordPress is about.

We must adjust our thinking. We need to think about how we can build products that fit in line with open source and learn to live with that. If you don’t adjust your viewpoint, you’ll be that same ol’ guy commenting on blogs five years from now about how some dude is not “respecting” you as a developer because they “stole” your code and are doing so “unethically.”

If everyone can learn to embrace the philosophy at the heart of WordPress, it’ll make the community a much nicer place and one that I’d be much prouder to be a part of.

One last thought: it’s not unethical to practice the four core freedoms of free software. Let’s stop saying anything different.

The post It’s legal but unethical appeared first on Justin Tadlock.

Elite

#1 Millions of Users

0
0

A month ago, Brian Krogsgard posted a great piece called On WordPress themes and frameworks. In the “Drop-In Frameworks” section of the article, he mentioned, “Drop-in frameworks are probably the least known and worst marketed theme frameworks available today.”

That statement is so true.

As many of you know, I have a [drop-in] theme framework for WordPress called Hybrid Core. Part of the reason I think these types of frameworks are often not known about is because most of what they do is behind the scenes. They’re not at the forefront of everything like themes typically are. So, they don’t get much attention.

Another reason is that there are so few of these frameworks around. Not to mention, the guys who built these things are horrible at marketing. I’m so bad at marketing that I’m going to publish this post at 12 a.m. on a Saturday morning.

This is the first of many posts I plan to write to rectify this situation. So, reason #1 of 101:

1,748,663 downloads

As of right now, there are 1,748,663 downloads of WordPress themes built off the Hybrid Core framework on the WordPress.org theme repository. That’s not a bad number.

No, all of those themes were not created by me. Here’s a list of all the theme author profiles I used to gather this data (ordered by number of theme downloads).

Theme shops/clubs

While the official home of Hybrid Core is at Theme Hybrid, other theme sites use the framework as their foundation.

The following is a list of my favorite theme sites using Hybrid Core.

Of course, other theme shops use the framework. Some use it as their foundation on sites like ThemeForest. Others, like WooThemes, integrate parts of Hybrid Core into their own code.

Freelancers and design agencies

Brian Krogsgard, the lead WordPress developer at Infomedia, uses it in their projects (I really wanted to just link back to Brian since he’s such an awesome guy).

I could, of course, go through a list of the 100s of freelancers and design companies who are using it every day, but it’d take me a while to gather up all those names.

What does it all add up to?

Hybrid Core powers millions of sites across the Web.

I don’t usually think about it that way. But, when I start looking at the sheer numbers, it overwhelms me sometimes. I’m the sole developer behind a project that gets used that much. Of course, I’m fortunate enough to have a ton of help and feedback from other developers and designers who are making use of the framework.

Mostly, I’m glad I just haven’t completely destroyed too many sites yet. :)

I’ve focused a lot in this post on the people developing/designing with Hybrid Core. The reason for this is because they represent those millions of users and sites. Without all these great folks building off the framework, well, I suppose all those users would have to use something else.

The point is that the Hybrid Core framework has been in development for 5 years now. It’s battle-tested, has a few scars, and keeps on keepin’ on. It’s possible that millions of users could be wrong, but I’m not betting against them.

I left a lot of names and links off the list above. I’m sorry if I overlooked you. There are so many great people doing great things, that it’s hard to keep track of them all. Just know that I appreciate all your work. Feel free to drop a link in the comments if you build with Hybrid Core.

The post #1 Millions of Users appeared first on Justin Tadlock.

#2 Your markup. Your design. Your theme.

0
0

We’ve established that loads of people use the Hybrid Core framework, but that’s not necessarily a good reason for you to use it too, right? I mean, tons of people watched Jersey Shore, so pure numbers don’t always add up to a good thing.

Therefore, let me appeal to your developer/designer side a bit.

How most theme “frameworks” work

There’s always been a bit of discussion about what actually constitutes a theme framework in the WordPress community. Let me go ahead and clarify what most people call a theme framework.

  • It’s a parent theme.
  • The parent theme creates the markup.
  • The parent theme houses the functionality.
  • It has lots of hooks, which can often create a steeper learning curve.
  • Child themes are then created to behave, usually, as an entire them unto themselves.

It’s no secret that I disagree with that definition of theme framework. Don’t get me wrong; I love the ideas there and use them myself. I just disagree that those things should be considered a framework. Essentially, you could then call just about any theme a framework.

How Hybrid Core is different

First of all, it’s not a theme at all. It’s a library that you use within your theme.

I created Hybrid Core because I needed a way to take bits of theme-specific functionality and apply them to many different themes without having to re-code those things every time.

Basically, I created a framework that mostly consists of standalone scripts that you can pick and choose to use, all of which aid in the process of theme development. This ranges from things like breadcrumbs to numbered pagination. Or, things like a powerful thumbnail script and a custom colors feature for the theme customizer.

Before releasing Hybrid Core, I had a popular [parent] theme like the “theme frameworks” mentioned above. However, it became very clear to me that no matter how many hooks there were or ways to override things, it just couldn’t handle any project you threw at it. For that, theme developers really needed complete control over their own theme. And, this control should actually be real HTML, not spaghetti code all mixed into a functions.php file.

Not to mention, most users just don’t understand using hooks without education. Many of them already have a working knowledge, even if limited, of HTML and CSS.

I needed to cater to both a development crowd and DIY users.

That’s where Hybrid Core came in. It’s a framework that you drop into your theme. Any theme designer could instantly use a set of pretty nifty tools and apply them to any markup structure they wanted. This allowed for a few things:

  • Theme template files could actually look like HTML with WordPress template tags mixed in.
  • Users of those themes don’t necessarily have to override template-related things via functions.php anymore, which has been an outdated process since WordPress beefed up child theming with template overriding.
  • The learning curve is decided by you. You can create a theme and only use the parts of Hybrid Core you’re comfortable using.

As a theme designer, Hybrid Core hands the control back to you while still giving you the power of the framework’s features. It also allows you to create a theme that shouldn’t confuse your DIY users.

I just want to write CSS

Okay, so not everyone wants to create full-blown themes. They just like fiddling with CSS to make pretty designs. That’s perfectly fine. A lot of my users like to do that too.

If you can remember that far back, I helped pioneer child themes back when WordPress only allowed a child theme to be a style.css file (ahh, the good ol’ days). If that’s really your thing, here’s three perfectly good Hybrid Core built themes to start with for that:

Wait. What if you want to get your feet wet with something more advanced than child themes? We’ve got you covered there too. Here’s two awesome themes that will guide you into making your own custom parent themes:

A little something for everyone

The Hybrid Core framework was meant to get the hell out of the way. It’s markup agnostic. It’s design agnostic. And, best of all, your users never have to know they’re using a framework. You’re just providing them with a theme that looks and feels like a theme.

Of course, you could make it as complex as you want it to be. But, that doesn’t sound like fun.

I’ve just given you basic HTML back. How does that sound as a selling point for a theme framework?

The post #2 Your markup. Your design. Your theme. appeared first on Justin Tadlock.


The ThemeForest Experiment: One Year Later

0
0

One year ago, I decided to run an experiment on ThemeForest. The major goal behind the experiment was to see if I could bring some awareness to other theme authors there about writing better code and playing nicely with the 1,000s of other themes and plugins out there for WordPress.

Selling my soul

Okay, not really selling my soul, but I knew I’d catch a lot of flack if I was just an outsider shouting at all the people inside. I needed to have ThemeForest creds. I needed to put my money where my mouth was.

That meant I needed an actual product on ThemeForest.

Submitting a theme

The number one rule for me was that my ThemeForest product had to meet the WordPress.org Theme Review Guidelines, which is something very few of the ThemeForest themes that I’d seen could do.

I was surprised to learn that my theme passed on the first go. It even got a $45 price tag, $10 above the minimum. Overall, it was a fairly painless experience (though I’d like to point them toward Creative Market for a much better example of how to make authors’ lives easier).

The one thing I disliked is that the reviewer rated my documentation level as “Some Help,” which may or may not have hurt sales (I’d love to poll real users on this). While I didn’t have a 100-page manual or video tutorials packaged with the theme, I covered each and every aspect that was specific to the theme. I even covered things about using WordPress in general (nav menus, custom header, custom background, etc.). I think the reviewer was accustomed to seeing oodles of documentation for products that required 4 hours of setup before use. Themes that “just work” must’ve been rare for my documentation level to be rated that low.

Overall, the experience wasn’t bad at all. Things went smoothly. Of course, following the WordPress.org Theme Review Guidelines meant that I was already a step ahead of many themes submitted to ThemeForest.

The financial aspect

While making a ton of money wasn’t a major goal of mine, I wanted to walk the walk and see if it would turn out anything. Whether I sold 1 or 1,000 themes didn’t really matter that much to me financially (though extra dollars are always nice). I already have a theme and plugin business of my own.

Because so many people focused on this part of the experiment, let’s get the juicy details out of the way.

Ultimately, I made $2,017.50 off 99 sales (part of that time as a non-exclusive author). As I had assumed, most of those sales came in the first month ($777 from 38 sales). Obviously, many of those sales were made for two reasons:

  • People were supporting or interested in the experiment. Several people told me as much when purchasing.
  • New theme exposure on ThemeForest.

So, yeah, the theme didn’t really sell that well. It was more than enough to get myself a nice Christmas present last December though (new Sony laptop).

Even without a lot of sales, I had many people, including ThemeForest authors send me messages and emails to let me know they respected what I was doing. Many of them also said they wished they could follow suit but selling on ThemeForest meant competing in the themes arms race; they just couldn’t take the risk.

As a final note on sales, I did absolutely zero marketing of this theme (other than the initial experiment article). I just wanted to see how it’d do on its own. Ultimately, I think with a little marketing and 10 – 15 themes on ThemeForest, I could’ve done extremely well financially. I would’ve just had to work my way up in the rankings by doing my thing and doing it well.

Pulling my theme from ThemeForest

Now that the experiment is over, I decided to pull my theme from the ThemeForest marketplace. I’ve updated it, changed a few things, and have submitted it for review on the WordPress theme repository (download). Now that it’s been a year, I think it’s time to give a little back to the community.

I don’t know if I’ll ever submit a theme to ThemeForest again. I’d like to think I might now that I have a little more experience with how their marketplace works. We’ll see. I’m going to focus on my own site for a while.

Changing hearts and minds

The main goal was always about raising awareness of standard WordPress practices. While I can’t claim all the credit (maybe even none of it), I’d like to think that I played some small role in helping push two major changes by ThemeForest over the past year.

If nothing else, I’m happy to see Envato pushing to get their WordPress theme marketplace in line with the rest of the WordPress community. These two moves are huge because it shows that they recognize that there’s been a serious problem and are taking steps to correct it.

Theme submission requirements

The one thing that’s making plugin developers like myself giddy is phase 1 of the new submission requirements, which would mean following best coding practices for theme authors. Most of us hope this means that we won’t have to spend countless hours debugging poorly-coded themes to keep our plugin users happy.

All other things aside, this is just awesome. Thank you.

Ultimately, phase 2 is what is going to make users happy if it’s done right, even if the users don’t realize it at first. Phase 2 of the new requirements would mean forcing theme authors to follow WordPress conventions by separating plugin and theme functionality. The reason this is so important is for data portability. I could write an entire article on the importance of this, but it comes down to making sure your users have access to their content when they switch themes (and, yes, they’ll eventually switch themes).

Why the new requirements will fail

I’ve already seen some caving to the vocal minority when the first revision of the requirements was released. It’s important to listen to their feedback, but you must do what’s going to be best for you as a business. I consider playing nice with the rest of the WordPress development community better for long-term business than caving to a small percentage of the most vocal of your theme sellers.

The second reason is skirting the rules. Based on what I’ve seen in the forums, many authors are just looking for ways to do what they’ve already been doing but just putting it in a plugin packaged with their theme. Basically, they don’t want anyone to “steal their code” nor do they want to truly make a wonderful user experience, one in which users will keep coming back long after they’ve switched to a new theme. If you package your plugin functionality into a plugin that’s only ever going to be useful with your theme, then you’re _doing_it_wrong(). That’s what I envision, but I hope that’s the sort of thing Envato will take a stand against. Otherwise, you’re just pulling the same ol’ tricks in a different costume.

Envato/ThemeForest, prove me wrong.

GPL. Woo-hoo!

I think many of us are happy to see this. I’d like to see the numbers and percentages of theme authors who have switched over to the GPL option. Those would be some interesting stats to look at.

One thing I’d really like to see ThemeForest do is allow for more open-source licensing options, not just the GPL. There are many GPL compatible licenses available.

I’d also like to see all WordPress themes there licensed under a 100% open-source license, but I’m living in a dream world if I think that’s happening.

Community involvement

Over the past year, I’ve met a lot of wonderful people at ThemeForest. I’ve gotten over a dozen emails from theme authors there who have told me that I’ve helped them by just preaching the WordPress gospel. A lot of them simply didn’t realize that there are better methods for doing things. They’d been so indoctrinated by the smooth sliders and shiny toys offered by other theme authors, that they just followed along.

This is all about the culture. ThemeForest has created an environment that promotes themes with the biggest and most bad-ass bells-and-whistles as something to be proud of (surprisingly, this is not from an American company).

I love the nature of competition as much as the next guy, but there has to be limits to how far we’ll go before we lose the thing that makes artistic pursuit worthwhile and the integrity of how we do business.

Not building themes

The biggest wall I hit when talking with some theme authors went something like, “We’re not building themes; we’re building a Web site solution.”

Actually, no you’re not.

ThemeForest is in the business of selling WordPress themes. Selling anything else is underhanded at best and false advertising at worst.

If you want to sell a “Web site solution” or whatever you want to call it, you’re selling on the wrong marketplace. Go create your own site and sell these applications for WordPress.

Solutions

Are you just ranting or do you have actual solutions? Well, I’m glad you asked.

One of the biggest hurdles ThemeForest must jump is separating plugin and theme functionality. This has been my main focus point over the last year. Thus far, I have built three plugins for helping with this and have more on the way.

These plugins handle functionality that I often see in themes at ThemeForest. The idea is to get theme authors to adopt a standard (whether it’s my plugins or someone else’s). Think of the standards that BuddyPress, bbPress, WooCommerce, and others have set. That’s the type of thing I’m interested in.

This idea was taken with little enthusiasm on the ThemeForest forums.

If theme authors don’t start adopting standard plugins for functionality, you’ll see many different plugins packaged in ThemeForest themes with countless options, all of which will be incompatible with each other. For example, Johnny Appleseed might build a portfolio plugin with the portfolios post type and Jane Smith might do the same thing with the jane_portfolio post type. That’s no good for users.

Therefore, I’ve taken it upon myself to start building some of these plugins. Feedback and patches are always welcome. The code for all plugins is available on my GitHub account.

Custom Content Portfolio

Custom Content Portfolio was the first plugin. There are many themes on ThemeForest with custom portfolio setups. But, no user could use their portfolios if they switched themes. This plugin was meant to bridge that gap.

I did get some decent feedback on this plugin in the forums. Thanks to everyone who provided the initial round of feedback. I’d love to hear more though.

By the way, some Theme Hybrid theme authors are starting to add styles for this plugin in their themes.

Grid Columns

The Grid Columns plugin spurred some good discussion. This plugin was created to give a standardized way for handling those [column_one], [column_two], and so on type of shortcodes theme authors were adding to their themes.

These column shortcodes were an experiment gone wrong in themes. Not only were they locking users into using themes, they were also breaking filters and shortcodes from other plugins. Not to mention, who needs 20 different shortcodes to handle what one can do?

My solution was to create a simple [column] shortcode plugin that had plenty of hooks and was easy to override. There’s absolutely no excuse for theme authors to include column shortcodes in their themes anymore. Just create custom styles (if needed) for my plugin. Your users will thank you in the long run.

Whistles

A couple of days ago, I released the Whistles plugin. The first version of this plugin was a proof-of-concept that we can make a better experience for users when displaying tabs, toggles, and accordions (possibly even more bells-and-whistles to come).

As with the column shortcodes, the same reasons for not including shortcodes for these things in your themes applies.

This one’s a little different though. It requires adoption by theme authors to make it look purty. That’s just the nature of this type of plugin. I highly recommend getting involved with this project if you’re a theme author, particularly if you’re good at admin UX design and jQuery goodness.

Wrapping up

He says as he looks at the 2,000+ words tallied by his word counter.

I have mixed feelings about it all. Right now, I don’t feel like much is going to change at ThemeForest. Many theme authors will find new ways to create the same problems. They’ll just need to be more creative about it. I hope I’m wrong on this point.

It’s been an interesting experiment. I got to know some cool people. I got a shiny, new laptop out of the deal. And, users have gotten three new plugins out of it.

I suppose I’d call that a win.

The post The ThemeForest Experiment: One Year Later appeared first on Justin Tadlock.

Why custom post types belong in plugins

0
0

Just to be clear before continuing, this article specifically deals with publicly-distributed themes and plugins, whether free or commercial. It may not apply to some custom work. What’s best for your client will have to be decided on a case-by-case basis.

I and others in the WordPress community talk a lot about putting custom post types, taxonomy, and content-generation features into plugins. We say it’s not a good idea to put this stuff into your theme. However, it recently occurred to me that the reasons for this are rarely explained in full detail.

This article will primarily focus on custom post types because they’re so prevalent in “premium” themes, but it’s really about any features/functions that can be used to create content.

What is a “content-generation” feature?

Essentially, anything that a user can use to create content falls into this category. The following is a list of some examples.

  • Custom post types.
  • Custom taxonomies.
  • Custom database tables.
  • Custom shortcodes.
  • Custom comment types.

If a user is creating some type of content or data on their site, they’re using some type of content-generation feature or tool.

Why users should be concerned

The first part of this article will focus on user concerns. If you’re a WordPress user, these are things you’ll need to take into consideration.

The lock-in problem

I’ve previously written about the lock-in problem in a post on shortcodes. The lock-in problem is when a user is forced to continue using a theme because their data would be lost to them if they switched to another theme.

Let’s face it. User’s switch themes. That’s the beauty of the WordPress theme and plugin system. A user can continue using the same plugins (functionality) and switch themes (presentation) daily if they want to.

If a user can only create certain types of content or loses access to that content after switching to another theme, that’s a major problem.

This is also a loss of functionality. Some post types have functionality tied to them, not just content. So, you might lose access to both your data and specific functionality that you had before.

Data portability

When custom post types were first introduced, it was an awesome time to be involved with WordPress. I even wrote one of the most popular tutorials on post types. Unfortunately, many people have used that tutorial to do more harm than good.

Custom post types in WordPress gave us a way to create custom types of content. There’s that word again — content.

Let’s suppose for a moment that your theme created a custom post type with the name of portfolio_item so that it could allow you to build a portfolio of your work. This seems harmless enough, right? It actually sounds like a good thing.

The reason it’s not a good thing is because your data is now tied to your theme. It is not portable.

When we talk about “data portability” in the WordPress community, we’re primarily talking about being able to keep and access your data regardless of the theme you’re using.

What happens when you switch to a theme without the same, exact post type defined? Suddenly, you can no longer access your portfolio. It doesn’t show on your site. Your portfolio items aren’t in the admin. They simply disappeared.

Granted, the data still exists in your database. You just can’t get to it without the proper WordPress functions.

Recreating content

Let’s suppose you did find another theme that had a portfolio post type after switching from the old one. You might think that it would allow you to use your data. That may or may not be true. It actually depends on the post type name.

In the example above, I used portfolio_item as the name. However, another theme might define that as portfolio. If those names don’t match, you must recreate each of your portfolio items if you wish to continue displaying your portfolio and using this new theme.

What you can do as users

You may be thinking as a user that you have no control over this. You actually do. Any good theme author listens to questions and feedback.

If you’re purchasing a commercial theme, be sure to find out if you’ll lose your data when switching themes before you make your purchase. Find out what plugins the theme supports or suggest plugins to the theme author.

It just seems a little crazy to me to spend $50 or more on a theme only to find out a while later that all your hard work has disappeared when you switched to another theme.

Theme authors

Obviously, this post is focused on themes. In this section of the article, I hope to explain the reasons you should stop adding post types to your themes and give you alternatives.

Separating function from form

WordPress has two systems for extending the platform:

  • Plugins
  • Themes

Plugins are meant to be installed on a site and provide functionality that can be used with, essentially, any WordPress install. They hook in their own functions using the plugin API and “do stuff”. Plugins have few limitations on what they can do.

Themes, on the other hand, are limited in comparison to plugins. Their purpose is to handle the presentation of the user’s data. They have a fairly strict set of rules they should follow because they need to conform to certain conventions in order to properly present that data.

Are there times when the line between theme and plugin functionality gets blurred? Certainly. There’s no denying that. However, I’ve rarely seen a case where that line wasn’t clear when it comes to generating content.

Reasons to put your custom post types in a plugin

I’ll just list off a few:

  • User concerns: For all the reasons I covered above about users.
  • Code re-use: If you decide to make another theme in the future with the same post type, you then have to maintain code in two (or more) places. If you place it in a plugin, you have only one set of code to worry about. Any good programmer knows it smarter to have it in one place. This is like Programming 101.
  • Playing nice: Wouldn’t it be great if other theme authors could build themes using your plugin? That just makes you more famous and popular in the WordPress community.
  • More users: Providing a plugin will provide another avenue for users to find your theme work. This is free marketing for your themes.
  • You’re a designer: There are some people who do both design and dev work, but most theme authors lean toward the design side of things. Why put all the effort into programming when you could be designing?

Examples to follow

One of the things I envision for the future of WordPress is a trusted set of plugins that define standards for post types and related data. The idea is that if you wanted to build a portfolio theme, you’d design for the most popular portfolio plugin. Or, if you wanted to build a restaurant theme, you’d choose the best restaurant plugin to design for.

Plugins like bbPress, BuddyPress, Jigoshop, WooCommerce, and others have already been paving this path.

When was the last time you designed a theme with built-in post types for forums, forum topics, and forum replies? Most likely, you’ve never done that. You simply added some templates and created some custom CSS for the bbPress plugin.

Are you building an entire e-commerce solution in your theme? I didn’t think so. You’re designing for Jigoshop or WooCommerce.

Why is it that you’re adding other post types to themes but not those? It might be for lack of a standard community plugin. If that’s the case, why are you not building that plugin and setting the standard?

What good is data without the theme to present it?

This is a valid question. Again, I’d really like to point out the plugins above as fine examples that answer that question.

Realistically, you need a theme that was specifically designed for a plugin to present the data in a beautiful way. But, if more theme authors start using and backing specific plugins, users will gain more choices rather than being stuck.

Let’s look at my portfolio plugin as an example. At the moment, it’s not that popular. However, there are now several themes that support it. Imagine if every “portfolio” theme for WordPress supported that plugin. Users would have tons of theme choices.

What I’m trying to do with that plugin is set a community standard for portfolios. Getting valid feedback on it from theme authors will help push that standard. Oh, and you actually have to support it by designing your themes around it (a few templates and some CSS).

Do you really need a post type for that?

I’m not entirely sure that my main example, portfolios, should qualify for their own post type. I see a case being made either way. One thing I ask you to consider as a theme author is if you even need a post type to do what you need to do.

Consider the portfolio_item post type. For many of the themes I’ve seen with this, all they really need is a custom page template that pulls in “image” (post format) posts.

Just give it a little thought. Consider if a post type is truly necessary first.

Edge cases

I’d like to take a moment and say that I do think there are use cases where these rules don’t strictly apply. With that said, this is usually not what I see in most themes.

If you think you have a good reason for adding a custom post type to a theme, I can probably give you a reason not to. Actually, I’ve probably already covered it above.

Questions/Comments

Feel free to ask me any questions about overcoming any development hurdles from a plugin or theme author standpoint. I’ve done a lot of work with custom post types over the past few years. I’ve done some of the greatest things and made some of the dumbest mistakes you can do with them.

If you’re here to just complain about “how that’s impossible”, then there’s little point in commenting. I’ve heard it all before. If you think something is impossible but are willing to work with me, I’ll be glad to discuss it with you.

The post Why custom post types belong in plugins appeared first on Justin Tadlock.

Theme template hooks are outdated

0
0

Believe it or not, there was a time when child themes were only a style.css and screenshot.png file. It wasn’t until August 2006 when they were allowed to have a functions.php file.

We wouldn’t see the ability for child themes to have their own templates until two years later when Ian Stewart opened one of the most important WordPress Trac tickets in the history of theming. Some of you may even remember the days when the only way to achieve this feat was with a plugin coded by Kristin Wangen. Those were the days, right?

These two changes marked vitally important points in history that drastically changed the landscape of WordPress theme design.

How template hooks became common

Back in 2008, Ian Stewart had the Thematic theme and I had the Hybrid theme. There was also Sandbox, the theme from which these two theme concepts derived. Thematic and Hybrid were the two big players in the community when it came to child themes. It was a concept that few people knew about. Sandbox had made it popular with some designers, but Thematic and Hybrid made it popular with many more 1,000s of users.

It took a while to grok the idea of child themes for many, but people were flocking to these two themes.

The ideas behind the child theme concept were:

  • You could upgrade your parent theme without losing your modifications.
  • You could create many different designs without writing the markup.

Users want to make theme modifications. Everyone wants their own personal touch to their site. But, child themes were limited at the time. You were only allowed a style.css, functions.php, and screenshot.png file.

This is where template hooks became extremely useful. Both Thematic and Hybrid allowed you to hook in at various places and insert whatever content you wanted (action hooks) or overwrite existing content (filter hooks). You could do this with a little bit of code in your child theme’s functions.php. The idea was brilliant. It was so brilliant that other theme authors caught on. The practice still exists today to the point of being commonplace.

Here’s the problem though: What are hooks? What’s a functions.php file? Oops, my whole site just went blank!

A theme’s functions.php file is dangerous territory for your average user. Hooks are part of the Plugin API. They were created for plugins to hook into various parts of WordPress and do cool stuff. It’s no place for Jimmy Joe to be messing around in.

We needed something better.

Overwriting templates

I mention Ian Stewart’s ticket as being the most important change to WordPress theming ever. That made it possible to overwrite templates in child themes, which makes a lot more sense to average users. HTML and a few template tags are a lot easier to deal with than the complexities of hooks.

This change was not without its drawbacks. Overwriting an entire template for a minor change in the posts loop wasn’t that useful. It was still better to use a hook for minor adjustments.

This brings me to the second most important change in theming history: the introduction of template parts (note the function named was later changed to get_template_part()). Template parts are a method of breaking a larger template down into smaller parts.

We had already been using template parts for headers, footers, and sidebars for some time. This change gave theme authors the ability to create custom template parts that theme users could overwrite in their child themes.

Making template hooks irrelevant

There has been a push to get a set of standard template hooks into WordPress core for a while. The problem with that is the adoption rate by theme authors and that all themes are coded a bit differently.

I question whether this enhancement to WordPress is useful anymore for two reasons:

  • With the introduction of template parts, child theme users can more easily make modifications.
  • Plugins really don’t need many more hooks (more on this below).

In the past year or so, I’ve been making major changes to themes at Theme Hybrid. I’m starting to build themes without template hooks. Yes, one of the guys who pioneered this movement is now pulling out. I’m breaking down my templates into smaller parts because:

  • I can cut back on some duplicated code.
  • I can create context-specific sections of code.
  • Users can digest minor bits of HTML and template tags better.

After 5 years of support questions, it’s finally sinking in — users understand HTML and template tags better than their functions.php file.

It’s much simpler for me to say, copy breadcrumbs.php into your child theme and do this than to say add_action( 'hook_name', 'your_func' ), functions.php, etc. One is easier than the other.

My advice to theme authors is to start rethinking your use of hooks. This is not to say that all theme hooks are useless. Hooks are a powerful feature and useful for many things.

Giving plugins some love

There are areas in themes where plugin authors have needed hooks for years, particularly areas surrounding posts and comments. Hooking into these two areas has been notoriously wrought with issues.

I’m all for adding in a few extra hooks to make plugin authors’ lives easier. Plus, with the WordPress.org theme review process, we can make sure theme authors adopt these new hooks in any theme coming through our system in a reasonable amount of time (we already do this for the wp_head and wp_footer hooks).

However, right now, I can’t get behind a project where we’re adding in a ton of new template hooks, not when the problem template hooks were meant to solve can now be solved with smarter template logic. Also, I have a method that would allow WordPress to auto-create additional hooks when using template parts.

The post Theme template hooks are outdated appeared first on Justin Tadlock.

#3 Grabbing media like a boss

0
0

Video post in the Socially Awkward WordPress theme

Now that Hybrid Core version 2.0 has been officially released, I thought it’d be a good idea to continue this series of posts highlighting cool stuff from the framework.

In this post, I want to introduce you to a feature we call the “Hybrid Media Grabber” because it can be pretty useful for theme authors who want to do awesome stuff with media.

An idea was born

Way back when I was a partner at DevPress, Tung Do had this awesome design (like he always has). Unfortunately, there were parts of it that none of us on our team really had the skill level to code without making it hard for the user and not portable to other themes.

Does this sound familiar to any other developers? Yeah, those pesky designers don’t know the limitations of the software.

What we needed was an easy way to get a video (YouTube, Vimeo, self-hosted, etc.) for a post and put it wherever we needed it for the theme’s design. That’s a bit of problem for a couple of reasons:

  • We could use custom fields, but that wouldn’t be portable to other themes.
  • The user could stick it in the content, but that’d make it hard to get out.

After our team parted ways, this idea stuck with me. I also found that I needed it for one of my own projects later.

Eventually, WordPress got lots of new stuff for working with media, which made this idea look a lot more realistic. I was motivated to get this thing done and first used it in Socially Awkward, a media-focused WordPress theme.

What does the media grabber do?

Well, it grabs media.

More precisely, it grabs media related to a post. It first looks within a post’s content for media that’s been added by the user. If no media is found, it’ll look for media attached to the post.

The ability to do this is cool for a couple of reasons:

  • You can get a post’s media without showing the full post content.
    • Use it in a widget.
    • Show it alongside excerpts on archive-type views.
  • You can split this media from the post content on single post views.
    • Show it above the content.
    • Show it somewhere else on the page.

It’s the audio/video equivalent of featured images, which has a lot of potential. Video theme, anyone?

The feature supports a lot of different methods of adding media that the user might have used:

  • Plain ol’ HTML <video>, <iframe>, and <object> tags.
  • [embed] shortcode.
  • WordPress auto-embeds.
  • [audio] and [video] shortcodes for self-hosted media.
  • The Jetpack plugin’s audio/video shortcodes.
  • Attached media files.

What does the future hold?

Right now, the media grabber only supports audio and video. However, I could easily see the day when other types of media are supported.

I’m also willing to work with plugin authors who have custom shortcodes for adding media. Jetpack integration was phase one. It’d be nice to integrate with other plugins too.

The post #3 Grabbing media like a boss appeared first on Justin Tadlock.

Custom post type standards

0
0

There has been some talk recently of setting some standards for custom post types in the WordPress community. Actually, this has been an ongoing discussion for a few years. I think I’ve made it clear that I’m a fan of this idea. So, I wanted to present my take on this discussion.

I also want to expand on this a bit because this is something I’ve been preaching for years. However, I don’t think I’ve ever explained what I mean completely.

What can we standardize?

When most people talk about standardizing custom post types, what they’re usually referring to is standardizing on a post type name. That’s a good start because WordPress stores this in the post_type field for a post. Therefore, a post is directly tied to its type.

It makes sense to have some standards on some common post types. Here’s a few:

  • testimonial
  • portfolio_item
  • recipe
  • faq
  • event
  • product

That’s a really, really good idea, right? Let’s standardize on some post type names so that there’s at least some portability between different plugins. It’s fairly easy to create a working group of standard names. An official page on the WordPress Codex wouldn’t hurt.

However, I’d argue that a little common sense also goes a long way. If you’re making an “events” plugin, don’t name your post type justin_event. Name it event. This isn’t really brain surgery, and I don’t think the WordPress developer community needs that much hand-holding to figure this out. But, if we do, let’s start that Codex page.

The only reason for any type of standards for post type names is so that it helps foster healthy competition between various plugins trying to fill the same space. This is so users can more easily switch between plugins to find the one they like the best.

We’ve been talking about the wrong problem.

While naming standards have been a problem, that’s not that big of a hurdle to overcome. That’s not the problem anyway. Brian Krogsgard explains the big problem perfectly in his article on post type standards:

For years we’ve been talking about the importance of not “locking in” users to CPTs bundled with themes. At some point, that gained decent adoption, but people still tended to just package the same code that was in their theme and put it in a separate plugin — a fine practice for sure. But it’s not a practice that makes it much easier to go from one portfolio theme to another …

People are still using their own, separate code rather than adopting existing solutions, preferring a solution built in-house instead of joining together with others. That’s the reason we don’t have standards. It really has little to do with post type naming conventions.

Standards are created after we’ve made them and they’ve been adopted by enough people. In other words, we create standards by building good plugins, getting users to install them, and having theme authors integrate with them.

A look at a standard that exists.

I want to provide a real-world example of an existing standard so that I can fully explain my meaning.

If you’re doing anything with e-commerce and WordPress right now, you’re either using WooCommerce or you at least took a long and hard look at it before deciding on a different solution. WooCommerce is the standard for e-commerce in the WordPress community. I don’t think anyone can argue that point.

Why is it the standard? Well, it’s got a whole heck of a lot of users and a wide adoption rate by theme authors who are building themes for it. That pretty much makes it the standard.

Does anyone know what the post type name is (I didn’t before writing this post)? Not that it really matters since they’ve established the standard in this space, but the main post type used is product. That fits right in with my common sense approach mentioned earlier for naming standards. If you’re a plugin developer who wants to compete in this space, you sure as hell better name your “product” post type product and follow all the other standards that WooCommerce has already established (post types, metadata, taxonomies, etc.).

Here’s the thing about post types though. They’re not really about registration (i.e., naming them). Post types are about implementation. What I mean by this is that we create standards by building the best plugin for the specific scenario. We can talk in circles about proper names all we want, but it’s not really getting down to the point.

Now, let’s get to the real point.

It’s not really about post types is it? Take a moment and think about it. Think about WooCommerce for a moment. Do you really care what post types it creates?

No. I didn’t think so.

What matters is building solutions. They’ve got a solution that works as evidenced by both the user and developer community around the plugin.

Ask a single non-developer WooCommerce user if they care at all about this discussion.

Shameless self-promotion

Hey, it’s my blog, so I’m going to point out my own plugins. Here’s a few solutions I’m working on. I’d love to get both plugin and theme developers on board these projects to help make them more of a standard in the WordPress community.

  • Whistles (GitHub) – Tabs, toggles, and other fancy bells-and-whistles. (need UI/UX developers).
  • Custom Content Portfolio (GitHub) – Portfolios (could use input from theme authors).
  • Restaurant (GitHub) – Restaurant management (lots of room for add-on plugins; definitely commercial plugin potential).

I’ve also got a few other projects in the pipeline. The only way these upcoming projects and those listed above will gain any traction is by use. What good is a Restaurant plugin if no one is building themes that will beautifully display the food menu items?

You want standards? Help me out. Help each other out. Let’s join together and build cool stuff.

The post Custom post type standards appeared first on Justin Tadlock.

Viewing all 153 articles
Browse latest View live




Latest Images