Javascript Chat Summary – December 4, 2018

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Agenda: Holiday / WCUS scheduling

Slack Conversation

We agreed to cancel the #core-js meetings for December 11th (post-WCUS travel), December 25th (Christmas), and January 1st (New year). @aduth posted a cancellation notice here:

Agenda: Linting

Slack Conversation

A PR which extracts Gutenberg’s ESlint config to its own package by @gziolo has been merged. It’s set to be published to NPM as @wordpress/eslint-config. Publication is currently blocked by the 5.0 RC freeze, but is expected to land around contributor day together with a post outlining revisions to the JavaScript coding standards prepared by @aduth

We also discussed how to manage custom eslint rules. Some linting rules might not be useful outside of the context of WordPress core or Gutenberg. We decided for now to go the same path as the Jest eslint package. For the time being we will have one package with multiple configs, which will allow consumers to select the configs they need. 

Agenda: 5.0 Script Changes

Slack Conversation

With WordPress 5.0, a few vendor scripts (like lodash) are being included in core. For these scripts in particular, there is a chance for conflict if a plugin or theme registers their own copy of the dependency with the same un-prefixed name. There is a greater likelihood if there is a large version mismatch between the registered scripts.

Different approaches to prevent this were discussed. @aduth is working on a devnote to help integrators prevent these kinds of conflicts from happening.

#javascript, #meeting-notes #summary

JavaScript chat summary – November 20th

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack transcript).

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

We tried to keep the meeting succinct as many people are pushing out a Gutenberg release.

Correcting Package Global Names

Relevant context in a previous Slack discussion. Question: Should we “deprecate” wp.escapeHtml to wp.escapeHTMLwp.tokenList to wp.TokenList?

There was a bit of a back and forth whether this should be something that is addressed now. At the end we concluded to add this to the list to address in a 5.0.x release.

Npm packages publishing workflow

From last week, we discussed this very briefly to keep it in our mind space. Link to the relevant issue on the Lerna repository.

#chats, #javascript, #meeting-notes

REST API Team Meeting Notes, 2016-10-17

As a reminder, in just 30 minutes there is a meeting in #core to decide whether the REST API Content Endpoints will be merged as a part of WordPress 4.7! See the ongoing discussion of this proposal here. Note that the OAuth server is no longer proposed for merge at this time, but authentication options will be a primary focus area for the API project during the 4.8 development cycle.

The REST API Content Endpoints provide a new foundation upon which the WordPress developer community can build themes, plugins, and core feature. They represent a common standard and consistent interface across WordPress’s core content data types, and provide robust support for custom post types and meta values. These endpoints lay the foundation upon which future releases will add remote authentication options, even deeper querying abilities, and broader endpoint coverage for site management. This iterative approach fits WordPress’s development model and philosophy, advancing the project’s long-term goal of opening WordPress up to a wider developer audience and helping to ensure continued work on the REST API in the release cycles and years to come.

Meeting Notes

At today’s weekly API team meeting in core-restapi (agenda here) the team resolved all outstanding decisions milestoned for the REST API 2.0 / WordPress 4.7 merge candidate:

  • The ?filter query parameter will be removed from the REST API plugin prior to core merge, a breaking change that improves the consistency of querying the API and eliminates a set of parameters that could introduce backwards compatibility issues were they to be committed to WordPress core. A separate plugin will be published to reinstate the `filter` parameter on a strictly opt-in basis.
  • Comments on password-protected posts are being deferred as a future enhancement until a robust solution is proposed that permits the API to adequately mirror existing functionality.
  • The unfiltered_html capability should be respected by the API, and a patch will be submitted to bring the API’s behavior in line with core’s.

There are 29 tickets left in the 2.0 milestone, several of which have open pull requests already. These issues represent a mix of outstanding bugs, documentation needs and improvements that will be moved to trac should the merge proposal be accepted.

The REST API team leads would like to recognize that the content endpoints plugin now has 95 contributors: thank you and welcome to all of the new participants who have joined the project in the past week!

