Make WordPress Core

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

  • Andrew Nacin 1:18 pm on July 13, 2012 Permalink | Log in to leave a Comment

    Trac 

    An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.

     

  • Andrew Nacin 1:18 pm on July 13, 2012 Permalink | Log in to leave a Comment

    IRC 

    Internet Relay Chat, a network where users can have conversations online. IRC channels are used widely by open source projects and by WordPress. The primary WordPress channels are #wordpress and #wordpress-dev, on irc.freenode.net.

     

  • 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

      Kudos!

    • 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…
          or:
          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 10:40 pm on February 16, 2012 Permalink
    Tags:   

    Results of 2/15 Dev Meeting 

    The teams and status document has been updated to reflect current cycles. Yesterday’s dev meeting focused on identifying issues pertaining to blockers and resources, and whether any adjustments or corrections needed to be made, across all teams. As I didn’t keep a general summary, you may find the log is here.

    I did take notes on who needs resources from whom:

    • @petemall and @MarkJaquith will be discussing #19796 and #19235 with @ryan and @nacin
    • @westi and @maxcutler will be discussing capabilities in XML-RPC and APP with @ryan, @nacin, @kurtpayne
    • @getsource and @helenyhou need @azaozz and @dkoopersmith to go over the scrolling JS
    • @jane and @helenyhou: screenshots review
    • @jane and @petemall: autocomplete UI review
    • Also @jane: Review HTML in captions UI (if necessary) and header changes

    And there may be a few others I didn’t catch. Ideally this will all happen before our meeting next Wednesday.

    Two teams were added: @georgestephanis and Zach Abernathy (thezman84) working on tablets, and @aaronjorbin working with Tom Auger (tomauger) on favicons. I have been communicating with both teams to help get things off the ground.

    If you want to get involved, there are 198 open tickets on report 5, many of which fall under no team. If they do, find the team during office hours or contribute directly to the ticket, as many have done.

    Next meeting is 2/22 at 2100 UTC.

     

  • Andrew Nacin 2:43 am on December 14, 2011 Permalink | Log in to leave a Comment

    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 it 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 be sure 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 offcial WordPress bug tracker. It uses the open source bug tracking software Trac, by Edgewall Software. For more on Trac, see The Bug Tracker (Trac). To create a good bug report:

    1. Read the section above on 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 | Log in to leave a Comment

    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. Tickets, which may be created by anyone (it requires a WordPress.org account) are assigned numerous properties that provide a snapshot of the status of the ticket.

    Ticket Properties

    • 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). [Link: see submitting a bug report.]
    • Type: A ticket falls under one of four types: defect (bug), enhancement, feature request, and task (blessed).
      • Tasks: 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.
      • 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.
      • 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.
    • Milestone: The milestone is the WordPress release where that ticket is expected to be resolved, such as 3.1. By default, all tickets are created in the Awaiting Review milestone. Only committers and trusted core contributors [todo] link [/todo] have the ability to change milestones, to prevent scope creep [todo] link [/todo] . A special component is WordPress.org. In this milestone, we manage tickets for core plugins such as the importers (under the Plugins or Import components), current and former default themes (Bundled Theme component), and the WordPress.org site (component of the same name).
    • 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. For a list of keywords, see the Workflow Keywords article.
    • 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 and to provide a logical grouping of tickets by subject area. One special component is “WordPress.org site,” which will always have the WordPress.org milestone as well.
    • 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 another ticket, which is to 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, and therefore 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 is 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 [todo] link [/todo] 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 also have numerous roles:

    • Reporter: The individual who opened the ticket.
    • Owner: This field is typically left avoided, 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 to which you’ve commented. The CC 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 regular developers read every ticket and comment anyway.)

    Triaging and Punting

    New tickets are 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, 2.8.2 if the current release is 2.8.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, 2.9 if the current release is 2.8.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.
    • The WordPress.org milestone is a special component for managing tickets for core plugins such as the importers (under the Plugins or Import components), current and former default themes (Themes component), and the WordPress.org site (component of the same name).

    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 | Log in to Reply

      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.

  • Andrew Nacin 6:44 pm on December 13, 2011 Permalink | Log in to leave a Comment

    Communication 

    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: The Subversion code repository is where the code “lives”, and is located at http://core.svn.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/.

    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/events: The blog for all things related to WordCamps, local meetups, and WordPress.tv.
    • make/meta: The blog for announcements and resources by and directed to 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, 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/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 | Log in to leave a Comment

    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.

    Meritocracy

    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, the head of User Experience (UX), and the two 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.

    Jen Mylo is the head of User Experience for WordPress, and acts as a project and community manager.

    Dion Hulse, Daryl Koopersmith, and Jon Cave 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. Helen Hou-Sandi is currently a guest committer.

    Other contributing developers include Michael Adams, Nikolay Bachiyski, Joseph Scott, Dominik Schilling, Sergey Biryukov, Cristi Burca, Andy Skelton, 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

    User experience lead Jen Mylo leads a team 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.

    Support

    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.

    Documentation

    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 and everyone to edit. There is some overlap with the Support team and the Codex.

    Mobile

    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 Isaac Keyet, 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 leads are Chip Bennett and Emil Uzelac, with Edward Caissie, Simon Prosser, 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 lead is Scott Reilly, with volunteers Samuel Wood, Mika Epstein, Kailey Lampert, Daniel Bachhuber, Pippin Williamson, 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 | Log in to leave a Comment

    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 2.8.0 or 2.9.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 2.8 and 2.9 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. 2.9.1, in the case of the 2.9 branch. These should generally be considered stable, but care should be taken when a minor release is being prepared. [todo] point release philosophy [/todo]

    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.

    To create a patch, you will first need to check out a working copy of WordPress trunk. Subversion keeps a history of the code, but it also provides centralized repository that way 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 as they cannot modify the central repository, they generate a patch that shows their changes. 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. [Link: 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 attention]

    Finding an SVN Client

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

    On Windows, the premiere client is TortiseSVN, which is freeware. Lead developer Peter Westwood wrote a tutorial many years ago. [todo] link [/todo]

    On Mac, you may wish to purchase Versions or Cornerstone [todo] (mac freeware?) [/todo]. Lead developer Mark Jaquith wrote a tutorial on command line usage. link

    Advanced Topics

    Using the Command Line

    Checking out SVN trunk

    If you do not yet have a directory set up to do WordPress core development in, you could create it with ‘mkdir’:

    mkdir ~/WordPress-dev

    Go to the directory where you will be hacking the WordPress core: 

    cd ~/WordPress-dev

    ‘Checkout’ the WordPress core trunk with SVN, then enter the ‘trunk’ directory, which contains the WordPress code:

    svn checkout http://core.svn.wordpress.org/trunk

