Ella van Durpe 8:41 pm on November 13, 2019
Tags: , ,   

What’s new in Gutenberg? (13 November)

In this newest release of Gutenberg, block content areas and the navigation block continue to be iterated upon. An experimental block pattern API has been added, and themes can now define custom gradient presets!

The navigation block, demonstrating newly improved horizontal block movers.
The navigation block, demonstrating newly improved horizontal block movers.

The block editor provides default gradient presets. Now, a theme can overwrite them and provide its own:

add_theme_support(
    '__experimental-editor-gradient-presets',
    array(
        array(
            'name'     => __( 'Vivid cyan blue to vivid purple', 'themeLangDomain' ),
            'gradient' => 'linear-gradient(135deg,rgba(6,147,227,1) 0%,rgb(155,81,224) 100%)',
            'slug'     => 'vivid-cyan-blue-to-vivid-purple'
        ),
    )
);

Note that this feature is currently experimental and subject to change.

6.9 🇦🇷

Features

Bugs

Enhancements

New APIs

Various

Experimental

Documentation

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience but is adequate for spotting variations in performance.

Version Loading Time KeyPress event (typing)
Gutenberg 6.9.0 11s 77.36ms
Gutenberg 6.8.0 11s 74.78ms
WordPress 5.3 10.6s 80.85ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Francesca Marano 4:47 pm on November 13, 2019  

Dev Chat Agenda for November 13, 2019 (Post 5.3 week 1)

Here is the agenda for the weekly meeting happening later today: Wednesday, November 13, 2019, 09:00 PM UTC.

Agenda

  • Announcements
    • Highlighted posts
  • 5.3
    • Housekeeping
  • Calls from component maintainers
  • Open Floor

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

This meeting is held in the #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#5-3, #agenda, #devchat

andraganescu 3:03 pm on November 13, 2019
Tags: ,   

Core editor chat summary November 13th, 2019

This post summarises the weekly editor chat meeting, agenda here, held on Wednesday, November 13th 2019, 13:00UTC in Slack, moderated by @jorgefilipecosta, notetaker: @andraganescu

Next week’s Core editor chat time: 14 UTC

Because of DST there was a decision to move the meeting one hour later. The async discussion is still open until Monday, November 18th to decide if people, other than those present at he core editor chat want it differently.

WordPress 5.3 was released yesterday

@youknowriad: Big kudos to all the contributors. It’s a huge release for the block editor

@jorgefilipecosta I would like to thank all the people that contributed and made all this improvements and bug fixes possible!!

There is some current effort to iron out issues that may appear.

Gutenberg 6.9 will be released today

A Release Candidate is already available at https://github.com/WordPress/gutenberg/releases/tag/v6.9.0-rc.1

@aduth and @ella are working on that (release post and performing the release)

Weekly priorities

The main priorities are the same ones highlighted in the November post What’s next in Gutenberg? (November) – Make WordPress Core

Also, one of the priorities is to fix WordPress 5.3 regressions as they come up.

Task coordination

@youknowriad

  • I was AFK for some days post WCUS
  • I worked on the WordPress 5.3 release a little bit
  • I’ll be focusing on support, triage and reviews for the next week.

@karmatosed

  • Navigation block: styling, reviews and testing
  • Triage: I want to dig in a bit and try and clear down low hanging tasks
  • Begin working out sprints for Tightening Up board. I have an idea to for 1-2 weeks focus on an area, move on and repeat.
  • Support is for me next week so last point won’t happen until week after.

@retrofox

@getdave

  • I’ve been focused mainly on Nav Block related PRs.
  • In particular, I’d draw attention to this one I created to allow parent Blocks to “consume” the toolbar of their children via InnerBlocks https://github.com/WordPress/gutenberg/pull/18440

@pbrocks

@michaelarestad

  • starting in on full site editing – largely research/information gathering at this point

@mapk

  • Helped review some of the Nav block work.
  • Worked on the Media replace flow.
  • Reviewed linking media in Media+Text block.
  • Helped @michaelarestad with some full site editing research.

@andraganescu

  • continued on the navigation block
  • need a code review on the media replace control here: https://github.com/WordPress/gutenberg/pull/16200

@nerrad

