WordCamp SF_6100572433_l

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.

query.php

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.