Commit announcements for 3.9

Lots of news to share! First: Helen Hou-Sandí has had guest commit for the past three release cycles. She’s been spending the last year reviewing contributions, mentoring contributors, and working on some of our larger UIUI User interface projects. I’m proud to announce @helen is now a permanent committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. to WordPress!

We’ve invited John Blackbourn (@johnbillion) to be a committer for the 3.9 cycle. His strong, consistent contributions have been backed by excellent judgment and temperament.

Matt Thomas, who led the dashboard redesign in 3.8 (and 3.2, and 2.7, etc.), will keep his commit to continue to maintain and improve WordPress UI. He’s been a great mentor to many contributing designers and his long-term impact is indelible.

For the last few years, we’ve been granting commit access on per-cycle basis, sometimes for a particular component, feature, etc. Generally, after about a year, a guest committer can be considered for permanent commit access. Dominik Schilling, Sergey Biryukov, Drew Jaynes, and Scott Taylor have all had their commit extended for 3.9.

Drew (@DrewAPicture) was given temporary commit for inline documentation starting with 3.7. He’s been heading up the long-running initiative to document every hook in WordPress. Scott (@wonderboymusic) also started committing during 3.7, and has a particular penchant for digging deep into the query and taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. APIs. And Sergey (@SergeyBiryukov) and Dominik (@ocean90), well, they are forces of nature.

(@aaroncampbell was also given guest commit in 3.7, but he ended up not having much time to use it.)

Here’s a full list of those with permanent commit: @markjaquith, @ryan, @westi, @matt, @azaozz, @dd32, @koopersmith, @duck_, @helen, and me (@nacin); @lancewillett for bundled themes; @iammattthomas for UI. You might have also seen commits before from @josephscott (XML-RPC), @nbachiyski (internationalization), and @mdawaffe (secret weapon for really tricky problems).

Next weekly meeting is January 8. Happy new year, everyone. Here’s to a great 2014.

#3-9, #commit

Finding and Fixing JavaScript errors with JSHint

The JavaScript Coding Standards have been updated, so it’s time to move on to tackling our JSHint errors!

JSHint is a tool to check for errors in JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. code. As was discussed last week, we’re kicking off a small effort to work through our coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. JavaScript files. To get through the errors revealed by JSHint as quickly as possible, we’re following the model established by the Inline Docsinline docs (phpdoc, docblock, xref) team and posting a list of files with issues so that people can “claim” the files they’d like to fix!