@jorgefilipecosta

  • I finished a big refactor for the legacy widgets, made some improvements on the custom gradient picker, worked on some PR reviews, continue the work around having configurable inner block settings to allow a parent block to absorve the child, and continued the iterations on some PR’s I had open.
  • For the next week, I’m hoping to merge the simulated media queries mechanism; I want to get involved again in the navigation block work, so I hope to do many reviews there and maybe pick up some tasks, besides that I will continue the buttons block and innerblocks UI work.

@tellthemachines

  • For task coordination: I’ve mostly been reviewing nav-related PRs this week and will be away from the 14th to the 24th November. (In case anyone wonders why I’ve gone strangely silent :D)

@noisysocks

  • I’m still looking at nav-related PRs and working on the Welcome Guide as time permits.

@gziolo

@youknowriad highlighted the new Storybook available at: https://wordpress.github.io/gutenberg/

It is also important to note for people reading this async: it is possible to participate on the task coordination by commenting on the agenda.

Open floor

  • Embedding Multilingual ability as standard core functionality: seems a bit early for implementation but it’s definitely being considered.

Let’s review more PRs!

Just a note to everyone. Do please also spend a little time going through older PR’s. As there are many just hanging waiting for a comment, a review etc. We’re definitely falling behind in terms of reviews.

The number of open PR’s increasing which in part is a good signal it means the project is getting more interest, but we should try to review these PR’s as soon as possible so new contributors keep the interest in contributing and we get the features/fixes sooner.

#core-editor, #editor-chat

Paal Joachim Romdahl 12:22 am on November 13, 2019  

Editor Chat Agenda: 13 November, 2019

Note taker: @andraganescu

This is the agenda for the weekly editor chat scheduled for Wednesday, 13 November, 2019, 08:00 AM EDT.

This meeting is held in the #core-editor channel in the Making WordPress Slack.

  • WordPress 5.3
  • Gutenberg 6.9
  • Weekly Priorities
  • Task Coordination
  • Open Floor

If you have anything to share for the Task Coordination section, please leave it as a comment on this post.

If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#agenda, #core-editor, #editor-chat

Darren Ethier (nerrad) 3:31 pm on November 12, 2019
Tags: ,   

Javascript Chat Summary – November 12, 2019

Below is a summary of the discussion from 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.

Switching to Prettier

Slack | Github Issue

Some discussion ensued on what is needed to merge this pull.

  • Post on make.wordpress.org regarding any code standard changes affected by this pull (and to inform about the change). This will need further feedback from core lead devs, core committers and contributors.
  • There are some rule removals from the es-lint plugin package, some discussion ensued about how to handle that and are those changes necessary. At a minimum, there seems to be some agreement that the ESLint rules should match the standards.

Tasks:

  • Check how many of the existing eslint rules could stay unmodified and what can be tweaked to work with Prettier and which need to be disabled. Should align with whatever standards are for the project (including any necessary modifications to those standards)
  • We should also seek a way so that the eslint plugin can continue to be used without prettier so folks can have the benefit of styling standard checks the same way as of today.
  • Once the above is done, write a post on make.wordpress.org/core outlining the changes and inviting feedback.

__experimentalCreateInterpolateElement

Slack | Github

This is a new function that makes it possible to interpolate elements within a translated string and have those rendered as react elements. Currently, doing something like the following can’t be done in react.

const MyLinkComponent = ( { href } ) => {
    return wp.i18n.__( 'This is a <a href={ href }>link</a>' );
};

In order to have <a> render, you’d need to split up the string, which in turn breaks context for translations. The solution is __experimentalCreateInterpolateElement:

const MyLinkComponent = ( { href } ) => {
    return __experimentalCreateInterpolateElement(
        wp.i18n.__( 'This is a <a>link</a>' ),
        { a: <a href={ href } /> }
    );
};

If you have any feedback or concerns with the proposed api please give feedback in the pull.

In the meeting:

  • generally seems to be approval around the api
  • concerns over whether the parsing should be cached.
  • wondering whether there’d be value in introducing a useInterpolation hook (that could also take care of some of the caching)
  • adding some sort of performance testing (although since it’s not used anywhere, there’s nothing currently in the project that can help with this).

Upcoming React Features

Slack

