Dev Chat Summary: March 8th (4.7.4 week 1)

This post summarizes the dev chat meeting from March 8th (agendaSlack archive).

4.7.3 Update

4.7.4 Planning

  • The release lead for the next regularly-scheduled minor release (currently versioned as 4.7.4) will be @swissspidy.
  • Timeline tentatively set for April-May 2017, but we’ll have to get into bug scrubs and work with @swissspidy on an actual timeline for 4.7.4 as time goes by.
  • Just like 4.7.3, the timeline may change and will be highly dependent on how triage get tickets goes.

Browser support

  • @desrosj graciously compiled a summary of the discussion along with stats –> The New Editor and Browser Support
    • The overwhelming developer sentiment in the comments was for dropping support. A handful of people expressed that we did not have a full list of pros for dropping support.
    • But there was not as much discussion as I would have liked comparing the three potential fallbacks mentioned in the post, and no new potential fallbacks were mentioned.
    • I think if a solid, workable fallback that everyone is comfortable with can be decided on, then making the decision to drop support would be made a lot easier.
    • Dropping support for lower versions of IE could impact up to 2m WordPress users on the high end.
  • Discussion continues on a follow-up post –> Continued Discussion on Browser Support
  • There will be an additional dev chat this week to further discuss the fallback strategy to be used if support is dropped for older browsers. This chat will take place on March 15, 2017 at 12:00 EDT.

Core team reps

General announcements

  • A11y: #35566 to replace widget, create new widget, or other option from @afercia
    • A couple proposals on the ticket. Some work was done on them also at WC Europe.
    • We’ve discussed this issue during last accessibility bug-scrub on Monday and thought to bring it to everyone’s attention.
    • Before moving on, we’d like to:
      • see if there’s consensus in removing the title attributes there
      • and most of all, get feedback and recommendations about the best path forward, especially from people who have more experience than the a11y team has in managing backwards compatibility issues
    • As “tooltips” can be a controversial topic so the second proposal doesn’t use them
    • Looking for input on the best option: Deprecating the old widget and introduce a new one? Just replace the current widget? Or something else?
  • #39377: wpautop adds a extra </p>
    • @pbearne looking for dev-feedback, input from @azaozz
  • In a minor release we can consider string changes in moderation and for core focuses only, but we’d need a string freeze two weeks prior.

#4-7, #4-7-3, #4-7-4, #community-summit, #core, #core-customize, #core-editor, #core-restapi, #dev-chat, #summary

Dev Chat Agenda for March 8th (4.7.4 week 1)

This is the agenda for the weekly dev meeting on March 8, 2017 at 15:00 CST:

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-7, #4-7-3, #4-7-4, #agenda, #dev-chat

Dev Chat Summary: March 1st (4.7.3 week 5)

This post summarizes the dev chat meeting from March 1st (agendaSlack archive).

4.7.3 Schedule

  • Reminder of plan to release 4.7.3 as bugfix and maintenance release on Monday March 6, 2017
  • RC is available so please test

Community Summit

  • Working to review submissions on Planning for Community Summit 2017 post on Make/Core as well as submissions to the Make/Summit team via the Community Summit 2017: Sign-up Request post
  • Between now and Friday, March 5th the Core team needs to come up with:
    • 1) a list of topics for the summit
    • 2) A list of representatives to attend the Community Summit
    • 3) One or two contributors who are willing to help with the organization of the event
  • “participating” generally means being physically present for the discussions in Paris, France days prior to WCEU this summer for the Community Summit
  • Each topic facilitator will do both a pre-summit and post-summit Make/Core post. @jbpaul17 to confirm timelines with @_dorsvenabili to help prep those facilitators for those post timings.
  • Javascript in core [will submit to CS]
    • “what we hope and imagine for the future with the REST API, and how we hope to get there… what we have in core now and how we can improve it and how we can attract more JavaScript first developers to build on WordPress and especially contribute to core… How the REST API relates to wp-admin.” Submitted by @adamsilverstein to attend and volunteer to help in whatever role is most helpful.
    • “REST API admin usage: Where we can start moving things to using the API (and maybe even get a couple of them done at the summit)” Related submission from @chriscct7, recommended to include @rmccue
    • @kadamwhite: A heavy dependency on “the future of JS in core” and that discussion should originate from the broader WP community, not be mandated by the REST API group
  • Technology version support policies [will submit to CS]
    • @jorbin: (versions of PHP, MySQL, Browsers, Screen Readers, other AT, etc.) Let’s come up with some concrete plans for when we intend to deprecate things and how we want to handle it. People Who would be good to have in this discussion: @dd32 (to help with stats) @pento (to help with messaging) @afercia and @rianrietveld ( to help formulate AT support policies if they don’t exist already), @westonruter ( as maintainer of the largest JS component) @azaozz ( as maintainer of tinyMCE component) @matveb ( as dev lead of new editor)
    • @getsource, @boonebgorges, and @matt as additional reps for this topic
  • Improved management of contributors with time to spare [will submit to CS]
    • @johnbillion: This topic is particularly focused on pre-existing contributors who are paid to contribute to WordPress (eg. those whose time is sponsored by their employers), but also pre-existing contributors who aren’t sponsored but who do want to contribute a significant and/or consistent amount of time, and also potential contributors in a similar position.
      As a project, we need to manage these people’s time much better. These people need to be project managed in one way or another to avoid repeats of situations we’ve had in the past where a contributor is literally being paid to fix things in WordPress and the project is failing to enable them to do so effectively, or even at all. I’d (@johnbillion) like to attend the summit, and I’d be happy to jointly lead this discussion with someone who has good project management experience and some ideas about how WordPress might be able to better manage contributors, but at the same time do it in such a way that retains the fun and interesting aspects of contributing without turning it into something that too closely resembles “work”. [Side note from John: Worth noting that this doesn’t only apply to core, but it’s a good place to start.]
    • @helen did a survey of time availability a while ago, sent list to John to use for this topic
    • @aaroncampbell, @getsource, @jorbin, @boonebgorges, and @logankipp as additional reps for this topic
  • On-boarding experience for new contributors [will submit to CS]
    • @joemcgill: Lots of people who want to get involved have no idea where to focus their efforts.
    • @kadamwhite: Speaking for myself this is hugely related to the future of JS in core and the REST API, since those pieces really need the energy new contribs would bring
    • @getsource: I am willing to participate or lead, although I don’t know what leading it means besides guiding conversation at this point. @aaroncampbell also willing to lead.
    • @peterwilsoncc, @flixos90, @logankipp, @jorbin, @johnbillion, and @stevenkword as additional reps for this topic
  • Communicating changes to WordPress Core [will NOT submit to CS]
    • @jorbin: For the past few years, core has produced a field guide and worked with the meta and plugins team to email plugin others about changes to core. Each release though triggers a number of people who don’t know about changes until after the release. Challenge: How can we help ensure changes that aren’t worthy of user marketing promotion are known by a far greater percentage of WordPress developers?
      Might also impact or benefit from input from +make.wordpress.org/plugins +make.wordpress.org/themes +make.wordpress.org/marketing +make.wordpress.org/meta.
      Even when we get the field guide out on time, issues come up post release.
      two ideas:
      1) Translating the field guide (is this reasonable if the posts that it links to aren’t translated?) Also means polyglots should be in the discussion
      2) Using the new release email mailing list to announce RC
    • @helen: I think it’s worth at least starting the conversation earlier, even if it ends up still being valuable to continue something in person.
    • @desrosj: There may also be some great ideas from people who cannot attend in person. It would be a great opportunity for them to have their ideas heard and contribute, even if they are not able to follow through with the discussion in person at the summit.
    • @jorbinI’m going to withdraw the communication topic as my proposal for the summit with the note that I might want to resubmit it depending on how the virtual discussion goes
    • @azaozz and @sergey as additional reps for this topic
  • Security [will submit to CS]
    • @chriscct7: The process of a security ticket from report through triage through disclosure. Aaron Campbell (security czar) has made it clear this needs to be discussed at some point and I feel like the community summit would provide a good venue as many of those on the team will be there in person and we can mirror the conversation easily for those who are not. Recommend including @aaroncampbell
    • @aaroncampbell: This is actually a good idea, although I don’t think it’s because “those on the team will be there” but rather because I’d love to get input from some other people too, and security is generally sensitive enough that a place like the summit seems useful
    • @rmccue, @kadamwhite, @matveb, @joen, @westonruter, @melchoyce as additional reps for this topic
  • Collection of Anonymous data [will NOT submit to CS]
    • @chriscct7: If core is interested in doing it, I think my experience with doing it for a trac ticket (settings reduction) might prove to be useful to add to the discussion. Recommend including @drewapicture
    • General agreement to NOT include this topic since this is currently opt-in and the issue is finding an owner of this topic
  • Bootstrap/Load [will NOT submit to CS]
    • @schlessera: Opening up the WordPress Core Architecture to make it flexible enough as a platform so that it can:  * serve both novice end-users as well as large-scale enterprise installations in an optimized way;  * quickly adapt to changing external requirements, to keep up with the accelerating pace of the web. Recommend including @rmccue
    • General agreement to NOT include this topic since it does not need to happen in-person, already has discussions underway, and should be scheduled in next couple of weeks
  • Code editor [will NOT submit to CS]
    • @georgestephanis: Code Syntax Highlighting implementation and accessibility concerns — how we can get CodeMirror or whatever better library there is implemented and rolled out for both Customizer Custom CSS, Theme/Plugin Editor, and Content Blocks. Recommend including @afercia @westonruter
    • General agreement to NOT include this topic since it does not need to happen in-person and should happen sooner than the CS.
  • REST API authentication [will NOT submit to CS]
    • @georgestephanis: Third-party authentication with the REST API.    Between OAuth 1.0a, OAuth2, central application brokers, Application Passwords, or some other system — there’s a lot of possibilities here, and it’d be really nice if Core could pick something and move forward with it before folks start spoofing cookie authentication in applications to integrate with core.
    • Relevant chat summary from the last time we had one
    • This really needs an owner, otherwise it’ll continue to be punted. There’s fundamental differences on what the direction should be.
    • @samuelsidler: I don’t think core can decide until someone has documented the possible options, along with their strengths and weaknesses, then had some discussions on what would be best for core and why.
    • @georgestephanis, @rmccue, @logankipp volunteered post on Make/Core to move this topic along
    • We will table this idea and maybe propose it for the summit based upon how the near term discussions go
  • Front-end Editing [will NOT submit to CS]
    • @westonruter: Frontend editing powered by bootstrapping the customizer onto the frontend, with inline direct manipulation of elements on the page and the controls sidebar being lazy loaded to slide in from the left as needed. Editable elements include post content and site configuration (sidebars, menus, options, etc). Recommend including @celloexpressions
    • General agreement to NOT include this topic since it depends on too many other things we won’t know by then, so we will pass on that topic (at least for now).
  • Nextgen Widgets [will NOT submit to CS]
    • @westonruter: Next generation of widgets which harmonize with content blocks in the editor.
    • General agreement to NOT include this topic for the CS, but good conversation for the contributor day.
  • Feedback on Core focuses [will NOT submit to CS]
    • @georgestephanis: Six months in, how are we feeling about shifting away to a more top-directed set of focuses for the year?
    • General agreement to NOT include this topic as it’ll be hard to say until/unless we’ve shipped a core release by then (we likely won’t) and is a conversation that should happen in public.
  • Complete list of representatives nominated to attend the Community Summit: @matt, @nacin, @adamsilverstein@rmccue@kadamwhite@chriscct7, @dd32@pento@afercia@rianrietveld@westonruter@azaozz@matveb, @getsource, @boonebgorges@aaroncampbell, @jorbin, @logankipp, @peterwilsoncc, @flixos90, @johnbillion, @stevenkword, @azaozz, @sergey, @karmatosed, @joen, @westonruter, @melchoyce, @jnylen0, @ipstenu, @joemcgill, @joehoyle, @rachelbaker, @michael-arestad, @petya, @danielbachhuber, @ocean90, @samuelsidler, @afercia@desrosj, @iseulde, @jjj@celloexpressions
  • We’re still searching for 1-2 contributors who are willing to help with event organization, so please comment here or reach out to @jbpaul17 if you’re interested
  • @jbpaul17 will send the Core team responses to the Community Summit team by Friday, March 3rd.

