CSS Chat Agenda: 19th March 2020

This is the agenda for the upcoming CSS meeting scheduled for 19th March, 21:00 UTC.

This meeting will be held in the #core-css channel  in the Making WordPress Slack.

If there’s any topic you’d like to discuss, please leave a comment below!

Agenda

  • CSS audit status update
  • Coding standards: differences between Core and Gutenberg
  • Open floor

#agenda, #core-css

JavaScript Chat Summary: March 17, 2020

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 Items

JSDoc Documentation Standards

(Slack conversation)

Question: Does it make sense to document changes to a function over time, and if so, how?

Context: https://github.com/WordPress/gutenberg/pull/20427#discussion_r386396607

The current JavaScript documentation standards restrict the @since tag to include only the version number:

@since x.x.x: Should always be 3-digit (e.g. @since 3.6.0).

This is in contrast to the PHP documentation standards, which include guidelines around using @since as a changelog:

If significant changes have been made to a function, hook, class, or method, additional @since tags, versions, and descriptions should be added to provide a changelog for that function.

Proposal: Incorporate some adaptation of the PHP since changelog guidelines into the JavaScript inline documentation standards.

Discussion Points:

  • @nerrad asks if this could be used to pull documentation automatically from the source code. This is quite possible, and is likely exactly what is done with the PHP source code documentation (example documentation and source).

Action Items:

  • Update the JS documentation standards, assuming there is no opposition presented in the coming days.
  • Disable the JSDoc since format validation for Gutenberg in the related changelog (already done)

News Roundup

This roundup contains a few links for Gutenberg and JavaScript related news curated (and commented on) by @nerrad

Other Random Stuff:

#core-js, #javascript

WP Notify weekly meeting for Monday 16 March 2020 cancelled

This post serves to notify everyone that the next WP Notify meeting, planned for today, Monday, March 16, 2020, 14:00 UTC has been cancelled.

We will continue with our planned weekly meetings next week on Monday, March 23, 2020, 14:00 UTC

#agenda, #feature-notifications

Dev Chat summary – February 12, 2020 (5.4 week 9)

@davidbaumwald facilitated the chat on this agenda.

Full meeting transcript on Slack

This devchat marked week 9 of the 5.4 release cycle.

Announcements

WordPress 5.4 Release Candidate 2 was released on Tuesday March 11th as expected 🎉

Feedback from hosts is needed on Make/Hosting regarding SimpleXML PHP extension usage.

@joemcgill shared that XML Sitemaps Feature Plugin version 0.2.0 was released this week and could continue to use feedback from folks testing.

@audrasjb shared that Plugins & Themes Auto-updates Feature Plugin version 0.2.1 was released this week. This feature now have a dedicated Slack channel, created right after the last devchat: #core-auto-updates. There will be weekly meetings on Tuesdays at 18:00 UTC. The kick-off meeting recap is available on Make/Core.

@chanthaboune shared the roadmap to get an All-women Release Squad by the end of 2020.

Upcoming releases

WordPress 5.4 Release Candidate 3 is scheduled for Tuesday March 18th, 2020.

trunk is open for 5.5, but the priority is on 5.4 Release Candidate cycle. Polyglots Team already started to work on translation packages.

Components Check-In

@imath worked on Ticket #49236 and needs some feedback. @jeffpaul advised him to slate it to 5.5 with early keyword so it could be handled at the early stage of the development cycle.

@garrett-eclipse found a list of the components and sub-components without maintainers:

There’s the potential to merge some of the less active sub-components like Charset and Emoji into it’s parent Formatting component. But that would needs further discussion.

Open floor

The main discussion of the open-floor was the Block Editor’s Full Screen Mode enabled by default since WP 5.4 Release Candidate 1.

Here is a quick transcript of the discussion. Please note that no decision has been taken during this chat.

@peterwilsoncc wanted to know when was this committed to the WordPress repository. @jorgefilipecosta answered it was introduced during Beta 3, before WP 5.4 RC 1 was released.

