function hwp_cached_query() {

	if ( false === ( $hwp_query_results = get_transient( 'hwp_query_results' ) ) ) {
		$hwp_query_results = new WP_Query( 'cat=5&order=random&tag=tech&post_meta_key=thumbnail' );
		set_transient( 'hwp_query_results', $hwp_query_results, 60*60*24 );
	}

	while ( $hwp_query_results->have_posts() ) : $hwp_query_results->the_post();
		echo '
<ul>
	<li>'; the_title(); echo '</li>
</ul>
';
	endwhile;

	// Reset Post Data
	wp_reset_postdata();

Quick breakdown:

	if ( false === ( $hwp_query_results = get_transient( 'hwp_query_results' ) ) ) {

Here we check to see if the transient entry exists.

		$hwp_query_results = new WP_Query( 'cat=5&order=random&tag=tech&post_meta_key=thumbnail' );
		set_transient( 'hwp_query_results', $hwp_query_results, 60*60*24 );

If our cached data doesn’t exist, we’ll run our query and cache it. In this case, we’re calling our cached entry ‘hwp_query_results’, using the $hwp_query_results variable, and setting the expiration for 24 hours.

function hwp_enter_title_here( $title ){
	$screen = get_current_screen();

	if ( 'custom_post_type' == $screen->post_type ) {
		$title = 'Custom Post Type Title Text';
	}

	return $title;
}

add_filter( 'enter_title_here', 'hwp_enter_title_here' );

Quick breakdown:

	$screen = get_current_screen();

This gets our current admin screen attributes — we’ll use this to make sure we’re viewing our custom post type.

	if ( 'custom_post_type' == $screen->post_type ) {
		$title = 'Custom Post Type Title Text';
	}

Here we check for our post type (replace “custom_post_type” with the name of your post type) and define the title text.

	return $title;

Finally, our function returns the title field text to the filter.

add_filter( 'enter_title_here', 'hwp_enter_title_here' );

All we need to do is add our new function to the ‘enter_title_here’ filter.

At first, I had a very hard time understanding why such a fairly benign post spiraled into a civil war of words.  Truth is, I shouldn’t have had any trouble understanding at all.  It blew up for the same reason most conflicts do — the upper echelon has been ignoring the hoi polloi again.  Oh, and vice-versa.

We can get a better understanding why this the community blows up over and over if we look at a few key words and phrases that get tossed about in WordPress circles these days…

Meritocracy

Ah, yes, meritocracy… A term often used and abused by people like Matt Mullenweg, Jane Wells and others in the WordPress community to describe the hierarchy and management of the team.  I’ve posted a definition of the word so that we can be clear on its meaning.

mer·i·toc·ra·cy  (mr-tkr-s)
n.pl.mer·i·toc·ra·cies
1. A system in which advancement is based on individual ability or achievement.
2. a.  A group of leaders or officeholders selected on the basis of individual ability or achievement.  b. Leadership by such a group.

– The Dictionary

Frankly, when I hear someone describe WordPress as a meritocracy, I can’t help but laugh a bit.  Ya see, I’ve spent a fair bit of time meeting developers over the last few years.  In fact, I’ve had the privilege of sitting down with a number of regular core contributors and even a couple of core committers.  Though I won’t name names, 9 out of 10 agree that, although ability and achievement do play a part in the “meritocracy”, it’s mostly a game of politics, ass kissing and playing favorites.  So, basically, if you’re not at least 99% on-board with the upper management, there is no place for you in the core WordPress group.

So, is WordPress really a meritocracy?  It’s pretty obvious from the outside looking in, and apparently from the inside looking in, that ability and intelligence are required but often trumped by favoritism and your ability to suppress any opinions you have that might not fall in line with the powers that be.

The vocal minority

Another term that’s been used quite a bit as of late.  The vocal minority is mentioned on the WordPress Philosophy page and as it’s presented there, it makes perfect sense:

There’s a good rule of thumb within internet culture called the 1% rule. It states that “the number of people who create content on the internet represents approximately 1% (or less) of the people actually viewing that content”.

In context, this is a great rule of thumb.  The statement is made regarding content creation and individuals on the web.  The problem is, it’s being used quite a bit to describe developers that use WordPress for their clients.  Once we alter the context of who the vocal minority is, it makes no sense at all.

Fact is that developers rarely speak for one person.  They each work with clients, typically dozens of them, and some have a client-base of thousands.  These developers probably have a wider and better perspective on how people want to use WordPress than many of those in the WordPress core group, so when a small handfull of developers start to rally around a feature that’s been removed, or disagree with a change that’s been made to the Admin UI, they’re more than likely not a vocal minority and probably speaking for more of the user community than those making decisions choose to perceive.

…we look to engage more of those users who are not so vocal online. We do this by meeting and talking to users at WordCamps across the globe, this gives us a better balance of understanding…

I’ve attended a few WordCamps and I’ve been to many WordPress centric meetups and events.  I don’t believe this statement to be true at all.  Perhaps I’m wrong, but every time I’ve had the opportunity to join in with a group of users and whichever core group members were there, the issues of the “vocal minority” are often the same issues that become central topics at WordCamps.  Every time I’ve gone out for drinks with fellow developers, their needs and wants seem to bare an uncanny resemblance to those that are dismissed as one-off needs of the “vocal minority”.

Patches Welcome

The ever more popular “Patches Welcome” response that core team members fling around is rarely realistic.

Often times a patch is outside the ability or comfort level of your average developer. Combine that with the fact that patches are often ignored or met with an angry us-vs-them mentality, the message of “patches welcome” is viewed more as a fuck you than an invitation to actually submit code.

It’s “Us” vs. “Them”

Not really something I’ve heard coming from the community — but it doesn’t surprise me when I hear it directed towards the community by highly regarded core contributors and committers.

Fact is that most of the community really appreciates what WordPress has done for them.  Whether a community member is a blogger just talkin’ about life, a hobby enthusiast that shares their passion and makes a buck or two on the side,  a freelancer earning their living installing, customizing or building really big things on WordPress – they all love the fact that WordPress exists.

Most of them, however, don’t think their gratefulness should extend to the point of blindly agreeing with core when they feel poor decisions are made; this seems to be a sensitive issue for many in core.   Disagreement is often met with aggressive and sometimes downright abusive responses.  I can’t count the number of times I’ve heard the phrase “Vote with your feet”.

Vote with your feet

Well, I guess we can finish off where we started.

If you don’t like the filter, vote with your feet or with a plugin. -Matt Mullenweg

“Vote with your feet” was a very popular phrase with WordPress A-Listers over the last couple years, but judging by the reaction to Kevinjohn and his vocal decision to ditch WordPress, I think what they meant to say is “Vote with your feet and please don’t say anything bad on your way out the door because we can’t deal with any sort of negative criticism”…  Not quite as catchy as “Vote with your feet”, eh?

Fact:  Kevinjohn is most definitely not the only one that’s making the tough decision to walk.  Slowly, but surely, agencies and freelancers are looking at alternatives for their clients.

Doomed to a life of Conflict?

So, do I really think WordPress is doomed to a life of conflict?  Frankly… Yes.

But I really hope I’m proven wrong.

As with all good things, the great stuff going on with clients and projects has caused one negative side-effect:
This cobblers kid has been wearing the same worn out kicks for over a year.

Well, in honor of the new year, we’ve remedied our neglect with a great new look based on Generate, a righteous new Genesis child theme from StudioPress.  It’s clean, it’s simple and it’s responsive.

Stay tuned — more changes and some really big news are just around the corner!

Can’t really blame them for wanting to produce some additional income from this awesome service, but I really hate the way they did it.  Instead of asking people to pitch in by suggesting a donation, they used a little UI trick to hide the free signup & donation form right under the 3 paying options.

So, in honor of Black Friday, I’ve reduced the price of my current Genesis child themes to $19.95 each! No codes, no coupons — just buy. Themes are on sale now and will remain on sale ’til Midnight on Friday Monday!

Endeavor Genesis Child Theme

Endeavor is our newest WordPress theme for the StudioPress Genesis theme framework.  A custom jQuery slider widget makes this one shine and brings the content you’d like hi-lighted to your visitors attention with a smooth slide-in effect. Check out the demo and buy at ThemeGarden.

Photo-Genic Genesis Child Theme

PhotoGenic is a basic portfolio style child theme for Genesis.  Some simple, but effective jQuery bring the homepage and selected category pages to life.  Check out the demo and buy at ThemeGarden.

Basically, Post Formats are just meta information and some front-end style additions to allow a theme author to customize individual posts both in “the Loop” and on single post pages.  Yes, it’s something that some theme authors have already been doing using categories or tags and some custom code — but this is easier and it also allows for some standardization and portability between themes which I think is the most important part.

At the time of this writing Post Formats is still in its early incarnation, so some things may change before the release of version 3.1.  That said, I think the feature is at a stage where we can start playing with it without much risk of major changes.

The basics:  Activating Post Formats

add_theme_support( 'post-formats', array( 'aside', 'gallery' ) );

That’s it!  That single line of code is all that’s needed to activate Post Formats in your theme.

Once active, a few things will automatically happen.

On the back-end, users will now be presented with a Format option in the Publish meta box of the post editor screen.

On the front-end, a couple of things happen. The post_class() function that most themes use to will start adding ‘format-’ classes to each post wrapper and the body_class() function will add ‘single-format-’ to the page body class.

A quick example of how to make use of this new class would could be as simple as this:

#content .format-default h2 {
   font-size: 32px;
   font-color: #333333;
}
#content .format-aside h2 {
   display: none;
}

