#nyc12: I Want to Learn WordPress

This morning, I gave the first of three CMA NYC sessions I’m leading this week:

So, you’ve heard of WordPress before, possibly used it for your personal portfolio, and want to learn everything there is to know about it. Well, everything we can cover in a hour at least :) Join Daniel Bachhuber, code wrangler for Automattic’s WordPress.com VIP, as we cover the WordPress interface, key concepts like themes, plugins, PHP and MySQL, and how to choose a good web host and design for your site. This session will be geared towards those with limited familiarity who want to learn more.

It was a quick introduction to the WordPress project, key terminology you’d hear, and then a tour through the WordPress admin. The room was packed with maybe 30-40 people which was sweet. Tomorrow is “Hacking WordPress in the Newsroom” and Tuesday is “Making the Switch to WordPress.”

#wcphx: Five tenets to mastering WordPress development

Enlightenment is knowing what your code is doing and why. Thankfully, instead of having to depend on your inner calm, there are a number of tools and strategies you can use to better see what’s going on. We’ll survey a range of topics you should explore to turn your frustration into bliss.

Feeling better already? In this session, we’ll touch on everything from debugging to best practices to coding standards to version control to performance and optimization. You’ll hear the insights WordPress.com VIP shares every day.

Session notes are below the slides.

Continue reading “#wcphx: Five tenets to mastering WordPress development”

Notes from livecoding the ONA11 website

What worked, and what ideas I have for next year.

This is a quick post I’ve been meaning to do about the work we did this year on the ONA11 conference website.

Background: last year, I was late on getting a conference pass and ended up volunteering for an entire day in the student newsroom. ONA’s student newsroom produces stories, video, and other coverage related to the conference. I had so much fun that I volunteered to do it again this year. I planned to work on it over the summer, but 90% of the work ended up being done in the last week.

The goals for the website varied depending on the context:

  • Before the conference, the focus was convincing journalists to purchase tickets and attend.
  • During the conference, there are two audiences: those who are physically at the sessions and those who want to participate virtually. The former probably want a backchannel for conversation and capturing the highlights, whereas the latter probably want to participate in realtime as much as they can.
  • After the conference, everyone wants to access a historical archive of the content presented in sessions, either to catch those they missed or find the link they heard referenced.

With this in mind, we worked on making the website dynamically reflect these needs. It was helpful, although somewhat distracting from the experience, that I was working on the website during the entire conference.

What worked this time:

  • Session pages as a custom post type. This gave us a structured database of all sessions and allowed us to easily build a session listing, etc.
  • Using Posts 2 Posts to associate posts and presenters with session pages. Our realtime curation crew could easily publish content from the WordPress admin, associate it with a session, and have it automatically pulled into the session page. Furthermore, every presenter had a dedicated profile page and their information could automatically be pulled into other contexts on the website.
  • Auto-showing the livestream player on an individual session page based on timestamp. Every session was associated with a track and I had a bit of logic to pull in the correct livestream based on current time, session start, and session end.
  • Showing the session updates in reverse chronological order during the event (because the user is most likely refreshing the page and wants the most recent updates at the top) and then flipping to chronological order 15 minutes after the event.
  • Leveraging the Zoninator on the homepage for featured stories and events. Editorial loved that they could have full control over which stories were highlighted. WordPress normally lists headlines in reverse chronological order, and developers hack this with “featured” categories, etc.
  • Post formats presented content exactly as it was intended to be presented. I was particularly proud of my gallery implementation, even if there weren’t the visuals to go with it.

Next time I’d like to:

  • Get started earlier so these features are actually fleshed out before the day of.
  • Build an interface for posting updates from the session page so it’s brain dead simple to update (no associating with session post, choosing post type, writing a title if you don’t need to, etc.)
  • Allow for “featured” session updates a la NY Times Editors’ Picks for commenting.
  • Guest session update submissions with a moderation queue.
  • Live update the session page so it’s essentially liveblogging with rich media.
  • Show the bylines/avatars for people covering the event, so you know how well it’s going to be covered (e.g. one person versus five people participating)
  • On the all sessions page, show the number of updates an event has, whether it’s currently live/being livestreamed, etc.
  • Order content on the single session page based when it was published (e.g. you can assume everything 30 minutes after the session is coverage of it, whereas during the event is realtime updates on it).

Lastly, I have one more idea I’d like to pitch: a way of indicating who you want to meet at the conference. Every attendee that registers get access to a page on the website listing every other attendee. Then, they can go through and indicate whom they want to meet at the conference. It’s a double win; you get to notify who you want to meet that you want to meet them, and you get to see in advance who wants to meet you.

For archival purposes, I’ve captured a gallery of screengrabs from the website too.

#wcpdx: WordPress Multisite

My notes from a 4:15 session at WordCamp Portland that served as a quick introduction to WordPress Multsite.

These are my notes from the 4:15 session I did at WordCamp Portland. It’s a quick introduction WordPress multisite, and why you might want to consider using it.

What is it?

WordPress Multisite is a way for using one instance of WordPress to host as many sites as you’d like. Originally known as WordPress MU, the multisite functionality was merged into WordPress in WordPress 3.0.


Danger, danger, danger! You’re entering the realm of advanced WordPress user and, by editing files, the database, etc. you can potentially break your site so it will cry. Make sure to back everything up before you get started. And know that you’ve been warned.

Why is it useful?

WordPress Multisite is especially useful for those who have to administer multiples sites. If you meet all of the prereqs, it can make keeping WordPress up to date, installing new functionality, backing your data up, etc. a breeze. Instead of having to manually update each website you’re responsible for managing, you simply update one.

How do I set it up?

There is documentation you can follow in the WordPress.org Codex. Basically, what you need to do is configure DNS if you plan to use subdomains, make a change to your wp-config.php file, change .htaccess values if you’re using Apache, and then run through the guide in the admin. Boom, you’re done.

What should I be aware of?

Converting a single instance of WordPress to WordPress Multisite creates and alters database tables, and isn’t recoverable.

Hosting a lot of websites with WordPress Multisite means you should scale the resources available to WordPress accordingly. Otherwise, all of your sites will be slow.

Plugins and themes are installed once, so any changes you make are incurred for all of the users across your site. For this reason, if you’re using any WordPress.org or premium themes, you should make all modifications to the theme as a child theme (or, better yet, just CSS changes).

You can make some themes available to all sites, and other themes available to just specific sites.

If you plan to install a lot of themes, it would benefit you in advance to establish a scheme for storing them (e.g. setting up /wp-content/themes/woothemes/ and /wp-content/themes/wporg/)

Usernames are unique across the network. If you’ve set up a multisite instance for all of your clients, create usernames as firstnamelastname or similar.

Network activating plugins means they’re activated across all the sites in your network, functionality is available by default, and it’s not possible for the site admin to deactivate it.

WordPress Multisite isn’t magic, it’s technology that makes your life awesome.

What tips do you have for me?

Use a plugin like Restrict Multisite Plugins to make certain plugins conditionally available to sites.

Map custom domains to sites on your network with the domain mapping plugin.

When importing content with embed codes into a site on your WordPress Multisite network, make sure to disable the KSEs filter. As of WordPress 3.2.1, you need to do so with a special filter (which didn’t exist before 3.2).

You may want to disable some of the email notifications that go out.

Keep your users from needing to modify theme template files with the WordPress.com Custom CSS plugin. This is the same code that formerly ran on WordPress.com, is super awesome, and keeps a revision history of all your changes.

Configure your admin bar to include network admin links for super admins so you can easily access management functionality. You can also expose additional functionality for your users (e.g. custom CSS) where it makes sense.

Write your short plugins to customize the admin interface, and put them in /wp-content/mu-plugins/ to have them automatically loaded.

Other useful management plugins:

  • Term Management Tools – WordPress plugin allowing you to easily move terms between taxonomies, among other things.
  • Unconfirmed – See a list of invited but unconfirmed network users.
  • Plugins for Publishers – A list I put together back in April with other plugins I like

What questions do I have for you?

What doesn’t make sense about the network admin UI?

What features or functionality would you like developed as plugins?

What features or functionality would you like included in core?

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

Quick set of notes from Nacin and Daryl’s 1:45 pm session at WordCamp Boston.

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

Quick set of notes from Marc and Wes’ 1 pm session at WordCamp Boston.

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: Enterprise Publishing on WordPress.com VIP

Quick set of notes from Chris Murray’s 3:30 pm session at WordCamp Boston.

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?