#wcpdx: WordPress Multisite

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.

Disclaimer

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?

What I’d like to talk about at WordCamp Portland

In the spirit of being prepared, here are a few things I’d like to talk about at WordCamp Portland:

WordPress Multisite – In a nutshell, how it works and why it will make your life infinitely more manageable. If we have a group of people who quickly get their heads around the basics, I’d also love to share tips and tricks for pimping a multisite instance. For instance, using plugins like Restrict Multisite Plugins and customizing your admin bar to give easy access to the network admin for super admins. (People I should bump in to: Emma McCreary, Kayleen)

Test-driven Development – WordPress doesn’t do it, and I’m terrible at it. I should find a mentor with fountains of knowledge. (People I should bump in to: Michael Fields, Than Taintor, Toby McKes)

WordPress for Publishers – More and more newsrooms are using WordPress for all parts of their workflow. From experience, I know that journalists tend tolerate crappy technology. I’d love to hear from users about their current frustrations and pain points. (People I should bump into: Joe BoydstonToby McKes)

Dogfooding It – We love WordPress and sell to our clients, but a lot of us developers don’t actually use it on a regular basis. Why? How should we fix this? (People I should harass to no end: Nacin)

If you see me there on Friday, Saturday or Sunday, say hello! I look like this but with much shorter hair.

Photo

Deep background: I did this on a Latin American keyboard too. Hunt, peck, hunt, peck.

#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.

Fundamentals:

  • 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&A

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