Editor chat summary: May 8

This post summarizes the weekly Editor meeting on Wednesday, 8th May 2019, 13:00 UTC held in Slack.

The agenda followed can be found here.

Volunteers for Note-Taking Requested

As there are not very many folks who are taking notes for the chat at the moment, volunteers were requested. @nosolosw, @andraganescu, and @jorgefilipecosta offered to help out.

WordPress 5.2

WordPress 5.2 was released! Thanks to everyone who helped!

@youknowriad noted that he wasn’t sure why all of these things weren’t highlighted in the release post, but updates include:

  • No more TinyMCE in blocks
  • Block Management UI
  • Performance more than doubled in async mode
  • All widgets ported to blocks
  • A lot of improvements to existing blocks (cover block with inner blocks, focal point picker,…)
  • Stability improvements
  • Zero-config scripts to help authors create blocks

Accessibility Audit

The accessibility audit has been published. This is a great resource to improve the accessibility of the editor. Thank you to everyone that worked on it!

@andraganescu, @karmatosed, and @mapk attended the Accessibility chat to collaborate (recap was posted on the agenda post).

Design has done two triage sessions focused on the report (the next is on Friday, May 10, 2019 at 14:00 UTC), and development has already started in fixing some of the issues found.

The project board can be found here, and issues are also being grouped into labels (like [a11y] Keyboard & Focus). There’s interest in solving all validated issues that were found.

Several folks expressed interest in an a11y focused WordPress release, with the note that it would need to be a broader conversation with core + leadership.

@bemdesign mentioned, and others agreed, that while automation can help, a11y should ultimately be built into the process. Tenon, the company that ran the audit, provided documentation on how they tested.

Some recommended next steps included:

  • Aim for closing the project board by the end of May
  • Focus all triages until that can happen
  • Consider adding a column for deeper conversations / focuses and make issues for those
  • Dev-triage session focused on the board next week (Monday)
  • If you’re looking for an issue to tackle, take a look at this board first 🙂

Task Coordination

Note: Anyone reading this summary outside of the meeting, please drop a comment if you can/want to help with something.

Open Floor

@karmatosed asked if anyone would be interested in working with them on more detailed RC notes to be included in calls for testing.

@aduth raised a question about merge permissions.
“Is there a good sense of criteria for this to be granted? Or similar to core committer status, at discretion of leadership?”

Folks present seemed to be in consensus that this should be clarified, even if it’s only in terms of documenting general expectations.

Recommendations on criteria often included a number of contributions (committed PRs or other activities), ranging from 3-10 — with a note from @gziolo that Gatsby automatically adds access after one.

In closing, a quote from @andraganescu, “The thing with merge access is that as long as we have the triage/review/automated testing process the only thing you need is to prove some kind of good faith I guess”

Have thoughts on the above? Please leave a comment on this post!

The agenda for the next meeting, on 15 May 2019 at 13:00 UTC, is here; please add anything that you want to discuss.

#accessibility, #core-editor, #editor, #gutenberg, #meeting-notes

JavaScript chat summary, March 26th, 2019

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: Building JavaScript

Slack Conversation

A post was published on the core Make blog titled Building JavaScript. It explains how to set up an ESNext development environment using the new WordPress scripts package. This provides an easy and standard method for building blocks and JavaScript heavy plugins.

The discussion continued towards a potential followup task: to offer a scaffolding package that would help to create your first block. This could then in turn be utilized by the wp scaffold command in WP CLI, to allow scaffolding blocks directly with WP CLI. The discussion continues on Github here: https://github.com/WordPress/gutenberg/issues/10629.

Agenda: Coding Guidelines

Slack Conversation

Coding guideline changes have been proposed for CSS naming and Experimental / Unstable JS API’s in Gutenberg. Feedback is welcome!

Agenda: Gutenberg Playground

Slack Conversation

A standalone Gutenberg playground environment has been merged. As we’re expanding the usage of Gutenberg outside of edit-post and also talking about cross-CMS usage and external usage (in the broad sense), we need a way to run the block editor in a context independent from WordPress Admin.

The playground allows us to test Gutenberg as a standalone editor. For example, we can use it to test that our components don’t rely on WP Admin styles to be present, that core blocks can be used without necessarily requiring a post object.

This is only a first step. The playground could evolve to contain examples of reusable components, and it could also serve as a contributor-tool to help developers discover API’s.

#core-js, #corejs, #javascript, #meeting-notes

JavaScript chat summary, February 19th, 2019