Browser support

  • Please take a look at @desrosj’s post: The New Editor and Browser Support
  • This will be a topic of discussion at next week’s devchat.
  • Please leave your thoughts there as comments, and bring them along next week as well.

#4-7, #4-7-3, #community-summit, #core, #core-customize, #core-editor, #core-restapi, #dev-chat, #summary

Dev Chat Summary: February 15th (4.7.3 week 3)

This post summarizes the dev chat meeting from February 15th (agendaSlack archive).

4.7.3 Schedule

  • Completed first pass on all tickets in the 4.7.3 milestone, @jnylen0 is reviewing those that “need” to land in 4.7.3, and identifying a release date for 4.7.3 in the coming week

Customizer team update

  • #23601 (Use ACE Code Editor for Theme and Plugin editors) and #12423 (Include Ace (or similar) as default code editor)
    • Topic of discussion is a code editor library to be used in Custom CSS, WP content editor HTML view, file editor, and any other place that code is modified
    • Had planned to go ahead with CodeMirror since it is what Jetpack uses in its Custom CSS module, but @afercia pointed out accessibility problems
    • So we’re looking for insights into best of breed accessible code editor libraries
    • @afercia: looking to to understand if (1.) there’s consensus about introducing some sort of syntax highlighter library (plus other functionalities) and (2.) if it is going to completely replace the current WP content editor HTML view
    • @jorbin: Once one is decided upon, would like to encourage reaching out to the project maintainers and opening a dialogue about things like security and backwards compatibility
    • @helen: each area (Custom CSS, WP content editor HTML view, file editor) needs individual consideration and rationale
    • Goal is to provide a better user experience for when users edit code in WP
    • Custom CSS:
      • #38707: Customizer: Additional CSS highlight, revisions, selection, per-page, pop-out
      • @westonruter this is what #core-customize is most interested in, but picking a code editor library should be done ensuring that it doesn’t cause headaches if code editors are implemented for HTML view and file editor. i.e. the same library should be used throughout core.
    • WP content editor HTML view:
      • @joemcgill: the text editor now is not technically an HTML view, but is a plain text editor that is parsed into HTML. For instance, breaks are turned into `<p>` tags, shortcodes can be typed, etc., so a “code editor” is something slightly different.
      • @helen: per @iseulde and lots of discussions over time, is a little more complicated in that it’s not an actual HTML editor, so is getting rid of wpautop() is a requirement
      • @mike: I’d love to see code highlighting in the HTML view.
      • @afercia: If both the visual editor and the text editor are going to be replaced by Gutenberg and some sort of CodeMirror-like, well the level of accessibility for both is still uncertain and there’s the danger to introduce an accessibility barrier for the main scope of WordPress: entering content.
    • File editor:
      • @jorbin: I seem to remember that having been replaced with something fancier than what is in place now, but that having been ripped out
      • @helen: File editors really raise the question of whether users should be made more comfortable in them vs. being encouraged to use something else.
      • @brechtryckaert: security-wise I’m not a fan of the ability to edit files from the backend, people who are comfortable enough to edit code usually have a prefered editor
    • @jorbin: We already have our agreed upon accessibility coding standards that state:
      • All new or updated code released in WordPress must conform with the WCAG 2.0 guidelines at level AA

    •  @westonruter: if CodeMirror fails this test, as it seems to, then we need input on GPL-compatible code editors that are accessible.
    • @afercia: I propose to discuss this at the next accessibility meeting on Monday, invite people to do research, and possibly involve the testers group.
  • #38900 (Customize: Add REST API endpoints for changesets) and #39634 (Customize: Add REST API endpoints for panels, sections, controls, settings, and partials)
    • Thanks to @kadamwhite we have an initial (empty) feature plugin repo for the REST API endpoints for customization
    • Feel free to watch that repo and be apprised of developments
    • Next steps are to design the endpoints, write the failing tests for them, and then  go about writing the endpoint controllers
    • @kadamwhite: this is the first major effort within other areas of core that are turning up inconsistencies like #39805 (Expose featured_media property on post resources in “embed” context) so I’m excited to see what other improvements we can make as this work continues