In this portion of the meeting there was mostly just some resource and link sharing around upcoming react features:

  • https://reactjs.org/docs/concurrent-mode-adoption.html
  • https://reactjs.org/blog/2019/11/06/building-great-user-experiences-with-concurrent-mode-and-suspense.html
  • https://www.youtube.com/playlist?list=PLPxbbTqCLbGHPxZpw4xj_Wwg8-fdNxJRh (React Conf 2019 playlist)

#javascript, #meeting-notes

Jb Audras 2:47 am on November 12, 2019
Tags: ,   

WordPress 5.3 RC 5

The fifth release candidate for WordPress 5.3 is now available for testing.

WordPress 5.3 is currently scheduled to be released on November 12 2019.

There are two ways to test WordPress 5.3 release candidate 5:

For details about what to expect in WordPress 5.3, please see the first,  second, third and fourth release candidate posts.

Release Candidate 5 contains some bug fixes for the new default theme, Twenty Twenty – for reference, see #48557 – and addresses the following tickets:

  • #47708 – 5.3 about page
  • #48312 – Fix a typo in an inline comment
  • #48542 – In wp_default_packages_inline_scripts(), make sure the root URL middleware is registered before using the media middleware
  • #48543 – Comments: check if comment form element exists before adding a key handler to detect the cmd/ctrl-enter key press.
  • #48517 – Bundled themes: several changes to ensure consistency and accuracy for default theme headers
  • #48518 – Upload: When an image was scaled because it is larger than the big image threshold, use the originally uploaded image’s dimensions in wp_get_missing_image_subsizes(). Fixes an edge case/inconsistent behaviour when a registered image sub-size is also larger than the big image threshold.

Plugin and Theme Developers

Please test your plugins and themes against WordPress 5.3 and update the Tested up to version in the readme to 5.3. If you find compatibility problems, please be sure to post to the support forums so we can figure those out before the final release.

The WordPress 5.3 Field Guide has also been published, which details the major changes.

How to Help

Do you speak a language other than English? Help us translate WordPress into more than 100 languages!

If you think you’ve found a bug, you can post to the Alpha/Beta area in the support forums. We’d love to hear from you! If you’re comfortable writing a reproducible bug report, file one on WordPress Trac, where you can also find a list of known bugs.

#5-3, #testing

Anthony Burchell 4:54 pm on November 11, 2019
Tags: , , , ,   

Media Meeting Recap – November 7, 2019

The following is a summary of the weekly media component meeting that occurred on Thursday, November 7, 2019. Weekly media meetings are held every Thursday at 14:00 UTC. A full transcript can be found here in the #core-media room in the Make WordPress Slack.

Attendees: @joemcgill , @mikeschroder, @afercia, @desrosj, @dinhtungdu, @karmatosed, @greglone, @azaozz

Meeting Time Discussion

It’s that time of year again (for some of us!) Fall Daylight Savings Time historically makes the meeting time move forward one hour. The next meeting will take place Thursday, November 14, at 14:00 UTC.

There was discussion in a group message consisting of meeting facilitators around potentially doing a rotation of one week at a convenient time for each side of the planet. The Hosting-Community room does this and it seems to work very well. This would allow for participation from groups outside of the normal hour that we hold the meeting while also allowing folks that have been stretching outside their normal work hours to catch the meeting async. Please let us know in the comments what you think about this! There was mention of potentially doing a few months on one schedule and a rotation after. Another suggestion was around doing many meetings instead of rotating meetings. This would entail two designated meeting times a week in an effort to encourage new participants. This topic will be discussed in the next Media Meeting. Any additional ideas would be appreciated.

WordPress 5.3 Tasks

There were three tickets discussed in the meeting.

  1. #48518 Inconsistent behavior when a registered image size is larger than the big image threshold – Testing is being done around this issue and should be ready for 5.3.
  2. #48451 Regression: wp_update_attachment_metadata filter now fires very often and without complete metadata – The Follow Up Post around this outlines a few areas to focus on with the recent uploads changes. Some discussion took place around whether or not a new hook would help folks adjust to the changes. This is still to be determined.
  3. #48522 Attachment size not generated when large images uploaded – A few more details about this issue can be found at this Slack Link. Testing would be appreciated on this ticket.

Feedback