Below is a summary of this week’s JavaScript chat (agenda, Slack Transcript). Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Agenda: NPM Mono-Repo Subdirectory Declaration

https://github.com/npm/rfcs/blob/latest/implemented/0010-monorepo-subdirectory-declaration.md

@adamsilverstein quoted @aduth‘s note that we should consider implementing the npm monorepo declaration in the WordPress npm packages.

@aduth added that implementing this declaration would be a straightforward task that would help make npm more “aware” of where to find the specific source for a package in a mono-repository, hopefully improving links.

The idea was well received.

@aduth has created issues related to this task:

Feel free to share your thoughts and provide feedback related to this subject in the issues.

Agenda: Feature Flags

https://github.com/WordPress/gutenberg/pull/13324

Feature flags were merged in the Gutenberg repository. Quoting @gziolo:

feature flags in Gutenberg, it’s very simple approach which will allow us to enable new features only for the plugin while keep it completely removed from WordPress core using dead code elimination.

We went into more detail of what feature flags are and what they allow.

@atimmer noted that most commonly feature flags allow to enable or disable specific features while Gutenberg feature flags apply to a whole set of features e.g.: “phase 2 features”.

@aduth referred that the reason behind this decision may be related at least partly to the objective of simplifying dead code removal.
More information can be found at https://github.com/WordPress/gutenberg/pull/13324.

@adamsilverstein shared that he wants to introduce a feature in the hooks package whose code should only be included when the SCRIPT_DEBUG flag is set. Any feedback to this is welcome and can be provided in https://github.com/WordPress/gutenberg/pull/12038.

During the discussions, it was referred that, although dead code removal is a common and used by famous libraries like React, there are no good resource/references available online to help developers understand how dead code removal works.
If you know any good resource feel free to share the link in the comments or the core-js channel.

Agenda: Build support for wordpress/scripts

Relevant PR’s:

According to @gziolo both PR’s are almost ready, but they need additional testing given the complexity of running the scripts with default configuration in various external projects.

@adamsilverstein noted that webpack setup is a significant barrier to entry for new developers and the more we can improve our tools the better.

@gziolo referred that a tutorial was already created and it will be simplified after latest changes are published.

Open floor

@nerrad referred that he would like to use the new version of React, more specifically React hooks, and asked when a React upgrade should be considered and when a WordPress release will contain the next version of React.

Answering to @nerrad, @aduth noted that upgrading React should be a non-issue although we may need some scrutiny on what is exposed. Regarding the WordPress releases, @aduth expects that anything merged to Gutenberg repository between now and mid-March should be part of the WordPress 5.2 release, but this specific subject will be clarified during the next #core-editor meeting https://make.wordpress.org/core/2019/02/19/editor-chat-agenda-february-20th/.

@nosolosw announced that in the past days the first auto-generated API documentation was merged to the Gutenberg repository: https://github.com/WordPress/gutenberg/pull/13856.
The tool that autogenerated the documentation is proposed in https://github.com/WordPress/gutenberg/pull/13329.
The next package/component that will be used as a testbed for the tool is not yet decided and every suggestion is welcome.

#core-js, #javascript, #meeting-notes

REST API Chat Summaries: Jan 31, Feb 7

This post summarizes the weekly REST API chat meetings on January 31, 2019 and February 7, 2019. (agenda/notes, Jan 31 Slack transcript, Feb 7 Slack transcript). Weekly REST API component office hours are held every Thursday at 18:00 UTC in the #core-restapi room in the Make WordPress Slack.

February 14 meeting agenda

Have a topic for discussion for today’s meeting on February 14 2019 18:00 UTC? Leave a suggested edit on the agenda document.

5.1: Dev Note needs?

  • The new rest_post_search_query filter could be called out in Other Changes.
  • changeset 44625 (update wp_die() to handle JSON contexts) could also be called out in Other Changes.

5.2 Tickets: Owners Needed

Gutenberg Widgets Endpoint

  • WordPress/gutenberg#13511: POC for a legacy widget block. @jorgefilipecosta requests input from REST API contributors.
    • Feedback provided around endpoint structure and parameter access
    • @kadamwhite proposes that user stories or use-cases for how these widgets will be consumed and displayed in the editor and rendered posts should be written for new endpoints, to inform implementation.

