You publish with WordPress, are comfortable with editing theme templates and making basic CSS changes, and you’re ready to take your site to the next level. Join Daniel Bachhuber, code wranger for Automattic’s WordPress.com VIP, to learn what you need to know. We’ll discuss topics like version control, performance and optimization, debugging, and other development best practices. This session will be geared towards the tech-savvy with a practical knowledge of WordPress.

It ended up being a little less ambitious. We started out with (the importance of) setting up a local environment, reviewed what makes a plugin, and introduced a few project ideas. Between a dozen and two dozen students attended; for almost all, the information was completely new.

The most important note on this subject: there are lots of jobs available.

Also, come hit us up with WordPress questions at our Happiness Bar!

Session notes are below the slides.

Do it locally

• Set up a sandbox
  • MAMP is an awesome way to get going on a Mac and there’s a way for Windows too
  • Sequel Pro allows you to easily access your database
  • Use ‘ack’ to find functions
    • Example: ack –before-context=10 –ignore-dir=wp-admin ‘function esc_’
    • Code is gospel. You might read tutorials or examples on the web that say one thing or the other; code will tell you the truth.
    • Reading code is a literacy of WordPress development. Dive into it to figure out what’s going on.
• Learn how to properly debug – fix those bugs as they’re happening
  • Enable WP_DEBUG in your local environment
    • It’s a quick and easy way to see what’s going wrong with your code for fatal errors
    • See PHP notices and other things you might normally miss
    • Make sure you’re using the best WordPress functions for the job
  • “5 ways to debug WordPress” and “Debugging WordPress” – Andrew Nacin
• Commit to version control and deploy to production
  • Why?
    • More easily communicate the changes you’re making with the rest of your team.
    • Work on multiple features at the same time.
    • Roll back if necessary; better than backups.
    • Automated deployment — no more copy and pasting over FTP.
  • What makes a good commit message:
    • Consider your audience: writing for coworkers and for historical purposes.
    • Explain why you made the change, not what it was. What it was should be self-explanatory from the code
    • Link to Trac tickets or other relevant conversation.

Anatomy of a plugin

• First, a quick introduction to PHP
  • functions, variables, and how the code is executed
• What are plugins then?
  • Description
  • Functions and variables
  • Do something useful
• How to audit a plugin
  • Reviewing on WordPress.org
    • Compatible with most recent version of WordPress?
    • Regular release cycle with clear changelog
    • Positive dialog in the WordPress.org forums
    • Reputable plugin author has other plugins released
    • Licensed under the GPL
  • Install it locally and test it out. Make sure it does what you want it to do.
  • Formal code review?
    • Follows best practices and coding standards
    • Uses core APIs and the proper hook
    • Secure and performant
  • Common problems with plugins
    • Doesn’t do what you need it to
    • Plays poorly with the rest of your site
    • Performance problems with queries or remote requests
    • Security holes
• How to write your own plugin

What to do?

• Making your design responsive across many screens
  • What is responsive design?
    • Design for many different browser widths
    • Different than creating a mobile-specific website
  • Examples
    • Smashing Magazine: http://www.smashingmagazine.com/
    • BU Pipe Dream: http://www.bupipedream.com/
• Multi-format publishing (post formatsand custom post types)
  • Post formats:
    • Customize the presentation of your content based on the type of content
    • Types include links, galleries, videos, statuses, audio, etc.
  • Custom post types allow you define arbitrary content types
  • Examples:
    • ONA11 conference website uses custom post types and post formats: http://ona11.journalists.org/sessions/friday-lunch-keynote-a-conversation-on-the-front-lines-of-the-arab-revolution/
    • WSJ Story Streams: http://stream.wsj.com/story/oscars-2012/SS-2-112/
• Moar plugins!
  • Edit Flow
  • Zoninator
  • JSON API
• Multisite blog network
  • Let students create sites for their organizations, etc.
  • Quick introduction to multisite
• Follow the five tenets to mastering WordPress development
• Read others’ code and have others read yours; work in public on Github

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.