If you have any feedback on the above, please feel free to leave a comment, join in #core-media for a chat, or attend the next meeting on November 14, 2019 at 14:00UTC!

#core, #core-accessibility, #core-media, #media, #summary

Jorge Costa 7:13 pm on November 8, 2019
Tags: , ,   

Javascript Chat Summary: Tuesday, November 5, 2019

Below is a of the discussion from 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.

Editor-specific .gitignore entries in Gutenberg

  • Context: https://github.com/WordPress/gutenberg/pull/18257#discussion_r342255694
    • Proposing to add a gitignore entry for VSCode’s “.vscode” local folder
  • Historically we’ve avoided editor-specific entries in the project’s gitignore to avoid opening pandora’s box (proliferation of ignore entries), but is this too rigid a guideline causing friction in new contributor onboarding?
  • Question: Should we allow more of these entries, and if so, which?

@gziolo said that he does not have a strong opinion on this item, but WordPress as a project is strict about it.

@mkaz also does not feels strong either way but said he would probably merge the PR because vscode its perhaps the largest and most popular editor.

@chancethedev shared his perspective as an instructor:

I often include vscode settings in my repos to make things easier for students when running workshops, so ignoring it globally won’t work for me. That said, I can just remember to remove it before I commit so it’s not a HUGE deal, I can just imagine folks slipping up often enough to where it’ll end up in commits from time-to-time and we’ll just have the conversation again.

@aduth and @adamsilverstein asked if the fact that WordPress os strict is written down somewhere?

@gziolo shared the following comment from https://core.trac.wordpress.org/ticket/34345:

IDE-specific .gitignore rules should not be present in a project. They should be managed in the user’s ~/.gitignore_global.

@gziolo added that it does not look like it is a written rule, as he was not able to find it in the docs. So, we can go both ways; we should document it to make it easy for contributors to update patches.

@nerrad said :

I lean towards adding the rule and just evaluating on a case-by-case basis.

It seems to be more dev friendly and avoids unnecessary noise in reviews.

@mkaz asked if there is any downside to adding the rule and @aduth answered:

I don’t think there’s a downside in-and-of-itself, more the slippery slope of how we make these decisions in the future without a well-defined approach.

@adamsilverstein suggested as action item working on some language for HOW we decide.

@mkaz and @gziolo suggested we add 3-5 top popular IDEs. @gziolo said we could also link to docs how to add an IDE to ~/.gitignore_global.

@aduth suggested, and @adamsilverstein supported that we can base it on “X% or greater” of some well-defined data, e.g., https://insights.stackoverflow.com/survey/2019#technology-_-most-popular-development-environments.

@chancethedev said he is joining the docs team specifically for Gutenberg docs, so he is happy to bring this up in the docs meeting today as well.

If you have any thoughts on this, please share them.

Bundling and loaders – extend core to allow SVG components

As part of the open floor, @mkaz introduced the topic by saying: 

For the open floor, I’m interested in the topic above regarding bundling and loaders – trying to extend core to allow SVG components.

Parcel sounds like an interesting option but looks like v2 is not out yet, so would need to wait

@aduth asked clarification on the background of this task and what is trying to be achieved by importing an SVG.

@mkas linked to the ticket https://github.com/WordPress/gutenberg/issues/14628 and said:

Right now the Social Links duplicates the SVG in CSS and PHP to work – we want to figure out some way to get it to a single .svg file

@aduth asked if it’d be feasible to manually shove the SVG into JSX. And asked if not an option to use something like <img src="icon.svg">.

@mkaz answered that the problem for the publishing view is KSES, and linking to images, one loses the ability to color them.

@aduth shared the main questions he thinks we should answer are “Should we do it, and if so, how?” and shared some thoughts :

  • I am conscious of the size inflation, though I think we need to be solving this problem anyways. Could be a way to prompt us to investigate better handling of “large” blocks (opening path for more complex blocks too, like reintroducing Code+SyntaxHighlighting).
  • I guess there is some issue with our build that the Webpack loader might not work? The Babel transform seems less ideal, but also workable.

@gziolo shared the following analysis of what creat react app did:

CRA experiments with Babel macros, but the blocker at the moment is cache invalidation. They had a very solid proposal to inline many types of files, including SVG with Babel macros https://github.com/facebook/create-react-app/issues/3722#issuecomment-458124126.