In this example, we’re not doing much more than changing the title formatting of two post formats, but as you can imagine, this could be applied to every element of each post.

Supported Arguments

Post formats has just one argument.  The supported post formats.  Because this feature is intended to be standardized and portable between themes, custom formats are not an option. Currently supported (per the codex):

• aside – Typically styled without a title. Similar to a Facebook status update.
• chat – A chat transcript.
• gallery – A gallery of images.
• link – A link to another site.
• image – A single image.
• quote – A quotation.
• status – A short status update, usually limited to 140 characters. Similar to a Twitter status update.
• video – A single video.

Enable support for each post format by adding it to the array in add_theme_support.

Additional Functions:

At the moment, the post formats feature only brings one new function to the table:

get_post_format( $post->ID )

This returns the post format of the current post – very useful in a custom loop to take your customization’s further than you could with a pure CSS solution.

More Info

There’s already been a fair bit of discussion about why custom post formats aren’t being supported.  Frankly, the logic behind this is simple and solid:  the feature is designed to be portable and standardized.  Allowing for a custom option steps all over that logic — the instant ‘custom’ becomes an option, standards and portability go out the window.  As much as I’d like to see every feature in WordPress as customizable as possible, this is one case where I think it’ll be more globally beneficial to keep options broad but standardized.