Editor team update

  • Working full steam on prototypes, notably the Gutenberg UI prototype
  • The related GitHub repo has quickly become wonderfully active
  • Looking to discuss browser support for the new editor
    • @georgestephanis: So long as it can fall back to something that doesn’t utterly die, it should probably be fine.
    • WP Admin currently supports IE 8
    • Current browser market share
    • @jorbin: I would love to see us not drop support for anyone if possible
    • @joemcgill: Alternately, if we’re going to bump the browser requirements at any point, now is probably the time.
    • @joen: flexbox was mentioned as being nice to use in context of editor UI
    • flexbox support
  • The agenda for the Editor chat today was to discuss how using the UI prototype felt in the past week, and deciding where to take it next
  • We are looking for people to use and provide feedback the prototype, so please take a look if you can!

REST API team update

  • The REST API team has no significant updates since last week.

#4-7, #4-7-3, #core-editor, #core-restapi, #dev-chat, #summary

Improving the Settings API for accessibility and ease-of-use

On January 2nd the first meeting to discuss improvements of the well-known, but not well-loved Settings API took place in #accessibility. After a healthy discussion the next meeting was set to take place last Monday. Since the suggested improvements are not solely related to accessibility, the location for the meeting was moved to #core. This post is a recap of what was decided during these two meetings.

Archives of the full conversations:

Attendees: @afercia, @flixos90, @helen@joedolson, @johnbillion, @rianrietveld, @sc0ttkclark

First Meeting

The original reason for calling these meetings were several accessibility problems on WordPress settings pages. To quite some extent, these are related to the table markup that is automatically printed by the current Settings API. On a related note, it was mentioned that being required to write callback functions for rendering each and every field is a major drawback. Providing default callbacks would thus not only make it easier to work with the API, but also further improve accessibility as these callbacks would all be reviewed by the team. So the two main goals that were figured out were:

  • Add some basic support to automatically render fields so that plugin developers no longer need to write their own callback functions for basic fields.
  • Get rid of the table structure to improve accessibility. Furthermore the accessibility team should also ensure that the markup generated as the core field output is accessible.

The first meeting was also centered on whether these improvements should be tackled through means of the Fields API project, a new “Settings API v2” or improving the existing Settings API. In the end it was decided to continue working with the existing API, mainly for the following reasons:

  • The Fields API project is a huge effort that will still take a while until it can possibly be merged into core. Still, it will follow up with the changes that will be introduced in the Settings API, as @sc0ttkclark pointed out. While printing fields is certainly the focus of the Fields API, introducing a few technically simple callbacks in core at this point will not be a problem as these can be migrated to the Fields API ones at any time.
  • While the existing Settings API has its problems, it appears to be possible to handle the necessary improvements without running into backward-compatibility issues. A completely new Settings API could have further benefits, but it would leave many users behind that would need to manually migrate, and furthermore would take much longer to scaffold and implement.

After the meeting, a general ticket for the task was opened at #39441. The ticket description provides more information on how the two identified goals should be accomplished. In addition to the technical details, the first part of the accessibility measures will be to create an HTML-only prototype of what a better settings page would look like. It should be created without the limitations of the Settings API, so that the result can be the best possible example for what the enhanced Settings API should produce.

Second Meeting

@rianrietveld had four items on the agenda for the second meeting.

  • At first, everyone was asked to review the patch that @flixos90 provided on the above ticket. The patch only applies to introducing default field callbacks, so it still lacks adjustment of the table markup and a proper accessibility review, but it shows a possible technical approach.
  • Related to the patch, a tiny plugin was created and uploaded to the ticket as well. This plugin allows for easy testing of the functionality. For easier collaboration and possible iterations, that plugin has now been moved to GitHub. Feel free to try it out with the patch applied.
  • Some results of an accessibility test for form elements that was conducted by the accessibility team were revealed as a preparation for the prototype settings page in HTML. A few major issues to consider were discussed, for example the requirement of IDs on every field, the proper usage of fieldset and legend elements and the problematic usage of <input type="number"> for Dragon NaturallySpeaking speech recognition software. For creating the HTML prototype, it was decided to focus on replicating the core settings pages “General” and “Discussion”.
  • For the next step of the efforts, @afercia volunteered for creating the prototypes. As of now, the field markup he created for the two replicated settings pages can be inspected on GitHub (last two items in the list). These will probably be discussed in the next meeting.

If you are interested in helping out, there are several ways for you to do so: Please review the suggested improvements, the HTML prototypes and/or the technical approach. Feedback can be provided on the ticket, this post or by participating in the upcoming meeting/s. The Settings API meeting takes place biweekly on Monday at 17:00 UTC, so feel free to drop by. The next meeting will be on Monday, January 30.

#accessibility, #settings

Week in Core, November 30 – December 6, 2016

Welcome back the latest issue of Week in Core, covering changes [39380-39529]. Here are the highlights:

  • 150 commits
  • 63 contributors
  • 140 tickets created
  • 17 tickets reopened
  • 104 tickets closed
  • WordPress 4.7 released 🎉

Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

Code Changes

Administration

  • Accessibility: Remove inappropriate content from the Themes screen heading. [39528] #26601
  • Accessibility: Remove inappropriate content from the Add Themes screen heading. [39527] #26601
  • Accessibility: Remove inappropriate content from the Media Library screens headings. [39526] #26601

Build/Test Tools

  • Correctly set up the current screen during list table tests so that they don’t fail when run individually. [39481] #38761
  • Specify exact node version in package.json. [39480], [39478] #35105, #38657
  • Remove PHP 7.1 from allowed failures [39424-39425] #37625

Bundled Theme

  • Default Themes: Update version numbers and readme files for 4.7 release [39496] #38858
  • Twenty Seventeen: Fix CSS specificity problem with CSS feature query for object-fit [39495] #39073
  • Twenty Seventeen: Improve display of video header and header image in modern browsers [39485], [39483] #39035
  • Twenty Seventeen: Add specific font stack for Thai language [39484], [39482] #38937
  • Twenty Seventeen: Improve ARIA for the nav menu. [39451-39452] #39029, #39026
  • Twenty Seventeen: Ensure header text color updates in Customizer preview when cleared [39447-39448] #38993
  • Twenty Seventeen: Fix broken menu toggle in Customizer after menu items are added [39419], [39423] #38992
  • Twenty Seventeen: Fix style issues with gallery image links [39418], [39422] #38969
  • Twenty Seventeen: Hide front section panels on page load of Customizer. [39417], [39421] #38951
  • Twenty Seventeen: Add .has-header-video styles for custom color schemes. [39416] #38995
  • Twenty Seventeen: Better handling of custom headers when no image is set. [39413-39414] #38995
  • Twenty Seventeen: Make spacing on pages without comments consistent [39404-39405] #38972
  • Twenty Seventeen: Make sure header text color is applied when color schemes are active. [39397-39398] #38980
  • Twenty Seventeen: Make fixed navigation apply at correct height on front page, without header video or image [39394], [39392] #38927
  • Twenty Seventeen: Provide a background color fallback for non-webkit browsers on input styles [39388] #38939
  • Twenty Seventeen: Allow child themes to easily extend custom color patterns [39386] #38949
  • Twenty Seventeen: Make screen reader text on scroll arrow more meaningful [39384] #38970
  • Twenty Seventeen: Keep header videos from extending past footer. [39380-39381] #38950

