#wcbos: Lean, Agile, Mobile, Social, Local, Organic, Pivot

This presentation is an insight into what Andrew Nacin (@nacin) and Daryl Koopersmith (@darylkoop) are thinking about, as it pertains to the next few years of WordPress. Nacin is a developer with Matt Mullenweg’s Audrey Capital and Daryl works for Automattic’s WordPress.org team.

The real title: “WordPress isn’t good enough.” There are so many more things that can be done to make WordPress better. Which, was pretty much the essence of the talk.

Improve stability. WordPress should be stable, for anything that you’re doing. How many people have lost content and had to recover through revisions or going back through browser history? It doesn’t happen often, but it still does sometime. There’s a Google Summer of Code project to use local storage in your browser to back up your drafts.

Plugin compatibility. It should be easier to know whether your plugins are compatible with the latest version of WordPress.

Seamless updates. WordPress should update automatically. Many users are distributed amongst a few different versions of Firefox (3, 4, 5, and 6). With Chrome, the version you’re on is less apparent but you can still track it down. On Facebook, there’s no way for you to know which version you’re on. More seamless updates means faster release cycles and better improvements.

Ease of use. Introduce simpler ways to post content. “Telling someone what to do is not as good as making it obvious.” New users should be able to immediately create content.

Better media handling. WordPress needs to improve how it handles non-text content. In the pipeline are a drag and drop media uploader, and a new workflow for managing media content.

#wcbos: Plugins Are Blueprints

Marc Lavallee (@lavallee) and Wes Lindamood (@lindamood) are half of the NPR Project Argo team. Both were relatively new to WordPress when they started; today they’ll be talking about the zen of using plugins.

“Each plugin speaks with it’s own voice,” says Wes. Sometimes they can produced cluttered and confused experiences for your users. The framework they’ve chosen as it relates to plugins is use, patch or build.

  • “Use” means they install the plugin, activate it, and it’s live. They may make minimal modifications with CSS, but it’s generally fine to go out of the box.
  • “Patch” means they may make minor modifications to the codebase, through hooks or actually changing core, and then try to push the improvements they made back upstream.
  • “Build” means they take ideas and inspiration from other options in the WordPress plugin directory, and roll their own plugin.

Example: Navis Slideshow

The Argo team decided to build a photo slideshow plugin that leveraged WordPress’ built in gallery functionality, and looked and worked as a standard slideshow.

Their functional starting point was the Slides for WordPress plugin. Wes downloaded and activated the plugin, and made basic presentation tweaks with CSS and Javascript. Unfortunately, there were other behavioral changes they wanted too. They thought about patching but then realized it would too much work. So they went around to rolling their own plugin.

Two improvements worth mentioning are conditionally loading images and Javascript. For the first, the problem to solve is reporters that like 60+ image photo galleries. If you load all of these images on page load, it increases your bandwidth costs and load time for end users. The solution is to reference the image URLs in a storage div, and then only load them when the user is getting close to viewing them. For the second, there’s a global variable on every page load for marking whether a WordPress gallery was included in the post. If so, the Javascript gets added to the footer.

Improvements included reducing the footprint of the plugin from 39k/895 lines to 8k/244 lines.

Example: Jiffy Posts

To make their content more engaging, Argo wanted it to make it easy for their reporters to embed rich media. Initially, this looked like Embedly or oEmbed but they didn’t want to cede control of what was embedded to the content provider.

Solution: A custom post type called Jiffy Posts. Reporters could create a new post with a title, short comment, link to the referenced media, and can include source attribution. Doing it this way, instead of having reporters embed rich media in the post, ensures there’s presentation consistency from post to post and content type to content type.

Ultimate takeaway: The decisions and opinions of plugin authors can directly impact the user experience of your website. Think about this more holistically, beyond just reviewing whether the code is clean.

The slides from the presentation are available on Slideshare and download as a PDF.

#wcbos: Advanced Theme Performance Techniques

Frederick Townes is the founder of W3 Edge, CTO at Mashable and author of W3 Total Cache. He’s presenting today on WordPress theme performance best practices.First, he recommends contributing back to the WordPress Codex because everyone in the room thinks it could be improved.

Pay lots of attention to the hierarchy with page templates.

Think about how many files you’re loading into memory, and the overall footprint they end up consuming. You can track this down using xdebug.


  • The larger the heap, the greater the execution time.
  • “Graduate” groups functions to plugins.
  • The fewer files the better.
  • Explore and use microformats for reviews, businesses & organizations, products, and people.
  • Use external services and fail gracefully.

W3 Total Cache has a debug mode that will show you what’s being cached on a request and what’s being missed.

Trick to debug on production:

define( 'WP_DEBUG', true );
// log to wp-content/debug.log, useful tests on production
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

#wcbos: Enterprise Publishing on WordPress.com VIP

WordPress.com is an “awesome blogging platform,” according to Chris Murray of Oomph. WordPress.com is “get started writing or blogging”, not “get started worrying about technology.” WordPress.org requires downloading the software, installing, and configuring. This gives you more flexibility, but it also means it’s more complex. Entreprise customers are somewhat in a lurch choosing between standard WordPress.com and WordPress.org because the former isn’t flexible enough and the latter has the potential of too many headaches.

WordPress.com VIP is the “best of both worlds.” Customers don’t have to worry about keeping servers up, but they have more of the flexibility that comes with installing new plugins, etc.

WordPress.com VIP clients include:

  • CNN
  • Dice.com
  • RIM
  • NBC Sports
  • VentureBeat

To think about the different types of hosting offerings, a typical basic dedicated server includes hardware, network connectivity, and electricity. Managed services include all of that, plus take care of your basic LAMP stack. WordPress.com VIP cares about everything plus WordPress, including caching, load balancing, upgrades and functionality.

