Editor chat summary: Wednesday, 22 January 2020

This post summarizes the weekly editor chat meeting on Wednesday, 22 January 2020, 14:00 WET held in Slack.

Gutenberg 7.3

@gziolo announced that the Gutenberg 7.3 release was planned to happen later in the day and said, this release includes among others:

  • Multiple performance improvements.
  • A new block collections API. The API is useful when a developer wants to group the blocks in its section in the inserter.
  • Further improvements to the Navigation block.
  • New experimental blocks for the full site editing.

More details about this release are available on the release post.

Weekly Priorities

For this week, we keep the same priorities as last week:

  • Block Content Areas (Full site editing)
  • Block UI updates
  • Block Patterns
  • Navigation block improvements

Task Coordination

@karmatosed

Has been mostly focusing on navigation block feedback/iterations and global styles – will continue to do this into next week.

@retrofox

Has been working on adding the background color feature to the navigation block, it is already merged.

Now is improving the sub-menus design, and polishing the feature.

It is possible to track the progress in the project dashboard.

@isabel_brison

Worked on resizable editor PR https://github.com/WordPress/gutenberg/pull/19082.

All the tests are now updated, and it’s ready for further review. There’s a bit of discussion on how to isolate the editor-specific styles for manipulation in the core, any feedback appreciated at this point!

@youknowriad

Has been working on the icons package. Referred Icons are all over the place in Gutenberg right now, and thinks at least we should gather them in a single package. Said technology-wise, we still need to explore different options to how best ship them for authors, but a tree-shakeable npm package seems like the best initial path forward without BC concerns. @youknowriad will continue working on a solution to this problem.

@youknowriad is also working on an Extensibility API Proposal ( will share more very soon) and keeps doing heavy triage as time allows.

@andraganescu

Is working on an attempt to have responsive backgrounds in blocks which have image backgrounds, and doing various tidying up PRs for the navigation block.

@getdave, @marek, and @jeryj

Are working on the navigation block.

@jeryj is improving the UX.

@getdave and @marek are working on the ability to Create Pages from within the Block on the fly. Relevant issue and PR:

@nosolosw

@nosolosw is focusing back on the work on Gutenberg. Revived a lingering PR to fix a focus issue in the gallery block https://github.com/WordPress/gutenberg/pull/14930. The PR needs a technical review!

@jorgefilipecosta 

Since last week:

For the next week:

  • Help to have a “Global Styles” mechanism in the core.
  • Continue the work on Angle Picker and Gradient type picker for the custom gradients.
  • Focus on triage issues. Reviewing PR’s required for 5.4 beta 1.

@mapk 

@aduth

  • Helping around improvements and consistency among various link components
  • Hoping to try to push user-meta-based preferences persistence (sticky preferences) over the finish line. @aduth referred it would be a nice feature for WP 5.4.
  • Would like to visit some project management automation at some point.

@chopinbach

Is getting up to speed on Gutenberg development.

f you are also starting and are finding any challenge, please share it so that we can improve the experience for everyone.

@gziolo 

Open floor

Template lock active at the post type level, and templateLock={ false } in InnerBlocks causes an invalid block warning

@chrisvanpatten brought up issue https://github.com/WordPress/gutenberg/issues/11681 and asked if there are any options to move the issue forward as the issue is causing a frustrating experience. The ticket seems stalled without a clear path.

Currently, @chrisvanpatten  relies on dispatch('core/block-editor').setTemplateValidity(true); as workaround to the problem.

@youknowriad said the plan outlined in https://github.com/WordPress/gutenberg/issues/11681#issuecomment-549641097 seems a sensible one. But the ticket is stalled because implementing that solution is a big-time investment.

@chopinbach volunteered to help address this problem, and @chrisvanpatten volunteered to team up. Thank you both!

FormTokenField: Make it possible to add children

@scruffian asked for feedback on https://github.com/WordPress/gutenberg/pull/19676.

@youknowriad said that while the change is minimal, it would be good to expand on the use-cases. @youknowriad referred that adding random children may not be the best path forward, and asked if there is another abstraction possible, or if the button is something that can be built-in.

@scruffian said @youknowriad ideas are valid, but his thought was that it would be more useful as it was proposed in the PR. @scruffian  is open to achieving the result differently.

Server-side context API

@chopinbach asked for the latest updates on server-side context API @epiqueras is working on.

@epiqueras said the API is similar to React context and that he needs a PR review.

@youknowriad and @mcsf referred that ideally, a block consumes from a “contextname”, not a “blockname” and different blocks can use the same context name to expose their context.

@epiqueras linked to a comment providing some reasons where the approach may have problems.

The conversation will continue on https://github.com/WordPress/gutenberg/issues/19685. If you have any insights on this issue, please provide them as it may be valuable.

#chats, #core-editor, #editor-chat, #meeting, #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

Shortcake (Shortcode UI) chat summary – November 2nd, 2015

Present: @danielbachhuber, @goldenapples, @matth_eu

Logs: https://wordpress.slack.com/archives/feature-shortcode/p1446494424000273

  • We released Shortcake v0.6.0. Read through the full release notes.
  • Weekly meetings are on hold until January. Between now and then, we’ll be thinking about what we need to do to put forth a core proposal. @matth_eu might put together sketches.
  • We missed the boat on getting a Shortcake representative to the community summit, and are researching ways to helicopter @goldenapples to said community summit boat.

Next chat: sometime in January 2016

#chats, #feature-plugins, #meeting-notes, #shortcode-ui, #shortcodes, #updates

Fields API chat summary – October 5th, 2015

Present: @sc0ttkclark, @nicholas_io, @tomharrigan, @ericlewis, @potatomaster

Logs: https://wordpress.slack.com/archives/core-fields/s1444021200000000

  • I just got 100 hours from 10up to work on Fields API!
  • I will be working on getting the WP 4.3 Customizer changes put into the Fields API, my first pass doesn’t have unit tests passing yet
  • We’ll be fleshing out Control classes, based on Customizer control classes and expand the main control class into individual classes as opposed to a ‘switch’
  • We laid out a few implementations we’d like to get into prototyping
    • User profile fields (piggy backing existing UI of section heading + fields) @sc0ttkclark
    • Settings API (cue the oooh’s and aaah’s sound effect) @sc0ttkclark
    • Post editor (meta boxes + fields) @tomharrigan
    • Widget forms @nicholas_io
    • Future: Term editor (sections + fields)
    • Future: Comment forms?
  • We want to improve the main Fields API readme to better explain the project, offer more links to information about the Customizer API since it’s what we based the Fields API on, and flesh out more examples
  • We need more examples, so any use-cases we can put together for any object type, would be handy to start putting that code together (structures, not custom implementations or overrides)

We certainly could use additional contributors involved with the project, especially as we seek to start more implementation prototypes of how things could work. Just hop into Slack #core-fields or check out our Github repo. Over the next 5 weeks my involvement in the project will be greatly increased, so if you are going to get involved — now would be the right timing!

Next chat: Monday 20:00 UTC 2015 (every Monday)

#chats, #feature-plugins, #fields-api, #meeting-notes, #options-meta

Shortcake (Shortcode UI) chat summary – October 5th, 2015

Present: @danielbachhuber, @goldenapples, @matth_eu

Logs: https://wordpress.slack.com/archives/feature-shortcode/p1444071794000007

  • Matt’s making process on support for encoding HTML in attributes. Gallery functionality is also almost done, but there’s one small bug.
  • Than started work on trying to add some filters that can be used to handle floated/non-block previews. It still some work to go, as it’ll involve overriding some methods deep in mce.view.
  • Daniel will hit up the backlog when he has a moment, as there are a number of unanswered open issues.
  • We discussed inline editing and agreed upon an ideal abstraction .

Next chat: same time and place

Next release: v0.6.0 – Tuesday, November 3rd

#chats, #feature-plugins, #meeting-notes, #shortcode-ui, #shortcodes, #updates

Taxonomy meeting summary – 2015/09/03

Present: @boonebgorges, @swissspidy, @masonjames, @drewapicture, @georgestephanis, @khromov, @srwells, @michaeltieso, @dpegasusm, @kraft, @mrahmadawais, @samuelsidler, @leatherface_416, @jblz, @tyxla, @jeroenvanwissen, @lindsaymac, @eric, @jbrinley, @brashrebel, @pdufour, @joehoyle, @timothybjacobs, @ryanduff, @krogsgard, @aaroncampbell, @rahe

Logs: https://wordpress.slack.com/archives/core/p1441310435002734

  • Had a general discussion about term meta: who’s used plugins for it, who’s used workarounds, various use cases. We talked a bit about some arguments against term meta: that it will not perform well at scale, that it encourages poor data modeling – but decided that they could be set aside for the most part.
  • Outlined the interpretation, including database table name and schema, function names, and other API additions to support term meta. @boonebgorges will work up a RFC for make/core for feedback.
  • Talked about various ways in which existing term meta libraries might conflict with the core implementation: duplicated function names, duplicate table names, incompatible table schemas, etc. @boonebgorges is assembling a list of plugins in the repo that may conflict with the core implementation. Once the outline of the core implementation is pretty much settled, @aaroncampbell, @krogsgard, @masonjames, and @boonebgorges (and anyone else who is interested) are going to collaborate on reviewing these plugins to see which ones will conflict in serious ways (via a Google Doc, which @boone will share once we’re ready to go). This will help us gauge the extent of potential problems, and get a sense of what outreach will look like.
  • We talked a little about combining the wp_terms and wp_term_taxonomy database tables #30262. We outlined some backward compatibility concerns, and strategies for minimizing conflicts. Put out a general call for thoughts and initial patches on the ticket, though we probably won’t move forward with schema changes for at least one more release cycle.
  • Had a very brief discussion about WP_Term #14162. Initial implementation – probably doable for 4.4 – will be simple, and will focus on strict typing for term data as well as cache invalidation. Future releases may see more functionality moved to the class.

#4-4, #chats, #meeting, #summary, #taxonomy

Shortcake (Shortcode UI) chat summary – August 31st, 2015

Present: @danielbachhuber, @matth_eu

Logs: https://wordpress.slack.com/archives/feature-shortcode/p1441047764000146

Next chat: same time and place

Next release: v0.6.0 – Tuesday, November 3rd

#chats, #feature-plugins, #meeting-notes, #shortcode-ui, #shortcodes, #updates

oEmbed Chat Summary – July 20th, 2015

Yesterday we held our first weekly chat in #feature-oembed. Hooray! There were quite a few participants already, which is great.

Logs can be found here: https://wordpress.slack.com/archives/feature-oembed/p1437426031000036

Summary:

  • There’s a proof-of-concept oEmbed implementation in the develop branch on GitHub (demo):
  • We agreed on keeping the embeds simple and minimally styled.
  • As expected, there was quite a discussion about the direction to pursue. There are basically two ways for doing this:
    1. WordPress has an oEmbed endpoint and returns HTML people can embed
    2. WordPress has no endpoint. We scrape the referenced websites to get data for a preview. Kinda like Facebook, Slack or Twitter show previews for links.
  • We decided on first finishing the HTML, as we need that anyway. After that we can focus on the next steps.

Development happens on GitHub, where we’ll be filing a couple of issues to work on until Monday. Anyone is welcome to contribute to the plugin.

Next chat: Monday, July 27, 2015 21:00 UTC

#chats, #embeds, #feature-plugins, #feature-oembed, #updates

Two-Factor Authentication — First Weekly Meeting!

Our very first first weekly meeting will be July 23rd, 2015 at 15:00 EDT in the #core-passwords channel on Slack.

We’ll be addressing some varied issues such as:

  • meeting times (is this a good time for everyone? Is earlier/later better?)
  • Two-Factor Providers, who is working on each.
  • Open Issues.
  • Code Reviews.
  • etc.

As I’m going on Paternity leave in mid-September for a bit, I’m also hoping that over the next few weeks we can collectively find someone else willing to take up the mantle and push Two-Factor forward in my absence.

For anyone else just new to this, who is wondering what the deuce I’m talking about, Two-Factor is a feature proposal for core to introduce two-factor support in the interest of greater security and paving the cowpaths with a standard api for plugins to extend to provide their own two-factor providers. Active development is currently on GitHub here ==> https://github.com/georgestephanis/two-factor — and I’m happy to add any regular core contributors as contributors on the repo — just ask during our meeting or in the comments below!

#chats, #feature-plugins, #two-factor, #updates

Feature Plugin Chat on July 14

Hey everyone!

As I mentioned at this week’s dev chat, we’re going to have a feature plugin chat this coming Tuesday July 14 19:00 UTC.

If you have an idea that you’d like to propose as a feature plugin or if you have a feature plugin already in development, come to the chat and comment below with the following details:

  • A brief (one paragraph) overview of your feature plugin proposal.
  • Current status (e.g. idea, planning, early/late development, existing plugin, testing, stable, etc). If you’re just in the idea stages, list any existing plugins that are similar to your idea.
  • A list of those involved or already interested in your feature plugin (including you!).
  • A link to the plugin in the WordPress.org plugin directory and/or GitHub repository, if applicable
  • What you’d like help with (scoping, planning, wireframing, development, design, etc).

Please leave just one comment per feature plugin/idea so others can comment on the ones they’re interested in.

Current feature plugin leads: We want your feature plugins here too! Please post an update with the information above.

#chats, #core-plugins, #feature-plugins