TwentyThirteen

As WordPress 3.6 goes to beta, it’s awesome the way the new default theme, TwentyThirteen (that I’m using on this site), handles a variety of post formats.

TUTORIAL: Developing Locally on WordPress with Remote Database Over SSH

Today, I went about setting up a local WordPress install for some development I am doing at work. The problem that existed is that I didn’t want to bring the database from the existing development server site into my local MySQL instance. It’s far too big. I figured this could be done via an SSH tunnel and so, I set abut trying to figure it out. The situation worked flawlessly and so, for your sake (and for myself for the future), I give you the steps.

Setting up the SSH Tunnel

I run a local MySQL server and that runs on the standard MySQL port 3306. So as these things go, I can’t bind anything else to port 3306 locally. I have to use an alternate port number. I chose 5555, but you can use whatever you want.

The command to run in a Terminal window is:

ssh -N -L 5555:127.0.0.1:3306 remoteuser@remotedomain.com -vv

A little bit about what this means.

the -N flag means that when connecting via SSH, we are not going to execute any commands. This is necessary for tunnelling as, we literally, will not execute any commands on the remote server. Therefore, we won’t get a command prompt.

the -L flag tells SSH that we are going to port forward. The following portion, 5555:127.0.0.1:3306 combined with the -L flag means, literally, forward all traffic on localhost (127.0.0.1) connecting on port 5555 to the remote server’s port 3306 (standard MySQL listening port).

The remote server and ssh connection is handled by remoteuser@remotedomain.com. This seems obvious, but just in case. You may be prompted to enter your SSH password.

The final part can be omitted, but I like to keep it there so I know what’s happening. The -vv flag tells the SSH daemon to be extra verbose about what is happening with the connection. It’s sort of a good way to debug if you need to, and to know that the port forwarding is actually taking place.

Configuring WordPress to use the Tunnel

Now that we have a successful SSH tunnel, you have to configure WordPress to use it. In the wp-config.php file, simply modify the DB_HOST constant to read:

1
define( 'DB_HOST', '127.0.0.1:5555' );

You need to add two more variables, though, to override WordPress’ existing siteurl and home options to allow you to work with the localhost domain, instead of redirecting to the remotedomain.com that is configured in WordPress.

1
2
3
define( 'WP_HOME', 'http://localhost' );

define( 'WP_SITEURL', 'http://localhost' );

BOOM!

With these configurations in place, loading up WordPress should now load in the database content from the remote host and you can get to work on local development. Word to the wise… don’t close the terminal window with the tunnel or the tunnel will be severed. If you have to minimize it so it’s not annoying you, go for it… just don’t close it.

Contest: 3 free copies of the WordPress Bible [UPDATE]

Today marked the drop of WordPress 3.5 and I want to celebrate.

Tomorrow, I’m going to give away three autographed copies of the WordPress Bible. You have to be on Twitter. I apologize to those who have chosen to abandon Twitter, or have chosen not to participate, but it is the defacto communications medium of the 21st century and how I operate.

The book is a mix of advanced and beginner content. Therefore, I will do trivia. Trivia will have a beginner round, an advanced round and an intermediate round. All WordPress oriented. The winner is in my sole discretion and you will be required to provide your mailing address if you are selected.

WordPress core contributors are not allowed to participate in the beginner or intermediate round. If your name is on “the list” of 3.5 contributors, you cannot win those rounds. You can, however, participate in the advanced round.

The beginner round will consist of questions surrounding theme and plugin management with possible questions around usability and interface.

The advanced round (the only round open to core contributors) will be based on WordPress APIs, hooks and advanced WordPress development.

The intermediate round will mix both but the developer-oriented questions will be more common and basic and user questions will be more difficult.

You must hashtag your answers with #wpbibletrivia. Failure to do so disqualifies you for an answer.

The first answer I see that is correct is a correct answer. My judgement solely.

There will be 10 questions per round so pay attention.

The beginner round begins at 11am Central Time.

Share this on Facebook, Twitter or whatever your social media channel of choice is. The questions will be asked on my Twitter feed: @technosailor.

Good luck!

Update

The winners of the trivia contest were David Peralty for the beginner round, Kim Parsell for the intermediate round and Kailey Lampert for the Advance round. Well done, everyone!

10 Things You Need to Know About WordPress 3.5

For 7 years, I’ve been publishing these articles every time a new version of WordPress comes out. Since version 2.0. It’s been a long run. It began as a need to fill people in about new features in WordPress (and there were a lot in 2.0). There wasn’t anybody doing these at the time, and certainly WordPress wasn’t nearly as popular as it is now (22% of the internet is powered by WordPress).

But many more people have stepped up in recent releases and have started updating readers with new features and expectations. My job here is done. I’m passing the baton but really the baton has already been passed and I’m happy about that. This will be my final 10 things article. Thank you for sticking around and following along all these years.

On Wednesday (likely), December 5th, WordPress 3.5 will drop with all it’s gooey goodness. A BIG shoutout needs to go out to Andrew Nacin, the lead developer on 3.5, for project managing this release while also planning his wedding, and to his best man, core developer Daryl Koopersmith for leading the media efforts. And of course, all the other core contributors to this release (I, sadly, am not one this cycle).

So without further adieu, let’s get into the guts of 3.5.

Media Manager