@peterwilsoncc: “same for the release in which it was moved from experimental to stable (for want of a better word) Gutenberg?”. @jorgefilipecosta answered that Full screen mode was not experimental, it was stabilized and working for a long time, it was just not enabled by default (although some hosts were doing it), and the Gutenberg team just had a small PR that enabled the mode by default.

@peterwilsoncc noted that in the discussion on the Make/Core blog, @matt mentions some user testing. @peterwilsoncc asked how much was done.

@joostdevalk proposed to revert and take another look for 5.5, given the negative feedback about this change.

@clorith pointed out that it is still being worked on, and even had a design change between RC1 and RC2. It feels like it’s not ready, and needs more UX work before it goes in.

@chanthaboune asked how the feedback has been in support forums. @ipstenu answered that it’s hard to get feedback in support forums at this stage, since only people beta testing would see it and they tend to be a little more technical savvy than mainstream users.

@youknowriad wanted to clarify some of these questions:
– “I believe we should just the merits of the full screen on its own not whether it can be disabled or not. For instance the customizer is in full screen and it can’t be disabled.
– The UX work after RC1 was a bug fix for RTL languages.
– The feedback is balanced. There were good comments about it. Most negative feedback is about the fact that it becomes default.
– This feature has been on the Gutenberg plugin for more than a year now, It’s in before 5.0.”

@pbiron asked if it was enabled by default in the plugin before being merged into core.

@youknowriad answered that was a request from @matt as release lead prior to the RC.

@joostdevalk added that it’s sounds good to say that @matt has every right to make that call. But he disagrees that this is a good idea in its current form, and he think it will be necessary to guide changes like this more. The Block Editor is changing its default behavior without explaining that in the interface.

For @peterwilsoncc, at this point the question is whether it should be enabled by default rather than whether the feature should exist.

@joemcgill’s main concern is that the reaction to this change will be for people to install code that permanently overrides the feature preference, which makes it harder to move to a fullscreen mode default in the future.

@nilovelez noted that it may seem daunting for existing users, as some part of the UI will apparently be gone, but existing users are the ones that won’t even notice the change. Some attendees disagreed on that as the current behavior for existing users is saved with LocalStorage so it won’t stay for users that use different devices to connect to WordPress Admin.

@clorith also mentioned that Apple clears LocalStorage at set intervals, so users would lose their “don’t use fullscreen” option.

@johnbillion feels concerned that how to switch back to non full screen mode is not obvious.

@youknowriad answered the argument can be turned to the opposite direction for people preferring the full screen mode if it’s disabled. That’s why he think the core team should discuss whether it’s good not whether it can be disabled. For @clorith, given that it’s been off by default, then this is an unexpected change, and thus should not be used as the basis.

@joostdevalk proposed to show how to get out of full screen mode and how to set personal preference in the interface, and save preferences as a user meta and not on the user’s browser.

@jorgefilipecosta pointed out that a new welcome modal is shown to new users. He asked if it would make sense to introduce full screen mode there. @joyously stated that most of the users wouldn’t see it. @jorgefilipecosta, answered that users that won’t see the new modal won’t switch to default FullScreen mode, their preferences will be kept unchanged.

@audrasjb added that users don’t necessarily come to the editor from the posts list. With fullscreen mode and the WP logo button, they can only go back to the Posts list instead of having the full Admin menu. This is the only Admin action/link directly available after editing/publishing a post.

@jorgefilipecosta raised that the development of database persisting mechanism is in progress and that should happen soon. @ipstenu added it really should be a requirement for this feature to land in WordPress Core. @jorgefilipecosta mentioned database persisting for user’s preferences is expected to land in WP 5.5.

In terms of actions, @peterwilsoncc suggested:

  • Setting full screen to off by default
  • Adding some onboarding for when the switch is made
  • Enable once the user’s preference is saved in the database
  • Clarifying exiting full-screen mode (currently active, stated for completeness)

@johnbillion pointed out Matt mentioned that some hosts enabled full screen mode. He asked what is the feedback been regarding not getting lost, switching modes, etc.