Who am I?

My name is Daniel Bachhuber and I work as a code wrangler on Automattic’s WordPress.com VIP team. We work with publishers like TIME, The New York Times, TechCrunch, Cheezburger, and more who use WordPress at scale.

The point of this presentation is to cover the things you mostly learn the hard way. Now you can learn them the easy way. Some of these topics were covered by Erick’s talk this morning… I’ll quickly review.

Why is this talk important?

• Make your code secure, performant, and protect against the future
• Let others love your code too

1. Do it locally

Set yourself up for success

→ WP_DEBUG opens your eyes

Why:

• It’s a quick and easy way to see what’s going wrong with your code for fatal errors
• See PHP notices and other things you might normally miss
• Make sure you’re using the best WordPress functions for the job

WP_DEBUG does the following:

• Turns on the display of PHP errors and warnings
• Triggers notices for deprecated functions

Slide: Show the whitescreen of death and then with WP_DEBUG on

“5 ways to debug WordPress” and “Debugging WordPress” – Andrew Nacin

→ Know thy codebase; when in doubt, ack

Why:

• Code is gospel. You might read tutorials or examples on the web that say one thing or the other; code will tell you the truth.
• Reading code is a literacy of WordPress development. Dive into it to figure out what’s going on.

Use ack to quickly search your code base. It’s better and faster than grep.

Slides: Different usages of ack

Some usage:

• ack ‘function my_function_name’ for the source of a function
• ack ‘/crazy-regex/’

Slide: Files you might commonly need to reference

// Some of your functions for sanitizing input
// and formatting output, including esc_*(),
// sanitize_*(), and capital_P_dangit()
wp-includes/formatting.php

// Post manipulation, including
// register_post_type(), get_posts(), etc.
wp-includes/post.php

// Reference for modifying the Query
wp-includes/query.php

// Functions you can override in your theme
// or plugin
wp-includes/pluggable.php

→ Install Debug Bar, it’s like Firebug for your WordPress

By default, the Debug Bar gives you information about the execution of the page.

Slide: Debug Bar by default

Define SAVEQUERIES to do the following:

• Saves each query
• Identifies which function calls it
• Saves how long it took to run

Slide: Debug Bar with SAVEQUERIES

Debug Bar Extender adds some profiling information

Slide: Debug Bar Extender

→ Use version control and write descriptive commit messages

Version control is an awesome historical record of your project. SVN and Git are two popular types of version control, the former is used for the WordPress.org project and the latter was popularized by Github, a social coding site.

Version control gives you these advantages:

• More easily communicate the changes you’re making with the rest of your team.
• Work on multiple features at the same time.
• Roll back if necessary; better than backups.
• Automated deployment — no more copy and pasting over FTP.

Slide: What a diff on Github looks like

What makes a good commit message:

• Consider your audience: writing for coworkers and for historical purposes.
• Explain why you made the change, not what it was. What it was should be self-explanatory from the code
• Link to Trac tickets or other relevant conversation.

Slide: What good and bad commit messages look like

Neat example of Wired Magazine accepting contributions via Github for an article.

2. Follow best practices

Let others love your code too

→ Don’t modify core. Do extend it properly.

Why: your changes will get blown away, you won’t upgrade regularly, and the sky will fall on your head.

WordPress has an extensive system of action and filter hooks you can use to extend functionality and modify values. It’s the “window into WordPress”.

Sometimes you will need to do ugly workarounds. Don’t worry, it’s better than modifying core.

Slide: Filter workaround for core problem with custom statuses

If you find something limiting in the API, open a Trac ticket!

→ Prefix all the things

Prefix all of your functions and variables to avoid collisions; better yet, write your functionality into classes.

“In WordPress, prefix everything” – Andrew Nacin

Slide: Example of non-prefixed vs. prefixed

→ Coding standards are standards for a reason

Why: You’re not the only one working with your code. WordPress’ coding standards are a common language for others to understand your code.

