Becoming A WordPress
WordCamp Columbus – June 2011
Who Am I?
• Kim Parsell
• Born & raised right here in Ohio
• WordPress user/developer/tester since 2008
• Author of the WP Hide Dashboard plugin
Show of hands, how many here are:
• WordPress users only?
• Developers that use WordPress to build sites for others?
Now, how many of you have:
• Upgraded your WordPress install & it broke? (Yes, we've all had
that happen, & we hate it when it does.)
• Tested a new version of WordPress before it was released
Hmmm, not too many hands on that last one....
Beta Tester Benefits:
• Preview all the cool new features coming in the next release.
• Test your plugins & theme to make sure they'll work right once
• Developers, you can detect possible conflicts with client sites,
begin working on solutions before the next release, not after.
• Plugin & theme authors, you can troubleshoot potential bugs
or conflicts, & prepare your next release.
Some WordPress numbers:
• WordPress project leaders: 6
• Extended core team: 8
• Core contributors:
- Version 3.1: 180
- Version 3.2: 101 (so far)
For those keeping score, that's roughly 120-200 people working on
a new release.
Compare that to:
• 30+ million users with:
- Thousands of hosting server configurations
- Millions of possible theme/plugin combos
• Potential for issues & conflicts: HIGH
The dev team & core contributors work hard, but they cannot test
every possible server configuration, or plugin/theme combination.
They need help from people like you.
How do I get started?
• Set up a separate WordPress install on your server to use for
testing. (Running bleeding edge code on your live website is
for experienced users only.)
• Grab latest stable version (3.1.3) & install it in a subfolder,
such as: http://yourdomain.com/testwp/
• Go to Settings/Privacy & check “block search engines” to keep
your test install from getting indexed.
Now the fun begins
• Install the WordPress Beta Tester plugin, by Peter Westwood:
• Activate the plugin, go to the settings page (Tools/Beta
Testing) & select Bleeding edge nightlies.
• To grab the latest code, click on the upgrade link & press the
Update Automatically button.
• Your test install just went from WordPress 3.1.3 to WordPress
3.2-RC1. Congratulations, you are now running bleeding edge
Take it for a spin
• Kick the tires, honk the horn, test the turn signals, play with
• In other words, put it through the paces.
• Write posts, make test comments, upload media, add links,
embed video, etc.
• Do what you normally do with WordPress & see if you can
Update your test install daily
• Each night, a new version of the trunk code is zipped up &
made available for download to testers.
• Log into your test install, click the link in the footer, & update
to the latest.
• Take a spin through everything to make sure all is still working
Oh my word, it's broken. Now what do I do?
• You may have found a bug.
• Document what you were doing when it broke – details matter
here, so include as much as possible.
• Document the error message you got or the unexpected result
• Try to duplicate the error - do the same thing again, see if it
Yep, it happened again
• Try deactivating all of your plugins, switch back to the default
theme, & try it one more time.
• Did it still give you an error? If so, then you've possibly found
a WordPress bug.
How Do I Report It?
• First, read the WordPress Codex article on Reporting Bugs:
• Follow instructions carefully in 4.1 – Before You Report A Bug –
to ensure that your problem really is a bug.
• If you're new to beta testing, join the wp-testers mailing list,
& send an email with the details of your issue. Others will be
happy to help you sort out whether it's a WordPress bug or not.
Houston, We Really Do Have A Problem
• It truly is a bug, & nobody else has reported it yet. Time to
submit a Trac ticket.
• Log into Trac using your wordpress.org forum username &
password. No account? Sign up at the forums & get one.
• Fill out the form, providing as much information as possible so
someone else can reproduce the issue.
• Include your forum username in the CC: field. Click
Preferences at top of Trac to include email address you want
notifications to go to.
• Submit the ticket, and...
The dev team & core contributors do closely monitor Trac for new
ticket submissions, & activity on existing tickets.
• You will need to monitor the ticket (remember the CC field?) &
provide any feedback requested.
• If a patch is submitted, you'll need to test it & let them know
if it fixes your issue. Lather, rinse, repeat until the ticket is
What is this patch you speak of?
• A patch is a file that lists changes to be made to program files
in version-controlled software.
• WordPress is managed via Subversion & uses Trac, an easy
web-based project management & bug tracking system.
• Yellow – the 2 files being compared
• Red – the lines to be removed
• Green – the lines to be added
How do I create a patch?
• The first thing you'll need to do is download & install a
Subversion (SVN) client.
• For Windows users, TortoiseSVN is the hands-down easiest
SVN client to use, & it's free: http://tortoisesvn.net/
• For Mac users, there are several options:
- Versions: http://versionsapp.com/
- Cornerstone: http://www.zennaware.com/cornerstone/
- SmartSVN: http://www.syntevo.com/smartsvn/
• Next, you'll need to download a copy of the latest trunk code
via your chosen Subversion (SVN) client.
• Create a folder on your computer called wordpress-3.2-svn-
trunk. Open that folder, right-click & choose SVN Checkout.
• You'll be presented with the checkout window. Enter the URL
of the wordpress.org SVN repo in URL repository field.
• The files will begin downloading to that folder.
• Open the folder & find the file you need to change. Open it in
your favorite plain-text editor. Do not use a rich-text editor
such as Word or OpenOffice to edit the files.
• Make the changes necessary, then save the file.
• You'll notice that the green checkmark has changed to a red
exclamation point. That means the file has been changed & is
no longer in sync with the repo version.
• Time to make the donuts...errr, the patch file. Right-click,
go to TortoiseSVN, and select Create Patch.
• A pop-up window will show you the list of changed files. Make
sure the file(s) you want to include in the patch are checked,
then click OK.
• You'll be prompted to save the file. Create a folder called
patches, then type in filename you want to save it as. I use
the format ticket#.patch.
• The TortoiseUDiff editor will open & show you the patch file
you just created.
• You can then attach the patch to the bug ticket you created
in Trac so it can be reviewed by the dev team & possibly
• Now wasn't that easy?
But I can't code...
• That's okay too! You don't have to be able to code to be a beta
• You can still test & report bugs, display issues in the admin
interface, the default theme (currently Twenty Eleven), even
typos, punctuation & capitalization errors.
• Find them, fix what you can, submit a Trac ticket with a patch
Bringing It Home
• Beta testers != WordPress Whiners Club
• Beta testing WordPress is a privilege & a responsibility.
• Be constructive & thorough with your feedback.
• Treat the dev team, core contributors & other testers with
respect – you'll get the same thing back from them.
• Don't be discouraged if your ticket is closed as WONTFIX.
Read their reasons, learn, keep on testing.
• Be encouraged when your ticket is marked FIXED. You just
helped make WordPress better!
Where you can find me:
• Follow me on Twitter: @kimparsell
• Find me at: http://kpdesign.net/
Thanks for flying with WordPress today!
We're working on the next WordPress release, &
we need people to test it.
To help find bugs in the code so we can fix them.
To check the new admin user interface for issues,
& the new Twenty Eleven theme too.
Because we want WordPress to be awesome, &
work properly for everyone.
But we need more testers...MOAR TESTERS!
You're going to help us, right? :)