@chanthaboune tried to summarize the concerns raised by the attendees:

  • Consistency/persistency of the visual experience
  • More thoughtful user flows
  • Clearer introduction to the full screen functionality

#5-4, #block-editor, #feature-plugins

Editor chat Summary: 11 March, 2020

This post summarizes the weekly editor chat meeting agenda here. Held on Wednesday, 11th March 2020 held in Slack. Moderated by @paaljoachim.

WordPress 5.4 Release Candidate

WordPress 5.4 Release Candidate (RC) was released 10th March.
https://wordpress.org/news/2020/03/wordpress-5-4-rc2/.

@jorgefilipecosta
Cherry Pick PR’s for WordPress 5.4 RC 2:
https://github.com/WordPress/gutenberg/pull/20743
Current status:
https://github.com/WordPress/gutenberg/projects/39.

Gutenberg version 7.7

Gutenberg version 7.7 release post: https://make.wordpress.org/core/2020/03/11/whats-new-in-gutenberg-11-march/

Weekly Priorities

There is master plan for March:

@youknowriad
Full Site Editing overview issue: https://github.com/WordPress/gutenberg/issues/20791

Task Coordination

@andraganescu
Working on LatestPosts block, LatestPosts v2 and Navigation block.
This PR allows Navigation menu to create items from an existing WP menu https://github.com/WordPress/gutenberg/pull/18869

@youknowriad
Strong focus on: the Block Patterns UI and the Full site editing.

@gziolo
Focus on block editor features API and registering block types from metadata in PHP.

@nosolosw
Focus on expanding the global styles system to other areas: first step the custom colors ( __experimentalUseColor component) and try to make them work with global styles.

@brentswisher
Continue working on storybook integration of components.

@karmatosed
Focus on Global styles wrap up for v1 and Navigation.

@jorgefilipecosta
Focus on the 5.4 release, and work on a package for generic screen functionality (share code between edit-post , edit-site etc), and global styles.

@mapk
In relation to FSE (Full Site Editing), Creating/editing templates and isolating template parts.

@itsjonq
Focus: adding more style controls to Gutenberg blocks, and making the controls easier to use.

@isabel_brison
Triaging the a11y audit board https://github.com/WordPress/gutenberg/projects/25

Needs review

Latest Post Block PR’s looking for a reviewer:
https://github.com/WordPress/gutenberg/pull/20785
https://github.com/WordPress/gutenberg/pull/20595
https://github.com/WordPress/gutenberg/pull/20563 @karmatosed
https://github.com/WordPress/gutenberg/pull/20541
https://github.com/WordPress/gutenberg/pull/20415

Open Floor

@matveb
WordPress 5.4 will use the pre Gutenberg 7.7 user interface.

@andraganescu
Brings attention to “Add menus endpoints.”
https://github.com/WordPress/gutenberg/pull/20292

@brentswisher and @itsjonq
Will work on improving the stories and docs for the storybook components.

@itsjusteileen
How do we show a template (wp_template post) we have built as a page on the frontend?
@johnstonphilip
It needs to have the right slug so that WP template hierarchy takes over and uses that template. https://developer.wordpress.org/themes/basics/template-hierarchy/#single-page

@paaljoachim
“Consistency between image options in single image and gallery blocks.”
https://github.com/WordPress/gutenberg/issues/11436
Regarding nesting single image blocks inside parent gallery.
@andraganescu
This comment should help with a composed Gallery block:
https://github.com/WordPress/gutenberg/issues/19685#issuecomment-576010263
@youknowriad
A big issue would be InnerBlocks defining alignments for the children blocks.

CSS Chat Summary: 12th March 2020

Full meeting transcript on Slack: https://wordpress.slack.com/archives/CQ7V4966Q/p1584046820150600

I (@isabel_brison) facilitated the meeting. 

Following on from last week’s discussion about meeting times and daylight savings changes, no one expressed a preference so we decided to keep meeting at the same time relative to UTC.

CSS audit status update