cd trunk

    Happy hacking!

    Creating a Patch

    Once you’ve edited files and made changes, you will want to generate a patch which records the differences between your version of the files and those from trunk. To do so, ensure that you are in the ‘trunk’ directory created by your SVN checkout, then run the following, where ’00000′ is replaced with the ticket number from trac:

    svn diff > 00000.patch

    If you’ve made multiple changes to trunk and you wish only to submit a patch for certain select files or directory trees, these can be passed to ‘svn diff’ as arguments. In the following example, only changes made in the ‘wp-includes’ directory tree and the ‘theme-options.php’ file in the twentytwelve theme will be recorded. This means that if you were tinkering with some of the JavaScript or CSS files in the twentytwelve theme, but those changes are incomplete or not relevant to this trac ticket, they will not be included in the patch:

    svn diff wp-includes wp-content/themes/twentytwelve/inc/theme-options.php > 00000.patch

    Applying a Patch

    So you have your SVN ‘trunk’ and you want to test out a patch that someone submitted in trac. Ensure that you are in the ‘trunk’ directory, then download the patch into that directory, if you have not done so already:

    curl -O https://core.trac.wordpress.org/raw-attachment/ticket/00000/00000.patch

    Note: If you download the patch this way, be sure that it is coming from the ‘raw-attachment’ directory on the trac server. You can grab this URL for copy-paste by clicking on the patch in trac, then grabbing the URL linked to by ‘Original Format’ at the bottom of the page.

    From the ‘trunk’ directory, where you have downloaded the patch file, you can apply the patch against the source tree by issuing the following command:

    patch -p0 < 00000.patch

    Now, the ‘trunk’ source tree on your computer has been patched with the file you downloaded, giving you the version of the source tree that the developer who submitted that patch was working with.

    Bash Help

    Here’s a few useful tips if you are new to BASH and the *nix commandline:

    Location

    pwd – Print Working Directory
    Show the current directory that you are working from.
    cd PATH – Change Directory
    Change the current directory to PATH, which can be an absolute or relative path or directory name.
    ls – List Directory Contents
    List the contents of the current directory. If you wish to list another directory without changing to that directory, use ls PATH.

    File Redirection

    PROGRAM > FILENAME – Redirect Output to File
    Instead of displaying the output of the program, put that output into the FILENAME file. This will create that file if it does not exist, or overwrite it (destroying anything which was in that file previously) if it already exists.
    PROGRAM < FILENAME – Redirect Input from File
    Instead of using your keyboard for the input of the program, use the contents of the FILENAME file as the program’s input.

    More Help with Bash

    man PROGRAM – Open the System Manual for PROGRAM
    To learn more about a program and all of its command line options (arguments), browse through that program’s manual pages with the ‘man’ command.
    Check out one of the many books devoted to learning to interact with the command line
    For instance, this free one:

    Introduction to the Command Line

    Helpers:

    http://nacin.com/2010/05/13/my-wordpress-bash-functions/

    http://blog.ftwr.co.uk/archives/2008/07/19/my-wordpress-toolbox/

     

  • Andrew Nacin 5:53 am on December 7, 2011 Permalink
    Tags: ,   

    Admin Bar API changes in 3.3 

    Howdy! The Admin Bar API has changed quite a bit in WordPress 3.3.

    First up, what may break your plugin. The added items are no longer stored in a publicly accessible (but ideally privately used) menu property. So, if you were doing something like $wp_admin_bar->menu->..., you won’t get anything back.

    The reason for this is that the internal structure has changed. Nodes are no longer internally stored in a tree. Now, they’re stored in a flat list, and the tree is bound together just before render. This makes the internal API much more stable, and allows us to provide plugin developers some nifty new tools. Even core only handles nodes using the same APIs developers use (mostly).

    If you were to open the file you will notice there are a number of new methods and signatures. Here are the ones developers will want to know:

    • Add a node: add_node( $args ) or add_menu( $args ) (these are equivalent)
    • Remove a node: remove_node( $id ) or remove_menu( $id ) (these are equivalent)
    • Fetch a node’s properties: get_node( $id ).
    • Add a group, which wraps nodes (more on that in a bit): add_group( $args ).

    Terminology notes

    Before I continue: I’m using “item,” “node,” and “menu” synomyously throughout this post. They all are referring to a single link in the admin bar. Nodes can be parents for other nodes, which creates dropdown menus. The API previously emphasized add_menu(), but this can be confusing, so add_node() is now being promoted a bit more. Both methods do the same thing.

    Since the optional admin bar has been merged into the admin header, we’re now calling it the toolbar in the UI.

    Groups

    An example of groups in the new toolbar.


    Version 3.3 introduces the concept of groups. Groups share the same namespace (in terms of IDs) as nodes, and a node’s parent can be a group, rather than another node. Groups allow us to group nodes together into distinct sections of a menu. As an example, see the new W menu in the top left of the toolbar (screenshot at right). Here’s how it was constructed:

    • The W logo node is added. It has no parent.
    • The “About WordPress” node is added. To create a submenu, we set the parent to the W logo.
    • We add a group for external links. The group’s parent is also the W logo. It uses an additional CSS class to add the gray styling.
    • We then add the four external links, and set their parent to the external links group.

    You can see these registrations in wp_admin_bar_wp_menu() and wp_admin_bar_add_secondary_groups().

    Groups were added to provide us some styling flexibility and semantic divisions for a few different menus. (The right side of the top menu, “Howdy” and search, are their own group.) But the possibilities for plugins are pretty great. A plugin can bundle all of their nodes into a single group that then maintain visual separation from all other nodes in that menu. You can use the add_group() method to add groups.

    Moving and modifying nodes

    While this isn’t a change from WordPress 3.2, it’s worth pointing out that add_node() is able to take the ID of an existing node as an argument, and then replace the specified arguments. For example, if you want to make the Network Admin level a top-level item, try this:

    add_action( 'admin_bar_menu', 'nacin_promote_network_admin_in_toolbar', 25 );
function nacin_promote_network_admin_in_toolbar( $wp_admin_bar ) {
    $wp_admin_bar->add_node( array(
        'id' => 'network-admin',
        'parent' => false,
    ) );
}

    That was easy!

    To make modifications easier, there’s now a get_node() to fetch a node’s properties, and even get_nodes() to fetch a flat list of all nodes, in case you want to loop through them.

     

    • Jane Wells 6:22 pm on December 9, 2011 Permalink | Log in to Reply

      The toolbar in not an optional admin bar now, it is part of the actual dashboard. If someone wants to remove it with a plugin, it would be on par with redesigning the dashboard, such as with Ozh’s dropdown menus, and the plugin author would need to design alternative ways to provide the information and access points in the toolbar. The toolbar is not a removable component like the old admin bar was, because it is also the dashboard’s header.

← Older posts

Newer posts →

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel