$30 off During Our Annual Pro Sale. View details »

WordPress: I found a bug! What next?

WordPress: I found a bug! What next?

This presentation covers the best and fastest ways to report bugs within WordPress that will get the attention they deserve, and how to contribute patches to those bugs as well as other new code improvements.

Topics Covered:

• Checking out WordPress from SVN and generating patches
• Using Trac, the WordPress issue tracker
• WordPress Coding Standards
• Effective team communication (getting your patch the attention it deserves)
• Contributing code beyond basic bug fixes and small improvements

Bryan Petty

August 28, 2013
Tweet

More Decks by Bryan Petty

Other Decks in Technology

Transcript

  1. I found a bug! What next? Bryan Petty bpetty@bluehost.com github.com/tierra

  2. Types of Bugs • Security Flaw • Plugin or Theme

    Bug • WordPress Core Bug
  3. Security Issues • Your site being hacked is not necessarily

    a security issue (but can be if you know how it was hacked). • Responsibly and Privately Disclose ◦ security@wordpress.org • Exploit Scanner Plugin
  4. Plugins and Themes • Disable plugins and themes one at

    a time (try switching to one of the default themes included with WordPress) • If one is guilty, don’t report it to the WordPress issue tracker (Trac). • WP.org plugins and themes have dedicated support forums for issues. • Check with your marketplace for reporting issues with premium plugins and themes.
  5. WordPress Core Bugs • If the bug can be reproduced

    on a clean installation of the latest version of WordPress without any plugins installed and using a default theme, it’s a core bug. • Core bugs reported in Trac
  6. Steps for Reporting a Core Bug 1. Ensure it’s actually

    a bug in core. ◦ Fresh installation, or use Debug Bar plugin 2. Search Trac for a similar report of the same bug before submitting a ticket. 3. Consider discussing the issue first on IRC or on the support forums. 4. Submit your bug to Trac: ◦ http://core.trac.wordpress.org/newticket
  7. Trac Ticket Fields • Summary or Title • Description •

    Type ◦ defect (bug), enhancement, feature request • Version • Keywords • Component • Severity
  8. Filling out Ticket Description • What steps should be taken

    to consistently reproduce the problem? • What is the expected output? What did you see instead? • Include environment details: ◦ Browser, Operating System, Server OS, PHP Version, MySQL Version
  9. Patches Welcome • Version Control: Subversion • TortoiseSVN on Windows,

    Cornerstone on OS X, command line on Linux • Repository Checkout URL: ◦ https://develop.svn.wordpress.org/trunk • Patch Demo Time!
  10. Coding Standards • HTML, PHP, CSS, and JavaScript Coding standards

    help avoid common coding errors, improve the readability of code, and simplify modification. They ensure that files within the project appear as if they were created by a single person. Following the standards means anyone will be able to understand a section of code and modify it, if needed, without regard to when it was written or by whom. http://make.wordpress.org/core/handbook/coding-standards
  11. Effective Communication • Subscribe to Trac bug report updates ◦

    Configure email in Trac profile, use CC field for existing issues, and/or subscribe to wp-trac • Address issues and refresh patches. • Bring up tickets in IRC for discussion (but not during meetings). • Follow up on tickets with feedback on how you’ve tested patches. • Don’t be afraid to ask questions.
  12. Beyond Bugs: Feature Plugins • New features being developed by

    the core team, except within official plugins. • Integrate plugins into core releases starting from version 3.8. • Very open and focused teams with dedicated meetings and lead reps. • Follow team updates on: ◦ http://make.wordpress.org/ • Small features still developed in patches on the issue tracker (Trac).
  13. Questions speakerdeck.com/u/tierra Bryan Petty bpetty@bluehost.com github.com/tierra