Progress this week was essentially creating tickets:

I also reviewed a ticket for removing some !importants from the common.css file: https://core.trac.wordpress.org/ticket/47569

@notlaura suggested checking in with design at the weekly meeting regarding any particular pain points they might be having with core CSS.

There was nothing for open floor, so we finished early 🙂

#core-css, #summary

Auto-updates feature meeting summary: March 10th, 2020 (kick-off meeting)

These are the weekly notes for the WP Auto-updates team meeting that happened on Tuesday March 10th, 2020. You can read the full transcript on the core-auto-updates Slack channel and find the meeting’s agenda here.

It was the first meeting for the Plugins & Themes Auto-updates feature, and this kick-off meeting was really efficient and worthwhile for the project 🚀

WP Auto-updates feature general scope

Here is the current general scope of the Feature Plugin:

  • Ability for website administrators to opt-in to automatic updates for plugins and themes in the related WP-Admin screens
    • ✅ Done for plugins
    • 🔲 Themes: needs to be ported. Slated for milestone 0.4.
  • Ability to enable/disable auto-updates on a plugin-by-plugin and theme-by-theme basis
    • ✅ Done for plugins
    • 🔲 Themes: needs to be ported. Slated for milestone 0.4.
  • Email notifications to send regular auto-update summaries to website administrators
    • 🔲 Plugins: Slated for milestone 0.3.
    • 🔲 Themes: Slated for milestone 0.4.
  • Hooks and constants to help developers disable or programmatically define auto-update settings
    • ✅ Done for plugins
    • 🔲 Themes: needs to be ported. Slated for milestone 0.4.

For the moment, the team started with plugins autoupdates, then all this work will have to be ported to Themes screen.

As a reminder, the Feature Plugin is developed on GitHub and is available for testing on WordPress.org plugins repository.

Current status of the project – version 0.2 🐝

Last week, version 0.2.0 was released with a lot of enhancements and bugfixes. Here is the complete changelog:

  • Remove auto-updates column from must-use and drop-ins screens – PR #39
  • Ensure the the enable/disable bulk actions appear in the dropdown and are handled in multisite – PR #38
  • Remove dashicon from “Enable” text in plugins auto-updates column – PR #36
  • Replace “Automatic Updates” with “Auto-updates” in filters – PR #35
  • Display only filters with at least one available plugin – PR #33
  • Remove setting from site option when deleting plugin – PR #32
  • Populate site health with plugins auto-updates informations – PR #24
  • In multisite, only add the “Automatic Updates” column on the plugins-network screen – PR #21
  • Add auto-update-enabled and auto-update-disabled views on the plugins screen – PR #18

@pbiron noticed some PHP notices on version 0.2.0 and made a pull request to fix them. It is milestoned for version 0.2.1, later this week.

@audrasjb shared some screenshots of the current design of WordPress Admin screens:

Click images to open them in full size (it will opens in a new tab).

@mclancy3 will open GitHub issues to provide some feedback on the Plugins screen’s user interface.

Work in progress

@pbiron raised an issue with a premium plugin that assumes there is no extra column on the plugins list table and add its own column with a colspan attribute. As mentioned by @clorith, this is not a bug in WP Auto-update feature plugin but rather a bug in this particular plugin. @jeffpaul proposed to add this to a Known Issues/Caveats section in readme files.

@jeffpaul also proposed to port the Features/to-do list section from readme.md into GitHub issues. @audrasjb already ported Email notifications and Themes auto-updates into issues, and @jeffpaul will take care of the remaining ones.

@jeffpaul pointed out that 10up uses two GitHub Actions to help deploy plugins to WordPress.org as well as readme/asset updates. He proposed to submit a PR to add those here and help streamline deploys to WordPress.org. For the moment, @audrasjb generates releases from the GitHub repository and deploy them manually on the plugin repository, using SVN. If it’s not a top priority, it would be nice to improve this workflow.