At the bottom is a list of every file in core that is displaying JSHint errors. Files with a checkmark have been patched and should now be passing lint. Files marked with (username #xxxxx) are already claimed, and being worked on.

Please read and understand the process we’ll be following to address these issues! Many thanks to @azaozz, @nacin and @jorbin for helping identify the safest way to approach fixing these errors, and to @rzen for posting the Inline Docs article on which we based this guide.

How to contribute:

  1. Leave a comment on this post with the file* you’re about to edit (check the list first to make sure it hasn’t already been claimed).
  2. Update your local WordPress SVN to the latest version of WordPress trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. (currently 3.8-alpha).
  3. Create a new ticket on Trac for the file.
    JSHint-related trac ticket settings
    • Format the title as “jshint shouldn’t throw errors – path/to/file.js”.
    • Assign the ticketticket Created for both bug reports and feature development on the bug tracker. to the “Build Tools” component.
    • Make sure your email is stored in TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.’s preferences

    If you are logged in, you can click this link to automatically open a ticket with the right settings.

  4. Edit the file, and make a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing.. Please make sure you create the patch from the root directory of your WordPress SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. checkout. If you are working on a large file, consider making multiple patches for each type of change.
  5. Upload your patch to the Trac ticket you created, and add the keyword “has-patch”.

*Note: We strongly encourage you to work on one file at a time. These shouldn’t take very long, but if you call a bunch at once and get tied up, we won’t be able to get through these as quickly as possible. To quote @rzen from the inline docs effort, “your edits should be made and patched swiftly so that they aren’t invalidated by (or don’t invalidate) another patch.”

Keeping Discussions Focused:

Any discussion about the specifics of a patch itself should happen on Trac. Discussion about the overall effort should take place during our standing weekly meeting, on Wednesdays at 1900 UTC in #wordpress-dev*.

Files needing patches:

Checked files are now passing JSHint

  • wp-content/themes/twentyfourteen/js/functions.js ( #26031) (@jorbin)
  • wp-content/themes/twentyfourteen/js/slider.js ( #26032) (@jorbin)
  • wp-includes/js/admin-bar.js (@kadamwhite, #25970)
  • wp-includes/js/autosave.js ( #26035)
  • wp-includes/js/comment-reply.js ( #26038)
  • wp-includes/js/customize-base.js ( #26039)
  • wp-includes/js/customize-loader.js ( #26040)
  • wp-includes/js/customize-preview.js ( #26019)
  • wp-includes/js/heartbeat.js ( #25986)
  • wp-includes/js/jquery/jquery.table-hotkeys.js ( #26015)
  • wp-includes/js/media-editor.js ( #26022)
  • wp-includes/js/media-models.js (@kadamwhite, #26132)
  • wp-includes/js/media-views.js (@kadamwhite, #25974)
  • wp-includes/js/mediaelement/wp-mediaelement.js (3 errors)
  • wp-includes/js/plupload/handlers.js ( #26041)
  • wp-includes/js/plupload/wp-plupload.js (@atimmer, #26044)
  • wp-includes/js/quicktags.js (@kovshenin, #26046)
  • wp-includes/js/shortcode.js (@tommcfarlin, #25945) (@nacin)
  • wp-includes/js/tinymce/mark_loaded_src.js ( #26014)
  • wp-includes/js/tinymce/plugins/wordpress/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wpdialogs/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wpeditimage/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wpfullscreen/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wpgallery/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wplink/editor_plugin_src.js ( #26024)
  • wp-includes/js/tinymce/plugins/wpview/editor_plugin_src.js ( #26027)
  • wp-includes/js/utils.js (@adamsilverstein, #25957)
  • wp-includes/js/wp-ajax-response.js (@originalexe, #25954)
  • wp-includes/js/wp-auth-check.js ( #26009)
  • wp-includes/js/wp-list-revisions.js (#25864)
  • wp-includes/js/wp-lists.js ( #26012)
  • wp-includes/js/wp-pointer.js ( #26012)
  • wp-includes/js/wp-util.js ( #25957)
  • wp-includes/js/wplink.js (@jorbin, #25914)

See all open tickets in the Build Tools component

For tips on dealing with global variables, inlined third-party code within first-party scripts, etc, see the JSHint tips in the JavaScript Coding Standards

For the curious, this list was created with a jazzy little command @nacin came up with to pipe Grunt output through ack:

grunt jshint --force | ack '^Linting src/' | ack -o 'wp-.*.js' | sort | uniq -c | sort

What we’re NOT doing

The two JSHint options called out in the earlier post, “curly” and “eqeqeq,” would ordinarily make up the vast majority of the errors JSHint reports in our files. We’ve currently set Grunt and JSHint to ignore these two types of errors when JSHint is run against core. While these are best practices, we’ll come back to them once we address the more significant code smell issues like undefined variables.

Also note that we’re not tackling whitespace or non-JSHint-related refactoring during this effort. We’ll get there, but we have to mitigate the risk to core as much as possible so we don’t interrupt the 3.8 cycle. Keep your changes focused on passing JSHint this go-around.

#build-tools, #javascript, #jshint

A first draft of the Twenty Thirteen theme…

Screen Shot 2013-02-18 at 5.15.50 PM

A first draft of the Twenty Thirteen theme is now in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., for your inspection and iteration. See: r23452

A demo site is available for you to browse.

@matt set the goals for this theme: a focus on blogging, and great support for post formats (which are getting attention on the backend in 3.6 as well). Under Matt’s guidance, @joen explored the artistic possibilities and was joined by @obenland and @lancewillett in bringing it to fruition.

What you’ll notice first is the colors. Way more use of color than a bundled WordPress theme has had before. Each post format has its own color, so each is distinct, yet they are all complimentary. The bold colors encourage authors to try out all the different formats. This color extends the full width of the window, which breaks your blogblog (versus network, site) up into a lush, segmented timeline. This effect is even more pronounced on mobile browsers, where the screen can be dominated by one or two posts at a time, in all of their chromatic fullness.

On closer inspection, you’ll notice details, like the font-based icons (“Genericons”, by @joen) that scale up to any resolution or zoom level and can be easily recolored using CSSCSS Cascading Style Sheets..

You may notice some playful details, like the size-offset pagination arrows:

Screen Shot 2013-02-18 at 4.52.23 PM

Or the 404 page (which I’ll leave to you to find).

One of the goals of having a new theme every year was to give ourself room to experiment. That hasn’t really happened. We’ve been far too conservative, trying to make themes that work reasonably well for everyone, but don’t push boundaries too much. That changes with Twenty Thirteen. It’s hard not to have a strong feeling about the theme, one way or another. It defies you to give it a shrug or a kurt nod. Some of you will hate it. And that’s okay. We’ll still be shipping Twenty Twelve, which is an excellent base theme and a canvas on which you can build anything from a blog to a static content site. But with Twenty Thirteen we’re taking a bold stance: this theme was meant for blogging, and it’s not a blank canvas. It comes pre-marinated with playfulness and warmth and opinions.

Twenty Thirteen really prefers a single column layout. Widgets live best in the footer, where jQuery Masonry bricks them together (but it supports a sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme., if you really insist). HeaderHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. images have a fixed width and height, and will be cropped at smaller resolutions, so the best choice is an artistic header where not 100% needs to be shown all the time (it ships with three).

Now that we have a first draft of Twenty Thirteen in core, it’s time to start iterating and sanding off some of the rough edges. AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) is still important, even when making bold artistic statements, and I’d be surprised if we didn’t have work to do there. We’ll need testing on lots of different browsers and platforms, and with lots of different plugins. @helen‘s Post Format UIUI User interface team will need to give feedback on upgrading Twenty Thirteen to use the new post format APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. functions that are available.

@lancewillett and @obenland will be holding Twenty Thirteen office hours on Tuesdays and Thursdays at 1700 UTC. Interested parties should make an effort to attend and help us get this beauty ready for betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.!

#3-6, #bundled-theme, #theme, #twentythirteen