Make WordPress Core

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

  • Andrew Nacin 7:49 pm on January 29, 2014 Permalink

    Bug Reports 

    WordPress uses open source software called Trac to manage bug reports and tasks. If you are looking to report a bug, please ​head on over.

    There are many ways to contribute. We have a detailed contributor handbook to help get you started. If you want to get started quickly, try one of the Getting Started reports blow β€” test a patch, or grab a bug and see if you can reproduce the problem it describes.

    If you have encountered a security issue in WordPress, please contact security at wordpress.org. For more, see our ​Security FAQ.

    Trac Ticket Reports

    Tickets by Topic

    Tickets by Component

    Tickets by Focus

    Other Workflow Reports

    • Mobile — Tickets flagged by the WordPress mobile apps team
    • WordPress.org — Importer plugins, old default themes, etc.
    • Meta Trac for the WordPress.org site itself
  • Jen 6:20 pm on January 29, 2014 Permalink
    Tags: ,   

    GSoC 2014 

    It’s that time of year again, when all good* core developers start thinking about whether or not they’re up for mentoring a GSoC student this year. Many in this group know the drill, but there quite a few involved core contribs active this cycle who haven’t been involved with GSoC before, so here’s the deal:

    • Google pays for a program that gives college students summer jobs creating open source code under the mentorship of an organization (like WordPress).
    • We apply to be a mentoring organization and put up a list with a bunch of potential summer project ideas and identify who the mentors might be.
    • If we’re chosen to participate, we get a certain number of slots to fill, and students submit applications to work with us.
    • All the potential mentors rate/rank the proposals, and decide if there’s someone they’d like to mentor.
    • In game of chance-meets-requests dizzy enough to rival medical school matches, we put together our wish list for mentor-student matchups. 2 mentors per student, to provide coverage and make things more collaborative.
    • We hope that none of our top picks also applied to other orgs who accepted them, and wind up with our student roster.
    • We provide volunteer mentors to work one-on-one with the kids on projects that they applied to do over a 3-month period.
    • Open source code is released into the wild.

    I’ll be putting together our application to be a mentoring organization this week, so it’s time to start thinking of project ideas we could suggest on the Ideas page that we need for the application (the more ideas the better) and who wants to be a mentor. The application deadline is February 14, so I’d like to get the Ideas list in solid shape (along with mentor bios) by Feb 10 (a week from Monday).

    If you have an idea or are interested in being a mentor, please leave a comment on this post. At the end of the dev chat after 3.9 business is out of the way, we can discuss some of the ideas and I can answer any questions people have about mentoring.

    Related: I’m also going to be posting soon about starting up a regular mentorship program, as outlined here. But that can wait for another day.

    *Where good means both skilled and kind and generous with their time.

    • Jen Mylo 6:22 pm on January 29, 2014 Permalink | Log in to Reply

      Also, will need a few people to identify tickets that no one’s working on that would be good ones to use for the “submit a patch” requirement of the application.

    • Ian Dunn 6:59 pm on January 29, 2014 Permalink | Log in to Reply

      Is it only open for Core, or can Meta, Mobile, etc also propose projects?

      • Andrew Nacin 7:10 pm on January 29, 2014 Permalink | Log in to Reply


        • Ian Dunn 7:54 pm on January 29, 2014 Permalink | Log in to Reply

          Awesome. @jenmylo, I’d be happy to mentor someone if you have any Community projects you think would be a good fit for GSoC.

          • Jen Mylo 8:41 pm on January 29, 2014 Permalink | Log in to Reply

            @iandunn: Definitely, just need to make sure that it’s something releasable, like a plugin vs building onto one of the sites. Maybe forms, finally?

            • Ian Dunn 9:04 pm on January 29, 2014 Permalink

              That could work. The idea of having the pre-defined forms for speakers/sessions/etc is specific to WordCamp.org, but we could easily put the general architecture for a pre-defined form into the plugin itself, and then define WordCamp.org’s specific forms via a filter in a custom plugin.

              The result from that approach would be the same as if the our forms were built into the plugin itself, but it would keep the core plugin independent so it could be released in the WordPress.org repo and used by anyone.

              We don’t necessarily have to release it in the wporg repo in order to open-source it, though. Most of WordCamp.org’s custom stuff is already open-sourced in the Meta repo. Not sure if the GSoC guidelines just want it open-source, or if the spirit of it is to make it easily available/useable for others.

    • Wojtek Szkutnik 7:48 pm on January 29, 2014 Permalink | Log in to Reply

      Always happy to help with mentoring if needed πŸ™‚

    • Marko Heijnen 8:48 pm on January 29, 2014 Permalink | Log in to Reply

      I would love to mentor. Hopefully this time I’m more lucky then last year. I can help with core, mobile or GlotPress.

      • Jen Mylo 9:20 pm on January 29, 2014 Permalink | Log in to Reply

        If you can write up some specific project ideas that you would like to mentor, that will help with the luck. Someone who applies for your idea would likely be given to the person who proposed it, vs running into a situation like last year where a handful of people all requested the same student.

    • Justin Shreve 9:28 pm on January 29, 2014 Permalink | Log in to Reply

      I’m interested in mentoring this year (did you even have to ask? :))

      Some things I would be interested in (based on some previous ideas):

      • New User Walkthrough. Specifically meter based “you are 10% setup, etc”. Think LinkedIn style.
      • A visual way to surface visual embeds / oEmebeds etc. Instead of needing to magically know that a Spotify or Twitter URL needs to go on its line, support some kind of UI (maybe in the media explorer) that allows you to insert content
      • Anything External API Related. No specific project here. It depends on what is in core at the time (if it’s XML-RPC still or if REST is available yet)
      • General Mentoring
    • Eric 9:35 pm on January 29, 2014 Permalink | Log in to Reply

      I’m game to mentor a mobile project this year. I’ll post some project ideas after I’ve had some time to brainstorm a bit.

    • Aaron Jorbin 5:04 pm on January 31, 2014 Permalink | Log in to Reply

      I would love to mentor once again. Some ideas that I have:

      • Make the PHPUnit tests run faster
      • Increase the number of JavaScript Unit Tests
      • CSS/JS Optimization
      • Automated performance testing
      • Anything dev tools related.
      • Bryan Petty 5:31 pm on February 4, 2014 Permalink | Log in to Reply

        I think the biggest improvement we could make to the unit tests in regards to speed is to find a way to merge multisite tests into the base tests, and only run tests that are actually affected by single/multisite environment changes.

        Right now, we run every single unit test a second time during the multisite run, but in reality, probably less than 25% of them are even affected by multisite. For example, we don’t need to re-run sanitize/escape tests a second time.

        There’s certainly probably lots of places we could avoid @runTestsInSeparateProcesses, especially if we were to deprecate/remove constants.

        Another option might be to find a way to cleanly reset the DB without calling wp_install() again (do one install, dump, and reload from dump directly on the next test with @runTestsInSeparateProcesses).

        Other than that, then you just have optimizations on individual tests, which just becomes a mundane task that no-one wants to do, especially if patches are just ignored because they are so minor and not important.

        • Andrew Nacin 7:43 pm on February 4, 2014 Permalink | Log in to Reply

          Re-running the entire suite under multisite has flagged a lot of issues over the years. I think we’re along way from that point. Multisite just has too many odd side effects on core.

  • Andrew Nacin 10:19 pm on January 9, 2014 Permalink
    Tags: ,   

    New Trac notifications feature 

    Monday’s long list of improvements to Trac was just the first course. Introducing per-ticket notifications.

    Just above the comment box, you’ll see a new notifications pane. Here, you can watch/unwatch tickets.

    This means Trac’s terrible email address CC feature is gone. (Last night, I migrated over about 15,000 CCs going back nine years.) Old comments that are just CCs are now hidden via JS, which makes a few of the busier or popular tickets easier to skim.

    You can also click the star next to the ticket number at the top:

    Screen Shot 2014-01-09 at 4.38.22 PM

    Watching a ticket adds it to some new reports: open tickets I’m watching and all tickets I’m watching. Now your list of starred tickets are all in one place.

    Coming soon: You’ll be able to watch/unwatch a ticket directly from a report, like starring conversations in a Gmail inbox (edit: added). You’ll also be able to subscribe to entire components and milestones (here’s a sneak peek). And, @-mentions will let you add someone to a ticket.

    A note on how this is implemented: isn’t just subscribe/unsubscribe. “Watch” can also be thought of as “Vote” or “Star” or “Favorite”. We’ll soon add a star count to reports (next to the new Comments column β€” edit: added). If you’re watching a ticket, you’ll always get notifications. If you’re not, you might still get notifications if you reported the ticket, or are subscribed to that ticket’s component or milestone, or if you’ve been mentioned (and the notifications box will tell you that). From there, you have the option to actively “Watch” the ticket, passively continue to receive notifications, or specifically mute/block notifications coming from that ticket.

    Follow-up question from @sabreuse, about watching/voting/starring/favoriting: If you subscribe to the “firehose” (wp-trac mailing list) and receive all notifications anyway, should you star tickets anyway as an indication of interest? Yes, I’d say so! (If you receive the mailing list to the same email address as your WP.org profile, you’ll only receive one email. It’s possible your mail client could ascertain you received it as a BCC versus just via a mailing list, though I’m not sure.)

    Feedback, ideas, suggestions are very much appreciated. Also, all of this code is open source (a lot of it is a WordPress plugin).

    Edit, bonus: @ocean90 converted most icons on Trac into Dashicons.

    • Avryl 10:26 pm on January 9, 2014 Permalink | Log in to Reply

      Awesome! What about notifications that are set on profiles.wordpress.org? πŸ˜€

      • Andrew Nacin 10:32 pm on January 9, 2014 Permalink | Log in to Reply

        For @-mentions and such? Yeah, I’m going to try to pipe mentions through that. That said, what should the emails look like? Should they be Trac content piped through the HTML emails, or should you receive a Trac email? I think it’ll end up being Trac-style emails for @-mentions but the HTML emails for other string matches… Still trying to figure out how I’m going to tackle it.

        • Avryl 10:44 pm on January 9, 2014 Permalink | Log in to Reply

          I’d be really nice if they’re all HTML emails, converting Trac’s markdown. But some people probably prefer plain text.

          • Andrew Nacin 10:49 pm on January 9, 2014 Permalink | Log in to Reply

            I just meant they are two completely different templates – mentions emails and Trac emails. Which one to use?

            • Avryl 9:34 am on January 10, 2014 Permalink

              I don’t know, but I’d use the same one for all kinds of notifications.

            • Mel Choyce 6:59 pm on January 15, 2014 Permalink

              My vote would be for using the current mentions emails for trac, if only because having an email that’s more designed makes it easier to scan and understand.

              (I’d also be game for redesigning the mention emails.)

    • Pippin Williamson 10:29 pm on January 9, 2014 Permalink | Log in to Reply


    • keoshi 10:35 pm on January 9, 2014 Permalink | Log in to Reply

      This is awesome! Great work.

    • Jose Castaneda 10:38 pm on January 9, 2014 Permalink | Log in to Reply


    • Amy Hendrix (sabreuse) 10:41 pm on January 9, 2014 Permalink | Log in to Reply

      Yay! I’m really liking all of these improvements. Trac is feeling both friendlier and more usable already.

      I’ve pretty much stopped using ticket cc’s since I sacrificed my inbox to the firehose — what you say about using star counts as votes suggests that it might be worth starring to indicate interest even though I’m already notified?

    • Kim Parsell 11:14 pm on January 9, 2014 Permalink | Log in to Reply

      Thank you for all of the hard work – Trac is so much better to work with now. πŸ™‚

      I’ve got several tickets from a few years ago with CCs for an old email address that will be going away soon. Do you want to remove those CCs so you don’t get the email bounces from them, if there would be any activity on them?

      • Andrew Nacin 11:28 pm on January 9, 2014 Permalink | Log in to Reply

        I managed to map every email address CC to the corresponding user account (took me about five hours to script it then manually go through about 200 unknowns). I then imported all of them into the new notifications system, which is based on usernames. Then I literally emptied every CC field across all tickets. So those old tickets are now linked to directly to your username and profile email. πŸ™‚

    • Brad Touesnard 12:33 am on January 10, 2014 Permalink | Log in to Reply

      Well done sir!

    • Lance Willett 3:16 am on January 10, 2014 Permalink | Log in to Reply

      This is really coolβ€”makes Trac even more user friendly and useful for both newbies and veterans alike.

    • Rami Yushuvaev 9:29 am on January 10, 2014 Permalink | Log in to Reply

      Looks great!

    • Marcus 11:50 am on January 10, 2014 Permalink | Log in to Reply

      bravo, removing cc is a welcome feature πŸ™‚

    • Lance Willett 6:42 pm on January 10, 2014 Permalink | Log in to Reply

      @nacin β€” Got my first email for Bundled Themes, nice! It was a notification for #26782.

      One question: I noticed the Reply-To is wp-hackers@lists.automattic.com β€” is that still correct?

      • Andrew Nacin 6:48 pm on January 10, 2014 Permalink | Log in to Reply

        Yeah, Trac emails have always been set up for that. Mostly to prevent replies from trying to go to the wp-trac list, which is announcement only.

        • Lance Willett 6:51 pm on January 10, 2014 Permalink | Log in to Reply


        • Lance Willett 6:51 pm on January 10, 2014 Permalink | Log in to Reply

          Crazy idea: what if an email reply made a new comment on the ticket?

          • Helen Hou-Sandi 6:56 pm on January 10, 2014 Permalink | Log in to Reply

            I thought about asking about that once, and then thought about how often using that feature on Basecamp leads to forgetting and/or ignoring context. It’s also good to actually visit tickets sometimes, as not everybody knows that uploading attachments doesn’t trigger any notifications.

            • Andrew Nacin 7:09 pm on January 10, 2014 Permalink

              GitHub supports this and every once in a while you can tell someone used it because some quoted text sneaks in. I think that ultimately, it’s a pretty edge feature. The cost of implementing this far outweighs the limited benefit.

              It doesn’t look like there are any decent Trac plugins that implement this. Even if they did, it sounds like it’d be a nightmare even just to configure and get working. It’s still a cool idea, of course, just not worth the energy.

    • Robert Dall 6:59 pm on January 10, 2014 Permalink | Log in to Reply

      @nacin When you click on next ticket… It stays in the same report now! Cool!!!

  • Andrew Nacin 7:47 pm on January 6, 2014 Permalink

    Lots of improvements to Core Trac 

    Over the holidays, I was sick for two weeks (boo). While resting and recovering, I took to working on our tools (yay). Specifically, Trac. Here’s an overview of the added features, enhancements, and bug fixes. There’s a lot (and more on the way), so I’ll try to keep each point brief. If you have any questions I’d be happy to elaborate in the comments.
    (More …)

  • Ryan McCue 2:20 pm on September 4, 2013 Permalink
    Tags: , , ,   

    JSON REST API: Coming Soon 

    It’s been a while since you’ve all heard from me, so I wanted to check in and assure you I am still alive. I’ve been plodding along behind the scenes with the JSON API and mostly getting design documents sorted.

    The big feature I’m working on at the moment – media – has turned out to be tricker than I initially thought. While media is technically handled via custom post types, it’s a completely different kettle of fish to normal post types, so I’ve been working through the conceptual issues behind this to ensure that the API stays consistent both internally and externally. I really believe that it’s worth my time to sit down and consider these conceptual issues in depth rather than pumping out the feature as soon as possible. (The implementation of the media-related endpoints is working locally, but I don’t want to push this up while it’s still in flux.)

    I still hold out hope to push through media, but will likely reduce the scope of the other tasks to compensate, due to the complexity of media and the time it has taken so far. I’d like to personally apologise for this, this is a result of improper scheduling for the second half of the project.

    Personally, the past month or so has been pretty stressful as well, due to a number of other things going on in the background. Balancing this project with university work has become a big issue recently, so I’m working through this as best as I can. Ideally, my preferred option at this point would be to push this project out of the Summer of Code phase and into the open source team phase rather than continuing to work on the project in isolation.

    Along those lines, revisions will be bumped from the Summer of Code phase completely. While they are part of core functionality, they’re a rather large task that is secondary in importance to media and also behind taxonomy handling. I’d love to see these in the plugin at some point, but that won’t be happening during the Summer of Code phase. What I would love is for someone to volunteer to develop this (in a separate plugin for now, thanks to GSoC’s restrictions) for integration back in as soon as possible, which would also help with validating the API’s usefulness.

    So again, sorry and hopefully I’ll have something better to show you next week. Thanks for your patience.

  • Frederick Ding 10:00 am on June 17, 2013 Permalink
    Tags: ,   

    Migration project for GSoC 

    Hello world! My name is Frederick, one of the GSoC interns who will be contributing to WordPress migration features this summer.

    A proud Canadian who grew up in Toronto and its suburbs, I am currently a bioengineering undergraduate at the University of Pennsylvania in Philadelphia, with hopes of working in the clinical and public health roles of a physician. The connection to coding might seem tenuous, but I am a firm believer in pursuing passions, despite how incongruous they may seem. As I wrote in my application, WordPress has offered me much in the way of community and inspiration, and I hope to gain better insight into my own aspirations through this internship.

    Like many in the community, my involvement with WordPress has included some plugins, and sites developed for work and student organizations. Although I’ve worked on two separate open source PHP projects, this is the first opportunity I’ve had to contribute to something that can reach so many people; indeed, the past Ten Good Years have yielded not only a collection of lines of code, but a huge and intensely active ecosystem of developers, designers, and users. To have the chance, even for 3 short months, to be a part of it, is both exhilarating and terrifying at the same time!

    My project is to improve the migration experience and the portability of WordPress. Just the thought of moving WordPress elicits headaches because of all the things that can go wrong, as one stunningly recent discussion in the community reminded me.

    For this project, I’ll be treading across both familiar and foreign territory. By current plans, I’d like to bring domain/URL renames to the backend and WP CLI, improve media handling and progress feedback in the WordPress-to-WordPress importer, and build in some semblance of plugin & option migration to the export/import workflow. (Subject to further change with notice.) More details will come in the days ahead.

    I’m really thrilled to be working with all of you! In addition to my weekly updates here, my notes-to-self and handy links to Trac/source can be found on my project site. I’d love to hear your feedback here and throughout the project.

  • 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!

  • Kim Parsell 2:59 pm on February 27, 2013 Permalink

    Installing a Version Control System 

    Installing Subversion on aΒ Mac

    Prior to OS 10.8 (Mountain Lion), Macs came with Subversion pre-installed. Subversion has since been moved to the Xcode developer package.

    This article will walk you through the steps to install Subversion on your Mac.

    1. Download The Package

    You can install Xcode to set up Subversion on your Mac; however, the download package is around 1.5 GB.

    Instead, you can download Apple’s Command Line Tools from Apple’s Mac Developer website. You will need an Apple ID to download the files.

    Log in to Apple’s Developer tools. Search for Command Line Tools, and download the correct package for your operating system.

    2. Install

    Install the package.

    3. Verify the installation

    You can verify the installation by typing:

    $Β Β svn --version

    You should see something like this:

    svn, version 1.7.10 (r1485443)
       compiled Aug 13 2013, 15:31:22
    Copyright (C) 2013 The Apache Software Foundation.
    This software consists of contributions made by many people; see the NOTICE
    file for more information.
    Subversion is open source software, see http://subversion.apache.org/
    The following repository access (RA) modules are available:
    * ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
      - handles 'http' scheme
      - handles 'https' scheme
    * ra_svn : Module for accessing a repository using the svn network protocol.
      - handles 'svn' scheme
    * ra_local : Module for accessing a repository on local disk.
      - handles 'file' scheme
    * ra_serf : Module for accessing a repository via WebDAV protocol using serf.
      - handles 'http' scheme
      - handles 'https' scheme

    Subversion is now installed and ready to use.

    Installing TortoiseSVN

    TortoiseSVN is an Apache Subversion (SVN) client, implemented as a Windows shell extension. It’s intuitive and easy to use, and doesn’t require the Subversion command line client to run.

    This sectionΒ will walk you through the steps to install TortoiseSVN on your computer.

    1. Downloading TortoiseSVN

    Download the latest version of TortoiseSVN, and save the installer file to your computer.

    Download TortoiseSVN

    2. Installing TortoiseSVN

    Next, you need to open the folder where you saved the file, and double-click the installer file. A security warning window will open, asking if you want to run this file. Click Run to start the installation process.

    TortoiseSVN Open File Warning Screen

    You will now see the welcome screen, which will confirm the version of TortoiseSVN that you are going to install. Click Next to continue.

    TortoiseSVN Installation Welcome Screen

    The next screen you are presented with is the End-User License Agreement (EULA). Read the agreement, check the radio button next to I accept the terms in the License Agreement, then click Next to continue the installation.

    TortoiseSVN End-User License Agreement Screen

    The Custom Setup screen will appear next. This screen will allow you to choose which components you would like to install. Unless you are dangerously low on disk space, you shouldn’t need to change anything. Click Next to continue.

    TortoiseSVN Custom Setup Screen

    Once the Confirm Installation screen appears, you are ready to start the installation process. Click Install to begin the process.

    TortoiseSVN Confirm Installation Screen

    The Installation Status screen will appear, which shows you the status of the installation process. Once the progress bar is completely green, click Next.

    TortoiseSVN Installation Status Screen

    The Installation Complete screen will now appear. Congratulations, you have now installed TortoiseSVN. Click Finish to complete the installation.

    TortoiseSVN Installation Complete Screen

    3. Configuring TortoiseSVN

    TortoiseSVN adds a few items to your context menu during installation, including a way to access the settings panel. To review and change any of the default settings, right-click inside any folder, go to TortoiseSVN, then select Settings in the submenu.

    TortoiseSVN Settings Menu Screen

    The first screen you see is for the General Settings. You can change your language, configure system sounds, and check for updates.

    TortoiseSVN General Settings Screen

    Select Context Menu under General in the settings tree on the left side of the window. You can now choose which items will appear on the first-level context menu. The items you will be using often when contributing patches to WordPress will be Checkout, Update, Show log, Repo-browser, Create Patch, and Apply Patch.

    TortoiseSVN Context Menu Settings Screen

    More information about the settings can be found in the Settings section of the TortoiseSVN documention.

    Next Steps

  • Helen Hou-Sandi 2:18 pm on July 17, 2012 Permalink

    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='https://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

      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

        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

      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


    • Umbrovskis.com 4:32 pm on October 11, 2012 Permalink

      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!

      • Helen Hou-Sandi 4:47 pm on October 11, 2012 Permalink

        Because that’s our particular style πŸ™‚

      • pickvector 6:00 am on April 18, 2015 Permalink

        i use Notepad++ editor,
        example : .blue-bubble vs .blue_bubble
        when i want to change “blue” to “orange” i just double click “blue” at ” .blue-bubble”
        but on “blue_bubble” i need to select manually with mouse.
        that one advantage avoid underscores.

        conclusion : hyphens ( – ) rename better speed than underscores ( _ ) because hyphens mark per block than underscores mark whole.

    • wpcustom 3:04 am on November 8, 2012 Permalink

      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

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


    • Ian Dunn 6:04 pm on March 9, 2013 Permalink

      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

        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

          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

      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

      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

      how i can check the code are standered or not?

    • cramdesign 3:01 am on March 13, 2014 Permalink


      “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

      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

      “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

      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

      A slight discrepancy that may warrant correction in the section on CSS inline commenting: https://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?

    • Reza 11:09 pm on October 25, 2014 Permalink

      can I use “or” as css class name

      • pickvector 6:15 am on April 18, 2015 Permalink

        im new to wordpress, personally i will avoid use “or” . I’m scared it conflict with ” or ” on PHP

        • tech_hutch 2:17 pm on July 23, 2015 Permalink

          Since all strings have to be quoted in PHP (well, except for the automatic turn-an-undefined-constant-into-a-string that PHP likes to pull), I don’t see how it could interfere.

          Regardless, I would avoid using “or” for code readability, since it’s not very descriptive. When someone else (read: you) comes back in a few months, they won’t know what “or” means.

    • omurphy 6:40 pm on July 22, 2015 Permalink

      Any reason why we have to type ‘input[type=”text”]’ instead of ‘input[type=text]’?

      The latter works fine in all browsers that I’ve tried. Is it against W3C spec?

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
Skip to toolbar