As proposed earlier in core-sitemaps meeting, @pbiron suggested to add a label to issues when something different will have to be done to the plugin code when it gets merged into core. @audrasjb stated that it would be nice to introduce this kin of labels and also to use DocsBlocks comments to point out things that will need specific implementation on WP Core. @jeffpaul proposed to use a GitHub pull request template for that.

About next development steps, @audrasjb is currently implementing email notifications. It shouldn’t be a problem given there is an useful automatic_updates_complete action to hook on.

Porting auto-updates features from Plugins to Themes will probably be a way more difficult, as there is not so much hooks in the Themes screen template. Themes in multisite is fairly straightforward, since a list table is used there, but for single sites there is no list table so what we’ve done for plugins won’t really apply. We’ll probably end up with JavaScript hacks to include the interface opt-in buttons and informations. @jeffpaul proposed to expand the focus of 5.4.x to include those hooks in the themes screen, which sounds like a perfect option right now.

Current GitHub issues

Issue 31: Automatically rollback to previous version if fatal errors detected after update

@audrasjb thinks this issue is out of the feature plugin’s scope. @clorith added that if auto-updates are off by default, yes this would be out of scope for the first release, but definitely something to look into in the future. If they are on by default, this would be a blocker. @audrasjb answered that Plugins, Themes and Core (major) auto-updates are all meant to be opt-in, in the 2020 general roadmap. The team agreed to keep this issue open for the moment.

Issue 13: Automatically delay/postpone updates

@audrasjb said Postponing updates is a great feature, but it’s not on this feature plugin scope, and not sure it’s even in Core scope. @clorith pointed out that the core solution should facilitate by providing filters and such, but not add all those options. The team agreed to keep this issue open for the moment.

Next steps

  • @audrasjb will focus on email notifications development and grant GitHub commit access to @pbiron.
  • A call for testing will be published on Make/Test once 0.2.1 is released with the PHP notices fixes.
  • @jeffpaul will work on improving the GitHub repository organization.

Next meeting is scheduled on Tuesday March 17, 2020 at 18:00 UTC and will take place on #core-auto-updates Slack channel.

#auto-update, #feature-plugins, #feature-projects, #feature-autoupdates

JavaScript Chat Summary: March 10, 2020

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.

News roundup proposal

(Slack conversation)

@nerrad as been kind enough to offer to share an aggregate of news relevant in the Gutenberg and general JavaScript ecosystem, to include in the summary notes for each week’s meeting.

Discussion:

  • There was an agreement that it’s a great idea.
  • The plan is to add this as an extra section in our JavaScript chat summary starting from this week.

Action items:

  • New agendas should be structured to include separate sections “Agenda Topics” and “News Roundup”
  • Note-takers should aim to include these items in the published summary notes.
  • Update “Note Takers” document guidelines.

ESLint “prefer-const” relaxation proposal

(Slack conversation)

@aduth added a pull request about a potential revision to our default ESLint configurations (i.e. coding standards) at https://github.com/WordPress/gutenberg/pull/20737. He just wanted to bring it to attention, since any of these sorts of coding standards changes are good to highlight. There’s been some positive feedback already on the pull request that was echoed in the chat.

Visual regression testing tools

(Slack conversation)

@isabel_brison created a ticket https://core.trac.wordpress.org/ticket/49606 to introduce visual regression testing in the WordPress core, so we can clean up some of the old CSS with confidence. She was wondering if this type of testing has been discussed or explored at all for core or Gutenberg. Also, would there be value in adding it for Gutenberg, too?

Discussion:

There’s no visual regression testing in Gutenberg as of today, but there are parts of the tooling that could make it possible, like taking screenshots with the headless browser via Puppeteer. At least with the ticket as presented, it seems primarily focused on existing screens which may not be expected to change, and thus primarily with the aim of preventing regressions while doing CSS refactoring.

The tests themselves are minimal, but the reference images are not insignificant though and need to be updated periodically. The biggest concern is the size of the assets that would have to be maintained and how to ensure they don’t pollute repositories with source code.

