What’s new in Gutenberg? (20th July)

Today’s release continues to improve multiple areas of Gutenberg, its behaviours and tools. Most of the updates are around refining the experience and strengthening the API surface, but there’s also a couple new server rendered blocks added to the library. There are also multiple packages being extracted as the APIs mature. Many thanks again to all the contributors!

Archives and Recent Comments blocks

3.3 🥝

Deprecations removed with this version.

WordPress 4.9.8 Beta 1

It’s that time again, we have a new beta release package for 4.9.8, and we’d love your help testing it out. It’s important to make sure that a release is fully tested and bugs are squashed. If you’re new (or it’s been a while) you can checkout the guide for helping to test a beta version.

This beta release contains 21 bug fixes, 9 enhancements and 2 blessed tasks. The purpose of this release has been to focus on additional enhancements for privacy in WordPress (following up on the tremendous work done for 4.9.6), as well as adding a callout to try the new Gutenberg editing experience.

The work being done to introduce the “Try Gutenberg” callout (#41316) is still in progress, and as such hasn’t been included in this first beta. Our plan (subject to change) is to release a second beta version once that’s ready, and once that hits we’ll ask for specific testing on the callout.

For the rest of the work, we’d love your help to make sure the enhancements and bug fixes are working as expected!

The release candidate is scheduled for Tuesday, July 24th, and the official release is scheduled for Tuesday, July 31st.

Bug Fixes

A full list of bugs fixed in 4.9.8 Beta can be found on Trac.

Bundled Theme

  • #44109 – TwentySeventeen backend editor: level 2 bulleted lists nested under numbered lists show numbers instead of bullets


  • #44141 – Privacy: Don’t replace comment author URL and email with anything
  • #44342 – Commenter cookie consent message should not be displayed if the cookie action isn’t hooked


  • #44104 – Customize: Attempt to count uncountable value


  • #44341 – Replace _deprecated_function( ‘add_filter’ ) with apply_filters_deprecated()

Filesystem API

  • #43054 – wp_is_stream fails with stream definition containing nonascii chars

Login and Registration

  • #44052 – Missing parameter type for `login_header()`


  • #43751 – REST API: Attachments controller should respect “Max upload file size” and “Site upload space” in multisite
  • #44532 – Extreme memory leak related to wp_is_stream in wp-includes/functions.php in WordPress 4.9.7


  • #44099 – Add Request Type into Admin Email Subject for GDPR
  • #44195 – “Silence is golden” index.html generates output
  • #44265 – Add filter for email subject for erasure complete notification
  • #44353 – Replace `site_url( ‘wp-login.php’ )` in `wp_send_user_request()`
  • #44379 – GDPR filters should provide either $request or $request_id
  • #44382 – Filter the subject within _wp_privacy_send_request_confirmation_notification
  • #44396 – Inconsistent use of blogname and sitename in Privacy emails
  • #44590 – Remove “// WPCS:” comments

Rest API

  • #43874 – REST API: Only render fields specific to request when _fields= is used
  • #42691 – WP_Term_Query get_terms generates invalid sql queries
  • #44096 – REST API: Taxonomy and term endpoints should use correct permission checks
  • #44330 – TinyMCE: do not force-load external TinyMCE plugins


A full list of enhancements in 4.9.8 beta can be found on Trac.

Posts, Post Types

  • #36085 – Add action hook to get_inline_data()


  • #44006 – Privacy Policy page should have suffix like other special pages
  • #44025 – Privacy: Pagination screen options for the requests list tables
  • #44100 – GDPR Privacy Page setting allows for Draft Pages
  • #44131 – If draft page selected for Privacy Policy page should verbiage change from view to preview
  • #44181 – The input field id username_or_email_to_export should be something else on remove_personal_data page
  • #44373 – Add a privacy setting to disable comment cookie consent
  • #44321 – REST API: Expose revision count and last revision ID on Post response
  • #44287 – REST API: Declare user capability to perform actions using JSON Hyper Schema `targetSchema`

Blessed Tasks

A full list of blessed tasks in 4.9.8 beta can be found on Trac.


  • #44339 – Emoji: Update Twemoji to 11.0


  • #44134 – Update to TinyMCE 4.7.13
    • See the TinyMCE changelog.  WP 4.9.6 included TinyMCE 4.7.11, WP 4.9.8 beta 1 updated to TinyMCE 4.8.0.

#4-9-8, #release

Servehappy: Roadmap Update and Priorities

At WordCamp Europe 2018, representatives from different teams got together to discuss the state of the Servehappy project, reevaluate its roadmap and priorities.

Meeting Context

While this blog typically contains updates from the core PHP team, it is important to highlight that the Servehappy project is an interdisciplinary effort that has involved several other teams as well. We have been collaborating closely with the marketing and design teams so far, however at the same time several efforts were pursued in other teams which had not been mentioned as much in the weekly recap posts: The community team and support team have been pushing a format called “Site Health Check”, providing support services at WordCamps to increase adoption of modern PHP versions as a part of that. The hosting team has also discussed on how to approach the problem on their end. Due to all these different teams being involved in the Servehappy project, we wanted to revisit the project state together with a representation of those teams.

Participants: @alexdenning, @flixos90, @mikeschroder, @miss_jwo, @pento, @schlessera

Meeting Summary

Short-Term Goals

While the general long-term goals of the project are clear and available in the project’s roadmap, the discussion briefly involved clarifying priorities and short-term goals.

  • Increase adoption of modern PHP versions by being more active and vocal about the necessity of those.
  • Encourage users in a positive manner to update and stay updated.
  • Make the process of updating as seamless as possible.
  • Release a first iteration of the project that warns administrators of sites running PHP 5.2.

Approach: Help People

We agreed that, in line with the WordPress philosophies, the approach to solving the problem should be based on framing the project in the user’s context, most of who have little to no technical knowledge of PHP.

  • We would like to boost user confidence by encouraging the update and educating about preliminary recommended steps to take in order to ensure the process goes without a hassle.
  • By highlighting tools such as Tide, the Health Check plugin, or the PHP Compatibility Checker plugin, we allow non-technical users to easily gain technical insights in a plugin’s compatibility with certain PHP versions.
  • We intend to reduce the risk of updating PHP as much as possible by implementing a sandboxing system to decrease the chance of a site breaking through the update. We need to ensure that site owners are never locked out of the backend due to an incompatibility.
  • We plan to run further Site Health Check desks at WordCamps and related events and encourage organizers to do so, in order to raise awareness of the importance of checking the PHP version on your website. An important side note to this, at this point only updates to PHP 7.2 and 7.1 should be encouraged, as both PHP 5.6 and 7.0 will be unsupported from the end of this year.

Data about PHP Version Updates

We briefly talked about the jumps from and to specific PHP versions, looking at how involved they typically are.

  • The update from 5.2 to 5.3 has known issues which are not small. We should review the support impact for hosting companies, agencies, plugins, themes, and the WP.org support team.
  • The updates between 5.3 to 5.6 are usually unproblematic, there have been no known major issues.
  • The update from 5.6 to 7.0 has many known issues. @mikeschroder will request a list of common issues and errors known to the hosting team when performing that update.
  • The updates between 7.0 and 7.2 have been less problematic, however due to several deprecations more investigations should be made in that area.

Improving the Updating PHP Page

While the nag to inform site owners about an unsupported PHP version has already been merged into core and an Updating PHP page is already available, it is necessary to improve the latter.

  • The above page, which is linked to from the core nag, will to a large extend determine whether the project will be successful or not, as people have to be willing to read its content and then act on its recommendations.
  • Currently the page is a simple wall of text, which will likely scare away visitors. The page content needs to be further reworked, broke down into more obvious sections, shortened, and be visually enhanced so that users are guided through the process as intuitively as possible.
  • @alexdenning will coordinate with @jaymanpandya who had worked on a design for the page before to move this forward.

Community Plans

  • A Site Health Check desk will be available at WordCamp Brighton in mid-August with the goal of testing this approach further and optimizing the process.
  • Following this, we would like documentation to be created about having this format, with the goal of it being ready by WordCamp US in early December. That documentation could then be shared with communities and organizers around the world, encouraging providing this format at more events.
  • Current plans also include there being a Site Health Check desk at WordCamp US, preferably also with more hosting team support at the desk, especially due to their high availability at that event.
  • Another idea was to have wapuus made available specifically for the Site Health Check.

Hosting Plans

  • The core PHP team would like to communicate more and collaborate more closely with the hosting team.
  • The hosting team is an ally to these efforts and would like to be more involved. Some miscommunications in the past were figured out and clarified.
  • It is planned that a representative of the hosting team will be participating in the weekly PHP team meetings, reporting back and voicing views of the hosting team on the topics discussed. As of now, @antpb has stepped up to fill that position.
  • It would be great if documentation for hosting companies could be created on how to integrate with the Servehappy nag in core (read more about the core integration) and on how to provide easy-to-understand documentation on how to safely update PHP in their specific environment.
  • An idea for further down the road that came up was having standardized endpoints as part of an API for upgrading PHP across hosts. CPanel or Plesk adopting this could move the needle across many hosts at once.

Core and Security Plans

  • The security and core teams plan to work on user-facing documentation on why running old versions of PHP or WordPress is dangerous.
  • Furthermore they intend to create documentation for both plugin and theme authors about how to ensure that their code is compatible with modern PHP versions.

Involvement of the Marketing Team

  • Going forward, all documentation created as part of the aforementioned plans should preferably be reviewed by the marketing team.
  • It is important to use an easy-to-understand, encouraging and positive tone of voice for all documentation.
  • We need to ensure that all marketing material documentation is localizable and uses language that is easily translatable.

Requirements for Servehappy in Core

In order for the first iteration of the Servehappy project to be shipped in a core release, we determined the steps that must be completed before.

  • The first iteration should primarily revolve around the core nag warning users about outdated PHP versions. It will only be displayed for PHP 5.2 in the first iteration.
  • Due to that version being controlled by a wordpress.org API, the nag’s visibility can be gradually increased by being shown on higher PHP versions too, without being tied to WordPress core releases.
  • Further efforts of the Servehappy project in core, such as preventing installation or updates of incompatible plugins and themes, are not specifically a requirement for the first iteration. Although not as high a priority at this point, they should definitely not stall and will be merged and released as they get completed, however only at the same time or later than the core nag.
  • The efforts of improving the Updating PHP page mentioned above needs to be completed, with the page being in a solid state. It should be fully translatable, and there should be enough time before the release to encourage the creation of localized versions of the page across the globe. The link to the page in core is localizable as well, being able to link to those versions.
  • A safe-mode functionality needs to be implemented in order to prevent WSODs (white screens of death) and other errors that would lock the site owner out of their backend. It will likely involve some sort of sandboxing system, with plugins being deactivated in the admin as necessary to ensure possible access. Having this will allow the instructions in the Updating PHP page to be more positive and confirming. @schlessera has since been making quite a bit of progress on this already in #44458.
  • It should be possible for hosting companies to hook into the nag and provide their own instructions of how to upgrade to WordPress users on their stack.
  • It is currently envisioned to have the first iteration ship as part of WordPress 5.0, however depending on when that version is released, this may change. It is certainly no hard deadline in that regard.

Project Name Proposal

  • Based from the Site Health Check desks, there is a suggestion to refocus the project to be the WordPress Health Check Project which encourages people by name to check for updates continually.
  • However, the problem has arised about defining what is in scope of the site health check. It needs to be clarified what kind of health check this is, as some users so far have looked at it as a performance check.
  • The name change would allow for a more positive mindset and for the scope of the project to change as the WordPress project needs it to.
  • Unless there are objections, the name Servehappy for the core efforts is solely an internal codename and will not be exposed to the user anywhere.

Get Involved

If you’re interested in these efforts, please get involved and get in contact with the respective team whose work you are interested in. The easiest way to do so is participate in their meetings. We need your input and ideas, specifically we would like to ask for your feedback on the outcome of the discussion that is part of this summary, as most of it is not set in stone. If you cannot make it to the respective meeting, posting a comment here is a great alternative.

As far as the core efforts go, the next meeting will take place on Monday, July 23th, 2018 at 15:00 UTC in the #core-php channel on Slack.

WordPress 4.9.7

WordPress 4.9.7 is now available. This maintenance and security release fixes 17 bugs.

Download WordPress 4.9.7 or visit Dashboard → Updates and click “Update Now”. Sites that support automatic background updates are already beginning to update automatically.

Thank you to everyone who contributed to WordPress 4.9.7:

1naveengiriAaron JorbinabdullahramzanalejandroxlopezAndrew OzzArunBirgir Erlendsson (birgire)BjornWBoone GorgesBrandon KraftChetan PrajapatiDavid HerreraFelix ArntzGarethIan DunnibelangerJohn BlackbournJonathan Desrosiers, JoykhaihonglbenicioLeander IversenmermelmetalandcoffeeMigrated to @jeffpaul, palmiakSergey BiryukovskoldinSubrata SarkarTowhidul Islamwarmlaundry, and YuriV.

WordPress versions 4.9.6 and earlier are affected by a file deletion issue where a user with the capability to edit and delete media files could potentially manipulate media metadata to attempt to delete files outside the uploads directory.

Thank you to Slavco for reporting the original issue and Matt Barry for reporting related issues.

Other highlights of 4.9.7 include:

  • Taxonomy: Improve cache handling for term queries.
  • Posts, Post Types: Clear post password cookie when logging out.
  • Widgets: Allow basic HTML tags in sidebar descriptions on Widgets admin screen.
  • Community Events Dashboard: Always show the nearest WordCamp if one is coming up, even if there are multiple Meetups happening first.
  • Privacy: Make sure default privacy policy content does not cause a fatal error when flushing rewrite rules outside of the admin context.

You can see the full list of changes in Trac.

The previously scheduled 4.9.7 is now referred to as 4.9.8, and will follow the release schedule posted yesterday.

#minor-releases, #security

Dev Chat Agenda: July 11th (4.9.8 week 2)

This is the agenda for the weekly devchat meeting on July 11, 2018 at 20:00 UTC.

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!

What’s New in Gutenberg? (6th July)

This release generally completes our MVP feature set for the editor by adding inline images, block style variations, and a new columns approach. Switching focus to bugs, enhancements, compatibility, and API stability from now on. Worth noting that there’s people working on some more individual blocks (a few widgets and playlist) to be included when ready.

The most significant addition is block style variations. This will allow registration of alternate styles (based on class names) for any block, with automated real thumbnails and live previews built in to the block transformation tool. We have added them to the Quote, Button, and Separator blocks for illustration. The public API will be exposed in a future release.

Block Style Variations

3.2 🥚

All Updates

Labeling Issues in the Gutenberg Project

Hello! I will be working closely with Gutenberg for the next several months and am really pleased to be here!! My WordPress username is designsimply and I go by sheri on Slack.

Part of my work is centered around bug gardening where my goal is to scrub bugs to fit the project’s workflow in a way that saves everyone else time by adding screenshots, checking validity, closing inactives, and sane labeling. Labels are important for historical reference too, so any work here should prove useful as the project grows!

Labeling rules I tend to follow:

  • Each issue should have a focus area and type label.
  • Each PR should have a focus area and status label.
  • Priority labels should only be set as needed—just using high and low is 👍.
  • High priority issues should have an assignee or be in an active milestone.
  • Action-based labels start with “Needs”.

I’ve made a few small changes to labels so far:

  • Added [Type] Duplicate (for tracking and so dupes can easily be filtered out of searches).
  • Combined [Type] Support and [Type] How do I? and renamed to [Type] Help Request.

Have I mentioned I love labels?! Let’s update them together as an iterative process. Deciding labels can be opinionated so open discussions about them will be fun and help us work together in good ways.

My next questions about labels:

  1. Can we move Chrome and UI Components to something like Block Controls?
  2. Can we move [Type] Plugin / Theme Interoperability to [Type] Plugin Conflict and [Type] Theme Conflict?
  3. Should Won't Fix and Works For Me be [Type] labels?
  4. I’d love to add Design Notes label as a way to track design decisions.
  5. What is [Type] WP Core Bug for exactly?
  6. Should Text Mode be changed to Edit as HTML to match the UI?
  7. Can we get rid of [Status] Stale in favor of closing?
  8. Let’s use [Status] Needs More Info or close with a comment instead of Works For Me.
  9. Would it be useful for devs to add [Status] Revisit to issues that are not good to keep open now but may be good to look at again in the future?

If you’re keen to help with Gutenberg bug gardening or discuss the inner amazingnesses of labeling 😊, then I would love to talk with you! Please comment here or say hello in #core-editor on Slack.

Dev Chat Summary: July 4th (4.9.8 week 1) [updated]

Please note: the previously scheduled 4.9.7 is now referred to as 4.9.8, since 4.9.7 has been released by the security team.

This post summarizes the dev chat meeting from July 4th (agendaSlack archive).

@joemcgill @audrasjb, @antpb, and @Whitney are helping out with dev chats coordination while @jeffpaul is on holiday.

4.9.8 Details

@pbiron and @joshuawold will be serving as release leads during this cycle, with @sergey and @psykro handling deputy duties.

4.9.8 Release Main Schedule:

  • Beta: July 17, 2018
  • RC: July 24, 2018
  • Final Release: July 31, 2018

The schedule for the 4.9.8 bug scrubs will be:

  • Thursdays at 21:30 UTC
  • Mondays at 14;00 UTC

The hope is that with those two different times a good majority of interested parties will be able to join one or the other.

4.9.8 Main Focus:

  • Introduction of the Try Gutenberg callout #41316
  • Privacy fixes/enhancements

Of course, 4.9.8 won’t be limited to those, but they will be the primaries.

Updates from focus leads and component maintainers

Thanks to both teams for posting notes from their chats. Reminder to focus leads and component maintainers to try and publish meeting notes from your chats to help socialize what’s happening across the different parts here in WordPress Core.

Open floor

  • @davecpage brought ticket #38280 to find out if it’s possible to get into 4.9.8.
    This ticket needs a validation by a component maintainer to be included in the milestone, for example @boonebgorges.

Next meeting

The next meeting will take place on July 11, 2018 at 20:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

4.9.8 Schedule

Note: This release was originally announced as 4.9.7.  Due to the 4.9.7 Security and Maintenance Release that rolled out on July 5, 2018 this release will now be 4.9.8.

The primary focuses of the 4.9.8 release are:

  • Introduce the Try Gutenberg callout ( #41316)
  • Privacy fixes/enhancements

The following is the current 4.9.8 release schedule:

Important Dates

  • Beta: July 17, 2018
  • RC: July 24, 2018
  • Release: July, 31 2018

Bug Scrubs

All bug scrubs will take place in #core.

#4-9-8, #bug-scrub

JS docs initiative: Add inline-docs for JavaScript! (part 2)

Because of a restriction of wordpress.org, you cannot comment on posts older than 120 days. This new post can be used to track the work on Javascript inline-docs. The original post on the JS docs initiative can be found here. In this post I have excluded files that have already been completed.

At the bottom is a list of every first-party JavaScript file in core. Files with a checkmark have been patched and are considered completed. Files marked with (username #xxxxx) are already claimed, and being worked on.

Directly below is the process we’re using to make sure each of these files can get patched swiftly with no duplicated nor wasted efforts.

How to contribute

  1. Familiarize yourself with the JavaScript documentation standard, as well as the formatting guidelines and documenting tips.
  2. Check the list first to make sure the file you want to work on hasn’t already been claimed.
  3. Update your local WordPress SVN (use svn up) or Git repo (use git pull) to the latest version of WordPress trunk.
  4. Create a new ticket on Trac for the file.
    • Format the title as “JSDoc: path/to/file.js”.
    • The Type should be “defect (bug)”.
    • Assign the ticket to the component the file is associated with.
    • Leave the Version blank.
    • Add the docs and javascript focuses.
  5. Edit the file, and make a patch. Please make sure you create the patch from the root directory of your WordPress SVN or Git checkout.
  6. Upload your patch to the Trac ticket you created, and add the keyword “has-patch”.

We’d like to welcome everyone to start contributing inline documentation! You can start contributing by picking a file from the list of unclaimed files below and claiming it in the comments. Please also see the JS docs handbook page for a step by step guide on how to get started.

Note: Note: To give everyone a chance to claim a file and to ensure the work proceeds as quickly as possible, please only work on one file at a time.

Determining the since version

We use JSDoc’s @since tag to indicate when a particular function was added to WordPress core. When you are documenting a function, you will also need to identify when that function was first introduced.

The recommended tool to use when searching for the version something was added to WordPress is svn blame. An additional resource for hooks is the WordPress Hooks Database. If, after using these tools, the version number cannot be determined, use @since Unknown.

If you use the git repository of WordPress you can also use git to determine the @since version. Either use git blame or the GitHub blame function. Once you have the commit hash which introduced a piece of code you can find out the version by using git tag --contains [commit-hash]. This will list all versions a certain commit has been shipped in. The lowest version is then what you put after the @since annotation.

Note: Make sure that the commit you found it the actual commit where a piece of code was introduced. JavaScript files have been moved around a lot in the past, so make sure to take that into account.

Note: All @since tags should follow the three digit x.x.x format.

Keeping Discussions Focused:

Any discussion about the specifics of a patch itself should happen on Trac. Any discussion about the broader scope of what we’re trying to do should take place during the weekly devchat. That’s either #core-js or #core.

Files needing patches:

Checked files are completed, marked files are claimed

  • src/js/_enqueues/wp/customize/controls.js (@jjcomack)
  • src/js/_enqueues/wp/customize/nav-menus.js
  • src/js/_enqueues/wp/customize/widgets.js
  • src/js/_enqueues/lib/gallery.js (@hunkriyaz)
  • src/js/_enqueues/admin/link.js (@andg)
  • src/js/_enqueues/lib/nav-menu.js
  • src/js/_enqueues/admin/plugin-install.js
  • src/js/_enqueues/wp/revisions.js
  • src/js/_enqueues/admin/set-post-thumbnail.js
  • src/js/_enqueues/wp/svg-painter.js
  • src/js/_enqueues/wp/theme.js
  • src/js/_enqueues/wp/updates.js
  • src/js/_enqueues/admin/user-profile.js
  • src/js/_enqueues/admin/widgets.js
  • src/js/_enqueues/deprecated/fullscreen-stub.js
  • src/js/_enqueues/wp/customize/base.js
  • src/js/_enqueues/wp/customize/loader.js
  • src/js/_enqueues/wp/customize/models.js
  • src/js/_enqueues/wp/customize/preview-nav-menus.js
  • src/js/_enqueues/wp/customize/preview.js
  • src/js/_enqueues/wp/customize/selective-refresh.js
  • src/js/_enqueues/wp/customize/views.js
  • src/js/_enqueues/wp/mce-view.js
  • src/js/_enqueues/wp/media/audiovideo.js
  • src/js/_enqueues/wp/media/editor.js
  • src/js/_enqueues/wp/media/grid.js
  • src/js/_enqueues/wp/media/models.js
  • src/js/_enqueues/wp/media/views.js
  • src/js/media/controllers/audio-details.js
  • src/js/media/controllers/collection-add.js
  • src/js/media/controllers/collection-edit.js
  • src/js/media/controllers/edit-attachment-metadata.js
  • src/js/media/controllers/embed.js
  • src/js/media/controllers/featured-image.js
  • src/js/media/controllers/image-details.js
  • src/js/media/controllers/library.js
  • src/js/media/controllers/media-library.js
  • src/js/media/controllers/region.js
  • src/js/media/controllers/replace-image.js
  • src/js/media/controllers/site-icon-cropper.js
  • src/js/media/controllers/state-machine.js
  • src/js/media/controllers/state.js
  • src/js/media/controllers/video-details.js
  • src/js/media/models/attachment.js
  • src/js/media/models/post-image.js
  • src/js/media/models/post-media.js
  • src/js/media/models/query.js
  • src/js/media/models/selection.js
  • src/js/media/routers/manage.js
  • src/js/media/utils/selection-sync.js
  • src/js/media/views/attachment-compat.js
  • src/js/media/views/attachment-filters.js
  • src/js/media/views/attachment-filters/all.js
  • src/js/media/views/attachment-filters/date.js
  • src/js/media/views/attachment-filters/uploaded.js
  • src/js/media/views/attachment.js (@digitalarticle)
  • src/js/media/views/attachment/details-two-column.js
  • src/js/media/views/attachment/details.js (@maartenleenders)
  • src/js/media/views/attachment/edit-library.js
  • src/js/media/views/attachment/edit-selection.js
  • src/js/media/views/attachment/library.js
  • src/js/media/views/attachment/selection.js
  • src/js/media/views/attachments/browser.js
  • src/js/media/views/attachments/selection.js
  • src/js/media/views/audio-details.js
  • src/js/media/views/button-group.js
  • src/js/media/views/button.js
  • src/js/media/views/button/delete-selected-permanently.js
  • src/js/media/views/button/delete-selected.js
  • src/js/media/views/button/select-mode-toggle.js
  • src/js/media/views/cropper.js (@kapteinbluf)
  • src/js/media/views/edit-image-details.js
  • src/js/media/views/edit-image.js
  • src/js/media/views/embed.js
  • src/js/media/views/embed/image.js
  • src/js/media/views/embed/link.js
  • src/js/media/views/embed/url.js
  • src/js/media/views/focus-manager.js
  • src/js/media/views/frame.js
  • src/js/media/views/frame/audio-details.js
  • src/js/media/views/frame/edit-attachments.js
  • src/js/media/views/frame/image-details.js
  • src/js/media/views/frame/manage.js
  • src/js/media/views/frame/media-details.js
  • src/js/media/views/frame/post.js
  • src/js/media/views/frame/select.js
  • src/js/media/views/frame/video-details.js
  • src/js/media/views/iframe.js
  • src/js/media/views/image-details.js
  • src/js/media/views/label.js
  • src/js/media/views/media-details.js
  • src/js/media/views/media-frame.js
  • src/js/media/views/menu-item.js
  • src/js/media/views/menu.js
  • src/js/media/views/modal.js
  • src/js/media/views/priority-list.js
  • src/js/media/views/router-item.js
  • src/js/media/views/router.js
  • src/js/media/views/search.js
  • src/js/media/views/selection.js
  • src/js/media/views/settings.js
  • src/js/media/views/settings/attachment-display.js
  • src/js/media/views/settings/gallery.js
  • src/js/media/views/settings/playlist.js
  • src/js/media/views/sidebar.js
  • src/js/media/views/site-icon-cropper.js
  • src/js/media/views/site-icon-preview.js
  • src/js/media/views/toolbar.js
  • src/js/media/views/toolbar/embed.js
  • src/js/media/views/toolbar/select.js
  • src/js/media/views/uploader/editor.js
  • src/js/media/views/uploader/inline.js
  • src/js/media/views/uploader/status-error.js
  • src/js/media/views/uploader/status.js
  • src/js/media/views/uploader/window.js
  • src/js/media/views/video-details.js
  • src/js/media/views/view.js
  • src/js/_enqueues/lib/quicktags.js
  • src/js/_enqueues/wp/shortcode.js (@hanopcan)
  • src/js/_enqueues/lib/cookies.js
  • src/js/_enqueues/wp/a11y.js
  • src/js/_enqueues/lib/ajax-response.js
  • src/js/_enqueues/wp/api.js
  • src/js/_enqueues/lib/auth-check.js (@pskli)
  • src/js/_enqueues/wp/custom-header.js
  • src/js/_enqueues/lib/embed-template.js
  • src/js/_enqueues/wp/embed.js
  • src/js/_enqueues/wp/emoji.js (@igorsch, @nicollle)
  • src/js/_enqueues/lib/list-revisions.js
  • src/js/_enqueues/lib/lists.js
  • src/js/_enqueues/lib/pointer.js (@maartenleenders)
  • src/js/_enqueues/wp/util.js
  • src/js/_enqueues/lib/link.js

Current status:

Happy documenting!