Macros struggle with the cache invalidation for the dependent files. See the comment in create-react-app https://github.com/facebook/create-react-app/commit/11737bc78676868e76ce5d0c04ddbb5c758d3908#diff-b1524f1e1ccabdb327a12f23b432b20bR13.

Related Babel issue which might resolve this issue in the future: https://github.com/babel/babel/issues/8497.

@mkaz said Parcel 2 sounds like a potential option for the future. Then, asked if we want to add SVGR support to wp-scripts without it in core Gutenberg, relevant PR https://github.com/WordPress/gutenberg/pull/18243. @gziolo answered that we use a custom config in Gutenberg, so it should be fine.

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

K. Adam White 5:02 pm on November 7, 2019
Tags: ,   

REST API Meeting Agenda for Nov 7

The REST API weekly component chat will occur this week at November 7, 2019 18:00 UTC in the #core-restapi Slack channel.

Please note: We have not changed the UTC time for this meeting. If your country has recently adjusted for daylight savings time, this may be a different hour than the past few months.

Agenda Items:

  • Continue discussion from WordCamp US around a canonical authentication solution and begin tasking out work towards that effort
  • Discuss priorities for the 5.4 development cycle
  • Discuss needed documentation improvements
  • Open Floor

All agenda items are welcome, from all teams and contributors; please post them as comments below or let us know by joining the meeting.

#agenda, #rest-api

Paul Barthmaier (pbrocks) 3:48 pm on November 7, 2019  

Core editor chat summary November 6th, 2019

This post summarizes the weekly editor chat meeting agenda here. Held on Wednesday, 6th November 2019 held in Slack, moderated by @karmatosed, notetaker: @itsjusteileen.

Weekly Priorities

WordPress 5.3RC4

WordPress 5.3 is currently scheduled to be released on November 12 2019, but we need your help to get there—if you haven’t tried 5.3 yet, now is the time!

November Gutenberg Priorities

Priorities for the coming month are categorized into these three headings: 

  • Block Content Areas,
  • Menu Navigation Block, and 
  • Tightening up existing interactions

For more details, consult this recent post.

Task Coordination

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

@karmatosed

  • Catchup after WCUS: so many good conversations about the editor!
  • Navigation block and catching up on reviews is my top priority.

@getdave

  • merging experimental `LinkControl` 
  • merging new link UI into the experimental Nav Menu Block 
  • Removing experimental flag soon, view progress dashboard is constantly updated with issues and PRs
  • Merged `DimensionControl` and `ResponsiveBlockControl` for creating Block Controls that require per-viewport “responsive” settings
  • Adding to the Group Block. Would love some eyes on this soon. 

@andraganescu

@bartczyz Taking on Special characters in permalink not being properly converted 

@copons started PRs for Site Description block: 

@nerrad — requesting review for PR that exposes a simple api for wrapping react elements for new feature: Introduce __experimentalCreateInterpolateElement. While I recognize this is not a complete solution, I think it provides an api for working with interpolated elements that also solves the need for i18n in those contexts.

@tellthemachines working on:

  • reviewing nav-related PRs
  • reviewing/testing the font size picker PR
  • picking up PR #13203 Responsive View Controls in Gutenberg

@noisysocks doing some work on replacing the NUX dot tips with a welcome guide modal.

@gziolo worked on Storybook integration

  • Playground awaiting review PR #18191
  • Progressing with explorations for Patterns API for blocks
  • Proposal for an experimental API PR #18270 
  • API integrated with the Columns block PR #18283
  • Will continue with Patterns API integrating proposed API with more blocks and extract common logic as an initial screen for blocks that define `patterns`

@nukaga

  • PR #18162 Updates columns index.js adding translatable (i18n) where a series of sentences displaying “lorem ipsum” was not translatable.
  • Looking at PR #15827 Twitter URL Embed automatically in Preformatted Blocks. Bug confirmed by @nerrad and ready to be picked up for work.

Open Floor

@pbrocks proposes picking up with adding SASS/PostCSS to wp-scripts process

@noahtallen looking for discussion and feedback about the block template API in his comment on Github.

@jesserh asking for review on PR#18164 to define allowed blocks per column