One of the most anticipated revamps in WordPress history has finally arrived. Since the days of implementing the media upload integration, core developers, users and everyone in between has cried for a new way of managing media. It’s finally here and it is one of the biggest undertakings in WordPress core development history.

The new media manager in WordPress 3.5 simplifies the process of uploading various media formats (usually, but not limited to, images). Everything is right up front and easy to understand. Instead of having cryptic icons over top of the edit area on a post editing screen, you now have an obvious “Add Media” button.

Clicking Add Media brings up a dialog that has a very large, and obvious “drop zone” where you can drag and drop files into. This aspect has actually been around for a few versions, but now it’s a much smoother experience. Of course, you can also click the prominent “Select Files” button in the drop zone to pull up a more traditional dialog for selecting those media files and uploading.

You can also get a much more intuitive view of your already uploaded media attachment, select any number of photos and insert them into a post or create a gallery. This was all supported before, but the logical workflow makes the process a million times easier.

Also, gone are the days of uploading an image, having to close the media dialog to then re-open it to create a gallery or futz around with details for each image. This was always kludgey before. You could assign an image as a featured image without having to close the dialog, but then inevitably you’d end up in a situation where the dialog had to be closed to get into another image mode.

I’m really curious what the reaction to this feature will be.

Twenty Twelve

WordPress Twenty Twelve default theme
The front page layout of the new WordPress 3.5 default theme “Twenty Twelve”
Twenty Twelve is the new theme that is coming with 3.5 A few cycles ago, the core team decided to retire the old default “Kubrick” theme and release a new standard theme once a year. Twenty Ten came in 2010. Twenty Eleven came in 2011 and, well, obviously, Twenty Twelve is dropping in at the tail end of 2012.

Twenty Twelve is a fun theme. It’s fully responsive, so it conforms to different viewport sizes – monitors, iPads, smart phones, etc. In WordPress 3.4, the Admin got responsive love, and now the default theme gets it as well.

You can actually download and install it now, as it is also compatible with WordPress 3.4 and is on the theme repository.

This default theme has better typography, a home page template, various options for columns and widgeted areas and would serve well as a handy theme framework for child themes as well.

In addition, if you haven’t started leveraging post formats (available since WordPress 3.1), you can do that now with Twenty Twelve. The theme has built in styling defaults the match the sort of thing you’d expect from Post Formats (to me, still one of the most neglected things in WordPress)

HiDPI “Retina” Admin

For those of you on the retina display bandwagon, both Twenty Twelve and the entire administrative interface are all retina ready. No pixelation on those high-end Macs!

In WordPress 3.4, the first steps were made by providing quite a few retina (or hi-def, if you will – it will make more sense in a minute why I offer that clarification) icons in the admin. Now, the CSS (specifically for print) also supports this hi-def rendering. If you must print a tree, the print stylesheets will be printing in hi definition.

This also opens up opportunity as browsers and CSS3 continue to advance and provide developers with new tools.

Retina not only gives print versions additional clarity, and those high end Macs more beauty, but it also renders things better for you iPhone 5, iPad 3, Kindle HD and various new Android device users. Rejoice! (but I have an iPhone 4S, so meh!)

Removing the Links Manager

Links Manager Removed
So long, Links Manager, and thanks for all the fish!
Oh my God. We finally got rid of this antiquated thing!

Remember back in the day when people actually kept blogrolls? And WordPress had this feature in the menu called “Blogroll”. And then people started realizing, as possibly one of the earliest turns toward WordPress not being only a blogging tool but also a full-blown Content Management System, that Blogroll just didn’t seem appropriate (or whatever the thinking was), so it was renamed to Links.

It’s now coming out entirely. Existing WordPress install retain the Links manager but new WordPress 3.5 installs no longer have this functionality.

If you still need it, you can install the Links Manager as a plugin.

Favorite Plugins

As a developer, I am constantly setting up WordPress installs, setting up new WordPress installs, resetting WordPress installs, etc. so perhaps my favorite new feature in WordPress 3.5 is the “Favorite Plugins” doohickey. I always have a subset of plugins I use for development and functionality I consider a “must have” for a client project, etc.

Favorite Plugins can be installed from right in your plugin manager.
Favorite Plugins can be installed from right in your plugin manager.
If you go to the WordPress plugin repo (and are logged in with your WordPress.org username), you will see a new “Favorite” button on every plugin page.

This becomes incredibly useful in WordPress 3.5 where you can now pull down your favorite plugins with one-click install. When you visit the Plugins > Add New admin page, you will see a new “Quick Link” along side the “Upload”, “Popular” and other links that have been there all along. Now you just have a new menu.

This brings up a page where you can enter your WordPress.org username and get a list of all the plugins you’ve favorited on the plugin repo and install as you need.

Protip: Now you can stop emailing me and asking me what plugins I recommend. Enter MY username – technosailor – and find out which plugins I prefer.

Tumblr Importer Support

One of the most popular blog types and platforms in the past few years is Tumblr. Up until now, there hasn’t been a way to get Tumblr content imported into WordPress. That’s no longer the case.

On the Settings > Import page, you can now activate Tumblr import support. Warning: The process of importing Tumblr is a little kludgey and that is due to Tumblr’s own systems. You will need to register an app with Tumblr, enter certain key information about your WordPress install into the Tumblr app registration page, and copy certain key information into WordPress.