Authentication

  • All present agree we have a strong need for a core authentication solution. Existing plugins like the OAuth2 or JWT-Auth plugins work and are used on numerous sites, but need UX improvements and more documentation / example clients to be truly broadly applicable. OAuth2 in particular is seen as too complex / difficult to implement as a client developer.
  • Discussion on core auth since WCUS has centered on supporting basic authentication (only over SSL) (#42790), as the simplest path forward.
    • The main weakness of basic auth is that it ties all authorized applications to the user’s account name and password, so apps cannot be individually authorized or disconnected without creating new site accounts (not workable for e.g. the core mobile applications).
  • @koke thinks a JWT-based solution could be workable from the mobile applications.
  • The way CGI environments mutate authorization headers complicates any core-wide solution. A custom header may be necessary.
  • @espellcaste has volunteered to reach out to authors of existing plugin directory REST API auth solutions to get their input on what is best for core.

Upcoming Meetings

What can the REST API do for you? Join an upcoming meeting to help shape the future of this component!

#core-restapi, #meeting-notes, #rest-api

JavaScript chat summary, February 5th, 2019

Below is a summary of the discussion from last week’s JavaScript chat (agendaSlack Transcript) Please excuse the delay!

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

Agenda: Changelogs

Slack Conversation

In a previous discussion a need surfaced to improve Semver for JS packages and better understand the changes we are syncing into WordPress core when we update the JS packages. For this, better changelogs are needed. @aduth has been working on a PR to enforce better changelog management. It explores adding a pre-commit githook which verifies that the contents of the pending commit include a CHANGELOG.md revision if applicable.

Some concerns were raised about the potential unwanted friction a githook could give and false positives that could occur when ie. committing typo fixes. A possible alternative is to make the check part of the Travis build for PR’s. On the other hand, the direct feedback gotten through the githook contains higher educational value and minimizes loss of context.

We agreed the current githook proposal was worth exploring further in order to see if false positives can be prevented.

Agenda: Code owners

Slack Conversation

A pull request which adds an initial implementation of a CODEOWNERS file in Gutenberg was merged.

You can use a CODEOWNERS file to define individuals or teams that are responsible for code in a repository.

Github Help

Contributors are invited to PR the file if they feel they would like to be added as a code owner for specific paths in the Gutenberg repository. When accepted, they will receive pull request notifications and review requests for these parts of the codebase.

The main goal is to alleviate some review pressure for the Gutenberg team and help distribute notifications and help requests better over more contributors. It was argued it could be good to have some guidelines for approving / merging PRs in order to allow new contributors and code owners to review with more confidence. The use is expected to further evolve and be evaluated in the coming weeks.

Agenda: Registry selectors

Slack Conversation

For a while now we’ve had the option to register multiple stores across multiple registries using the core/data package. But how can we create selectors which derive data across multiple stores / registries? A PR to tackle selecting data over multiple stores has been created by @youknowriad. Input and feedback is requested.

An effort that depends on this is a PR which tries to make the editor module more generic so it can be reused outside of WordPress. We need to be able to respect backwards-compatibility while moving selectors and action dispatchers from one module to another. See also: https://github.com/WordPress/gutenberg/pull/13088

Open floor: React hooks

Slack Conversation

React hooks has been included in the latest release of React. There is a PR on Gutenberg which explores the possible advantages of this new API: https://github.com/WordPress/gutenberg/pull/11161. Since Gutenberg relies heavily on React, it could be worthwile checking out the API and the ways it could be leveraged in Gutenberg.

#core-js, #javascript, #meeting-notes

REST API Chat Summary: January 24, 2019

This post summarizes the weekly REST API chat meeting on January 24, 2019. (agenda/notes, Slack transcript). Weekly REST API component office hours are held every Thursday at 18:00 UTC in the #core-restapi room in the Make WordPress Slack.

Have a topic for discussion for the next meeting on January 31, 2019 18:00 UTC? Leave a suggested edit on next week’s agenda.

5.1 Tasks

  • One open Docs task: #45486 needs review (PHPDoc)
  • Awaiting Review ticket list needs triage & grooming but nothing currently stands out as a 5.1 priority

Tickets Awaiting Review

  • @desrosj to lead a bug scrub for this list next week, on Tuesday January 29, 18:00 UTC
  • As time permits prior to Tuesday, contributors may review that list and assign the Future Release milestone to any valid issues to show they have been triaged

5.2 Priorities

  • 6 tickets currently milestoned for 5.2. @desrosj proposes that every ticket assigned to a numbered release have an assigned owner.
  • Milestoned Tickets needing owner or review:
    • #41305 – Lazy String Evaluation: assigned to @timothybjacobs to investigate invalidating cache when locale changes within a request lifecycle
    • #39953 – Avoid updating date when modifying a “date floating” post (Related to #44975): needs owner
    • #44983 – Needs review
    • #45611 – Needs patch update to remove unused method

Gutenberg Priorities

  • content.rendered is not used by Gutenberg, and filtering the content for a large post slows down the editor load speed. @aduth suggests extending ?_fields= support to permit “deep” filtering, which the posts controller could then use to skip filtering post content where not needed, and raised the issue last week in the REST API component channel.
  • Delivering on this performance improvement within the block editor is architecturally complex, but implementing the nested _fields handling is tracked in #42094 and that ticket is now milestoned for 5.2 to lay the necessary groundwork.

Upcoming Meetings

What can the REST API do for you? Join an upcoming meeting to let the component team know!

#meeting-notes, #rest-api

JavaScript chat summary, January 22nd, 2019

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: NPM Scripts

Slack Conversation

A few new commands have been proposed for addition to the @wordpress/scripts module:

  • build and start: https://github.com/WordPress/gutenberg/pull/12837
  • format: https://github.com/WordPress/gutenberg/pull/13394

The discussion around build and start focused mostly on the question how to approach default configuration for plugins and themes. We’re considering to extract parts of the Webpack config as npm package to simplify setup for plugin developers. This would also allow to provide a default config for @wordpress/scripts and proposed scripts. To provide flexibility, it was raised that an eventual Webpack config package could have 3 types of exports:

  • A full webpack config with a simple preset entries map for simple starter plugins ( front.js, admin.js, blocks.js or something like that ) to provide a simple zero-config option
  • A function that takes an entries map and outputs the full webpack config with recommended values.
  • Each part of the recommended config as their own keys.

The discussion provided good input for further iteration. Next, progress was shared on the format command, which aims to provide autoformatting functionality using Prettier and Eslint autofixers. It is still in an experimental state, but would provide a powerful tool for developers to more easily adhere to coding standards.

Agenda: Linting

Slack Conversation

We discussed the lack of ES2015+ rules in the WordPress JavaScript coding standards. A pull request was proposed on Gutenberg which makes using Object shorthand notation required for Gutenberg JavaScript. We agreed this was a desirable standard to have for ES2015+ code. For now, we decided to include the rule in the Gutenberg coding guidelines until a formal proposal to include ES2015+ rules in the WordPress JavaScript coding standards is drafted.

Agenda: E2E tests in core

Slack Conversation

Progress is being made on making Gutenberg’s e2e test functionality reusable for WordPress core and beyond. @gziolo gave the following status update:

  • Added package for Axe API integration with Jest and Puppeteer: https://github.com/WordPress/gutenberg/pull/13241. This is set of tools for accessibility static analysis which we want to integrate with e2e tests to ensure that we can catch regressions early on.
  • Extracted test utils to their own @wordpress/e2e-test-utils package: https://github.com/WordPress/gutenberg/pull/13228. It will allow some code reuse for those who would like to start writing e2e tests for their WordPress sites, plugins or themes.
  • Moved tests to their own @worpress/e2e-tests package: https://github.com/WordPress/gutenberg/pull/12465. There are now located in packages/e2e-tests/specs folder.

@gziolo plans to continue working on enabling a11y support to e2e tests in Gutenberg next. In order to start reusing the e2e setup in WordPress core, quite some configuration is still needed in WordPress core. This is tracked in https://core.trac.wordpress.org/ticket/45165. @adamsilverstein agreed to explore this further.

Agenda: PropTypes and React Doc Generation

Slack Conversation

@ajitbohra proposed to add PropTypes to components in Gutenberg, in order to allow automated documentation generating and have type checking for components.

There was interest in the idea but also some concerns were raised:

  • There is some uncertainty of PropTypes’ future, considering that Facebook doesn’t use them and there exist other type systems which supersede them (Flow, TypeScript). PropTypes seems like a good solution for what we need right now, but in terms of type system, there might be better solutions available.
  • If they’re added, we need to make sure they are added as part of a proposal which also includes how they are going to be used, ie. for auto-documentation.

For now, we decided to avoid to add complexity without clearly understanding the merit. More exploration is needed on auto-documentation and the benefits of strong typing.

#core-js, #javascript, #meeting-notes, #summary

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: https://make.wordpress.org/core/2018/12/04/javascript-weekly-chats-wordcamp-us-holiday-scheduling/

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