Make WordPress Core

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

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

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

      #selector-3 {

      background: #fff;

      color: #000;


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

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

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

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

      This is super cool.

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

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

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


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

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

      If there is, please refer to some source!

      • Helen Hou-Sandi 4:47 pm on October 11, 2012 Permalink | Log in to Reply

        Because that’s our particular style :)

      • pickvector 6:00 am on April 18, 2015 Permalink | Log in to Reply

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

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

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

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

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

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

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

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

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

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


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

      The Selectors section says,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      how i can check the code are standered or not?

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


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

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

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

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

      “Avoid camelcase and underscores”

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

      Could we count these classes as exceptions?

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

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

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

      A slight discrepancy that may warrant correction in the section on CSS inline commenting: 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 | Log in to Reply

      can I use “or” as css class name

      • pickvector 6:15 am on April 18, 2015 Permalink | Log in to Reply

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

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

      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?

  • Andrew Nacin 1:18 pm on July 13, 2012 Permalink |


    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


    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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

          Just my 2 cents.

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

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

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

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

      The readme standard rocks again.

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

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

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

    Reporting Bugs 

    Reporting Security Issues

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

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

    Overview of Bug Reporting and Resolution

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

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

    Before You Report a Bug

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

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

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

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

    2. Search for your bug or enhancement request.

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

    3. Consider discussing a possible bug before reporting it.

    Reporting a Bug

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

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

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

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

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

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