The instructions are all on the Import admin screen. I suggest opening up the Tumblr app registration page in a separate tab as you’ll have to go back and forth between Tumblr and WordPress.

Once you do this, you can connect WordPress to your Tumblr blog and slurp in all the data you’ve had over there. I know y’all love Tumblr, but this is your opportunity to get off of it and onto a more widely used and customizable platform. Plus, you have Press This in WordPress to allow you to continue your Tumblings.

Simplified Dashboard

Simplified Dashboard
Simplified Dashboard
The Dashboard has always been a bit of a sore spot for new users unfamiliar with WordPress. What is all this information? Unfortunately, that’s not going away quite yet. However, WordPress now makes it easier for users to get up to speed with common things like writing an about page, setting up a theme, etc.

In addition to Dashboard fixes, there have been a number of smaller UI changes in the admin, including the Privacy page being removed and merged into the Reading Settings pages. Lots of effort was put into a simpler user experience.

It’s the little things that help users get up to speed and using WordPress quickly and effectively and reduces the learning curve.

Multisite: switch_to_blog() performance problems fixed

There are a couple of Multisite improvements for developers. For the longest time, well before the merge of WPMU into WordPress, the way developers could switch “context” from one site to another would be through switch_to_blog(). Even after the merge, that function still remained the way to do it. But it has always come at the price of performance and caching. It was an extremely expensive function to use, filled with unnecessary database queries and other fudge.

It left developers looking for ways to accomplish the same task in a different way – which is really not the WordPress way. We encourage developers to use the tools WordPress provides and not to try to get around them. This mentality is almost universal and prevents problems with backwards compatibility in the case of database schema changes, etc. However, this beast had never been tamed for this specific functionality.

As of WordPress 3.5, this function has now been refactored and performs significantly better than what it did, including massive caching changes. Developers should feel far more comfortable using it. Hooray!

Multisite: Sub Directory

Another Multisite improvement is the ability to install WordPress Multisite in a folder. Up until now, WordPress Multisite could not be installed in a subdirectory. It had to be installed in the document root which was… silly.
In WordPress 3.5, a lot of work was put into making it possible to do just that. Specifically, this came out of Hack Day at WordCamp San Francisco in August. Nice work Mark Jaquith and company.

WP_Query Enhancement

One final developer tool that was added in WordPress 3.5 is a modification to the post__in argument that can be passed to WP_Query to affect what posts are pulled in a custom query/Loop. While post__in has been around awhile, and takes a comma separated list of post IDs to be retrieved, now, if the orderby parameter is set to post__in, the order of the IDs matter. Specifically, the order of the IDs in post__in is the order they are retrieved in the resulting dataset. Before they were simply ordered in numerical order (or whichever custom order parameter was supplied – post_name, post_title, etc) .

This is pretty effective for CMS-style usage of WordPress where a developer may want to have granular control of how specific content pages are listed, displayed, etc.

Summary

So that’s it! Nice big release. A lot of under the hood stuff for developers, but really this release is less of a developer’s release and more of a user experience release. When WordPress 3.5 drops on Wednesday (assuming that happens as expected), I’d love to hear feedback.

Thanks for reading all these years. I’m not disappearing. I’m just retiring from this column. Of course, I’m always looking for full-time or consulting work. Please feel free to contact me if you think we might be able to work together.

Until then…

So long and thanks for all the fish
Original Photo by Starrarte Used under Creative Commons.

HOLIDAY WORDPRESS DEAL: 30 Minute WordPress Consultation

As the holidays kick into full gear, and people start looking at a short sprint to gift times with family, I am offering a 30 minute phone consultation related to WordPress for $100. This is a great thing for someone who needs to figure out how to do something that may be unfamiliar for them or if they are just getting setup with WordPress and need plugin recommendations, or the like.

To setup your 30 minute appointment or to inquire about gifting that appointment, fill out this form. For the description, just reference this deal.

For longer term commitments or consulting engagements, including custom plugin development, I am booking clients for Dec and Jan, so feel free to ask about those opportunities as well.

This offer is only good today, Friday Nov 23, 2012 until midnight Central Time.

This offer is good through Midnight, Monday, November 26, 2012 – Cyber Monday.

TUTORIAL: Building Custom Rewrite Endpoints in WordPress

Recently I concluded a sizable project that involved deep integration with an external API. I was responsible for creating content pages based outside of WordPress. To be clear, the pages would use an internal WP template, but all the content was generated using this external API.

In order to make this work within the WordPress Rewrite system and serve pages that WordPress knew how to handle in a non-traditional way, I had to tackle this in a multi-prong way: using the template_redirect as well as the built in Rewrite API.

Note: I’m not giving away the full sauce here as the project is non-open source. As well, I’ll be abstracting some stuff a bit. If you’re smart, you can fill in all the blanks regarding how to fully implement this.

First we need a base class:

1
2
3
4
5
6
7
8
9
10
11
12
13
<?php

class Base_Class {

  public function __construct() {
    $this->hooks();
  }

  public function hooks() {
  }
}

new Base_Class;

This is the base of pretty much every class I write as part of a plugin in WordPress. If you don’t follow Object Oriented coding practices, start now.

The next step is to register some variables with WordPress. Because WordPress is using the template_redirect hook to get the proper template files, you will often lose necessary query string variables, and you definitely can’t use them in an endpoint (i.e. /foo/bar) without WordPress knowing about them.

So let’s register them using the query_vars filter.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?php
class Base_Class {

  public function __construct() {
    $this->hooks();
  }

  public function hooks() {
    add_filter( 'query_vars', array( $this, 'query_vars' ) );
  }

  public function query_vars( $qv )
  {
    $qv[] = 'foo';
    $qv[] = 'bar';
    return $qv;
  }
}

new Base_Class;

After this, we want to actually create some rewrite endpoints. In this example, I want to allow permalinks like /foo/content-slug/ and /bar/content-slug. With the following code that adds a rewrites() method to the class, and hooks on the generate_rewrite_rules filter, we can create these two endpoints. In our imaginary template, we would use get_query_var() function to handle logic for display purposes, but that’s outside of this article scope.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
<?php
class Base_Class {

  public function __construct() {
    $this->hooks();
  }

  public function hooks() {
    add_filter( 'query_vars', array( $this, 'query_vars' ) );
    add_filter( 'generate_rewrite_rules', array( $this, 'rewrites' ) );
  }

  public function query_vars( $qv )
  {
    $qv[] = 'foo';
    $qv[] = 'bar';
    return $qv;
  }

  public function rewrites( $rules )
  {
    global $wp_rewrite;

    $new_rules = array(
        'foo/([a-z]+)/?$' => 'index.php?pagename=wppage-holder&foo=' . $wp_rewrite->preg_index(1),
        'bar/([a-z]+)/?$' => 'index.php?pagename=wppage-holder&bar=' . $wp_rewrite->preg_index(1),
    );
   
    $wp_rewrite->rules = $new_rules + $wp_rewrite->rules;
    return $wp_rewrite->rules;
  }
}

new Base_Class;

Specifically, note the new rewrite rules and how they are structured. If those permalink structures identified above match these new rules, then we will pass the request on and use the template file designated for a page (that you do have to create in WordPress, by the way) with the slug ‘wppage-holder’. This can be done by designating a template file on the page edit screen or by naming the template as page-wppage-holder.php in your theme – again, outside the scope of this article.

If the permalink matches foo, we pass the foo variable on. If it matches bar, we pass the bar variable on. Logic on the other end left to you.

This is where I have to stop using this example, for client confidentiality purposes, but imagine what is possible now if you extend this and use the template_redirect hook to handle some custom redirects leveraging wp_redirect()?

Imagine. :)

Competing Interests: WordCamp SF and the WordPress Foundation

WordCamp SF
Photo used under Creative Commons and taken by Niall Kennedy.

Six years ago, the first WordCamp ever was held in SF and it became the launching point for many local regions and cities to continue the conversation, learning and educating around WordPress. It was always meant to be a hyper-local thing. Actually, as a correction, it was never meant to be a thing at all. It was meant to be a get-together of SF WordPress people.

But surprise, it caught the attention of WP developers, users and designers worldwide (including myself), and we came in by storm!

The following year, the decision was made that, due to such high demand in SF, and to try to encourage WordPress user groups in other cities, WordCamps should be distributed and locally organized. That kicked off a slew of WordCamps that (seemingly) doubles every year. I organized WordCamp Mid-Atlantic (the roots for WordCamp Baltimore and WordCamp DC today) back in 2009 and 2010.

Personally, I’ve been at or spoken at dozens of WordCamps (Mark your calendars… if you’re in Las Vegas on October 6, I’ll be speaking there too). To name a few, I’ve been to WordCamps in SF, San Diego, Las Vegas, Raleigh, Baltimore, Miami, Atlanta, Dallas, Houston, and New York to name a few. I’ve been to San Francisco every year except one, and that was due to another travel conflict.

I’ve been an organizer, speaker, sponsor and attendee.

In other words, I am no rookie and I am in good standing in the community!

The WordPress Foundation

A few years ago, after some financial mis-management for a large WordCamp, the WordPress Foundation was setup. The Foundation was designed to promote the use of WordPress, protect trademarks of WordPress and related WordPress trademarks, including WordCamp. As part of this responsibility, the Foundation has issued rules around WordCamps via WordCamp Central. Today, I could not run WordCamp Mid-Atlantic the way I did before as the rules are quite rigid. On the other hand, I would also not have taken a nearly $3k personal loss on Mid-Atlantic in 2010, so the rules, in my opinion, aren’t all bad.

A sampling of these rules include that any WordPress-based commercial sponsors who distribute code must distribute 100% GPLv2 compliant software and having organizers approved. Also, all sponsorship money goes through the Foundation at this point.

WordCamp SF

Which leads me to a problem I feel the need to weigh in on. WordCamp San Francisco is no WordCamp. It is a conference in every rightful way of the word, as it should be. And it should be renamed as the WordPress Conference or something other that WordCamp. WordCamp SF is commanding massive sponsorship levels, of which one sponsor is gladly paying a whopping $30,000 for “California Street” level sponsorship.

Other sponsorship levels are at $10k, $7500, $5k and $2k.

This is against an unstated, yet enforced, Foundation policy surrounding limits for sponsorships. These rules were put in effect to encourage big companies, like Dreamhost who is in for $30k at WCSF, to spread the wealth among a variety of WordCamps instead of just one. The idea is that if, say Microsoft, was well-connected to an organizer of one WordCamp, the Foundation has mechanisms in place to move funds around to other less-connected, but still necessary, WordCamps. It also ensures that WordCamps don’t put their eggs in one basket and then have a major sponsor flake and leave them holding the bag. Fine, I can get behind that rule.

WordCamps also have rules about content. It used to be that every WordCamp had some session on using social media. While that is perhaps important to WordPress users, it’s not WordPress! So sessions need to be WordPress related. I totally get that and have no gripe with that provision. For the first WordCamp Mid-Atlantic, I invited Anil Dash to keynote, knowing that at the time, Anil was an SVP and Founder of a WordPress competitor. But it was open source and I felt that the competition only made us as a WordPress community stronger. I expected push-back from inviting Anil, and if the rules were in place then… he may not have been able to Keynote.

We know WordCamp SF is Matt’s baby and he chooses content, not based on whether if it’s WordPress-related, but whether it’s inspired him. At least that was true until last year when Jane Wells organized.

We also know food, photography and Jay Z inspire Matt, but I don’t think Rachael Ray would be a speaker at WordCamp SF… though perhaps I wouldn’t be surprised if she did end up speaking there. I digress.

Matt Mullenweg, who is both the President of Automattic, the commercial arm of WordPress, and the President of the WordPress Foundation responded to my request for comment by admitting that some content in the past has drifted from WordPress but that he still stands by them. “None of those speakers normally speak at WordCamps, but we’re able to attract them and orient them to contributing something interesting to the WordPress community because of WCSF’s location and prominence.”

I suppose, again, Rachael Ray could speak and discuss the merits of using WordPress for a food blog.

Related, ticket prices are kept artificially low, but sponsorship levels are extremely high. It feels wrong.

The Foundation does suggest lower ticket prices (around $20 is typical), but one wonders why WordCamp San Francisco could not charge a reasonably low rate of $200 for an attendee ticket, given that people would still come from all over the world to attend. This would also lower sponsor levels and cause less controversy. DrupalCon is charging $400-$450. RailsConf is approximately $800. Why does the official WordPress conference have to sell at $20 when sponsorship levels feel inappropriate?

;

The Foundation Risks Major Implications from Non-Enforcement

When the Foundation was established, it’s stated goals were inspired by the Mozilla Foundation, as much of the philosophy of open-source development and products in the WordPress world are. It’s important to point out that, from a governance standpoint, the Mozilla Foundation and Mozilla Corporation, though closely tied, are governed by different people with similar but differently stated goals.

If Mozilla Corp goes outside the bounds of protected Mozilla.org auspices, you better believe that Mozilla.org is going to have something to say about it. The reason is simple… if you don’t enforce your own policies with your closest ally, friend and organization made from the same DNA, you leave yourself open to risk later on. Otherwise, you have a conflict of interest which is both legally and publicly difficult to reconcile.

Trey Roberts, a well-decorated Intellectual Property attorney of Roberts & Roberts in Austin, TX, commented to me that, “Though there is no ‘discrimination’ in a legal sense, since an organization has the right to choose what aspects of their licensing contract to enforce, if a pattern of suspended enforcement occurs, there is a risk of legal repercussions.”

Of course, some organizers see a level of subjectiveness in Foundation rules. Tony Perez, one of the organizers of WordCamp San Diego, lamented, “Often case when a request would be made, the response would be,’we would prefer not.’ When the question was asked, ‘well why not?’ the response was not very clear or decisive, so the decision felt as if it was in limbo. At the same time, you almost felt bad going against the recommendation, so it starts to become easier not to ask, than to ask.”

Opportunity exists though. “I can say though that it’s a necessary evil, but perhaps its time to think outside the box on the approach,” says Perez.

I love WordPress

I write this post not to bash WordCamp, the WordPress Foundation or any individual involved. In fact, I love WordPress. My professional career is Proudly Powered by WordPress. I want the Foundation to succeed as an organization charged with the governance of the software and events around it – and it is making strides to become a respected, independent governing organization. But conflicts of interest (or perceived COIs) do not provide a healthy community atmosphere and it causes bad blood among other WordCamp organizers. It, in fact, keeps potential organizers from wanting to jump in the mix. Or former organizers (like myself) from wanting to participate.

One former organizer, Amanda Blum, who has been a frequent critic of the Foundation tells me she won’t organize another WordCamp but she “still actively advises other camps [sic]” and “all I hear is complaints”. She goes on to express a concern about “the vast chasm between what the Foundation thinks Camps [sic] purpose is, and what the attendee interprets.”

Policies of the WordCamp Foundation around WordCamps are heavy-handed, in my opinion. There should be education (and there is some) around how WordCamps should be organized. Perhaps the rules that require WC money to be funnelled through the Foundation are merited (I actually do agree with this for non-profit reasons). However, where possible, it strikes me as necessary (and in fact, opportune) for local organizers to be able to blaze their own path and put their own local stamp on their own local WordCamp in almost every case. When it comes to sponsorship level, a WordCamp in NYC is likely going to cost more on orders of magnitude than a WordCamp in Omaha. One size shouldn’t fit all and the discretion should be left, with guidance from the Foundation, at the local level.

Mullenweg states, “The guidelines on Central encourage lower per-company sponsorship levels to encourage more sponsors per WC, decrease reliance on a single sponsor (we’ve had them flake out before), and have a level where even smaller firms can participate. It also hasn’t appeared to be a hindrance to larger city WordCamps, with NYC and Boston both raising 20k and putting on great events.”

Jane Wells, who helped to draft the original rules, tells me that the Foundation does try to not take a one size fits all approach to WordCamp’s and that they try to assist local WordCamps with financial assistance for venues, etc when needed. It does seem there is a perception among many organizers like Perez that this is not the case. One area where better communication between the Foundation and organizers may occur is at a new community blog that just went up.

With the spirit that this article is written with, I hope the Foundation, Automattic and the community take this as constructively confrontational. I do not wish to throw anyone under the bus, but change needs to happen for the integrity of the community. I cannot and will not be attending WordCamp SF this year or in the future, as long as these grievances continue year after year. I, however, will be at WordCamp Las Vegas and possibly Baltimore in the months to come, and I hope to see you there.

Corrections: Inserted a reference to WordCamp Central that serves as a central organization point for WordCamps. Also, updated the date for WordCamp Las Vegas to Oct 6, 2012. Corrected some content flow (paragraphs inserted in the wrong place) and noted that Matt did not choose content in 2011.

WordPress Plugin: Easy Graphs

Everyone likes data visualizations so I wrote a plugin that will make the quick and secure creation of Pie Charts, Bar Charts and Line Charts easy. The answer is: Easy Graphs.

Easy graphs is very simple to use. It’s a shortcode – [easy_graphs]

Not just like that. The shortcode also requires one parameter “data”. This parameter is a comma separated list of number values “1,2,3,4,5,6,7”.

You can also add a “type” parameter. The “type” can be “line”, “bar” or “pie”. “bar” is the default.

For a Bar graph, you can optionally pass additional parameters: width, height, and color.

Example: [easy_graphs height="200" type="bar" data="30,70,65"]
[easy_graphs height=”200″ type=”bar” data=”30,70,65″]

By default, width and height are populated from your media embed sizes that are set in your Settings > Media menu inside WordPress. Color should be a hex color code.

For a line graph, the options are similar: color1, color2, height and width.

If you will: [easy_graphs height="200" type="line" data="200,150,175,260"]
[easy_graphs height=”200″ type=”line” data=”200,150,175,260″]

In this case, color1 is the “fill” color and color2 is the line color. Both should be hex.

For Pie charts, there are some additional limitations but fewer parameters: color1, color2 and diameter.

Try this: [easy_graphs diameter="150" data="40,60" type="pie"]
[easy_graphs diameter=”350″ data=”40,60″ type=”pie”]

Diameter should be an integer represented in pixels. Color1 and color2 are the fill colors of the pie slices. The limitation is the pie chart, at this time, can only take 2 values. I’ll work on that.

On the roadmap are other things. Make the pie chart take more values than just 2. Maybe include other graph types. Labels so the data can be more easily understood.

What would you add to this?

Download Easy Graphs

Eliminate Unused WordPress Plugins

Consider this post a public service announcement.

It’s a common misconception that if a plugin is deactivated in WordPress, that you are immune from performance or security issues.

On it’s face, this is not true, and you are risking the internet with this mentality!

Take last year’s Timthumb debacle, for instance. Many themes include Timthumb for dynamic resizing of images. Sometimes plugins do. When those themes or plugins are not activated, you are correct in assuming WordPress is not loading them. What you are failing to see is that their existence on the filesystem provides a vector of attack for someone wanting to exploit a system-level exploit.

Not to say Timthumb is insecure. Old versions are. I still don’t like it for other reasons, like performance. Simply using it as an example.

But if you decide to not use a plugin or a theme, delete the damn thing so it’s presence doesn’t even exist. In the case of Timthumb, the security flaw wasn’t a WordPress exploit. It was a “PHP directly interacting with the system” exploit and it would be there anywhere else regardless of CMS. It could exist on a static site.

And it’s not just your site at risk. Fuck your site. What if that flaw in whatever flawed code existed woke up a botnet? Then everyone is at risk. I’m at risk. You and your silly site are at risk. Joe the plumber’s site is at risk. Thoretically.

So be responsible. Delete unused code from your site. Remove themes you don’t use. Delete plugins you don’t use.

And when I say delete, I mean, permanently delete. Don’t just deactivate.

The Internet thanks you.

Update: This is not a verdict on any plugin or theme. To my knowledge, most are perfectly fine. Just clarifying that this is a “just in case” precaution.

10 Things You Need to Know About WordPress 3.4

WordPress 3.4 is around the corner. It’s currently beta4 which means a Release Candidate or three will be needed before it drops officially. If you want to test what’s out there now, the way to do that is through SVN. As usual, however, pre-release WordPress is not supported. As usual, however, I have been running trunk throughout the entire development cycle without any problems.

Before I get into the guts of WordPress 3.4, I want to point you to a resource which highlights some of the thinking that is going into the development, now and in the future, of how WordPress is built. Andrew Nacin sent an email to the “hackers” mailing list discussing object-oriented development that informs the thinking of the core developers now that WordPress supports PHP 5.2 and true object-oriented programming.