Comments

  • Merge a similar string between comments.php, XML-RPC and the REST API comments controller. [39508] #39013

Customize

  • Prevent infinite full refresh from occurring when selective refresh falls back for a nav menu that has items excluded from rendering via filtering. [39510-39511] #38612
  • Defer populating post_name for auto-draft posts in customized state until posts are published. [39506-39507] #39078
  • Ensure changeset_uuid query param is removed from the customize.php window’s location once a changeset has been published (committed) with starter content. [39504-39505] #39081
  • Prevent posts/pages imported via starter content from being dropped when adding post/page stubs via nav menus and the dropdown-pages control. [39502-39503] #38114, #34923, #39071
  • Ensure textarea for Custom CSS displays as code (in LTR) when an RTL language is active. [39499-39500] #35395, #39085
  • Ensure a custom_css post insertion gets an initial post revision. [39479], [39477] #30854, #38672, #35395, #39032
  • Custom CSS: Change the help link to something better for users. [39467], [39466] #39015
  • Fix posts limit query arg for WP_Query from incorrect number to posts_per_page. [39434-39435] #39022
  • Reuse existing non-auto-draft posts and existing auto-draft posts in the customized state with matching slugs when applying starter content. [39411] #38114, #38928
  • Reject a changeset update when a non-future date is provided and also ensure that a published changeset always gets set to the current date/time. [39409-39410] #30937, #38943
  • Fix handling of the nav menu item labels (titles) that match defaults (original titles) and fix the display of item type labels. [39395], [39393] #38015, #38955

Feeds

General

Help/About

Media

  • Accessibility: Improve keyboard accessibility avoiding confusing tab stops in the Media views. [39529] #30599
  • Docs: Add inline documentation for image-edit.js. [39493] #38748
  • Fix regression with display of small images in media library. [39399], [39396] #38965
  • Docs: Document the usage of the global $wpdb in _filter_query_attachment_filenames(). [39390] #38973

Misc

  • Tag 4.7 [39525] #
  • WordPress 4.7 “Vaughan”. [39524] #
  • Post-RC3 bump. [39519] #
  • WordPress 4.7 RC3. [39516] #
  • Post-RC2 bump. [39474] #
  • WordPress 4.7 RC2. [39473] #
  • Twenty Seventeen: Add .has-header-video styles for custom color schemes. [39415]

Options, Meta APIs

  • REST API: Register the admin_email setting in single site only. [39470-39472] #38990
  • REST API: Site URL setting should not be present on multisite installations. [39468] #39005
  • REST API: Correct the admin_email setting description for single site installs. [39406] #38990
  • Multisite: Display different descriptions for multisite or single site installations. [39407] #38990
  • Options: Pass the $passed_default parameter to the 'default_option_{$option} filter in add_option(). [39382] #38176, #38930

Plugins

REST API

  • Comments: Merge similar strings between comments.php and the REST API comments controller. [39490-39491] #39014
  • Merge similar date strings in the revisions and comments controllers. [39488-39489] #39016
  • Treat any falsy value as false in ‘rest_allow_anonymous_comments’. [39487] #39010
  • Docs: Add missing REST API-related args to register_post_type() and register_taxonomy(). [39462-39463] #39023
  • Merge similar strings in a comments endpoint parameter description. [39457] #39036
  • Fix bug where comment author and author email could be an empty string when creating a comment. [39446], [39444] #38971
  • Fix handling of some orderby parameters for the Posts controller. [39440-39441] #38971
  • Disable DELETE requests for users in multisite. [39438-39439] #38962
  • Return a WP_Error if meta property is not an array. [39436-39437] #38989
  • Add test for creating a comment with an invalid post ID. [39408] #38991
  • Fix incorrect uses of rest_sanitize_value_from_schema(). [39400-39401] #38984

Role/Capability

  • Don’t assign the delete_site capability to anyone on single site installs. [39494] #38326
  • Multisite: Replace is_super_admin() with manage_network for admin bar permissions. [39492] #39064, #37616

Taxonomy

  • Docs: Update an @since as there will not be a 4.6.2 before 4.7. [39475-39476] #37291
  • REST API: Capability check for editing a single term should use the singular form. [39464] #35614, #39012
  • REST API: Use the correct error message when editing a single term. [39460-39461] #39017
  • REST API: Fix incorrect capability check on term create. [39402-39403] #35614, #38958
  • Performance: Revert [38677] from the 4.7 branch. This avoids fatal errors caused with recursive calling of term functions within the get_terms filter. [39454] #21760

Themes

  • Reuse existing non-auto-draft posts and existing auto-draft posts in the customized state with matching slugs when applying starter content. [39412] #38114, #38928

TinyMCE

  • Fix the styling of notices generated by the editor UI. [39501] #38917

Users

  • Clarify the return value of get_current_user_id() for non-logged-in users. [39486] #39051
  • REST API: Require the reassign parameter when deleting users. [39426-39427] #39000

Thanks to @andizer, @mor10, @adamsilverstein, @afercia, @azaozz, @boonebgorges, @celloexpressions, @ChopinBach, @clorith, @coffee2code, @davidakennedy, @dd32, @desrosj, @dlh, @flixos90, @georgestephanis, @helen, @helen, @hnle, @iaaxpage, @imnok, @jbpaul17, @jeremyfelt, @jnylen0, @joedolson, @joehoyle, @joemcgill, @johnbillion, @jorbin, @kadamwhite, @karmatosed, @ketuchetan, @laurelfulford, @littlebigthing, @lucasstark, @melchoyce, @michaelarestad, @mikeschroder, @mt8.biz, @nacin, @netweb, @ocean90, @ovenal, @pento, @peterwilsoncc, @presskopp, @rachelbaker, @rahulsprajapati, @ramiabraham, @ramiy, @rensw90, @rianrietveld, @rmccue, @samuelsidler, @sayedwp, @SergeyBiryukov, @sstoqnov, @The PHP tea, @timmydcrawford, @utkarshpatel, and @westonruter for their contributions!

#4-7, #week-in-core

Customizer Improvements in 4.7

WordPress 4.7 has been the most active release on record for the customize component, with four major feature projects merging and shipping with 4.7 and over 90 tickets closed as fixed. This post summarizes the highlights of the user and developer-facing changes.

4.7 Customizer Feature Projects

Create pages within live preview during site setup

Add new pages while building menus and setting a static front page; outline your site directly in the customizer.

This project began with the ability to create posts and pages direction from the available menu items panel in the customizer, as originally proposed near the end of the 4.6 cycle:

https://make.wordpress.org/core/2016/06/16/feature-proposal-content-authorship-in-menus-with-live-preview/

Subsequent changes also added the ability to create new pages when assigning the front page and posts page in the Static Front Page section. Because this is now built into the core dropdown-pages customizer control, themes and plugins can also allow users to create new pages for their options instead of relying on existing content. The homepage sections in Twenty Seventeen include this new allow_addition parameter. Here’s how to register a dropdown-pages control supporting new pages:

