Ready to get started?Download WordPress

Make WordPress Core

Search Results for: open source Toggle Comment Threads | Keyboard Shortcuts

  • Ryan McCue 9:01 am on June 17, 2013 Permalink
    Tags: ,   


    Hi everybody! Some of you may know me from various patches or WP-related endeavours: I’m Ryan McCue, developer of the SimplePie library used in core, along with a HTTP library called Requests, and long-time core hacker. I’ve been working with WordPress for quite a while now, both on open source and professional work with clients. What you may not know is that I’m also studying Electrical Engineering and Maths at UQ in Australia, and I’m here to give you a heads up on my Summer of Code project over the coming months.

    For those who missed the discussion on wp-hackers about my proposal, I’m working on a JSON-based REST API for core. I started on this with an initial proof-of-concept back at the end of last year, and I’m now working on expanding this out into a larger project. The code is being written as a plugin for testing, with the goal of having it integrated into core in some form post-GSOC.

    I’m planning on following a release strategy similar to MP6, with a weekly release along with the updates included in the release. At the moment, I’m working on completing the basic reading and writing of post data having just completed the major design documents, and I’m hoping to get the first weekly release out next week. I have a more detailed timeline which you can check out in my announcement post on my blog.

    (You’ll notice I’m currently about a week behind on my schedule, which I suspected may happen, as I’m in the midst of my final exams here. I’ve allocated an extra week just before the midsemester review for catching up if I don’t do so before then.)

    As it is, the plugin is in a usable format, and you can grab it from either GitHub or Subversion. I’d also recommend checking out the GSOC Trac issues if you’d like to keep track of the status. I’d love to have your feedback (especially on the design documents) as I move forward.

    Cheers, and I look forward to working with you all in the coming months!

  • Kat Hagan 11:24 pm on June 13, 2013 Permalink

    OPW Introduction – Hello! 

    Allow me to introduce myself — my name is Kat. I’ll be working on core this summer as an OPW intern.

    I live in the Bay Area and have been a freelance web developer for the past couple of years, so as you can imagine, I work with WordPress quite a bit. I’ve written custom themes, taxonomies, post types and plugins, but nothing that I’ve been able to release back to the community.

    Even though contributing to an open source project has been a goal of mine for many years, I was never able to figure out how to get started until now. When a friend sent me the OPW page and I saw WordPress on the list, I leapt at the chance to get more involved with a tool (and a community) that I’ve worked so much with, and in the process really level up my WP knowledge.

    For my summer project, I’ll be removing the “post by email” functionality from core, deprecating it and replacing it with an official plugin. This addresses Trac ticket #22942.

    There are some more details in the initial version of the proposal I wrote up. Note that I haven’t yet hashed through the plan with my mentors, so standard disclaimers apply. (Details subject to change without notice. Void where prohibited. Not labeled for retail sale.)

    Feel free to comment with feedback, or just to say hi. I’m looking forward to working with you!

  • Helen Hou-Sandi 2:18 pm on July 17, 2012 Permalink | Log in to leave a Comment

    CSS Coding Standards 

    Like any coding standard, the purpose of the WordPress CSS Coding Standards is to create a baseline for collaboration and review within various aspects of the WordPress open source project and community, from core code to themes to plugins. Files within a project should appear as though created by a single entity. Above all else, create code that is readable, meaningful, consistent, and beautiful.

    Within core stylesheets, inconsistencies will often be found. We are working on addressing these and make every effort to have patches and commits from this point forward follow the CSS coding standards. More information on the above and contributing to UI/front-end development will be forthcoming in a separate set of guidelines.


    There are plenty of different methods for structuring a stylesheet. With the CSS in core, it is important to retain a high degree of legibility. This enables subsequent contributors to have a clear understanding of the flow of the document.

    • Use tabs, not spaces, to indent each property.
    • Add two blank lines between sections and one blank line between blocks in a section.
    • Each selector should be on its own line, ending in either a comma or an opening curly brace. Property-value pairs should be on their own line, with one tab of indentation and an ending semicolon. The closing brace should be flush left, using the same level of indentation as the opening selector.


    #selector-3 {
    	background: #fff;
    	color: #000;


    #selector-1, #selector-2, #selector-3 {
    	background: #fff;
    	color: #000;
    #selector-1 { background: #fff; color: #000; }


    With specificity, comes great responsibility. Broad selectors allow us to be efficient, yet can have adverse consequences if not tested. Location-specific selectors can save us time, but will quickly lead to a cluttered stylesheet. Exercise your best judgement to create selectors that find the right balance between contributing to the overall style and layout of the DOM.

    • Similar to the WordPress Coding Standards for file names, use lowercase and separate words with hyphens when naming selectors. Avoid camelcase and underscores.
    • Use human readable selectors that describe what element(s) they style.
    • Attribute selectors should use double quotes around values
    • Refrain from using over-qualified selectors, div.container can simply be stated as .container


    #comment-form {
    	margin: 1em 0;
    input[type="text"] {
    	line-height: 1.1;


    #commentForm { /* Avoid camelcase. */
    	margin: 0;
    #comment_form { /* Avoid underscores. */
    	margin: 0;
    div#comment_form { /* Avoid over-qualification. */
    	margin: 0;
    #c1-xr { /* What is a c1-xr?! Use a better name. */
    	margin: 0;
    input[type=text] { /* Should be [type="text"] */
    	line-height: 110% /* Also doubly incorrect */


    Similar to selectors, properties that are too specific will hinder the flexibility of the design. Less is more. Make sure you are not repeating styling or introducing fixed dimensions (when a fluid solution is more acceptable).

    • Properties should be followed by a colon and a space.
    • All properties and values should be lowercase, except for font names and vendor-specific properties.
    • Use hex code for colors, or rgba() if opacity is needed. Avoid RGB format and uppercase, and shorten values when possible: #fff instead of #FFFFFF.
    • Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values as much as possible. (For a shorthand reference, see CSS Shorthand.)

    Property Ordering

    “Group like properties together, especially if you have a lot of them.”
    — Nacin

    Above all else, choose something that is meaningful to you and semantic in some way. Random ordering is chaos, not poetry. In WordPress Core, our choice is logical or grouped ordering, wherein properties are grouped by meaning and ordered specifically within those groups. The properties within groups are also strategically ordered to create transitions between sections, such as background directly before color. The baseline for ordering is:

    • Display
    • Positioning
    • Box model
    • Colors and Typography
    • Other

    Things that are not yet used in core itself, such as CSS3 animations, may not have a prescribed place above but likely would fit into one of the above in a logical manner. Just as CSS is evolving, so our standards will evolve with it.

    Top/Right/Bottom/Left (TRBL/trouble) should be the order for any relevant properties (e.g. margin), much as the order goes in values. Corner specifiers (e.g. border-radius-*-*) should be top-left, top-right, bottom-right, bottom-left. This is derived from how shorthand values would be ordered.


    #overlay {
    	position: absolute;
    	z-index: 1;
    	padding: 10px;
    	background: #fff;
    	color: #777;

    Another method that is often used, including by the Automattic/WordPress.com Themes Team, is to order properties alphabetically, with or without certain exceptions.


    #overlay {
    	background: #fff;
    	color: #777;
    	padding: 10px;
    	position: absolute;
    	z-index: 1;

    Vendor Prefixes

    Updated on 2/13/2014, after [27174]:

    We use grunt-autoprefixer as a pre-commit tool to easily manage necessary browser prefixes, thus making the majority of this section moot. For those interested in following that output without using Grunt, vendor prefixes should go longest (-webkit-) to shortest (unprefixed). All other spacing remains as per the rest of standards.

    .sample-output {
    	-webkit-box-shadow: inset 0 0 1px 1px #eee;
    	-moz-box-shadow: inset 0 0 1px 1px #eee;
    	box-shadow: inset 0 0 1px 1px #eee;


    There are numerous ways to input values for properties. Follow the guidelines below to help us retain a high degree of consistency.

    • Space before the value, after the colon
    • Do not pad parentheses with spaces
    • Always end in a semicolon
    • Use double quotes rather than single quotes, and only when needed, such as when a font name has a space.
    • 0 values should not have units unless necessary, such as with transition-duration.
    • Line height should also be unit-less, unless necessary to be defined as a specific pixel value. This is more than just a style convention, but is worth mentioning here. More information: http://meyerweb.com/eric/thoughts/2006/02/08/unitless-line-heights/
    • Use a leading zero for decimal values, including in rgba().
    • Multiple comma-separated values for one property should be separated by either a space or a newline, including within rgba(). Newlines should be used for lengthier multi-part values such as those for shorthand properties like box-shadow and text-shadow. Each subsequent value after the first should then be on a new line, indented to the same level as the selector and then spaced over to left-align with the previous value.


    .class { /* Correct usage of quotes */
    	background-image: url(images/bg.png);
    	font-family: "Helvetica Neue", sans-serif;
    .class { /* Correct usage of zero values */
    	font-family: Georgia, serif;
    	text-shadow: 0 -1px 0 rgba(0, 0, 0, 0.5),
    					   0 1px 0 #fff;


    .class { /* Avoid missing space and semicolon */
    .class { /* Avoid adding a unit on a zero value */
    	margin: 0px 0px 20px 0px;

    Media Queries

    Media queries allow us to gracefully degrade the DOM for different screen sizes. If you are adding any, be sure to test above and below the break-point you are targeting.

    • It is generally advisable to keep media queries grouped by media at the bottom of the stylesheet.
      • An exception is made for the wp-admin.css file in core, as it is very large and each section essentially represents a stylesheet of its own. Media queries are therefore added at the bottom of sections as applicable.
    • Rule sets for media queries should be indented one level in.


    <a href='http://profiles.wordpress.org/media' class='mention'>@media</a> all and (max-width: 699px) and (min-width: 520px) {
    		/* Your selectors */


    • Comment, and comment liberally. If there are concerns about file size, utilize minified files and the SCRIPT_DEBUG constant. Long comments should manually break the line length at 80 characters.
    • A table of contents should be utilized for longer stylesheets, especially those that are highly sectioned. Using an index number (1.0, 1.1, 2.0, etc.) aids in searching and jumping to a location.
    • Comments should be formatted much as PHPDoc is. The CSSDoc standard is not necessarily widely accepted or used but some aspects of it may be adopted over time. Section/subsection headers should have newlines before and after. Inline comments should not have empty newlines separating the comment from the item to which it relates.

    For sections and subsections:

    * #.# Section title
    * Description of section, whether or not it has media queries, etc.
    .selector {
    	float: left;

    For inline:

    /* This is a comment about this selector */
    .another-selector {
    	position: absolute;
    	top: 0 !important; /* I should explain why this is so !important */

    Best Practices

    Stylesheets tend to get long in length. Focus slowly gets lost whilst intended goals start repeating and overlapping. Writing smart code from the outset helps us retain the overview whilst remaining flexible throughout change.

    • If you are attempting to fix an issue, attempt to remove code before adding more.
    • Magic Numbers are unlucky. These are numbers that are used as quick fixes on a one-off basis. Example: .box { margin-top: 37px }.
    • DOM will change over time, target the element you want to use as opposed to “finding it” through its parents. Example: Use .highlight on the element as opposed to .highlight a (where the selector is on the parent)
    • Know when to use the height property. It should be used when you are including outside elements (such as images). Otherwise use line-height for more flexibility.
    • Do not restate default property & value combinations (for instance display: block; on block-level elements).

    Related Links

    • Dwenaus 8:02 pm on July 30, 2012 Permalink | Log in to Reply

      wow, there is some really trippy CSS going on here:

      #selector-3 {

      background: #fff;

      color: #000;


      then I realized it’s just auto-trac ticket replacement!

      • Andrew Nacin 10:04 pm on July 30, 2012 Permalink | Log in to Reply

        I went ahead and updated that plugin to only touch ticket numbers that were 4 or 5 characters long. Should avoid messing with 3- and 6-character color hex codes!

    • Lance Willett 8:42 pm on August 2, 2012 Permalink | Log in to Reply

      This is super cool.

      Once it’s finalized could you merge it with the pre-existing CSS Coding Standards on the Codex? I added that over 2 years ago and we’ve been using it for default themes since.

      Biggest differences are ordering of properties, comment format (standard on Codex is more strict), and the one line between rule blocks (no line in the Codex standard when in a grouping of similar rules).

    • Noel Tock 1:13 am on August 6, 2012 Permalink | Log in to Reply


    • Umbrovskis.com 4:32 pm on October 11, 2012 Permalink | Log in to Reply

      is there any reason to “Avoid underscores”? As far as I can find answers in Google, there is no reason, unless we care about very,very old browsers before 2002.

      If there is, please refer to some source!

    • wpcustom 3:04 am on November 8, 2012 Permalink | Log in to Reply

      Hi, Phil here, I’m doing my first review of a wp theme. The css will not validate after the second test. The 6 errors are below, can these be fixed? there are also 71 warnings(due to the 6 errors i suppose), also, does the css have to pass validation for a wp theme? Thanks wpcustom

      294 Unknown pseudo-element or pseudo-class ::-webkit-search-decoration [-webkit-search-decoration]

      297 Unknown pseudo-element or pseudo-class ::-moz-focus-inner [-moz-focus-inner]

      298 Unknown pseudo-element or pseudo-class ::-moz-focus-inner [-moz-focus-inner]

      382 .assistive-text Value Error : clip Invalid separator in shape definition. It must be a comma. : rect(1px 1px 1px 1px)

      674 .page-links a, .more-link Value Error : background-image linear-gradient(rgba(240,240,240,0.8),rgba(210,210,210,0.8)) is not a background-image value : linear-gradient(rgba(240,240,240,0.8),rgba(210,210,210,0.8))

      1176 .widget ul li Value Error : background-image linear-gradient(rgba(240,240,240,0.8),rgba(210,210,210,0.8)) is not a background-image value : linear-gradient(rgba(240,240,240,0.8),rgba(210,210,210,0.8))

    • suastex 12:46 pm on February 22, 2013 Permalink | Log in to Reply

      Hi! would it be worth it to incorporate something about shorthand?


    • Ian Dunn 6:04 pm on March 9, 2013 Permalink | Log in to Reply

      The Selectors section says,

      “As in the WordPress Coding Standards [...] separate words with hyphens when naming selectors. Avoid [...] underscores.”

      But I think that conflicts with the WordPress Coding Standards article on the Codex. In the Naming Conventions section, it says, “Separate words via underscores”, and only mentions hyphens in the context of filenames.

      Is the general coding standards article only referring to PHP, and not HTML? It seems odd to me to use underscores in PHP, but hyphens in HTML/CSS, especially since there’s so much PHP and HTML intertwined in Core. You’d end up with lines of code that looked http://pastebin.com/iZ4tu9e6, where hyphens and underscores are mixed for the same piece of data.

      Since hyphens can’t be used in PHP variable names, would be better to standardize around always using underscores for PHP, HTML and CSS? Maybe it’s too late for that, though.

      • Helen Hou-Sandi 6:27 pm on March 9, 2013 Permalink | Log in to Reply

        CSS uses hyphens itself: font-size, border-width, etc. And yes, the other coding standards are referring to PHP.

        • Ian Dunn 7:44 pm on March 9, 2013 Permalink | Log in to Reply

          Ok, thanks for updating the wording in the Selectors section; it’s clearer now.

          Is there a WP naming convention for hyphens vs underscores in HTML? I couldn’t find any. I’m wondering what’s appropriate for the example I linked to above. I’m guessing hyphens in the id attribute (because it’ll be used as a CSS selector), but underscores in the name attribute (because it’ll be processed by PHP when the form is submitted) ?

    • Kowen 10:09 pm on July 26, 2013 Permalink | Log in to Reply

      It would be nice if we can download a generated handbook pdf to all of the items or each one. Thanks for the good content

    • Looimaster 8:45 am on November 19, 2013 Permalink | Log in to Reply

      You say “Above all else, choose something that is meaningful to you and semantic in some way. Random ordering is chaos, not poetry. In WordPress Core, our choice is logical or grouped ordering, wherein properties are grouped by meaning and ordered specifically within those groups. The properties within groups are also strategically ordered to create transitions between sections, such as background directly before color. The baseline for ordering is [...]” but in WordPress core, not even a single CSS file in /wp-admin/ or /wp-includes/ follows any standard…… it’s chaos.

    • wsaiful 2:38 pm on December 13, 2013 Permalink | Log in to Reply

      how i can check the code are standered or not?

    • cramdesign 3:01 am on March 13, 2014 Permalink | Log in to Reply


      “Use double quotes rather than single quotes” but then goes on to use single quotes in the example.

    • Rameez_Iqbal 2:24 pm on May 6, 2014 Permalink | Log in to Reply

      Hi, What is meant by “Add two blank lines between sections and one blank line between blocks in a section.”

    • weeix 4:48 pm on May 16, 2014 Permalink | Log in to Reply

      “Avoid camelcase and underscores”

      But some classes that WordPress generated use underscores, e.g. wp_nav_menu() generates a list that uses page_item, current_page_item, page_item_has_children class names.

      Could we count these classes as exceptions?

    • ExpertNovice 10:49 pm on June 3, 2014 Permalink | Log in to Reply

      Do WordPress ” CSS Shorthand Standards” always override “CSS Coding Standards”? Examples
      ** “Properties should be followed by a colon and a space.” vs shorthand standards which eliminates the space
      **Placing block items and braces on separate lines vs shorthand standards which uses a single line.
      (Probably obvious to everyone else but I am a newb and standards are for newbs!)

    • Mickey Kay 6:06 pm on July 27, 2014 Permalink | Log in to Reply

      A slight discrepancy that may warrant correction in the section on CSS inline commenting: http://make.wordpress.org/core/handbook/coding-standards/css/#commenting

      The text reads:
      “Inline comments should not have empty newlines separating the comment from the item to which it relates.”

      However the following code example is formatting WITH a newline break between the comment and the subsequent code block:

      /* This is a comment about this selector */

      .another-selector {
      position: absolute;
      top: 0 !important; /* I should explain why this is so !important */

      Is this deliberate or not?

  • Andrew Nacin 3:18 pm on April 30, 2012 Permalink
    Tags: ,   

    The plugin directory’s licensing guidelines have been updated. The guidelines will now allow code that is licensed under (or compatible with) version 3 of the GPL.

    The guidelines still encourage use of “GPLv2 or later,” the same license as WordPress. However, we understand that many open source libraries use other licenses that are nonetheless compatible, such as GPLv2 only, GPLv3, and Apache 2.0.

    Now may be a good time for plugin authors to review their plugins to ensure a license is specified. You can add License and License URI headers to readme.txt and the plugin’s headers. (You may also wish to include a copying permission statement.) For example:

    License: GPLv2 or later
    License URI: http://www.gnu.org/licenses/gpl-2.0.html

    You can see this used in the sample readme.txt.

    This change brings the guidelines in line with the themes directory, which has for some time accepted GPLv3-compatible code. (Probably a good time to note that Creative Commons licenses are still incompatible with the GPL, and the theme and plugin directories.)

    • Mike Schinkel 6:31 pm on April 30, 2012 Permalink | Log in to Reply


    • Alid 7:53 pm on April 30, 2012 Permalink | Log in to Reply

      It would be nice to have a list with (in)compatible licenses for users which aren’t familiar with this topic.
      Since it’s also a problem if your plugin is GPL but your are using an external lib which is incompatible and you didn’t know that.

    • John James Jacoby 8:01 pm on April 30, 2012 Permalink | Log in to Reply

      Do you recommend still packaging a license.txt with plugins, or is the link in readme.txt sufficient?

      • Andrew Nacin 12:38 am on May 1, 2012 Permalink | Log in to Reply

        It’s good practice to include a license.txt or COPYING file. At the very least, you should probably include the copying permission statement, which would state, “You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.” At worst, as long as it is specified somewhere in the readme or code, at least people know what your intent is.

        And, if it is in the readme, we will be able to show it on your plugin’s page in the future.

    • Herb Miller 9:56 pm on April 30, 2012 Permalink | Log in to Reply

      I used the readme validator twice today. it worked earlier this afternoon then failed this evening. I was expecting some explanation would surface eventually. Currently the validator has trouble with the License: lines – sometimes suggesting that the description is too long as well

      • Mika Epstein (Ipstenu) 12:28 am on May 1, 2012 Permalink | Log in to Reply

        I’ve seen the same issue with the readme. Adding in the license lines gets it pushed into the Desc.

        I tend to use the copying permission, with “This file is part of PLUGINNAME, a plugin for WordPress.” and then saying the license should have come with WP. But then again I release GPL2.

        • Andrew Nacin 12:39 am on May 1, 2012 Permalink | Log in to Reply

          I pushed some changes earlier to fix some issues with the validator for the License lines. Can you still reproduce?

        • Mert Yazicioglu 9:49 am on May 1, 2012 Permalink | Log in to Reply

        • David Decker 11:12 am on May 1, 2012 Permalink | Log in to Reply

          It seems to add now the License URL to the short description word counter… :) Some plugins with a real short description work correctly, some with a longer like the mentioned “WordPress Move” work not.

          I’d like to see this fixed, as the update with the 2 new license short tags in the header is really helpful – especially when this is displayed on the plugin page on .org! ;-)

          Another suggestion for the short description: What about taking another short tag like:
          Short Description: Here goes it…
          Intro: Here goes it…

          Seems to be a bit more self-explaining as a lot of plugin authors still mix it all up and use the same – long – description everywhere making it less readable for users.

          Just my 2 cents.

          Thanks for all your hard work with repo – much appreciated! You guys really ROCK!!
          -Dave :)

      • Andrew Nacin 5:03 pm on May 1, 2012 Permalink | Log in to Reply

        This was fixed yesterday, but a few plugins had pages generated before then. I went through and re-generated the data for the 12 plugins affected. Should be all set.

    • vsgloik 7:18 am on May 1, 2012 Permalink | Log in to Reply

      The readme standard rocks again.

    • Herb Miller 8:16 am on May 1, 2012 Permalink | Log in to Reply

      thanks, now I have more work ensuring all my source files have both Copyright AND (currently missing from some) a statement of copying permission, saying that the program is distributed under the terms of the GNU General Public License.

  • Andrew Nacin 2:43 am on December 14, 2011 Permalink

    Reporting Bugs 

    Reporting Security Issues

    While we try to be proactive in preventing security problems, we do not assume they’ll never come up. If you believe you’ve found a security problem in a release of WordPress, please see the Security FAQ for information on how to report the problem.

    It is standard practice to notify the vendor (the WordPress security team, in this case) of a security problem before publicizing, so a fix can be prepared, and public damage due to the vulnerability minimized.

    Overview of Bug Reporting and Resolution

    There are many steps in the process of reporting and resolving a bug in WordPress. Here is an overview:

    • A user finds a bug that appears to be in the core of WordPress (not a theme or a plugin).
    • The user confirms it is actually a bug which has not yet been reported.
    • The user submits a bug report, called a ticket, to Trac, the WordPress Bug Tracker.
    • A WordPress developer (who is a volunteer, like you) confirms that the bug does actually exist, and that it should be fixed, and comments as such.
    • A WordPress developer (which could be you) decides to fix the bug. The developer figures out how to fix the bug, create a patch, and uploads the patch to Trac.
    • Members of the WordPress development community test the patch to see if it fixes the bug, and doesn’t break anything else. They may also run Automated Tests against the bug and patch, and write new tests (or suggest new tests be written).
    • One of the WordPress developers with authority to modify the official WordPress source code commits the patch to the core code in the SVN repository. They are more likely to do this if the bug and patch has been verified by someone they trust – WordPress development operates largely on a system of trust and merit.
    • The person who commits the patch closes the bug as fixed.

    Before You Report a Bug

    With large projects like WordPress, so many users report bugs that there’s a good chance your bug has already been reported. Because of this, it’s very important to check to ensure it’s not already in the system before you submit it. If you are new to reporting bugs in WordPress, it is also a good idea to discuss the issue with more experienced developers before reporting it.

    1. Make sure the bug is actually caused by WordPress core.

    Just because an error message points to a core file, doesn’t mean that’s where the problem is. You may want to use a plugin like Debug Bar to track down the problem. A simple script like this debugging file could help you see where exactly the error is coming from. (You can place this file in your wp-content/mu-plugins directory; create it if it doesn’t exist.)

    Another key strategy is to try and replicate the bug in a fresh WordPress install with no extra plugins or themes. While this may not always be possible, if you can find it in a fresh install, the issue is much more likely to be in core.

    2. Search for your bug or enhancement request.

    • If your issue has already been reported, please do not report a duplicate bug. If you have further information to contribute, add a note to the existing bug.
    • If your issue is similar, but not quite the same as another issue, you may decide whether to add a note to the similar issue, or report a new one. In general, if you just have more information to contribute to a current, open issue, simply add a note to that issue. If you have a different enough issue, or if you are experiencing a recurrence of an issue that was previously resolved, report a new bug. Either way, core contributors will offer you guidance once you’ve posted about your issue.
    • If your issue was recently reported and then closed, and you do not agree with the resolution, you can still post comments as to your reasoning.
    • It is best not to re-open bugs that have been closed for some time. If the bug was closed as fixed for a version of WordPress that has been released already (see the Milestone field), open a new ticket.
    • The Version field relates to the version in which the bug was originally discovered. If you’re seeing the same bug in a newer version, mention so in a comment, but please do not change the version number.

    3. Consider discussing a possible bug before reporting it.

    Reporting a Bug

    Trac is the name of the official WordPress bug tracker. It uses the open source bug tracking software Trac, by Edgewall Software. To learn more about Trac, see The Bug Tracker (Trac). To create a good bug report:

    1. Read the section above about what to do before reporting a bug.
    2. Log onto WordPress Trac using your support forum username and password. If you don’t have an account at the support forums, you can register.
    3. Click New Ticket in Trac to reach the bug reporting page.
    4. Fill in the title, summary, and other fields. For more, see the section on Ticket Properties.
    5. Click Submit Ticket after previewing it.

    Your involvement doesn’t end after you’ve submitted a ticket. Developers may need more information as they review the ticket (and may specifically request more information from you by tagging the ticket with reporter-feedback).

    You can also help by verifying that proposed fixes solve the problem you were experiencing. The processing of your bug may require your participation, so please be willing and prepared to aid the developers in resolving the issue. If you’d like to help fix the bug, see the section on Fixing Bugs.

    You will be automatically emailed when your tickets are updated if you’ve entered your email address in your Trac preferences.

  • Andrew Nacin 6:51 pm on December 13, 2011 Permalink

    The Bug Tracker (Trac) 

    Trac is an open source project that serves as a bug tracker and project management tool for WordPress. Using Trac, developers can browse source code history as well as manage bug reports and feature development.

    Tickets are used for both bug reports and feature development, and may be created by anyone with a WordPress.org account.

    Ticket Properties

    Tickets are assigned numerous properties that provide a snapshot of the status of the ticket.

    Title and Description: Provide a strong title and clear description. For the title, it is generally best to describe the problem, not a solution. Concentrating on the problem, rather than the solution, is a good mantra in general. For the description, it is generally best to include steps to reproduce, and actual versus expected results (for bugs), and proper rationale (for enhancements).

    Type: A ticket falls under one of four types: defect (bug), enhancement, feature request, and task (blessed).

    • Defect (bug): A 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.
    • Enhancements: These are simple improvements to WordPress, such as the addition of a hook or an improvement to an existing feature.
    • Feature requests: These are proposals for new features. Feature proposals should generally begin the process in the ideas forum, on a mailing list, as a plugin, or brought to the attention of the core team, such as through scope meetings held for each major release. Unsolicited tickets of this variety are typically, therefore, discouraged.
    • Tasks (blessed): Feature development for the upcoming major release centers around task tickets, which are major features or important enhancements that have been blessed by the core team. A ticket should otherwise never receive this designation.

    Milestone: The milestone is the WordPress release where that ticket is expected to be resolved, such as 3.7. By default, all tickets are assigned, upon creation, to the Awaiting Review milestone to prevent scope creep. Only committers or trusted core contributors have the ability to change milestones.

    Keywords: After the milestone, the keywords field is the most important field. These are not like tags on a WordPress post, but rather a defined list of keywords that describe the ticket’s current status in our development workflow. We use these keywords to build important reports. As an example, tickets tagged with ui-feedback or ux-feedback are pulled into a report on which the UI team heavily relies. See Trac Workflow Keywords for a complete list of the keywords.

    Component: The component is the area of WordPress that the ticket affects. The UI team, for example, will often be working on tickets in the Graphic Design, UI, or Accessibility categories. Try to choose specific components (when applicable) over more generalized ones, such as General or Administration. Components are used in reports to provide a logical grouping of tickets by subject area.

    Tickets for core plugins, such as the importers, are managed under the Plugins or Import components, and current and former default themes are managed under the Bundled Theme component.

    Issues with the WordPress.org site were formerly managed on the same Trac as WordPress core. As of June 2013, meta.trac.wordpress.org is now the proper, canonical place for bug reports to be filed that are related to the WordPress.org site. See the full components list to determine if your issue should be reported there.

    Resolution: Upon one or more commits to the codebase, a ticket may be closed as fixed. Not all tickets result in a commit, however, and may be closed for other reasons:

    • duplicate: The ticket is a duplicate of an existing ticket, which will be referenced by the contributor closing the ticket.
    • invalid: The ticket is not a bug, or is a support request.
    • worksforme: The bug reported in the ticket cannot be reproduced. Sometimes, an existing plugin, hook, or feature may render the ticket moot, so the ticket can be closed without further action.
    • wontfix: The ticket will not be addressed. Occasionally, bugs are considered to be acceptable edge cases, and will not be addressed further. This is sometimes used when a request for an enhancement or feature has been rejected for core inclusion.
    • maybelater: Similar to wontfix, maybelater is used for a ticket that, while perhaps not outright rejected, has no current traction.

    There is certainly some overlap among these five resolutions. It is not an exact science.

    Severity and Priority: The severity is the seriousness of the ticket in the eyes of the reporter. The priority is the seriousness of the ticket in the eyes of the project. Generally, severity is a judgment of how bad a bug is, while priority is its relationship to other bugs. Only committers and trusted core contributors have the ability to modify the priority.

    Version: The version of WordPress being used. Ideally, this would be the earliest affected or applicable version. It should not be updated to a later version once set, as we utilize this to track the age of tickets and bugs, regressions, and the like.


    Individuals have three roles on Trac tickets:

    Reporter: The person who opened the ticket.

    Owner: This field is typically left blank, even if you have contributed a patch. The owner component is used by committers and trusted core contributors to accept and assign tickets among themselves. Committers utilize the field to offer traction for a ticket, to identify they are investigating, committing, or otherwise following a ticket, or to tentatively accept the bug or enhancement for core inclusion. It is also common during the feature development phase for developers to accept tasks in the area of responsibility for which they have volunteered, as well as related bug reports. Trusted contributors may assign tickets to others based on an inside knowledge of who should be responsible for reviewing it.

    CC: As long as your email address is configured in Trac preferences, you’ll receive email updates for any tickets you’ve created or ones you’ve commented on. The field is generally a visual confirmation you are adding yourself to the ticket and wish to receive updates. From time to time, it may make sense to add other individuals to the CC field, such as when a committer requests this. It should be noted that most committers and core developers read every ticket and comment anyway.

    Triaging and Punting

    New tickets are automatically assigned to the Awaiting Review milestone. Upon initial review, it may be recommended for closure, or require more feedback from the reporter or a core developer. Keywords often used here are 2nd-opinion, close, reporter-feedback, and dev-feedback.

    It may also be moved to a milestone by a committer or trusted core contributor:

    • The next point release milestone (for example, 3.6.2 if the current release is 3.6.1) is for critical bugs and regressions. Our point releases are only for security fixes, critical bugs, and regressions in behavior from the previous version of WordPress. We do not fix regular bugs or enhancements in these releases.
    • The next major release milestone (for example, 3.7 if the current release is 3.6.1) is for tasks and features slated for the release, bugs affecting those features, and regressions in the current alpha or beta version over the latest release. Existing bugs may also be addressed, but this generally won’t be considered until a solution exists, unless the bug is sufficiently major to warrant priority. Enhancements may also be included at the discretion of committers, but only during alpha development (prior to the beta release). Larger enhancements are generally not considered for the next major release as they are out of scope.
    • The Future Release milestone is reserved for other tickets. It’s been determined as a potentially good enhancement or confirmed as a bug, but it is not slated for the next release of WordPress.

    Giving Feedback

    When reviewing a ticket, here’s your primary goal: participate in a constructive dialog with the reporter to get the ticket to some form of resolution. The resolution doesn’t need to be immediate, although it’s fun when it is — slow and steady progress is the name of the game. If you’re new to this, here’s some tips on how you might approach and handle a ticket.

    When giving feedback for a ticket:

    • Thank the individual for the report. Some of these tickets are quite old; for those, a simple “Thanks for the report nacin. Sorry you never got a response.” is fine.
    • If this was one of the reporter’s first tickets, it will tell you above the comment box. Be nice. :-)
    • If it’s a support request, you can refer them to the WordPress.org support forums and close the ticket as “invalid”.
    • If it’s a bug report that sounds like an enhancement, then change the ticket to an enhancement. Enhancements are a bit more difficult to triage (as the feedback is more subjective), so it’s much easier to start with bugs.
    • Consider a quick search to see if it is a duplicate of another ticket that may be farther along.
    • If there’s a component that is more appropriate for the ticket, feel free to move it.

    If it’s a bug report:

    • See if you can still reproduce it in trunk. (And/or try the latest stable release) Some bug reports may have been invalid to begin with; others might have been fixed already.
    • If when reproducing it, you feel you can elaborate on the issue, or write clearer steps to reproduce, please do so.
    • If you can’t reproduce it, ask the reporter for more information and add the “reporter-feedback” keyword. If you think the ticket should be closed, you can mark it with the “close” keyword. (There doesn’t need to be a rush to close the ticket.)
    • Reproducible bugs need patches (and unit tests, if applicable)!

    If it has a patch:

    • Test it out — does it fix the problem? How did you test it? Did you notice any side effects?
    • If the patch doesn’t apply cleanly (as in, it fails when you try), add the “needs-refresh” keyword.
    • If you’re a developer, consider doing even just a cursory code review. Make sure it follows WordPress coding standards.
    • If the “has-patch” workflow keyword is missing, add it. Or, if after review you don’t find the patch to be sufficient, you can set it to “needs-patch” instead.
    • If the patch touches on any WordPress internals, it probably needs unit tests.
    • If you feel the patch is ready to be reviewed by a core developer to be considered for inclusion in WordPress, simply say so in a comment. Up until beta 1, you can file it against the current milestone. After beta 1, file it against “Future Release” with an “early” tag.

    It might take only a few minutes to triage some of the more straightforward tickets, especially once you get the hang of it. You could easily spend twenty or thirty minutes on others, or even longer if there’s a lot to test or if you have a lot of feedback to give.

    If you come across a ticket you like and want to write a patch for it, that’s great! Feel free to leave feedback on the ticket and start working on a patch.

    Triaging can be a great way to find tickets that interest you. You might find yourself timid to start — if so, find a buddy in #wordpress-dev and work collaboratively until you get comfortable.

    Punting Tickets

    Tickets are punted when they are moved out of a minor or major release milestone to a future milestone. This generally happens at different intervals in the cycle to lower priority tickets. Some tickets are individually deemed as too complex or out of scope, and are therefore moved.

    • Eddie Moya 12:30 am on June 20, 2012 Permalink

      This is great. I’m very familiar with issue tracking/pm systems like trac, and even thought I dig through trac all the time to see if issues I’m dealing with are known, I’ve only opened a couple of tickets of my own – but each time I have I’ve felt completely lost as to how to fill them out, or if I even should be touching some of them.

      This, or something like this should be linked to directly from the form for opening tickets. Maybe its in there somewhere and I just missed it. Either way…

      Thanks for this, it really clears things up.

    • McGuive7 8:03 pm on July 28, 2013 Permalink

      Hi there,

      Firstly, awesome handbook! Great resource, thanks!

      Secondly, found a typo in the text on this page: “and are” (in the below text) looks like it’s missing the third term in the comma separated list of enhancements:

      Defect (bug): A 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.

  • Andrew Nacin 6:50 pm on December 13, 2011 Permalink

    WordPress Coding Standards 

    The purpose of the WordPress Coding Standards is to create a baseline for collaboration and review within various aspects of the WordPress open source project and community, from core code to themes to plugins.

    The WordPress community developed the standards contained in this section of the handbook, and those standards are part of the best practices that developers and core contributors are recommended to follow.

    Why have coding standards?

    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.

    If you are planning to contribute to WordPress core, you need to familiarize yourself with these standards, as any code you submit will need to comply with them.

    • Brad Dalton 11:37 am on February 15, 2013 Permalink

      This is a great resource to learn how to code using best practices.

    • andrewsi 6:43 pm on March 20, 2013 Permalink

      Under ‘Self-closing elements’, there’s a tag wrapped around a tag - the tag is showing up, but the is being interpreted as a linebreak. Does it need to be wrapped in tags, instead?

      • andrewsi 6:45 pm on March 20, 2013 Permalink

        And it’s nicely interpreted my tags as HTML. That should be:

        Under ‘Self-closing elements’, there’s a <code> tag wrapped around a <br /> tag – the <code> tag is showing up, but the <br /> is being interpreted as a linebreak. Does it need to be wrapped in <pre> tags, instead?

    • makethea 2:38 pm on April 22, 2013 Permalink

      I would like to become a Core Contributor. If anyone is not, yet, moving content over from Codex, I am available to help.

  • Andrew Nacin 6:44 pm on December 13, 2011 Permalink


    WordPress Trac: This is our bug tracker and project management tool, where the code happens. We track bugs, enhancements, and tasks here. SVN actions are deeply integrated into Trac, including creating patches, and commits by core developers. Trac is for discussing code. Philosophical issues and questions over implementation of a potential future feature do not belong on Trac. Trac is located at https://core.trac.wordpress.org/.

    WordPress SVN and Git: The Subversion code repository is where the code “lives”, and is located at http://develop.svn.wordpress.org/. There is also a Git mirror available at git://develop.git.wordpress.org/. This is the core development repository. After a build process, commits to “develop” are synced to the traditional “core” repository, located at http://develop.svn.wordpress.org/ (git://core.git.wordpress.org).

    IRC: The #wordpress-dev channel on irc.freenode.net is our place for real-time discussion. It primarily serves as the venue for our weekly developer meeting. The channel is public, but the majority of chatter, especially during our weekly project meeting, comes from core contributors. Often, a conversation for a Trac ticket will be pulled into IRC, with the consensus later posted to the ticket. Bugs and questions of implementation will often be hashed out in IRC before ending up on Trac. Many contributors idle here. The channel is logged; you can read the logs at http://irclogs.wordpress.org/. You can connect to our channel through a local client or webchat.freenode.net.

    WordPress Blog: The WordPress Blog is a source of official announcements and news for the users of WordPress. The core team uses this blog to announce releases and initiatives. The blog feed appears in the dashboard of WordPress installs. The WordPress blog is located at http://wordpress.org/news/.

    Development Blog (make/core): Sometimes referred to as “wpdevel” for its original location of http://wpdevel.wordpress.com/, the make/core blog leverages P2 for conversation and announcements that are not code (this is Trac), real time (this is IRC), or appeal to the user base (main blog). Located on the make.wordpress.org network as http://make.wordpress.org/core/, along with several other blogs:

    • make/accessibility: The blog for all things accessibility.
    • make/community: The blog for the team dedicated to growing and strengthening our contributor community.
    • make/docs: The blog for the documentation team.
    • make/meta: The blog for the developers of the WordPress.org website.
    • make/mobile: The blog for all things mobile (iOS/Android).
    • make/plugins: The blog for plugin developers.
    • make/polyglots: The blog for translators.
    • make/support: The blog for the support team (forums, IRC, etc).
    • make/systems: The blog for those working on the WordPress.org site and infrastructure.
    • make/themes: The blog for the theme review team.
    • make/training: The blog for the WordPress Training contributor sub-group, part Make/Community.
    • make/ui: The blog for the UI team. Much of the UI work is done under the umbrella of core, but make/ui is used for discussion of user testing and design issues.

    Mailing Lists: WordPress leverages numerous mailing lists like most open source projects, but as a secondary tool. Patches are posted to Trac, rather than to any mailing list, and discussions on the mailing lists are often better suited in another venue. For example, wp-hackers was used for core development discussions years ago, but now these discussions will occur in IRC, on Trac, and on make/core. The list currently has a rather poor signal/noise ratio, but is still a source of good information and discussion when other venues might not be ideal. Additional mailing list information is available on the WordPress.org Codex.

    There are some important mailing lists for those who wish to follow core development:

    • wp-svn: An announcement list of every commit to the WordPress codebase, which includes both the commit message and the actual patch of changes. Volume: There were more than 4,500 changes to WordPress in 2010, an average of about 10-15 per day. This fluctuates wildly depending on the phase of the development cycle, from 50 or more in a busy day to only a handful during a slow week.
    • wp-trac: An announcement list of every comment to Trac. Truly the WordPress firehose, there were more than 20,000 comments posted to Trac in 2010.
    • wp-testers: A mailing list for developers testing the current alpha, beta, or release candidate of WordPress. This list is typically dormant until the first beta release. Closely watched by core developers, this is a great way for developers to post questions or potential issues that can then be addressed by those familiar with the codebase and the changes that went into each release. The list has seen a decline in traffic over the years, with more individuals opting for the Alpha/Beta support forum or Trac.
    • wp-unit-tests: An announcement list of commits to the WordPress tests repository, and comments to the tests Trac. If you are subscribed to both wp-svn and wp-trac, you’ll already get these, but if you’re interested specifically in unit testing, you’ll want to follow along here.
  • Andrew Nacin 6:40 pm on December 13, 2011 Permalink

    Project Organization 

    About the Project

    The WordPress project is a meritocracy, run by a core leadership team, and led by co-founder and lead developer Matt Mullenweg. The team governs all aspects of the project, including core development, WordPress.org, and community initiatives.


    Trusted contributors and core developers earn their stripes on more than just ability and actions. Leadership roles need to be earned on the basis of professionalism, personality, attitude, and respect among peers.

    The best contributors naturally respect and subscribe to the project’s core philosophies. A lack of a personal agenda is paramount: we’re all a part of the same community, and we all share common goals. This doesn’t mean you can’t have an opinion, far from it. The best contributors can balance their opinion with the goals of the project and the perspectives of both users and developers. Offering consistently good suggestions, demonstrating a strong ability to collaborate with others, and being able to accept (and provide) feedback are all important.

    You can identify these standards in some of our best core contributors, and that’s why they have strong influence over the project. Final decisions are made by the core team, which in turn has evolved over the life of the project based on merit.

    Community Leadership

    The WordPress community is led via two main roads: the Internal Leads and the Community Volunteers. In many areas, such as UI and Support, the Community Leads are the driving force.

    The WordPress Core Team

    The WordPress project is led by the core leadership team, which consists of WordPress co-founder Matt Mullenweg, five lead developers, and six core developers with permanent commit access.

    The lead developers are Ryan Boren, Mark Jaquith, Andrew Nacin, Andrew Ozz, and Peter Westwood. These developers have final authority on technical decisions, and lead architecture discussions and implementation efforts.

    Sergey Biryukov, Jon Cave, Helen Hou-Sandi, Dion Hulse, Daryl Koopersmith, and Dominik Schilling are permanent core committers.

    Contributing Developers

    WordPress has a number of contributing developers. Some of these are former or current committers, and some are likely future committers. Regardless, these are trusted and veteran contributors to WordPress core who have earned a great deal of respect among their peers.

    As needed, WordPress also has guest committers, individuals who are granted commit access, sometimes for a specific component, on a temporary or trial basis. John Blackbourn, Drew Jaynes, and Scott Taylor are currently guest committers.

    Other contributing developers include Michael Adams, Nikolay Bachiyski, Mike Schroder, Joseph Scott, Andy Skelton, Matt Thomas, Lance Willett, and Samuel Wood.

    Core Contributors

    The core and contributing developers only guide WordPress development. Every version, hundreds of developers contribute code to WordPress. These core contributors are volunteers who contribute to the core codebase in some way. All it takes is a single patch to make a difference.

    UI and Design

    The UI team is made up of core contributors who work on the design and user interface of WordPress.

    Matt Thomas is the style lead for WordPress. Ben Dunkle is the icon designer.


    The support forums are run by a team of volunteer moderators, who remove spam, handle disputes, and generally keep the peace. They are led primarily by a self-appointed team leader, and everyone is encouraged to jump in.


    The Documentation team is responsible for all things documentation, including the Codex, handbooks, developer.wordpress.org, admin help, inline docs, and other general wordsmithing across the WordPress project.

    This handbook, and the Codex, are the primary sources of information for learning how to develop, improve, and troubleshoot WordPress. The handbook is curated by a small group of volunteers, while the Codex is open for anyone with a wordpress.org user account to edit.


    WordPress applications for mobile devices are open source software, just like the project. There are six applications currently for iOS, Android, BlackBerry, Windows, WebOS, and Nokia platforms. WebOS and Nokia mobile application development has stopped, as the platforms are no longer supported.

    The mobile development team consists of Aaron Douglas, Brad Angelcyk, Isaac Keyet, Eric Johnson, Dan Roundhill, Jorge Bernal, Danilo Ercoli, and others. As the projects are open source, anyone can contribute.

    Theme Reviewers

    Themes submitted to the WordPress Themes Directory are reviewed by a team of volunteers to ensure compliance with the WordPress.org theme guidelines. The team rep is Jose Castaneda, with Chip Bennett, Emil Uzelac, Edward Caissie, Simon Prosser, Justin Tadlock, and many other contributors working on developing standards and reviewing themes.

    Plugin Reviewers

    Plugins submitted to the WordPress Plugins Directory are reviewed by a team of volunteers to ensure they meet WordPress.org guidelines before being included in the plugin directory. The team rep is Boone Gorges, with volunteers Pippin Williamson, Scott Reilly, Samuel Wood, Mika Epstein, Kailey Lampert, Daniel Bachhuber, and Mark Riley (Reviewer Emeritus) reviewing plugins and developing standards.

    Community Blogs and Communication

    You can get core development updates from the teams above on the Make WordPress blogs, or follow the development process in a variety of other ways.

  • Andrew Nacin 6:26 pm on December 13, 2011 Permalink

    The Code Repository (SVN) 

    What is SVN?

    WordPress uses Subversion (SVN), a very popular version control system managed by the Apache project, to manage changes to its codebase. A change to the WordPress codebase increments the revision number. Individual changes are called commits or changesets. These are denoted as either r12345 or [12345].

    The WordPress repository of code is organized into three main directories: tags, branches, and trunk.

    • The trunk directory contains the latest development code in preparation for the next major release cycle. The latest revision may be unstable or broken at times. The latest development code may be referred to as trunk.
    • The tags directory contains individual snapshots of each official release, such as the 3.4.0 or 3.5.1 tags. Once created, these are unmodified, and these are used to build the download packages.
    • The branches directory contains directories that consist of the latest code for each major release, such as the 3.4 and 3.5 branches. Minor release development occurs within the branch. For example, a critical bug that affects the latest release may be fixed in both trunk and the most recent branch, in preparation for a point release – i.e. 3.5.2, in the case of the 3.5 branch. These should generally be considered stable, but care should be taken when a minor release is being prepared.

    While it takes a developer with commit access (called a committer) to change the WordPress codebase, anyone can suggest a change in the form of a patch. A patch is 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 (after the Unix command to generate a differences file). Patches have the extension of either .patch or .diff.

    Patches are created using a working copy of WordPress trunk that has been checked out of the repository. Subversion keeps a history of the code, but it also provides centralized repository so that committers do not overwrite each others’ changes. (A conflict occurs when a patch changes code that has since been modified.) For this system to work, each committer keeps a working copy of the same repository. Code is checked out as a local working copy, and then checked in (committed) to the centralized repository.

    Contributors follow the same process, but they generate a patch that shows their changes, since they cannot modify the central repository. This patch can then be applied to the individual working copies of other contributors or committers, so it may be reviewed, tested, and potentially committed.

    When writing a patch, it is important to always update to the latest version of trunk. Patches should never be written against a released version, such as a tag or branch, with very rare exceptions (e.g. during the preparation of point releases). Trunk is, however, a moving target, which can cause patches to become stale and require a refresh – they no longer apply properly, because code in the central repository no longer matches what the patch is attempting to change. Patches that alter a significant number of lines or files should generally be brought to the attention of committers sooner rather than later. [Link: Getting Your Patch Committed]

    Finding an SVN Client

    Many developers run SVN commands using the command line interface (CLI), such as Terminal on the Mac. Even though most basic commands are simple, the command line is reasonably intimidating for many users. Many developers do rely on GUI applications though, either for regular use, or to handle complex actions more effectively.

    For Windows, the recommended SVN client is TortiseSVN, which is free and open source.

    For Mac, the recommended SVN client is Cornerstone, which must be purchased.

    Learn More

    If you would like to learn more about working with Subversion, check out Installing A Version Control System, Installing WordPress Via SVN, and Working With Patches in the Tutorials and Guides section of this handbook.

    • Russell Heimlich 4:16 pm on April 11, 2013 Permalink

      For a free cross-platform SVN GUI I use SmartSVN. They also have SmartGit which is the equivalent for Git.

    • Robert Dall 8:11 pm on July 28, 2013 Permalink

      Please correct me if I am wrong but Versions can not create or apply patches… I tried a trail version of the program and couldn’t find any reference of that which made the program some what useless for the purpose of contributing to WordPress core.

      • Dominik Schilling (ocean90) 8:19 pm on July 28, 2013 Permalink

        That’s right. But Cornerstone can.

        • Kim Parsell 12:24 am on July 29, 2013 Permalink

          Perhaps I should remove Versions from the page, and only recommend Cornerstone as a Mac client? I’ve modified the page to remove Versions.

    • Robert Dall 11:58 pm on July 28, 2013 Permalink

      Pardon my curmudgeon comment, but should we mention a svn client that doesn’t work with our current workflow?

    • adragos 2:09 pm on August 2, 2013 Permalink

      Eclipse (and Eclipse based PHP Editor) has a pretty neat SVN GUI.
      PhpStorm (which is not free but it’s worth paying for) also have a cool SVN/Git GUI

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc