The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in our bug tracker.
Commit messages are a critical aspect of how WordPress is developed. They are an integral part of the project’s history, along with the changesets themselves. We write commit messages for multiple audiences: contemporaries (fellow coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. developers, pluginPluginA 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 developers, anybody following along with core development), future contributors, and computers. Good commit messages serve each of these audiences well. They describe the what and the why of the changeset; the how is described by the diff itself.
Even if you are not a committercommitterA 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., you can make use of these guidelines while contributing to WordPress, as well as in your own projects. By describing your patchpatchA 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. in a way that is sensitive to the concerns outlined here – or even drafting a commit message yourself – you make it easier for the committer process your contribution quickly.
Remember: Do not commit to multiple branches in the same commit. This will, at a minimum, break the GitGitGit is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. mirrors.
The general format for a commit message is as follows:
Component: Brief summary.
Longer description with more details, such as a `new_hook` being introduced with the context of a `$post` and a `$screen`.
More paragraphs can be added as needed.
Props person, another. Fixes #30000. See #20202, #105.
Generally, each line in a commit message should begin with a capital letter and end with a full stop. Code, such as the name of a function or a hook, should appear inside backticks, to ensure proper formatting in TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. TicketticketCreated for both bug reports and feature development on the bug tracker. numbers preceded by a number sign #20202 and revision numbers inside square brackets [30000] will auto-link in Trac, Slack, and here on make/core.
The first line of a commit message is a brief summary of the changeset. The brief summary is used for email subject lines, Trac changelogs, and features prominently in most VCS log formats, such as git log --format=oneline. The high visibility of the summary makes it critical to craft something that is as descriptive as possible within space limits.
Aim for around 50 characters or less, stopping at 70. This is important because log-viewing tools nearly all expect the first line of commit messages to fit within these limits. This difficult restriction may force you to think critically about the essence of your commit; if you can’t describe the change in a short sentence, the commit may not be atomic enough.
You may prefix the summary with the component or focus of the change. Such a prefix may make it easier for contributors to scan the changelog for commits of interest. See [33901], [33883], [33848] for some examples. Note that the prefix counts toward the 50/70 character count.
Use the imperative mood when possible: “Relax term ID comparisons…” instead of “Relaxes term ID comparisons…”
The longer description of a commit should include more details about the commit and its repercussions for developers. These may include new hooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same., “gotchas”, other solutions that were considered, or backstory. Consider your audiences when deciding what should go into the description: developers following along with the commit mailing list, volunteers collating information for each release’s dev notesdev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include:
a description of the change;
the decision that led to this change
a description of how developers are supposed to work with that change.
Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. and WordPress Core Weekly, and future code archaeologists trying to figure out who did what and why.
Must be separated from the summary by a blank line.
Can be multiple paragraphs if necessary, separated by blank lines. It is not unreasonable for a commit message to be more verbose than the final changeset itself.
Unlike the Summary, lines should not be manually wrapped – log viewers can take care of wrapping the description themselves, if they need to.
Props should be given to all those who contributed to the final commit, whether through patches, refreshed patches, code suggested otherwise, design, writing, user testing, or other significant investments of time and effort. Usernames are parsed for the credits list and WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ profiles.
In the case of bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. reports, props should also be given to the reporter of the bug.
Check any tickets which were closed as a duplicate in case they contain contributions that warrant props too.
Separate usernames by comma + space. Think: /^props (\s*([^,]+),?)+$/
Copy/paste usernames to avoid typos. (Sorry, rmccue; or is that rmmcue?)
If the user has a space in their displayed name, use the slug from their w.org profile URLURLA specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org. For example Frank Klein on Trac should get props as frank-klein.
Err on the side of giving props liberally. Props provide major encouragement for contributors.
If you forget to prop someone, check to see if they already have props in the current release as it won’t matter in the long run as they’ll be included in the release credits anyway. If they aren’t already propped, then you can flag it to the Release Coordinator so they can ensure that person is added on release day. It’s also recommended to reach out to the contributor in Slack or in a comment on the ticket as a courtesy and apologize for missing their name in the commit message and letting them know their contribution will be recognized and note how.
Prop yourself when the commit is the product of huge efforts involving multiple people, such a major feature, APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., or particularly nasty bug.
Generally, giving contributors feedback on patches and giving them a chance to iterate is the recommended process. However, on the occasions where you as the committer complete the idea of a patch, you could write “props X for initial patch.”
It is normal for committers to adjust style or rearrange logic before a commit, or to account for a simple edge case. In these instances, omit yourself. Your name on the commit implies that you’ve reviewed and tested it, which is just as important as the contents of the commit.
If committing your own code, props are assumed, so omit yourself here as well.
Trac will add commit messages as comments on all tickets referenced as “fixes” or “see”. If a commit message contains the text “Fixes #12345“, Trac will close ticket #12345 and assign you as the owner if there isn’t one already.
Ticket references should be on their own line directly below any props. If there are no props, an empty newline should separate it from the content above.
Multiple tickets should be separated by a comma + space.
If referencing both fixed and related tickets, begin with “Fixes” and end each set with a period, e.g. “Fixes #19867, #9864. See #31696.”. If there are many items in a set, put it on its own line.
If you forget to include a ticket number, comment on the ticket (e.g., “Fixed in [changeset_number]” with an optional copy of the commit message to help ensure traceability.
Term IDs are sometimes provided as strings. This is particularly evident in `wp_dropdown_categories()`, where the `selected` argument was not being respected. Plugin authors should also be wary of using strict comparisons for term IDs.
If you use Git (and possibly commit with git-svn), you can have a hook automatically fill a new commit message with the standard format.
Create a .git/hooks/prepare-commit-msg file with the following script, and then chmod +x .git/hooks/prepare-commit-msg.
#!/bin/bash
COMMIT_MSG_FILE=$1
COMMIT_SOURCE=$2
if [ $COMMIT_SOURCE ]; then
# A messages is already being provided via `commit -m`, rebase, etc.
exit 0;
fi
template="Component: Brief summary.
Longer description with more details, such as a \`new_hook\` being introduced with the context of a \`\$post\` and a \`\$screen\`.
More paragraphs can be added as needed.
Props person, another.
Fixes #30000. See #20202, #105.
#
# See https://make.wordpress.org/core/handbook/best-practices/commit-messages/ for more detailed guidelines."
# Wrapping the variable in quotes preserves the newlines, because BASH is weird.
echo "$template" > $COMMIT_MSG_FILE
PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher
To check all lines in all changed files, run phpcs $(git diff master --name-only) or phpcs $(svn stat | grep "\(M \|A \)" | grep -v "external item" | cut -c8-) .
To check only the changed lines, clone wp-dev-lib and runDIFF_BASE=master DEV_LIB_ONLY=phpsyntax,phpcs /path/to/wp-dev-lib/pre-commit. Note that you need to be on a local branchbranchA directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". other than master, and the changed need to be either committed, or staged for commit. Unstaged changes will not be scanned.
Creating Bash aliases for the above commands is recommended for convenience.
JavaScriptJavaScriptJavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.
Runnpm run grunt jshint. This will be done automatically by npm run grunt precommit as well.
HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers., CSSCSSCascading Style Sheets., a11yAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access�? (i.e. unassisted) and “indirect access�? meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility)
These must be checked manually.
Run npm run grunt build && npm run grunt precommit. This runs the automated test suites for PHP and JavaScript, as well as various other tasks for CSS, images, etc.
You may also need to manually run PHPUnit with various flags, depending on the change.
Check the full diff one last time (svn diff). If you’re using Git, interactive staging (git add -p) is a good way to review individual chunks.
Check the list of modified files (svn stat), making sure that new files are added. It is also good to double check the contents of new files, as applying patches that add new files can result in the content of new files being duplicated. Also make sure that new files are not named the same as something in the $_old_files array, or else they will be deleted again right away. If one is, comment out the line from the array with a note indicating when a file with the same name was added back. Do not delete the line.
If deleting files, add them to the $_old_files array.
You can “cherry-pick�? commits from trunk to a release branch via svn switch ^/branches/4.3 && svn merge -c 12345 ^/trunk. You will be prompted to edit the message prior to committing. See Backporting Commits for more details.