Writing Patches

Picking a ticket

• Pick a bug to work on
• Work on the most important bugs first
• Make sure documentation gets updated
• Take extra time to do it right the first time
• Test your code
• Regressions are bad
• Smaller patches get reviewed faster
• Work on multiple bugs in parallel
• Get advice before, not after
• More detail for these guidelines here: Mozilla Development Strategies
• Review disagreements best handled quickly in Slack with summary on Trac

Requirements for patches

• Inline documentation
• Automated testing (spin-off)
• Feature requests
• WP_DEBUG, SCRIPT_DEBUG
• Patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. development scripts, and don’t minimize
• Images (attach originals)
• Patches should be made against the latest code in the SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. repository
• Patches should be made against the root WordPress directory (not against a subdirectory)
• … however, if your patch includes tests, both the code changes and tests can be included in the same patch.
• Patches should adhere to the coding standards

Expectations for patches

• Expect rounds of feedback
• Expect potential for rejection (wontfixwontfix A resolution on the bug tracker (and generally common in software development) that indicates the ticket will not be addressed further. This may be used for acceptable edge cases (for bugs), or enhancements that have been rejected for core inclusion., invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid., pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, etc.)
• Understand it may not be a priority
• Bugs: Expect steps to reproduce
• Enhancements: Expect request for justification
• UIUI User interface/UXUX User experience: There is a separate process

Seeking feedback

• SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., bump, find committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers – a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component., etc.
• Knowing where to ask for help: https://make.wordpress.org/chat/

Helpful tools/tips/code snippets/design patterns

• parse_args

Pro tips

• Good attributes of a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. contributor
  • Brevity (Patches, Comments, Personal Agendas)
  • Thick Skin
  • Don’t assume everyone is stupid
  • Do your homework (study code and history)
  • Constraints of pragmatism and back compatback compat Backward compatibility – a desire to ensure that plugins and themes do not break under new releases – is a driving philosophy of WordPress. While it is a commonly accepted software development practice to break compatibility in major releases, WordPress strives to avoid this at all costs. Any backward incompatible change is carefully considered by the entire core development team and announced, with affected plugins often contacted. It should be noted that external libraries, such as jQuery, do have backward incompatible changes between major releases, which is often going to be a greater concern for developers.
  • Constructive criticism
  • Humility