• Tabs, not spaces, for indentation. Allows the most flexibility between clients.
• under_score for functions and variables. Everyone else does.
• Capitalize_Classes. This too.
• use-hyphens-to-separate-words-in-files.php. This three.

Slide: The coding standards I run into most commonly with VIP

3. Use the correct hooks and APIs

There are so many

→ Use the WP_HTTP class for remote requests

The transport mechanisms available for WordPress to use vary from server to server, especially if you’re releasing code to be used on shared servers. That’s why you should use the WP_HTTP class… it uses the best mechanism available.

Slide: different HTTP functions you can use

→  Find the proper action for your action

‘init’ isn’t everything. Invest some time into finding the right action to avoid bugginess later. Make sure all order of execution code in your functions.php and/or plugin is hooked into an action.

‘after_setup_theme’ is a good place for:

• Registering nav menus
• Setting your post thumbnail sizes
• Adding theme support

Slide: after_setup_theme

‘wp_enqueue_scripts’ is where you should enqueue all of your scripts and styles. Define a dependency if you need to. Enqueuing on ‘wp_print_styles’ may cause issues.

You can also minimize HTTP requests by only enqueuing them on the pages you need them.

Slide: wp_enqueue_scripts

Others:

• ‘add_meta_boxes’ is a good place to register your meta boxes
• ‘admin_menu’ for adding admin menus
• ‘widgets_init’ is a good place for registering widgets

4. Protect yourself

Don’t trust strangers

→ Properly handle your user-submitted data

Validate that the data is what you need. Follow a whitelist approach

Sanitize what the user has submitted:

• sanitize_text_field() // strips tags, checks for invalid UTF-8, remove line breaks, tabs and extra white space
• intval() // integer value
• wp_filter_post_kses() // sanitize for allowed HTML tags and attr
• sanitize_title() // strip PHP and HTML tags
• sanitize_key() // lowercase alphanumeric characters, dashes and underscores

Slide: All of the core sanitize functions you can use

Make sure you sanitize your data at the point of accessing it.

Slide: Sanitize at the point of using your data

“Data Validation” in the WordPress.org codex
wp-includes/formatting.php includes all of the functions

→ Escape data on output

There are different escaping functions you can use to protect your HTML. Make sure your HTML is what it’s supposed to be:

• esc_html() // escape for data within HTML, checks for invalid UTF-8
• esc_attr() // escape for HTML attributes, checks for invalid UTF-8
• esc_js() // escape single quotes, htmlspecialchar ” < > &, fix line endings.
• esc_textarea() // escapes data for use in a textarea
• esc_url() // removes a bunch of invalid characters from your URL, makes it good

Slide: Different escaping functions you can use

Slide: Escape at the point of printing data

→ Nonce (numbers used once) to make sure people are who they say they are

Use Nonces for security (XSRF) and checking user intention (Edit vs. Quick Edit)

Nonces are temporary (24 hours), tied to specific users (if authenticated) and actions, and in some cases, referrers.

Slide: Adding a nonce to your form, and then checking for it on form process

“WordPress 2.0.3: Nonces” – Mark Jaquith

→ When you must use SQL, $wpdb->prepare()

$wpdb->prepare() properly escapes strings.

Use %s and %d depending on whether you’re using a string or a digit; quote marks will be auto-added for strings.

Slide: Usage of $wpdb->prepare

“Protect queries against SQL injection attacks” in the WordPress.org codex.

5. Optimize

Performance matters — make it fast

→ Know your Query

query_posts() should be used in one and only case if you need to modify main query of page. It sets a lot of global variables and will lead to obscure and horrible bugs if used in any other place and for any other purpose.

get_posts() is very similar in mechanics and accepts same arguments, but returns array of posts, doesn’t modify global variables and is safe to use anywhere.

WP_Query class power both behind the scenes, but you can also create and work with own object of it. Bit more complex, less restrictions, also safe to use anywhere.

Slide: Different ways of the Query

WP_Query actually does four SQL queries