$wp_customize->add_control( 'featured_page', array(
	'label'          => __( 'Featured Page', 'mytextdomain' ),
	'section'        => 'theme_options',
	'type'           => 'dropdown-pages',
	'allow_addition' => true, // This allows users to add new pages from this dropdown-pages control.
) );

Additionally, a proposal for term statuses was developed as a first step toward expanding the menus functionality to work for creating and previewing taxonomy terms in a future release (see #37915).

Improvements to the Sliding Panels UI

Customizer navigation is now faster, smoother, and more accessible.

This project tackled a series of tickets focused on improving the usability of the “sliding panels” UI in the customizer controls pane. The first step was to refactor the section and panel markup so that sections and panels are not logically nested. This is the biggest internal change to the UI and has a dedicated post going into the details:

https://make.wordpress.org/core/2016/09/28/changes-to-customizer-sliding-panelssections-in-wordpress-4-7/

This primary change resolved numerous problems with sections and panels not opening and closing properly, and eliminated situations where navigation to leave a section could become hidden. The next step was making section and panel headers “sticky” so that navigation is easier to access within long sections (such as for a menu); see #34343.

Finally, hover and focus styling for navigation in the customizer has been updated to use the blue-border approach found elsewhere in core, including for the device-preview buttons in the customizer, in #29158. This completes a refresh of the customizer controls pane’s UI design that began in WordPress 4.3 with #31336. The core UI now uses the following consistent UI patterns in the customizer:

  • White background colors are used only to indicate navigation and actionable items (such as inputs)
  • The general #eee background color provides visual contrast against the white elements
  • 1px #ddd borders separate navigational elements from background margins and from each other
  • 15px of spacing is provided between elements where visual separation is desired
  • 4px borders are used on one side of a navigation element to show hover or focus, with a color of #0073aa
  • Customizer text uses color: #555d66, with #0073aa for hover and focus states on navigation elements

Plugins and themes should follow these conventions in any custom customizer UI that they introduce, and inherit core styles wherever possible.

Any custom sections and panels, as well as customizations to the core objects in plugins and themes, should be tested extensively to ensure that they continue functioning as intended with all of these changes in 4.7. It’s particularly important to ensure that things like the use of color match the core conventions so that the user experience is seamless between functionality added by plugins and core.

Customize Changesets (formerly Transactions)

Browse your site and switch themes more seamlessly within the customizer, as your changes automatically persist in the background.

This project rewrote the internals of the customizer preview mechanism to make changes persistent. Each change made to a setting in the customizer is saved to a changeset (a new customize_changeset post type), facilitating future features such as scheduled changes, revisions, or saving and sharing drafted changes. Changesets also open the door to using the customizer to preview Ajax requests, headless sites, and REST API calls for mobile apps. In 4.7, changesets enable switching themes in the customizer without needing to decide between publishing or losing your customizations, as they’re automatically persisted in the background.

For more details on changesets, check out the two dedicated posts:

https://make.wordpress.org/core/2016/10/12/customize-changesets-formerly-transactions-merge-proposal/

https://make.wordpress.org/core/2016/10/12/customize-changesets-technical-design-decisions/

Custom CSS

Fine-tune your site and take your theme customizations to the next level with custom css in the customizer.

#35395 introduced a user-oriented custom CSS option in the customizer. Now that the base functionality is in place, it will be further enhanced in #38707 in future releases. Read the feature proposal for details on the implementation and why it’s important for core:

https://make.wordpress.org/core/2016/10/11/feature-proposal-better-theme-customizations-via-custom-css-with-live-previews/

There’s also a dedicated post that walks through the process of migrating existing custom CSS options in themes and plugins to the core functionality – be sure to follow those steps if your plugin or theme does custom CSS:

https://make.wordpress.org/core/2016/11/26/extending-the-custom-css-editor/

Other Changes with Dedicated Posts

4.7 features several other features deserving special attention. Read the posts for visible edit shortcuts (which expand the functionality of customizer partials), video headers (which extend the custom header feature), and starter content for more information:

https://make.wordpress.org/core/2016/11/10/visible-edit-shortcuts-in-the-customizer-preview/

https://make.wordpress.org/core/2016/11/26/video-headers-in-4-7/

https://make.wordpress.org/core/2016/11/30/starter-content-for-themes-in-4-7/

Additional User-facing Changes

With over 90 tickets fixed in the customize component in 4.7, we can’t cover everything here. But, here are a few more highlights:

Improved Custom Background Properties UI

#22058 introduces a more comprehensive and more usable custom background properties UI when a custom background is set up. There are now presets to control all of the detailed options at once, and the individual options are presented in a more visual way. Background size and vertical position are also now available as standalone options when using a custom preset.

Theme developers should update their add_theme_support() calls for custom-background to specify the default size, vertical position, and preset to reflect their default background image CSS. Perhaps the most significant improvement here is the ability for users to easily set up fixed full-screen backgrounds – and the ability for themes to make that behavior default if desired.

And even more…

4.7 also:

  • Loads the frontend preview iframe more naturally, eliminating a lot of weirdness with JS running in an unexpected location and ensuring that JS-based routing will work (#30028)
  • Allows the search results page to be previewed, and any forms that use the GET method in general can now be submitted whereas previously they would do nothing when submitted (#20714)
  • Hides edit post links in the customizer by default. Plugins, such as Customize Posts, can restore the links if they make post editing available in the customizer (#38648), although the visible edit shortcuts should generally be used instead.
  • Shows a cursor: not-allowed for mouse users when hovering over external links in the preview, as these can’t be previewed
  • Officially removes support for the customizer in Internet Explorer 8, preventing users of this outdated browser from accessing the customizer at all (#38021)

Additional Developer-oriented Changes

Hue-only Color Picker

#38263 adds a hue-only mode to the Iris color picker, wpColorPicker, and WP_Customize_Color_Control. Built for Twenty Seventeen’s custom colors functionality, the hue-only mode allows users to select a hue and saves the hue degree as a number between 0 and 359. To add a hue-color control:

$wp_customize->add_control( new WP_Customize_Color_Control( $wp_customize, 'colorscheme_hue', array(
	'mode' => 'hue',
	'section' => 'colors',
) ) );

As demonstrated in Twenty Seventeen’s custom colors strategy, the hue-selection strategy opens up a whole new world of possibilities for custom color options in themes. Rather than introducing numerous text and background color options and requiring users to adjust them to ensure that adequate color contrast is provided, themes can consolidate their color options into one or more hue pickers. Then, the corresponding use of hsl colors in CSS allows themes to define color patterns where users customize color hues without impacting the lightness of a color option, thereby preserving the designer’s use of proper contrast between text and background colors, and any use of color lightness for visual hierarchy. Check out the implementation in Twenty Seventeen for inspiration (including instant live preview).

Fix Sections that .cannot-expand

When creating custom customizer sections that, for example, display an external link but don’t actually expand to show section contents, the cannot-expand class can be added to the section title container to prevent JS events and CSS hover/focus styles from being applied. Be sure to also remove the tabindex="0" from the container if you copy the core code since your custom section shouldn’t be focusable if it can’t expand (and any contained links or buttons would be keyboard-focusable automatically). See #37980 for details.

Allow Plugins to do Comprehensive Late Validation of Settings

To account for custom subclasses of WP_Customize_Setting that don’t apply the customize_validate_{{$setting_id}} filter, this filter now will be applied when WP_Customize_Manager::validate_setting_values() is called. This ensures that plugins can add custom validation for every setting. For more, see #37638.

Credits

Huge thanks to the 61 people (and counting) receiving props for the 120+ customize component commits in 4.7 (as of RC2): @westonruter, @celloexpressions, @afercia, @sirbrillig, @ryankienstra, @helen, @ocean90, @melchoyce, @bradyvercher, @folletto, @johnbillion, @delawski, @karmatosed, @georgestephanis, @dlh, @curdin, @valendesigns, @mattwiebe, @michaelarestad, @joemcgill, @sstoqnov, @lgedeon, @mihai2u, @coreymcollins, @stubgo, @utkarshpatel, @desrosj, @odysseygate, @johnregan3, @aaroncampbell, @mapk, @iseulde, @mrahmadawais, @vishalkakadiya, @sayedwp, @hugobaeta, @jonathanbardo, @jorbin, @tristangemus, @deltafactory, @kkoppenhaver, @seancjones, @Presskopp, @Mista-Flo, @nikeo, @adamsilverstein, @lukecavanagh, @coffee2code, @peterwilsoncc, @presskopp, @pento, @Kelderic, @sebastian.pisula, @mckernanin, @FolioVision, @MikeHansenMe, @welcher, @cdog, @grapplerulrich, @iamfriendly, @flixos90.

 

#4-7, #customize, #dev-notes

Starter content for themes in 4.7

One of the hardest things for people setting up sites with WordPress for the first time is understanding what themes are and how a given theme can work for you, especially when there’s no content there to visualize. There are also significant gaps between local theme previews, screenshots, and .org previews. Even when there are easy-to-use site customization tools, it is difficult to figure out where to start and what things are going to be like.

To help users along that path, 4.7 introduces the concept of “starter content” – theme-specific selections of content to help showcase a theme to users and serve as a starting point for further setup of new sites. Starter content works especially well in tandem with visible edit shortcuts, allowing users to not only see what content might work best where within a theme, but from there to be able to jump to building off of that base without having to initially spend time figuring out, say, which widgets areas map where.

How it works

Starter content is applied and displayed upon entering the customizer, with no changes appearing on the live site until customizer changes are explicitly saved and published. In 4.7, this initial view of a theme with starter content will only happen for “fresh sites” – new installs that have not yet had any posts, pages, widgets, or customizer settings updated. This state is indicated in the fresh_site option with a value of 1. The current limitation is in line with prioritizing initial site setup for this release, and allows for themes to begin implementing content and ensuring that there is a solid base before introducing more complicated logic and UI to “merge” starter content with existing content in a future release (#38624). That being said, if two themes in a given fresh site both have starter content, if the starter content from the first theme is applied and you make some changes to that starter content, when you switch to the second theme the starter content from that theme will override the starter content from the first theme only for the settings which have not been modified. Also remember that theme mods are always theme-specific, so starter content for theme switches will never be copied.

Core provides a set of content that themes can select from (technical details below). These include a variety of widgets, pages, and nav menu items (including references for the pages), along with the ability to provide attachments, theme mods, and options. Any included images for attachments need to be from within a theme or plugin folder and cannot be loaded from an external URL. Twenty Seventeen will ship with starter content enabled; there are no plans to add the functionality to past default themes.

How to use it

Themes define a subset of core-provided starter content using add_theme_support() – let’s look at a breakdown of how Twenty Seventeen does things. In its setup function hooked to after_setup_theme, we see an array with collections of widgets, posts (pages), attachments, options, theme mods, and nav menus registered as the starter content. The customizer looks for this starter-content at after_setup_theme priority 100, so do make this call at that point or later:

add_theme_support( 'starter-content', array( /*...*/ ) )

Widgets

Each widget area ID corresponds to one sidebar registered by the theme, with the contents of each widget area array being a list of widget “symbols” that reference core-registered widget configurations. Most default widgets are available (archives, calendar, categories, meta, recent-comments, recent-posts, and search), as well as text widgets with business hours (text_business_info) and a short prompt for an “about this site” style blurb (text_about). Themes should place widgets based on what works best in that area – for instance, business info in a footer widget of a business-centric theme, or a nicely styled calendar widget in the sidebar of a blog.

Custom widgets can also be registered at the time of starter content registration or later filtered in, which will be more likely the case for plugins, as add_theme_support() for starter content will be overridden by any later calls.

// Custom registration example
add_theme_support( 'starter-content', array(
	'widgets' => array(
		'sidebar-1' => array(
			'meta_custom' => array( 'meta', array(
				'title' => 'Pre-hydrated meta widget.',
			) ),
		),
	),
);

// Plugin widget added using filters
function myprefix_starter_content_add_widget( $content, $config ) {
	if ( isset( $content['widgets']['sidebar-1'] ) ) {
		$content['widgets']['sidebar-1']['a_custom_widget'] = array(
			'my_custom_widget', array(
				'title' => 'A Special Plugin Widget',
			),
		);
	}
	return $content;
}
add_filter( 'get_theme_starter_content', 'myprefix_starter_content_add_widget', 10, 2 );

Posts (Pages)

Like widgets, core provides posts which can be referenced by symbols; all six currently in the core set are pages, but the starter content API can support various post types (including attachments, which are defined and handled separately). The symbols for the core-provided pages as of 4.7 are home, about, contact, blog, news, and homepage-section. The pages references by blog and news are both empty in the content area and are meant to be assigned as the page for posts (detailed with options below). Imported posts can further be used as post IDs when referenced using the symbol of the item within double curly braces, e.g. {{home}} for the static front page option.

Posts, like widgets, are also easily customizable, either by overriding specific fields for a predefined item or by defining a new custom one entirely. The available fields are post_type, post_title, post_excerpt, post_name (slug), post_content, menu_order, comment_status, thumbnail (featured image ID), and template (page template name, as would be stored in post meta).

// Overriding/supplementing a predefined item plus a custom definition
add_theme_support( 'starter-content', array(
	'posts' => array(
		'about' => array(
			// Use a page template with the predefined about page
			'template' => 'sample-page-template.php',
		),
		'custom' => array(
			'post_type' => 'post',
			'post_title' => 'Custom Post',
			'thumbnail' => '{{featured-image-logo}}',
		),
	),
);

Attachments

While attachments are post objects, they have special handling due to the sideloading of specified media. Media must be loaded from within the theme or plugin directory – external URLs are currently disallowed for performance reasons. The location of the media, either as a full file path or relative to the theme root, is indicated in the file array item, and some other post fields are available, with post_content mapping to description and post_excerpt to caption. Imported attachments can further be used by using their respective array keys as symbols used within double curly braces, e.g. {{featured-image-logo}} as the featured image (thumbnail) for a post. In the example below, an attachment is specified and used as the featured image for the about page.

add_theme_support( 'starter-content', array(
	'attachments' => array(
		'featured-image-logo' => array(
			'post_title' => 'Featured Logo',
			'post_content' => 'Attachment Description',
			'post_excerpt' => 'Attachment Caption',
			'file' => 'assets/images/featured-logo.jpg',
		),
	),
	'posts' => array(
		'about' => array(
			// Use the above featured image with the predefined about page
			'thumbnail' => '{{featured-image-logo}}',
		),
	),
);

Nav Menus

Nav menus are also specially treated post objects. There are essentially two types of nav menu items – custom links, which require a title and url, and object references, which require type, object, and object_id, which can be a {{post}} symbolic reference.

Options and Theme Mods

Options and theme mods are more freeform and merely require a match for a name. Symbolic references to imported items are particularly useful here, such as for the page_on_front option and Twenty Seventeen’s multi-section homepage as stored in theme mods. Themes hosted on .org will likely be limited to theme mods and a subset of options; all other developers are encouraged to consider user experience and expectations first.

What does this mean for themes?

Core-provided content helps support a consistent preview experience across themes with high quality localized content, helping users understand how WordPress and that theme fit their needs. Theme authors are encouraged to select from core-provided content, but as is always the case with WordPress, starter content still has some flexibility, and will continue to mature as a feature over time.

While theme review guidelines need to be finalized and documented, it is anticipated that themes being submitted to WordPress.org will be expected to select from core-provided content to promote consistency and to help keep the theme review process from becoming lengthier, with exceptions being made on a case by case basis. Themes being distributed outside of WordPress.org are not subject to the same review process; however, it is recommended that consistent user experiences be the primary consideration in how starter content is chosen and implemented.

What’s next?

Testing this feature with your theme or plugin does not require a fresh install every time – you can set the fresh_site option to 1 using the tool of your choice, such as wp-cli or phpMyAdmin. Do note that content merging logic has not been tackled so you may not quite get the exact same effect as a truly fresh install; however, since all of the changes are held in a customizer changeset and are not otherwise live on the site, there is no data loss, unless you save and publish the starter content overrides of course.

In the future, all sites should be able to live preview new themes in ways that really showcase that theme’s capabilities, whether that’s with no content made yet or with a lot of existing content to work into the preview. This will take a lot of consideration around user expectations for content merging, and should be tackled as its own feature. There are also potentially interesting extensions such as UI for users to select from sets of content or selectively accept/reject staged changes.

And finally, to best align preview experiences in various places, theme previews on .org should also leverage starter content. Helping hands are needed here – please ping me (@helen) in Slack should you be interested!

#4-7, #dev-notes

Week in Core, November 23 – 29, 2016

Welcome back the latest issue of Week in Core, covering changes [39341-39379]. Here are the highlights:

  • 39 commits
  • 30 contributors
  • 81 tickets created
  • 3 tickets reopened
  • 31 tickets closed

Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

Code Changes

Build/Test Tools

  • Build: Remove fsevents from npm-shrinkwrap.json [39368] #38657
  • Add an extra WP_Error assertion when testing a valid user activation key. This provides a better failure message if the assertion does fail. [39364] #38716
  • When testing the output of wp_list_pages(), use a known and fixed date for each post so the tests don’t fail when the date changes between the beginning and end of a test. [39363] #38688
  • Git: Prevent untracked files from being ignored by git in bundled themes. [39362] #27207, #38779
  • Add npm-shrinkwrap.json to 4.7. [39358] #38657

Bundled Theme

  • Twenty Seventeen: Add textdomain for starter content attachment titles. [39374-39373] #38981
  • Twenty Seventeen: Ensure edit button label displays properly in other languages [39341] #38876

Customize

  • Fix regression in ability to hide fields for advanced menu properties in nav menu item controls. [39379-39378] #34391, #38952
  • Fix regression in ability to create submenus for nav menus via drag and drop. [39377-39376] #34391, #38948
  • Fix logic for previewing the URL for nav_menu_item settings for terms and post type archives. [39365] #38114, #38945
  • Refactor logic for updating custom_css posts by introducing wp_update_custom_css_post() function and renaming update filter. [39350] #35395, #38672
  • Clean up docs and code style for customize changes in 4.7. [39345] #37770, #38908

Embeds

  • Correctly remove security attribute from iframes in IE 10 and IE 11. [39347] #38694

General

  • Git: Ignore patch related files, so they can’t be accidentally committed. [39361] #38727
  • SVN: Ignore patch related files, so they can’t be accidentally committed. [39360] #38727
  • Docs: Add a missing changelog entry for the point where the $tagnames parameter was added to get_shortcode_regex(). [39351] #38914

Misc

Plugins

  • WP_Hook: Re-initialize any actions added directly to $wp_filter by advanced-cache.php. [39370-39369] #38929

REST API

  • Add test for creating a comment with an invalid post ID. [39375] #38816, #38991
  • Add tests for empty or “no-op” updates. [39371] #38700, #38975
  • Special case the “standard” post format to always be allowed. [39353] #38916
  • Allow unsetting a post’s password. [39352] #38919
  • Add support for comments of password-protected posts. [39349] #38692
  • Always fire the rest_insert_* actions after the related object is updated or inserted. [39348] #38905
  • Make JS Client store schema in session storage. [39344] #38895
  • Allow unsetting of page templates in update requests. [39343] #38877
  • Update “resource” strings to use the appropriate nouns. [39342] #38811

Themes

  • Fix logic for previewing the URL for nav_menu_item settings for terms and post type archives. [39366] #38114, #38945
  • Theme starter content: Add support for featured images and page templates. [39346] #38615

TinyMCE

  • Fix the styling of notices generated by the editor UI. [39367] #38917

Thanks to @mor10, @adamsilverstein, @afercia, @azaozz, @celloexpressions, @danielbachhuber, @davidakennedy, @dd32, @delawski, @DrewAPicture, @flixos90, @georgestephanis, @helen, @iseulde, @jnylen0, @joehoyl, @joehoyle, @johnbillion, @karmatosed, @keesiemeijer, @lucasstark, @nacin, @ocean90, @odysseygate, @pento, @rachelbaker, @ramiy, @swissspidy, @tg29359, @westonruter, and @xrm for their contributions!

#4-7, #week-in-core

Week in Core, November 15 – 22, 2016

Welcome back the latest issue of Week in Core, covering changes [39233-39340]. Here are the highlights:

  • 108 commits
  • 53 contributors
  • 114 tickets created
  • 16 tickets reopened
  • 101 tickets closed

Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

Code Changes

Bundled Theme

  • Twenty Seventeen: CSS coding standards [39340] #38901
  • Twenty Seventeen: Ensure galleries display correctly in IE11. [39339] #38872
  • Twenty Seventeen: Avoid an undefined index notice after [39291]. [39317] #38847
  • Twenty Seventeen: Adds background-attachment: fixed; to devices that should support it [39297] #38395
  • Twenty Seventeen: Ensure the use of proper image size for custom header image [39291] #38847
  • Twenty Seventeen: Remove some extraneous function calls. [39286] #38848
  • Twenty Seventeen: Additional default header image optimizations. [39279] #38793
  • Twenty Seventeen: Add styles for custom header video controls. [39273] #38697
  • Twenty Seventeen: Compress the default header image. [39248] #38793

Comments

  • REST API: On Comment create, limit the ability to set the author_ip value directly. [39302] #38819
  • REST API: Change “ipv4” types to “ip” to support ipv6. [39296] #38818
  • REST API: Remove the karma property and query parameter from the Comments endpoints. [39292] #38821
  • REST API: On comment create, return an error if the type property is set to anything other than comment. [39290] #38820
  • REST API: On comment create, return an error if the post parameter does not relate to a valid WP_Post object. [39288] #38816
  • REST API: On comment create, fallback to the user_agent header value. [39287] #38817
  • Query used to fill comment descendants should reset ‘offset’ and ‘number’ params. [39274] #37696

Customize

  • Prevent selective refresh from causing infinite fallback refreshes when nav menu contains invalid items. [39333] #38890
  • Remove iframe-specific behaviors from customize preview when previewing on frontend and not contained inside iframe. [39332] #30937, #38867
  • Ensure that WP_Customize_Manager::save_changeset_post() returns setting_validities even for supplied values that are unchanged from values in changeset. [39320] #38705, #30937, #38865
  • Ensure WP_Customize_Setting::value() returns previewed value for custom types utilizing the customize_value_{$id_base} filter. [39318] #38864
  • Autoprefixer for [39249]. [39301] #29158
  • Remove obsolete edit shortcut style rules from Twenty Seventeen. [39285] #38776
  • Ensure Close button actually closes customizer (instead of going back) after switching to a different theme inside a customize-loader iframe. [39271] #38833
  • Prevent edit shortcut buttons from being inserted into container elements in the head or into elements which should not get interactive children. [39270] #27403, #38672, #38830
  • Allow URL for Codex link in Additional CSS section to be translated. [39268] #35395, #38823
  • More visible focus and hover states for close and back buttons. [39249] #29158
  • Ensure edit shortcuts have same background color regardless of theme colors. [39243] #38776
  • Add !important line-height to edit shortcut buttons. [39242] #38787
  • Allow starter content to apply in a new theme when switching from another theme containing changes. [39241] #38114, #38541
  • Only show video header controls if previewing front page; show explanatory notice when controls are hidden. [39237] #38796, #38778
  • Adjust layout for edit shortcuts only when shown. [39233] #38651

Database

  • Add support for LIKE-escaped tables in ::get_table_from_query(). [39275] #38751

Emoji

General

  • Plugin install: De-duplicate a conditional, introduced in [38172]. [39336] #38190
  • Docs: Use 3-digit, x.x.x style semantic versioning for @since 4.7.0 entries. [39281] #37770
  • Tests: Add a missing $message argument for assertEquals() in [39265]. [39267] #23626
  • Tests: Use assertEquals()‘ native functionality for delta comparison in test_wp_convert_bytes_to_hr(). [39265] #23626

I18N

  • In wp_dropdown_languages() rename the new show_site_locale_default argument to show_option_site_default. [39331] #38632, #38871
  • Add an additional caching layer for _load_textdomain_just_in_time(). [39330] #37997
  • Introduce more translator comments for strings that contain placeholders but don’t have an accompanying translator comment. [39326] #38882
  • Move the support forums URL in update-related HTTP API error messages to a separate translatable string that is already used elsewhere. [39325] #38880
  • Remove an erroneous @TODO introduced in [39323]. [39324] #38882
  • Begin introducing translator comments for strings which include placeholders but no accompanying translator comment. [39323] #38882
  • REST API: Merge two error messages for edit / update. [39322] #38879
  • REST API: Update error messages in WP_REST_Comments_Controller to use the common text for permission errors. [39321] #38875
  • Use ‘WordPress hook name’ instead of ‘PHP hook name’ in translator comments added in [39315]. [39316] #38862
  • Add translator comments for strings in _deprecated_*() functions. [39315] #38862
  • Remove unnecessary __() calls in _rotate_image_resource() and _flip_image_resource(). [39314] #38862
  • REST API: Merge some more permission error strings missed in [39309]. [39313] #38857
  • Text Changes: Merge strings referring to list_users capability. [39312] #38857
  • Merge two ‘RSS Error:’ strings. [39311] #38861
  • REST API: After [39306], move author_ip argument to the correct place. [39310] #38822
  • REST API: Merge and clarify some permission error strings. [39309] #38857
  • Text Changes: Merge and clarify some permission error strings in the admin. [39308] #38857
  • Merge two ‘ERROR:’ strings. [39307] #38860
  • REST API: After [39302], clarify author_ip parameter in error message. [39306] #38822
  • REST API: Merge two similar permission error strings in class-wp-rest-comments-controller.php. [39305] #38857
  • REST API: Merge two similar permission error strings. [39304] #38857
  • REST API: Clarify parameters when used in error strings. [39298] #38822
  • REST API: After [39252] and [39264], uppercase some more ‘ID’ references in translatable strings. [39266] #38791
  • REST API: Uppercase ‘ID’ in endpoint descriptions and error messages for consistency with other strings. [39264] #38791
  • REST API: Unify some more permission error messages. [39259] #38803
  • REST API: Unify permission error messages. [39257] #38803
  • Remove “ tags from translatable strings in wp-includes/class-wp-customize-manager.php. [39254] #38802
  • REST API: Remove two duplicate strings, use the ones we already have. [39252] #38791
  • REST API: Unify permission error messages. [39251] #38791, #34521
  • REST API: After [39238] and [39239], move the remaining translator comments to preceding line. [39245] #38791
  • Docs: Apply documentation standards to the new get_available_languages filter. [39244] #38788
  • REST API: Move translator comments to preceding line. [39239] #38791
  • REST API: Add translator comments to text with placeholders. [39238] #38791
  • Add the get_available_languages filter. [39235] #38788

Media

Misc

  • REST API: Check read permissions on posts when viewing comments. [39295]
  • Small coding standards cleanup of wp-custom-header.js. [39277]
  • Post-4.7 beta 4 bump. [39263]
  • WordPress 4.7 Beta 4. [39262]

Options, Meta APIs

  • REST API: Update description strings to match already existing ones in the admin. [39335] #38807

Posts, Post Types

  • Accessibility: Improve the Post Attributes meta box fields labels. [39247] #38790
  • Improve sanitisation of templates’ post types. [39236] #38766

REST API

  • Set the comment type to a readonly property in the schema. [39337] #38820, #38886
  • Trim trailing slashes from routes. [39329] #38873
  • Correctly map meta keys to field names. [39328] #38786
  • Disable anonymous commenting by default. [39327] #38855
  • Add test case for users/me endpoint that the context param defaults to view. [39293] #38842
  • Allow parent property to be explicitly set to 0 when creating or updating a Post. [39289] #38852
  • Clean up argument and property types. [39250] #38792

Taxonomy

  • Update register_taxonomy hook to use WP_Taxonomy object. [39283] #38765
  • Prevent wp_list_categories() from producing not well-nested output if hide_title_if_empty is true. [39280] #38839, #33460

Text Changes

  • Merge some duplicate strings with the same meaning in error messages, adjust some other strings for consistency and accuracy. [39278] #38808
  • Unify permission error messages in wp-admin/users.php. [39258] #38804
  • Unify permission error message in wp-ajax-response.js. [39253] #34521

Themes

  • Prevent unneeded database updates in wp_get_custom_css_post(). [39338] #38866
  • Twenty Seventeen: Make all Codex links in DocBlocks use HTTPS [39300] #38854
  • Twenty Seventeen: Rename the starter content menus to match the menu area names. [39294] #38615
  • Improve a11y and extendability of custom video headers. [39272] #38678
  • Theme starter content: Add reference IDs for most default widgets. [39261] #38615
  • Theme starter content: Refine the content for pages. [39260] #38615
  • Theme starter content: Add more social link items to select from. [39256] #38615
  • Theme starter content: Revamp the credits widget into an about widget. [39255] #38615
  • Remove front page restriction from video header functions. [39240] #38738
  • Customize: Use video-specific labels for buttons in Header Video media control. [39234] #38172

TinyMCE

  • Avoid calling editor.focus() on loading the content in the editor. It may trigger scroll-into-view in the browser. Call the quirks fix in TinyMCE directly. [39334] #38511
  • Fix automatic scroll on page load. [39299] #38511
  • Remove extra space in tooltip. [39284] #38063
  • Tews: fix Firefox issues. [39282] #36434, #38511

Upgrade/Install

Users

Thanks to @adamsilverstein, @afercia, @andy, @azaozz, @boonebgorges, @bradyvercher, @celloexpressions, @chesio, @ChrisWiegman, @danielbachhuber, @davidakennedy, @dd32, @derrickkoo, @dimadin, @flixos90, @folletto, @gitlost, @helen, @iseulde, @jnylen0, @joehoyle, @joemcgill, @johnbillion, @johnpgreen, @jrf, @laurelfulford, @lucasstark, @lukecavanagh, @markoheijnen, @melchoyce, @mikeschroder, @netweb, @ocean90, @odysseygate, @pento, @peterwilsoncc, @Presskopp, @rachelbaker, @ramiy, @rianrietveld, @rmccue, @schlessera, @SergeyBiryukov, @sharkomatic, @sirbrillig, @sstoqnov, @swissspidy, @tharsheblows, @timmyc, @transl8or, @welcher, @westonruter, and @yoavf for their contributions!

#4-7, #week-in-core