While it may be over the head of non-developer types, the gist is that now that we (used loosely) can write code smarter, we’re working our way in that direction. Some of the code in WordPress has existed for “generations” of versions and is bulky and inefficient. With new tools at our fingertips, we can begin to approach the idea of refactoring some of this code in better ways. Backwards compatibility is always retained, however, in 99 out of 100 times. WE ARE NOT DRUPAL!

Without further adieu, however, let’s get into what you can expect in the new version of WordPress.

Embed Tweets with oEmbed

Since version 2.9, WordPress has supported a technology called oEmbed that, simply put, has allowed the inclusion of rich media in content in a very simple way. Simply paste a YouTube link on a new line, and WordPress turns it into a properly sized video. No embed code needed. Same for Vimeo, Flickr, Scribd and more. The entire list can be found on the Codex. Now, however, Twitter is supported. Simply place the URL of a tweet on it’s own line and… bam, you have this:

Query Efficiency Improvements

The common bottleneck for all WordPress users are database queries and data “munging”… that is, what WordPress does with data when it’s returned from the database. The query that brings in all the necessary content necessary to render a page used to look like this:

1
SELECT * FROM wp_posts WHERE...

This has been how the query has worked for years. Really since the beginning of WordPress. And while, in theory that works (and it does, again it has for years), the core reality of this approach is that all the data in the posts table matching the criteria in the WHERE clause is more data than is needed, thus causing potential performance problems.

The new approach is simple and elegant. The first database query simply fetches a list of post IDs that fit the criteria provided in the WHERE clause.

1
SELECT ID FROM wp_posts WHERE...

This approach means the amount of data in memory and floating around WordPress is concise and compact. PHP doesn’t have to work harder to traverse arrays or objects… it is simply a smaller list of data.

But what about the other data? We need the other data! Yes, in fact we do. But since WordPress has an object cache, much of this data is in the object cache. We don’t need to retrieve it from the database.

The second step is to look to the object cache for posts with IDs matching any of the IDs in the first dataset. Anything we can’t find is followed with a second query to get all the information matching the non-matched IDs using MySQL’s IN() function:

1
SELECT * FROM wp_posts WHERE ID IN(10, 34, 78);

By changing how SQL and object caching is used, WordPress 3.4 finds new efficiencies. In the original ticket, developers were observing 2-3x speed performance improvements. I’ll drink to that.

Theme Customizer

Non-technical WordPress users will love the new Theme Customizer. Otto has a great write-up on this new feature. His video is above. The key takeaway from this new feature is that is possible now to customize a great number of things in a theme  from right within WordPress. On the fly. with a live preview.

Change your title, tagline, background color, image and more with a click of a mouse. I can see this being used to create child themes in the future, but for now, it manages settings that are already in WordPress (and accessible in other areas of the WordPress Admin) on the fly. The best way to really appreciate this feature is via Otto’s video above. Related: The best way to leverage this as theme developers is outlined in great detail in his post…

Bundled ‘Touch’ Support

We live in a touchy-feeley world. And by that, I mean mobile. Specifically iOS and Android. In WordPress 3.3, we saw adaptive design come to portions of WordPress. Adaptive design, for the uninitiated, is a technology that elegantly resizes a website to adapt to the the screen it is rendered on. It is a way for developers to create a single experience that works on desktop/laptop browsers as well as mobile interfaces with arbitrary resolutions.

As mobile continues to lead the charge in today’s web, WordPress 3.4 has bundled the jQuery UI Touch Punch library that will give front-end developers more tools to work with in making a website mobile-friendly. Simply include the library via wp_enqueue_script() and now your element has the .draggable() method available. This method enables “drag and drop” support that was previously unavailable and the one major caveat is that it does not support Windows 7/7.5 phones due to limitations in the IE9 browser.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<?php
class My_Awesome_Plugin {
    public function __construct()
    {
        $this->hooks();
    }
    public function hooks()
    {
        add_action( 'wp_head', array( $this, 'js' ) );
    }
    public function js()
    {
        wp_enqueue_script( 'jquery' );
        wp_enqueue_script( 'jquery-ui' );
        wp_enqueue_script( 'jquery-touch-punch' );
        wp_print_scripts();
        ?>
        <script>
        jQuery(document).ready(function(){
            jQuery('#element').draggable();
        });
        </script>
        <?php
    }
}
$my_awesome_plugin = new My_Awesome_Plugin;

HTML in Captions

Red Sox
Photo by Kyle McCluer and used under Creative Commons. Some Rights Reserved.

I’m trying to rotate between developer tools and user tools in this article, so at this time, I’d like to point out a simple yet important frustration in previous versions of WordPress. When you upload an image and use the media uploader to then insert an image, you have the option of writing a caption. Sadly, it was impossible to include HTML in previous WordPress versions.

Often times, linking the source of a photo is welcome and, possibly depending on the usage restrictions on a photo, required. Before, the only way to do that was to set a link in the media uploader and then the photo would be linked. Now, in WordPress 3.4, you can include basic HTML in your captions as I have done above.

XML-RPC Improvements

XML-RPC. The thing that allows the WordPress apps for Android, BlackBerry and iOS to function. The thing that allows offline editors to function by remotely communicating with WordPress through a public-facing API.

XML-RPC is a venerable technology that is based mainly on the Metaweblog API invented a decade ago. WordPress has supported this iteration of XML-RPC as well as the Movable Type XML-RPC and Blogger XML-RPC APIs for a long, long time. However, WordPress has also extended the Metaweblog API and added it’s own methods along the way.