• Main posts get
• postmeta get
• taxonomy terms get
• SQL calc rows

Slide: How you can disable extra queries on the Query

Slide: How you should modify the query

“When should you use WP_Query vs query_posts() vs get_posts()?”
“You don’t know Query” – Andrew Nacin

→ Cache expensive data

If a given set of data takes more than ~200 ms to generate, you should cache it.

WordPress has three different types of caching:

• Transients -Transient data, persistent across page loads but could expire at any time.
• Object cache – Page load by page load, unless you use an object caching backend like memcache or APC.
• Options – Data will always persist, maybe can’t handle a lot of it.

→ Cache remote requests, or offload to the frontend

Remote requests are when your code has to pull some data from somewhere else. Retrieving that data can be expensive. Uncached, every millisecond the remote request takes are milliseconds added to the page load. And these are for every visit to your site.

Sometimes, we can rely on the API to be fast enough that we can just request and cache on the frontend.

Slide: Remote request on the PHP end

Oh, but we actually need new live data all the time. Trying to invalidate the cache and repopulate all of the time is bad news bear. Let’s just move this to some Javascript on the frontend

Slide: Offload the request entirely to the frontend

The beginning

The best thing you can do is read others’ code and share your own. If you have a friend or colleague you can match up with, swap code and leave feedback for each other. It’s tremendously beneficial for both parties. A good WordPress developer never stops learning.

When exporting, the script gives you a summary of what will be included in your export file.

For importing, it would be nice if the script pre-flighted your data and told you how many total posts were to be imported, whether new tags were going to be created, identified the custom post types in your export file that were to be rejected by the site, etc.

Also, we should figure out a better way to make sure all of our internal scripts are regularly open sourced (and synced to most recent versions).

From Mike:

Consider the audience when you write a commit message. What is that audience? It’s at least two groups of people:

• Your coworkers: You’re telling everyone else what you did. Commit messages are one to many, asynchronous and textual. Sounds like email, so write the commit message like an email. The first line should be a descriptive subject. The next line should be blank (as a separator). Then comes the body of the message. Write everything as if you’re describing it to Nikolay.
• Your future self: Think back on the times you were fixing something and needed to understand why an old commit was made. How often was the commit message useful? How often was it your own useless commit message? The commit message should say what the problem was (repro steps?), how you fixed it (briefly – the code itself gives more details), and why you changed what you did. That way the shiny pants people of the future have the information they need to decide if they can safely change your code.

From Matt:

I think as a company we need better commit messages. Very often in our messages we say what is happening but not the why, and most importantly the context of the change. I’m going to pick on this changeset, but you could really pick almost anything:

[link to changeset]

4 lines changed, with the message:

“Fixing incorrect $blogid variable, should be $blog_id.
Check if $current_blog is === false before trying to reset it.”

First a good thing: it’s a multi-line message, which is nice. Commit messages can use as many lines as you like, and be as verbose as you like.

However if I were to come across this changeset 3 years from now, say if I were debugging a similar area in the code, I’d have no idea why this change happened. The message might as well be blank, since it doesn’t really say anything I couldn’t tell in 2 seconds from looking at the diff. Some useful context would be:

• What bug did this code cause? (This is most important.) Why change it?
• Is there a relevant discussion, either on a P2 or in Trac?
• Who was involved in the fix, IE who else would have context for this change either because they reported the bug or reviewed the fix.

From Lance:

Good commit messages are my gospel. The actual syntax should vary by context, though. For theme commits, for example, we always start with the theme name up front.

But, the goal of giving context and pointing to related items is key.

I personally don’t think long commit messages are better. Instead, point to a Trac ticket or P2 post with all the gory details.

For instance, Inline Google Spreadsheet Viewer is still a perfectly valid plugin, but hasn’t been updated since September 2010, has WP_DEBUG as true at the top of the file, and needs user input sanitization for it to be secure. These things I’ll fix for my own site; there should be an easy way to contribute these fixes back to the community.