When working with WordPress.com VIP, the process is probably a little different:

  • Any custom code needs to happen in the theme layer.
  • You need a great developer to work with (in-house or third-party).
  • Highly collaborative approach. As a developer, you can actually interact with folks at WordPress.com. You can pitch ideas and ask for feedback on the best way to do it.
  • Theme submission is a process with WordPress.com VIP. All code is reviewed line by line for best standards, security, and performance. Once the theme is approved, they’ll set up a Subversion repository for your theme.
  • Deployments are done with the WordPress.com VIP team.

Code is a little different too:

  • When you’re writing code for the WordPress.com VIP environment, someone is always reviewing. It makes you think more about whether you’re doing it the right way. The focus is on beautiful code.
  • Need to follow WordPress Coding Standards.
  • Plugins are included in your theme’s functions.php file.
  • Security and performance is the number one concern with the WordPress.com VIP team, things like sanitizing input fields and ensuring database queries are performant.

When it comes down to it, the biggest different between WordPress.com VIP and self-hosted: you (have to|get to|learn how to) do it right.


Q: How do you do staging?

Chris: Often we’ll have a staging server in-house that’s client facing and/or use one of our five sites with the standard package as the pre-production site.

Q: Could you explain more about the lack of network admin?

Chris: WordPress.com is a multisite network in itself, so they don’t give you super admin access. If you want to set up a new blog, it’s a more involved process including requesting the site, configuring everything, submitting a theme for review, etc.

Q: Is customer code required to be licensed under the GPL?

Chris: I’m not sure. Licensing is definitely something to be discussed.

Q: What types of things does VIP support?

Chris: VIP support offers lots of support including theme reviews, plugin reviews, data migration. They don’t write code for you however. Any custom development should be done in-house or with a contracter.

Chris: “Working with the VIP team has added tons and tons of knowledge to my team.”

Other questions:

  • Is WordPress.com VIP running stock WordPress, or are there tons of custom modifications?
  • If VentureBeat were to install a new plugin, would other WordPress.com VIP clients be able to access it?
  • What things can be done to expedite the deployment process? Are there any common gotchas?
  • How do new features get requested if lots of clients want it?

#wcbos: Entreprise WordPress Do’s and Don’ts

What does enterprise mean? In the context of the WordPress presentation: sites on a large scale. Sites with a lot of traffic, content, and that require high availability.

WordPress evolution from an enterprise perspective:

  • 2.3 – Introduction of custom taxonomies
  • 2.9 – Introduction of custom post types; WordPress matures to a real CMS
  • 3.1 – Network admin and expanded queries
  • 3.2 – Modernization and performance improvements

Conde Nast started migrating a lot of sites from Movable Type to WordPress in 2008-2009, and the total number has only been growing.

Guidelines for using WordPress in enterprise

Hosting infrastructure do’s:

  • Carefully examine your site’s requirements and evaluate service offerings before deciding on a host
  • Give yourself at least 2 weeks for new WordPress VIP setups
    • This lead time requirement can sometimes be a deterrent for clients that want to get a project live on a quick turnaround
  • Give yourself additional time for VIP code and plugin reviews. Plugins that aren’t already in their set of accepted set can take a while
  • Leverage AMI’s for sites on Amazon Web Services
  • Use multiple regions for failover on Amazon Web Services
  • Use a Content Delivery Network (CDN)

Hosting don’t: Host multiple high-trafficked sites on the same hardware

Migration do’s:

  • Transfer your SEO juice using 301 redirects
  • Minimize the need for a double-publishing scenario

Migration don’t: Forget your image assets.

Neat trick: If you don’t know whether all of your image assets were copied over, write a script to tail Apache/Nginx request log, watch for 404s, and pull the image over from the old environment if the request 404’s.

Development do’s:

Development don’ts:

  • Modify WordPress core
  • Write your own SQL queries unless absolutely necessary
  • Forget about your admin users — use contextual help and train them

Launch do’s:

  • Lower DNS TTL settings before launch (if updating DNS address)
  • Apply appropriate CDN exceptions for wp-admin pages
  • Remove your robots.txt file to make the site visible to search engines
  • Verify server permissions on files and directories
  • Set up an automated deployment process

Launch don’t: Keep .htaccess writable

Resources on hardening WordPress

#wcbos: Web Strategy in Higher Education

Web strategy defined: The translation of the organizational objectives and values into high-level management directives for the web. This will be Jay Collier’s focus for this morning.

Common principles for web strategy:

  • Be dependable – Anywhere, anytime, on any device
  • Be intuitive – Simple publishing, searching, finding
  • Be helpful – Helpful information and instructions
  • Be interesting – Appealing, personal, immersive
  • Be welcoming – Online spaces for collaboration

Not often is there one sponsor for web strategy; there are generally multiple. Question how long your web strategy is going to be in place, and whether that’s an appropriate timeline. Thinking about why you’re doing it, vision and principles, and figure out what exactly you’ll do and how to measure it.

In determining which platform to deploy, or functionality to implement, Jay recommends having stakeholders list features and prioritize on a 1-10 basis.

A “domain architecture” map will help you understand all of the requirements by department, and how they interrelate.

Lafayette College has integrated WordPress in all aspects of their publishing.

Queen’s College in Australia has gone as far as focus their homepage entirely on prospective students. All other content lives elsewhere on the site, and is accessible after community members receive a login.


Flying an hour late Delta 2542 up to Boston for WordCamp Boston after a perfectly-timed trip to the airport. Delta sent me a notification email this morning and I adjusted my departure accordingly.