#4-7, #meeting-notes, #rest-api

Core Dev chat notes for Feb 17


Schedule Notes, Status Updates, Open Floor

Schedule Notes

  • Today is the feature plugin merge deadline!
  • Customizer Responsive Preview was merged. Thanks to everyone who helped out there!
  • The first beta is scheduled for release next week! This means that any remaining features/enhancements need to land before then.
  • @chriscct7 has been leading daily scrubs of these tickets; ticket owners should post an updates on the ticket status.

Status Updates

  • Image Improvements: @joemcgill
    • Improving the performance of wp_uploads_dir() (#34359). @azaozz committed this and left the ticket open for possible function name changes or additional tests.
    • PDF Thumbnails (#31050) are close. Creates a thumbnail version of uploaded PDFs. Feedback would be welcome, particularly from UI focused folks and around how the PDF thumbs’ meta is stored. This needs careful consideration as it would be a model for any other thumbnails for non-image types. The intent for this release is to improve the editor experience a bit, which the thumbnails would achieve.
    • Improving default image compression (#33642): Looks like we should be able to reduce the default compression quality and see big improvements in file sizes without a perceptible loss in image quality. Look for a blog post requesting feedback later this week to make sure core is ok with changing the default quality for intermediate sizes.
  • Customizer: @westonruter, @celloexpressions
    • Published a post on Make Core that detailed Selective Refresh in the Customizer. Hoping to get feedback on the implementation for nav menus and widget, on the framework for theme/plugin authors to register their own partials for selective refresh, and also for a general code audit for security and docs. In the process right now of creating that core patch and will attach to the ticket #27355. I’m also in the middle of writing unit tests, but help there would be appreciated.
  • Multisite/WP_Site: @jeremyfelt
    • No big updates. Started making progress on a few tickets today. Nothing negative or breaking with the new `WP_Site`, though we’ll continue to keep testing and looking for ways to improve. @spacedmonkey has also submitted a ticket for `WP_Site_Query` which will be fun.
  • Editor: @azaozz, @iseulde
    • Thinking and testing if the inline link dialog should have two fields, URL and link text, like the modal. Seems the more streamlined version with just the URL is better.
    • Another change that’s coming is to add autocomplete to the modal instead of the infinite scroll at the bottom. That gives plugins some more space to add additional “advanced” settings and simplifies it/makes it consistent with the inline dialog.

Open Floor

  • @mike Wanted to discuss Theme Logo Support (#33755).  @obenland was kind enough to do a port of the feature from Jetpack, and there’s been good conversation happening on the ticket. It needs testing. Can be tested with Twentysixteen and a patch and with any theme that supports Jetpack site logos. Needs work on this suggestion.
  • @ocean90 raised Unifying permission error messages (#34521). Right now we use a variety of  language for error messages and this ticket is about unifying and clarifying that language. @ocean90 asked for opinions about the best language to inform users they are not allowed to perform some action. Extensive discussion ensued and Sorry, you are not allowed to… seemed to be the top choice.

Full meeting log available in Slack.


#4-5, #dev-chat, #meeting-notes

Core Dev chat notes for Feb 10


Schedule Notes, Status Updates, Open Floor

Schedule Notes

  • Today is the feature plugin decision deadline: Responsive Preview and Selective Refresh will be merged.
  • Next Wednesday (Feb 17) is the deadline for merge for these, with beta scheduled for the week after, on Feb 24.
  • Reminder: once beta ships, no more enhancements can be committed, so anything that is left or close to finished needs to be shored up in the next two weeks. Enhancements mile-stoned for 4.5 need attention to make it into the release in time.
  • Any help triaging the 4.5 milestone is definitely appreciated.
  • The REST API team’s proposal is to merge the four main endpoints when they are ready, and they are not ready for 4.5. As such, no endpoints are targeted for WordPress 4.5. A summary of last week’s chat is on make/core: leave feedback there or in the #core-restapi Slack channel.

Status Updates:

  • Image Improvements: @joemcgill
    •  Cache output of `wp_upload_dir()` to improve performance (#34359) is about ready to go in after some unit test updates )
    • Making progress on Improving Imagick file sizes (#33642) and Better animated GIF handling (#28474)
    • @markoheijnen made some interesting progress on generating thumbnails of PDFs in the media library and could use some feedback if you’re interested #31050.
  • HTTPS Improvements: @johnbillion
    • Plan is enforcing HTTPS on a per-feature basis (eg. enqueued assets, post content, redirects, canonical, links).
    • HTTPS-by-default on install will be something to aim for for 4.6, but we’ll see what happens over this next week.
  • Customizer: @westonruter, @celloexpressions
    • Pushed out the new version of the Customize Partial Refresh plugin. Needs testing!
    • Introduces a framework for registering partials (refreshable regions) with complete rewrites of nav menu partial refresh and re-implementation of widget partial refresh to use the new framework.
    • Going to write a Make Core post about it, documenting the API.
    • Biggest question is whether widgets should opt-in for selective refresh by default. Widgets that use JavaScript for their display will need get updated to work with selective refresh.
    • Responsive Preview (#31995) @valendesigns:  need to add unit tests and address any remaining issues
  • Multisite/WP_Site: @jeremyfelt
    • 15 tickets on the 4.5 milestone. Hoping to establish readiness for these over the next week and get some stuff in.
    • Going to start focusing more multisite related energy toward the REST API’s site (and meta) endpoints.
  • Editor: @azaozz, @iseulde
    • No updates this week: planning to get paste shortcuts in and work on mce views.

Open Floor

#4-5, #dev-chat, #meeting-notes

REST API meeting summary, Feb 4

The core REST API team, members of the API team, and other interested developers met to discuss the REST API.  Full logs of the meeting are available on Slack.

Existing endpoints

The meeting opened with a discussion of the existing endpoints: what is and isn’t ready. @rmccue summarized:

  • The main focus has been on the 4 “core” objects in WordPress: posts, terms, comments, and users.
  • Posts
    • Password-protected posts are going to be ignored from the API until we have a good solution.
    • Meta
      • Post (and other) meta has been pushed out into a separate feature plugin led by @jeremyfelt. Discussion is on the github repo.
      • The main issue is that there’s no differentiation between meta fields. Meta could be added via the Custom Fields meta box, or by a plugin.
      • Enhancing register_meta() in core would allow opt-in to the meta REST API – requiring some core work. See the patch on #35658 for details.
      • There is no current way to explicitly register meta as public.
      • We need to support object meta (post, user, comment, term) and object types (custom post types, etc)
    • Media
      • Mostly complete (it’s a custom post type).
      • Some special handling around uploading media.
    • Autosaves and post previews
      • Tricky, but we think we have a solution for that moving forward.
      • Working on them in a separate feature plugin instead.
      • This will be an enhancement to the API in the future, and doesn’t block compatibility.
  • Terms
    • Work great.
  • Users
    • Works great; undergoing final review.
  • Comments
    • Works; custom comment types are harder until core better supports them.

Merge proposal and discussion

An extensive discussion ensued regarding the possibility and appropriateness of merging the endpoints into core. The discussion continued for over an hour; mainly covering whether we should merge the 4 core endpoints, or wait for a complete API before merging…  and what the definition of a complete API is.

The REST API team’s proposal is that we merge the 4 core objects in the REST API with full read, create, update, delete support, then add more peripheral features when they’re ready. 

@matt argued that we wait until the API supports everything you can do in wp-admin before merging.

The discussion revolved around these proposals and what is best for the WordPress project. Would merging the existing well developed endpoints sooner help or hinder developer adoption, and further iteration/improvement? Would delaying the endpoint merge help or hinder progress?

Here are some key comments from the discussion.

  • @rmccue  The approach to the API needs to change from “the API team creates all of the API” to “the API team controls the general shape of the API, and each team works with it”
  • @danielbachhuber Options / a Site Resource is more easily viable, as are Plugins and Themes. Widgets and Menus essentially need to be reinvented before they’ll work in a REST API
  • @jnylen It’s a question of when, and how much testing can be done first. Shipping an API that is read-only and incomplete in several key areas feels like a big mistake.
  • @kadamwhite we’re shipping an API with write capabilities but only cookie-based auth will be supported OOTB.
  • @matt  I would be pretty skeptical of merging a partial API into core…  no partial endpoints in core. let’s design a complete API, not half-do it.
  • @rmccue The API is specifically structured around progressive enhancement
  • @jorbin I think only supporting the four core object types allows for some amazing themes and amazing content editors to be created, but doesn’t allow for full wp-admin replacements. I’m ok with that.
  • @jnylen From what I’ve seen so far, I’m most concerned about shipping individual endpoints with missing features.
  • @jorbin I think the best way to pick up the pace is to get key things locked up and get the four core object types in core. This would help core develop API-first for those features
  • @codebykat On the WPCOM side, we’re committed to taking the plunge, but we’re not there yet which means things are untested.
  • @jnylen I think this needs more testing at large scale before shipping, including some of the more difficult and obscure features of WP.
  • @drew Shipping with full wp-admin replacement capability is unrealistic, imo. We need something flexible and stable that developers can use as solid jumping off point. All the rest can get separately iterated.
  • @mike I think that, realistically, to ship the API… we need an MVP, and I don’t think that defining our goalpost as “all of wp-admin” fits that criteria.
  • @matt Full wp-admin coverage is a firm goalpost, it gives us a super clear criteria for when it should be merged into core. is everything possible in wp-admin, possible through the API?

#meeting-notes, #rest-api

Core Dev chat notes for Feb 3


  • @danielbachhuber announced a WP REST API meeting, happening tomorrow in #core-restapi on Slack: Thursday, February 4, 2016, 11:00 PM GMT. Full details are posted on the make/core blog.
  • A reminder that the feature plugin decision deadline is coming up next week, Feb 10th.
  • For the “Field Guide” posts, @jorbin proposed organizing around “focuses” and called on any feature plugins that get merged to make a post highlighting the following: anything with potential to break backwards compatibility along with significant new classes, functions, and hooks that you expect plugin, theme, and site developers to use. The goal is to have everything published before beta2.

Feature Plugin Updates

  • Customizer Device Preview: @celloexpressions
    • Very close. Has UI/UX approval, a11y approval.
    • Waiting for fixes after dev review and security audit.
    • Consensus is that, pending the above, it is approved to merge in 4.5.
    • See #31195 and the related make post.
  • Application Passwords: @georgestephanis
    • Application passwords got split off from two factor auth, so we’re only talking about application passwords (Two-Factor is not dead, and will come back at a later date)
    • Lets you use an application password for XMLRPC and the REST API, instead of your normal password or oAuth 1.
    • Questions and discussion around whether there is a large enough use case to make this a core feature. Consensus is that at this point, it doesn’t benefit enough end users to warrant inclusion, but might after or when the REST API endpoints land in core.

Focus Status Updates

  • Customizer: @westonruter, @celloexpressions
    • Customizer Pane Resize (#32296): Stalled.
    • Selective Refresh (#27355): Getting very close.
      • Selective refresh works well together with postMessage JS-updates, as the JS update can apply an immediate (approximate) preview while the Ajax request is being made to get the actual rendered content
      • Selective refresh `partials` have associated selectors and settings, so shift-clicking on any of the containers will focus on the corresponding control in the pane.
    • Customizer notification area (#35210): Needs help!
      • In progress, but an initial patch based on available mockups is needed here.
      • This is a dependency for the setting validation model (#34893) and creating page stubs via nav menus (#34923).
    • Transactions (#30937): Punting due to dependency on the REST API and on selective refresh.
  • Image Improvements: @joemcgill
    • Main focus on improving the default Imagick compression settings, some progress this week identifying the main hurdles there.
    • Could use additional opinions on #28474 (animated gif resizing) and whether it’s worth pursuing.
    • Could use some additional eyes on #34359 (particularly on multisite installs)
    • Weekly meeting is Friday at 20:00 UTC.
  • Multisite/WP_Site: @jeremyfelt
    • WP_Site is in with only minor issues surfacing.
    • Considering a `sites` endpoint for the REST API – primary use right now would be to refactor the My Sites menu.
    • A new repository for the site(s) endpoint has been set up on github.
    • Some renewed interest in a network settings API (or expanding the settings API to include networks)
    • Make/core post coming soon.
  • Editor: @azaozz, @iseulde
    • Going through and fixing edge cases for the inline link dialog. Please test!
    • Next will be the extending of “editing shortcuts”.

View the full logs on Slack.

#4-5, #dev-chat, #meeting-notes

Core Dev chat notes for Jan 27


  • Extending the Feature Plugin decision and merge deadline by one week, taking them to Feb 10 and 17, respectively. This does not affect the rest of the release schedule, and betas, RC, and release are all the same dates. This gives feature plugins a little more time to have necessary discussions.
  • @ebinnion has graciously continued with the week in core post, and @rockwell15 volunteered to lend a hand.  If you like these posts, please help!  Many hand make light work.
  • @dd32, @jorbin and a few others are working on finishing up 4.4.2. Ticket owners should review the list of tickets tagged for the release.

Focus Status Updates

  • Customizer: @westonruter, @celloexpressions
    • Posted a recent status update here on the make/core blog.
    • Customize Device Preview is up and ready for testing #31195, with a make/core post coming shortly.
    • Assistance requested with the Customizer Pane Resize plugin #32296.
    • Some movement on adding a notification area to Customizer #35210, with the need for an initial workup – help needed.
  • HTTPS Improvements: @johnbillion
    • Focusing on avoiding mixed content on https sites – a working http site is much preferable to an https site full of mixed content.
    • Working on a feature plugin which implements various granular controls over forcing HTTPS on a site: forcing enqueued assets to https, rewriting URLs in content on the fly to force their scheme to https, forcing redirects to the https version of the site, etc. Individual options with the ability to enforce the lot.
    • Adding a GitHub repo where this will be worked on and also posting a summary to make/core soon.
  • Image Improvements: @joemcgill
    • Good conversation last week about displaying responsive images in the editor.
    • Team could use help with profiling to Improve default Imagick compression settings #33642.
    • The old #feature-respimg channel has been renamed #core-images to be a place to talk about images in any/all capacities.
    • Weekly meeting is Friday at 20:00 UTC.
  • Editor: @azaozz, @iseulde
    • The inline link dialog is in. Please test! #33301
    • Looking into wpviews soon (Using the TinyMCE API).
    • Also looking at improving the shortcuts soon.
    • Could use help investigating using the image editing tools from TinyMCE for the media library.

Open Floor

  • @veraxus brought up #16031 and the inability of handle new bulk actions in a non-hacky way (you can add the actions in the list, but not handle the action). Is it worth the effort to rework the patch? Will the core team support it?

View the full logs on Slack.

#4-5, #dev-chat, #meeting-notes

Core Dev Chat Notes for Jan 20


Focus Status Updates

  • Customizer: @westonruter, @celloexpressions
    • Good progress has happened for selective refresh, with good feedback and an architectural direction #27355.
    • A responsive preview feature has been getting good feedback and is nearing a committable patch #31195.
    • Update make/core post coming soon.
  • HTTPS Improvements: @johnbillion
    • Nothing specific to report about the HTTPS work, there will be a meeting next week about ‘force ssl’ which he will post about in make/core tomorrow morning for those who want to get involved.
  • Image Improvements: @joemcgill
    • Improving Imagick compression settings #33642 is still a priority.
    • Looking into options for #28474 (better animated GIF handling).
    • Longer term effort: what can be done to improve some of the core API for working with images
  • Multisite/WP_Site: @jeremyfelt
    • Several things assigned to the 4.5 milestone
    • A reorg of filters for network allowed themes went in today.
    • Working at the latest <code>WP_Site</code> patch now with the intent of putting it in today or tomorrow.
    • Office hours on Tuesdays at 21:00 UTC in #core-multisite; bring your bugs.
  • Post New: @michaelarestad
    • @karmatosed is going to be leading a team focused on improving the Revisions UI
    • @hugobaeta is going to be leading the Toolbar Remix team
    • @michaelarestad working on improving the Publishing UX and Metaboxes
    • @michaelarestad made a Sketch template for wp-admin that’s accurate and will be published later this week.
    • Update posts coming soon
    • Join the effort: comment on the original post and join the Slack #design channel.
  • Editor: @azaozz, @iseulde

Open Floor

  • @ipstenu brought up #35429; @michaelarestad going to review from UX perspective, discussion
  • @azaozz brought up inline link dialog autocomplete, extend suggest.js or use another library (typeahead, select2)? what is the use case? discussion in #core-editor. @sheri offered to help with user testing to determine the best UX.
  • Meeting ended, ticket conversation continued…

View the full logs on Slack.

#4-5, #dev-chat, #meeting-notes

Core Dev Chat Notes for Jan 13

Plugin Chat

  • Chat meeting notes posted on make/core.
  • Another feature plugin chat will be scheduled before the feature plugin decision deadline which is Feb. 3rd.

Week in Core

  • These are very popular and much appreciated updates.
  • @morganestes has done a great job with them; we need more volunteers!
  • @ebinnion and @grantpalin volunteered to take on these updates; The crowd reacted wildly!

Focus Status Check

  • HTTPS Improvements: @johnbillion
    • Continue with HTTPS fixes, including edge cases, mixed content
    • Help fix sites that use a mixture of HTTP and HTTPS (for example, HTTPS for the admin area)
    • Introduce a means of forcing a site to use HTTPS exclusively
    • Attempt to default to HTTPS for new installs where it’s supported
  • Image Improvements: @joemcgill
    • Some bug fixing from 4.4 implementation
    • Picking up work on #33642 – improving compression of images
    • Start working thru code cleanup in images
    • @azaozz mentioned the longer term goal of changing image handling overall
  • Post New: @michaelarestad
    • Project ideas posted on the make blog.  Many ideas here; some will take longer than a single release cycle.
    • Comment there to express interest in working on any of the items.
  • Editor: @azaozz, @iseulde
    • Inline wplink dialog.
    • Improved wpView/blocks inside the editor using the recently introduced TinyMCE API.
    • Few more “editing shortcuts” like backticks for <code> and triple backticks for <pre><code>.
    • Thinking about how to integrate TineMCE’s image manipulation module.
    • Will post a “wishlist” for 4.5 by the end of the week.

Open Floor

  • Comments update from @rachelbaker: 8 open tickets right now slated for 4.5. Highlights
    • #4332 – a 9+ year old Trac ticket that @wonderboymusic made some progress on in 4.4. I refreshed the patch yesterday, but it still needs i18n and developer feedback.
    • #34133 has some great UX feedback/discussion from @melchoyce @karmatosed and @afercia. Improves Moderate Comments screen. Feedback requested.
    • #33717 ( Notification Email When a Comment is Approved ) has an updated patch and @swisspidy is looking for some feedback.
  • Notifications API update from @johnbillion:
    • Would like to replace wp_mail() with an extensible notifications API, which sends emails by default but can easily be hooked in to send notifications via any other means, such as webhooks that enable Slack/IM/push notifications, etc. Optional admin UI for users and admins to opt in/out of individual notifications and notification types. Will post to make/core shortly.

View the full logs on Slack.

#4-5, #meeting-notes