No more. Instead of band-aiding a solution on top of a limited set of methods intended for blogging only, WordPress 3.4 includes a brand new WordPress XML-RPC API designed to support all the rich features that have evolved since WordPress started focusing on CMS-style features. It incorporates all the methods introduced before as extensions to Metaweblog such as wp.getOptions, wp.getMediaItem, etc and introduces new ones such as wp.getPostTypes and wp.getTaxonomies to name just a few.

It’s important to note that only WordPress products are likely to ship with support for this new API at first, but old capabilities will still exist and function, as backwards compatibility is ensured. As API clients add support for WordPress’ new capabilities, we will see more common usage.

Internationalization (i18n) Improvements

For international WordPress users, WordPress 3.4 continues the tradition of enhancing your experience. As we in the community have stated many times, i18n is incredibly important to WordPress growth and development. In discussing this article with someone inside of the WordPress core community, I am told 2 out of every 3 WordPress users are non-American. Additionally, I am told that 40% of WordPress installations are non-english.

That’s Huge!

The running list of i18n changes in WordPress 3.4 is here. Some notable changes include:

  • Comma translation. While most languages use a comma as a separater (or delimiter), some do not. This enhancement is useful for languages like Chinese and Arabic that don’t use a comma.
  • Single-Double quote translation. It’s odd to think, but some languages like Hebrew, actually have distinct meanings for jots that are punctuation marks in an English world.
  • Default Timezones. It’s possible now to override the timezone WordPress uses in a translation. This, as you can imagine, is important when a language is largely spoken in one region in a single timezone.

Page Template Handling

For theme developers looking to put more organization around their theme file structure, a new change has gone in that has both an obvious, front-facing benefit as well as a background benefit. Now, you can place any page template inside a subdirectory of a theme. So you can now have a /pages/ subdirectory and segregate all of your extraneous one-off or multi-use page templates to that folder (or any folder). WordPress will identify all page templates in the theme root or in a subdirectory of a theme root and make them available for pages to use.

The background benefit of this comes in a new WP_Theme API that is lighter weight, more efficient and handles all the work for you. It’s important to note that most developers will never need to use this API and it is largely considered an “internals” thing.

In relation to the i18n improvements discussed earlier, the headers in these page templates are also now translatable. Simply include a Text Domain: and Domain Path: header in your style.css where the textdomain is the defined textdomain for translations (i.e. twentyeleven) and the Domain Path is the path relative to the stylesheet directory (i.e. the proper place the theme is regardless of if it’s a parent theme or a child theme) where the POT file is (/langs). I don’t want to get too deep into this as Andrew Nacin, the architect of this feature, plans to put out a field guide going into detail. Stay tuned to that.

Custom Header API

For a few versions now, WordPress has supported two functions add_custom_header_image() and add_custom_background(). These two functions have added new menus for designating header and background images to the Appearances menu.

WordPress 3.4 introduces a new API for dealing with custom headers and backgrounds and introduces new flexibility in terms of image sizes, etc. The two functions above have been deprecated (which means they’ll work for awhile but will ultimately go away, so use the new techniques) and replaced with new theme support. If you recall from previous version, we use the add_theme_support() function to, well, add support for a feature in a theme. To integrate the new stuff, include these lines in your theme functions.php:

1
2
3
<?php
add_theme_support( 'custom-header' );
add_theme_support( 'custom-background' );

Both function calls can take a second argument which must be an array of presets, but it’s entirely optional. To omit the second argument renders behavior as we’ve known it for some time. To include it allows theme developers to designate designate parameters for both elements, that can then be customized by the end user.

For custom headers, you may include defaults along these lines (gregariously stolen from the Codex):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?php
$defaults = array(
    'default-image'          => '',
    'random-default'         => false,
    'width'                  => 0,
    'height'                 => 0,
    'flex-height'            => false,
    'flex-width'             => false,
    'default-text-color'     => '',
    'header-text'            => true,
    'uploads'                => true,
    'wp-head-callback'       => '',
    'admin-head-callback'    => '',
    'admin-preview-callback' => '',
);
add_theme_support( 'custom-header', $defaults );

Likewise, for custom background defaults you might have this:

1
2
3
4
5
6
7
8
9
<?php
$defaults = array(
    'default-color'          => '',
    'default-image'          => '',
    'wp-head-callback'       => '_custom_background_cb',
    'admin-head-callback'    => '',
    'admin-preview-callback' => ''
);
add_theme_support( 'custom-background', $defaults );

Bonus

Did you know?

  • PHP end of file closing PHP tags are now removed. Those are these – ?> Why is this important? Including the closing tag means that if there is any white space at the end of a file, PHP is likely to break. Omission means that PHP assumes a close tag at the end of the file and whitespace can’t corrupt. Personally I’ve argued for this in the past. The main opponent must have been in a coma when this was slipped through by other core developers.
  • Distraction Free Writing, first introduced in WordPress 3.2 is now supported by all custom post types.
  • The theme installer now has infinite scroll which is just kind of pretty aesthetic thing. It also defaults to keyword searches when you’re browsing for a new theme on the WordPress Theme repository.
  • Internal functions and classes now output “rtl”, “ie7”, “ie8”, etc as classes for browser targetting.