If you can think of post formats that are missing, get yourself over to this trac ticket (#14746) and make your case for inclusion.

UPDATE:  Or join in here: http://wpdevel.wordpress.com/2010/11/11/list-of-post-formats/

This post is an update to my previous article.  Though I think I made a valid argument, I no longer think it’s accurate and it’s doesn’t cover the “whole truth” which I’m going to do here.

While reading all the articles that have been written recently, I came to an epiphany!  Most of these articles, including my own, make one critical error:  They missed facts and focused on beliefs.

I’ll have to thank Matt Mullenweg for pointing out this fantastic quote:

“In reality, we often base our opinions on our beliefs, which can have an uneasy relationship with facts. And rather than facts driving beliefs, our beliefs can dictate the facts we chose to accept. They can cause us to twist facts so they fit better with our preconceived notions. Worst of all, they can lead us to uncritically accept bad information just because it reinforces our beliefs. This reinforcement makes us more confident we’re right, and even less likely to listen to any new information.”

– Joe Keohane in How facts backfire.

One of the most well written articles on the subject of Derivative Works and WordPress would probably be Mark Jaquith’s “Why WordPress Themes are Derivative of WordPress” ².  It spends most of it’s space explaining why WordPress themes should be considered “derivative works” without ever quoting a single line of the GPL v2.  He spent 2,000+ words on defining what makes something derivative but he missed one fact that qualifies, or in this case, disqualifies his entire opinion.

I commented:

Your article does a detailed job of describing your opinion. I truly appreciate hearing your point of view.

That said, I can’t help but notice that you don’t mention which part of GPLv2 you’re basing this opinion on. I think it’d be helpful to the readers to see what part of the license brings you to your conclusions.

Mark responded with the following:

The crux of it, to me, is this:

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works

I do not consider themes independent and separate works. They form one work, when combined with WordPress, and necessarily contain WordPress code and WordPress-derivative code.

BAM!  There it was.  The qualifier.  Not the quote from the GPL v2, but his words:  ”when combined with WordPress”.  As Matt Mulenweg’s post quoting Joe Keohane helped me realize, Mark Jaquith twisted some facts by omitting this one statement from his entire article.  Perhaps he did this intentionally, or maybe it was just his beliefs driving his facts.

Mark made some very valid points throughout his article and it is VERY well written.  Points about how themes are run, how they interact with WordPress the same way that WordPress interacts with itself and how a theme uses the same functions as the core uses.

Yes, valid and convincing points indeed, except none of his points qualified until after a theme is distributed.  The GPL v2 is a distribution license, after all.  Until a theme is combined with WordPress, none of his points are valid.  If you go back and re-read his post, adding “when combined with WordPress” to each point, the article takes on a completely different meaning than what it’s title implies.

Now lets take a second to review James Vasile’s “official legal opinion” ³ as posted on WordPress.org back in July of 2009.  Since his legal opinion tends to be the de facto go-to when issues of WordPress and commercial themes come into question, I think it’s a very important read for everyone.  Since Mark and several others pointed to this Legal Opinion, I decided to read it one more time — really trying to absorb it this time, opening my mind to any new information that I may have missed in the past.

Now, I’m guessing I can’t be the first person to notice this — and I’m sure someone will point it out (please do).  James Vasile qualifies his entire legal argument with the following statement:

On the basis of that version of WordPress, and considering those themes as if they had been added to WordPress by a third party, it is our opinion that the themes presented, and any that are substantially similar, contain elements that are derivative works of the WordPress software as well as elements that are potentially separate works.

As James sates, it’s his official legal opinion is that themes AS IF THEY HAD BEEN ADDED TO WORDPRESS BY A THIRD PARTY are derivative works.

How the HELL did I miss this the first 10 time I read it?  Perhaps because I wasn’t expecting the go-to, “Official Opinion”, to support my opinion of commercial themes and plugins as they are currently distributed.  I read right over that statement because I was looking at the information and trying to find ways to refute it rather than agree with it.

So, there ya go – I now officially agree with the official WordPress.org published legal opinion of James Vasile.

WordPress themes and plugins that do not contain actual code from within WordPress and that are distributed without WordPress are NOT derivative works.  They do not become derivative works until a third party places them within the codebase of WordPress.  As we all know, people selling commercial plugins almost NEVER distribute them with WordPress and if they’re on the up-and-up, they’re not distributing copy pasta ⁴ that could possibly cause their code to inherit the GPL v2.

Now, many of you may wonder why I’m so adamant about this subject.  Those of you that know me, know that I wholeheartedly support Open Source and what it stands for.  WordPress and other Open Source projects have been putting food on my table for over a decade.  Why would I speak out against people like Matt Mullenweg and other GPL evangelists?

Well, the answer to that is very simple:  I believe in freedom in its purest form.

Just as much as I appreciate the work of people like Mark Jaquith, Matt Mullenweg, Andrew Nacin and all the many other contributors to WordPress, I also appreciate the fact that not everyone is able to put food on their table as a side-effect of freely contributing to a project such as WordPress.  I understand that some people might be creating original work that simply doesn’t have as much broad appeal or is amazingly innovative but simple, and the only way they’re time and effort will be repaid is by keeping the creation their own.

Yes, there are plenty of people that code commercial software that could contribute to the open source community and still make money, but it’s not my place, nor do I think it’s the intent of the GPL, to force those people to do the right thing.

Other good reads:

For a ton of research and potentially related case law, Chip Bennett did a very in depth write-up on this same topic, from a slightly different angle.

A short note on Chris Pearson:

Since I started this post with mention of Thesis, I feel I need to add a note about it.  As I don’t want to make Thesis a focus here, I’ll keep it brief.

Chris Pearson allowed code from within WordPress and other GPL’ed plugins into his code-base.  Because of this I believe he has, at least to some extent, violated the GPL.  If he had kept it clean and used only his own code in the making of Thesis, I would probably be supporting him and would be rejoicing a precedent-setting lawsuit against him.  As it stands I cannot support him, nor do I find any joy or purpose (other than to compel him to re-release his code under the GPL) in any legal action against him.  Thats is all.  I will not respond, and will probably delete any comments in direct regards to Chris or Thesis.

Today, it started with an independent WordPress consultant being removed from the CodePoet.com website.

CodePoet is a directory of WordPress consultants brought to you by Automattic, the company behind WordPress.com.

The reason cited  was that the consultant promoted the Thesis theme, a commercial theme written by Chris Pearson, which Automattic, Matt Mullenweg and several others claim to be in “blatant violation of the GPL”.

As these things go, members of the community immediately dug their trenches and started throwing verbal hand grenades around.  Very few people had any real valid points to make; Understandable as I’m quite sure  most people haven’t taken the time to read the GPL much less understand it enough to try to interpret it.  I don’t know why, but this WP GPL fight always brings up humorous memories of 2 groups of high school aged girls arguing over which actor in the Twilight series is hotter: Edward or Jacob.  Weird, hu?  Anyway, I digress …

First of all, lets take a quick second to review my point of view on the GPL and how it applies to WordPress extensions.  Mind you, this is my interpretation of it — not anyone else’s.  Furthermore, if I were to start selling premium or commercial themes or plugins for WordPress, there is a very good chance I’d release under a GPL compliant license.

• WordPress code is release under the GPL, so obviously modifying it’s code and then reselling the code would be in violation of copyright law.
• WordPress provides an API – an interface that allows it to be extended to work with 3rd party code as well as allow 3rd party code to interface with it.
• Many 3rd party, commercial, plugins can and do work without WordPress.

So, those things said — I’m feeling a bit torn.  I think it’s a fringe area of the license and it requires someone unbiased, with a lot more contract law experience, like a Judge, to make the legal distinctions.  I do however feel like I sway towards non-gpl extensions being legal and not in violation of the GPL.

I’ll explain why with the following example:

WordPress, as well as countless other GPL licensed projects offer an interface for external applications.  Does the GPL extend to commercial 3rd party projects, such as FTP Clients, software media players or email clients?

Lets use an email client as a comparison to a WordPress theme.  Why?  On it’s exterior, it may seem like an apples to oranges comparison, but if we dig deeper these two things are much more similar than they seem.  You see, an email client doesn’t do much more than take information stored on a server, format it’s display and allow you to view and navigate it in a particular way.  In that same fashion, a WordPress theme does the same thing.  It takes an an authors content and formats how it’s displayed, and in most cases, gives you a method of navigating the content.

If we apply the logic that all extensions of WordPress are covered under the GPL, then we would have to apply that same logic to software like Microsoft Outlook and Internet Explorer, not to mention the countless other products that interface with and extend GPL licensed software.

In the Pearson vs. Mullenweg scenario, who has more to loose?  Matt believes that the whole open source community would take a hit if it went to court and lost.  It’s an exaggeration, but sure, this same battle has gone on within other GPL projects and they might have to concede that 3rd party extensions that don’t use actual GPL licensed code might be in the right to sell their wares.  On the other hand, if the GPL side of the argument won, what would happen to all those commercial clients that interface with GPL code?

Here we have the “new code” – I haven’t altered a single line of it nor have I disabled the capital_P_dangit() filter in this installation of WordPress (version 3.0.1 from the SVN).

function capital_P_dangit( $text ) {
// Simple replacement for titles
if ( ‘the_title’ === current_filter() )
return str_replace( ‘WordPress’, ‘WordPress’, $text );
// Still here? Use the more judicious replacement
static $dblq = false;
if ( false === $dblq )
$dblq = _x(‘“’, ‘opening curly quote’);
return str_replace(
array( ‘ WordPress’, ‘‘Wordpress’, $dblq . ‘WordPress’, ‘>Wordpress’, ‘(WordPress’ ),
array( ‘ WordPress’, ‘‘WordPress’, $dblq . ‘WordPress’, ‘>WordPress’, ‘(WordPress’ ),
$text );
}

Check out the screencast for a quick overview of the new filter — or read on.

Now, if you don’t code — you might not understand why, but if you cut and paste this code expecting it to work, it won’t. See, the code snippet I pasted into the post is not the same as the code you’re looking at here. The filter has changed some capitalization and rendered it useless. I intended to give you a working code snippet, I made sure the snippet worked, but WordPress has broken by transparently “correcting an error in my spelling”.

WordPress_my_intent() <- This is just an example of what a function could be called — but this too has been altered. So, if I were to use an incorrectly capitalized “WordPress” in my function names, perhaps in code snippets I wrote last year, I then upgraded to 3.0, none of my snippets would work for anyone.

And what about not technical articles where I was trying to make a point — for whatever reason — by spelling WordPress incorrectly?

Perhaps the next revision of this junk code, that should NOT be in the core, will include some advanced mind-reading fuzzy logic.