There is an existing prototype in the Gutenberg repository (https://github.com/WordPress/gutenberg/pull/18797) that uses 3rd party service percy.io that can be used as a reference when exploring the final implementation.

Introduce a common API to style Button from both web and mobile

(Slack conversation)

There is a pull request that explores primitive UI components that can be used both in native mobile apps and in the browser: https://github.com/WordPress/gutenberg/pull/19104. There was no specific discussion item attached to this, but it was requested that anyone interested take a look and provide any feedback they have to drive further development.

News roundup

A few links to Gutenberg and JavaScript related news (curated by @nerrad).

WordPress 5.4 dev notes

Other random stuff

#core-js, #javascript

CSS Chat Agenda: 12th March 2020

This is the agenda for the upcoming CSS meeting scheduled for 12th March, 21:00 UTC.

This meeting will be held in the #core-css channel  in the Making WordPress Slack.

If there’s any topic you’d like to discuss, please leave a comment below!

Agenda

  • CSS audit status update
  • Open floor

#agenda, #core-css

Editor chat summary: Wednesday, 4 March 2020

This post summarizes the weekly editor chat meeting on Wednesday, 4 March 2020, 14:00 UTC held in Slack.

WordPress 5.4 Upcoming Release

WordPress 5.4 RC 1 is out, more details can be checked on the release page.

The list of editor PR’s cherry picked can be checked on #20593 and #20613.

The team published all the block editor dev notes. In total, the team ended up publishing a total of 10 posts with block editor dev notes https://make.wordpress.org/core/2020/03/03/wordpress-5-4-field-guide/ covering 32 PR’s that needed a dev note.

@jorgefilipecosta gave a big thank you to everyone that helped the big effort on writting the editor dev notes.

@jorgefilipecosta ended the topic by sharing the following information:

For the next RC currently, we have three issues that should be fixed. Two of the issues have a PR that needs review. Another one does not have a PR yet. The status of these tasks can be checked on https://github.com/WordPress/gutenberg/projects/39

Weekly Priorities

The Post with the priorities for March is published.

@gziolo shared the following summary of the priorities:

  • Block Content Areas
  • Global Styles
  • Block Patterns
  • Tightening up

Task Coordination

@karmatosed

@karmatosed referred that for Feedback from design just note in the core-editor channel or in GitHub.

@joen

Is experimenting with new iconography to explore the G2 iterations: https://github.com/WordPress/gutenberg/pull/20464.

@nosolosw

@mapk

@gziolo

  • Started development for the new block editor features API.
  • Code reviews, testing, etc.

@brentswisher

Is continuing to work through the components and adding storybook stories to any that are missing: https://github.com/WordPress/gutenberg/issues/17973#issuecomment-591093951

Referred that if anyone has experience with the story shot integration, he has some questions in the Disabled PR: https://github.com/WordPress/gutenberg/pull/20514.

@andraganescu

@ajlende

Is experimenting with WebGL blocks right now and working around the constraints. Is trying to get people’s thoughts/opinions on a Gutenberg feature request he has related to rendering in the background and providing a single requestAnimationFrame render loop for multiple blocks https://github.com/WordPress/gutenberg/issues/20483.

Open floor

Custom text color format

@paaljoachim brought to the discussion the fact that the text color may or may not be a main format.

@jorgefilipecosta clarified that the fact that the text color appears on the main formats when a color is selected and disappears from the main formats if no color is selected is not a bug. It was an implemented behavior to avoid too many main formats but at the same time give relevance to the format if color is chosen. We may discuss this behavior in an issue and it may make sense to change.

Fullscreen mode enabled by default

@paaljoachim raised the fact that now fullscreen mode is enabled by default, and referred he is very skeptical about this change as it can bring much confusion to users.

@gziolo referred that:

  • Fullscreen mode is a feature that already existed.
  • Customizer also uses fullscreen.
  • The feature will only affect new users as the current setting the users had is persisted in the local storage.
  • The feature is still being discussed and it may end up being reverted during the RC phase.

#block-editor, #chats, #core-editor, #gutenberg, #meeting, #meeting-notes