Jeffrey Paul 2:49 am on May 8, 2020
Tags: , WCEU   

Help needed —> Core team and WCEU Contributor Day

You may have seen update posts on WCEU’s plans on how to create an online Contributor Day this year (see posts from April 15th and April 24th). You may have also caught a reference to this in this past week’s devchat (see related summary post).

As part of the coming online/virtual WCEU, we’ve been asked to plan for how Core will handle an online Contributor Day.  The specific items we’ve been asked to consider:

  • Ensure our Getting Started at a Contributor Day handbook page has been updated as necessary
  • Ensure new contributor meeting happens between 25 May and 3 June, alerting the WCEU Contributor Day team via comment
  • Record a video intro about the Core team, similar to the live intros usually given in-person
  • Confirming list of good-first-issues and experience-issues for Contributor Day
  • Identifying 2+ experienced contributors to help facilities during Contributor Day
  • Plan for a live intro session at the beginning of Contributor Day

So I’m looking to you all to help here: who can help cover any of these tasks and help during the actual WCEU Contributor Day event? Please comment on this post noting which of the bulleted needs above are items you can assist with, thanks!

#contributor-day, #wceu

Jb Audras 10:52 pm on May 12, 2020
Tags: , , , ,   

Auto-updates feature meeting summary: May 12, 2020

These are the weekly notes for the WP Auto-updates team meeting that happened on Tuesday May 12, 2020. You can read the full transcript on the core-auto-updates Slack channel.

Reminder, WP Auto-updates Feature Plugin is developed on GitHub and is available for testing on WordPress.org plugins repository.

Update on core patch

@pbiron is in charge of the core patch. It should be ready around the middle of this week. Paul asked whether it’s better to do a pull request against wordpress-develop GitHub repository or a diff file on Trac.

@azaozz answered both would work, and have different pluses and minuses:

  • Pull requests can be reviewed in inline comments, but are harder to modify by different people.
  • A diff file would need to be applied to a svn checkout before testing, but easier to iterate (to make new diffs)

Paul will send a diff file.

WP auto-updates version 0.8.0

Here are the expected steps for the core merge:

  1. Publish the diff file on the related Trac ticket (#50052)
  2. After merge details are known, update Pull request #123 – Self-deactivate the plugin after the functionality has been merged to core
  3. Release WP Auto-updates version 0.8
  4. Commit the Trac diff file to WordPress Core

@azaozz noted that releasing version 0.8 after the diff is available on Trac is needed to make sure the plugin can self deactivate once the diff file is merged into WordPress core. The check in version 0.7 doesn’t actually work with the patch, because the name of the function it is checking changed in the patch

The plugin’s options should also be deleted from WordPress installs once the plugin is uninstalled by sites owners. @audrasjb opened pull request #125 to handle that.

The team noted the feature plugin reached 900+ active installs. 77% are running version 0.7, 12% are running version 0.6 and 11% are running versions 0.6.0 or less.

@whyisjake also implemented prettier on the plugin. It allows to run CSS/JS lint check, using npm test , and to fix linting issues using ESLint --fix option.

Open floor

@azaozz shared some thoughts about keeping some stats on successful/failed autoupdates, on the WordPress.org API side. It’s not a blocker for merging and can be added later. The idea is to potentially have anonymous/aggregated stats per plugin/theme. This is also related to the Tide project, which can use those stats to determine how “safe” an update may be.

@audrasjb asked if it’s directly related to this feature or if it should be handled in a separate ticket/project. For @azaozz, it is part of plugins and themes auto-updates, but it can be a separate Trac ticket.

@pbiron asked if we were talking about stats on the results of auto-updates, or about user preferences for what should be auto-updated (since whether an auto-update is attempted can be controlled by other plugins, such as Easy Updates Manager, etc). Andrew answered that it may be both.

@audrasjb asked what would be the main benefit for the end user? Having prompts to alert on “not recommended” updates? @azaozz doesn’t think it would be a direct communication but an auto-update may be eventually stopped/postponed if there are many failures.

@apedog wanted to mention a version-rollback feature for plugins. For them, it would become relevant as more installations start using WP Auto-updates feature plugin. @audrasjb answered it should eventually be introduced independently of auto-updates feature as it’s not only related to this type of updates mechanism. @apedog pointed out that breakage occurring from a manual update gives the user immediate feedback. An over-night auto-update (especially if multiple plugins/themes were updated) could make debugging much harder. @audrasjb added that the best way to move this independent project forward is to open a ticket on Trac if it doesn’t exists yet. @sergeybiryukov added that WP Core do perform a rollback if a background core update fails (enabled for minor versions by default), that might be helpful when looking into implementing this for plugins and themes too.

@apedog also asked whether WP Auto-updates log the previous version vs new version? For example, for a user encountering breakage from an auto-update. Site breakage can occur even on successful updates – simply due to conflict. @audrasjb answered there is no such log mechanism in core, even for manual updates.

@pbiron asked @audrasjb if Pull request 121 – Add help tabs on update-core, plugins, and themes admin screens is going to be ready on time for version 0.8.0. @audrasjb is on it, but it will probably needs copy review.

The team agreed Help Tabs will be handled separately from the initial core patch, to give it time for copy review.

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

Andrew Duthie 8:52 pm on May 12, 2020
Tags: ,   

JavaScript Chat Summary: May 12, 2020

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.

@wordpress/scripts CSS support

(Slack conversation)

Pull request: https://github.com/WordPress/gutenberg/pull/21730

Discussion topics:

  • There was surprise that this wasn’t already supported.
  • The pull request will add a new package @wordpress/postcss-plugins-preset, which would provide a default set of WordPress’ preferred PostCSS plugins configuration.
    • Similar to @wordpress/babel-preset-default, @wordpress/jest-preset-default, @wordpress/prettier-config
  • Question: Was there any consideration for CSS-in-JS? (styled-components)
    • Needs clarity on desired end-goal
    • Still valuable for plugin authors regardless, if it’s easy enough feature to simply not use if they’d prefer to use an alternative approach.
  • Advantages: Dead code elimination and bundle splitting for CSS
  • It was suggested to request feedback from the CSS group

Action items:

@wordpress/create-block third-party templates

(Slack conversation)

Pull request: https://github.com/WordPress/gutenberg/pull/22175

Discussion topics:

  • It could help to support flexibility of third-party templates, in order to alleviate pressure for first-party templates to support all features.
  • Concern: Is it the purpose of the tool to support third-party templates? If so, why not use something like Yeoman?
    • Counter-point: It’s not unlike Yeoman, but utilizes NPM’s own npm init <initializer> functionality. They’re comparable, but it’s not necessarily a criticism.
    • Suggestion: Focus less on third-party template flexibility, more on first-party “knowledge of blocks”, including additional commands and customizations.
    • Point of contention: Should customizability come from third-party templates, or first-party support?

Action items:

Block Identifier

(Slack conversation)

Topic: Should the block editor provide a stable way to connect server and client data? For example, associate posts to blocks using post meta.

Additional context can be found in the agenda document.

Discussion topics:

  • Question: Is this suggesting some value saved in post meta which corresponds to individual blocks of a post?
    • Answer: Yes
  • Question: What’s the use-case? Is there an example?
    • Answer: It’s needed for the image block.
  • It might be something which is fine to have an ad hoc implementation specific to one or a few blocks, if it’s not a common requirement.
  • Concern: Duplicating data can risk desync (see related post)

Action items:

  • Create an issue which describes the use-case and requirements (Owned by: @sageshilling)

Open Floor

Miscellaneous Updates

@aduth shared a number of updates from the past week:

The coding guidelines documentations we discussed last week are most all merged:
https://github.com/WordPress/gutenberg/pull/22090
https://github.com/WordPress/gutenberg/pull/22030
https://github.com/WordPress/gutenberg/pull/22029

That last one prompted the idea for a new ESLint rule, currently in progress, but potentially blocked on the fact that there appears to be legitimate cases for wanting the “gotcha” behavior.
https://github.com/WordPress/gutenberg/pull/22041

Now pinning .nvmrc to specify Node version in Gutenberg, to avoid issues when running on older branches:
https://github.com/WordPress/gutenberg/pull/22236
(As far as I know, Core does the same)

ESLint 7.0 was released the other day, which notably includes an interesting feature to allow comments within the inline configuration tag
https://eslint.org/blog/2020/02/whats-coming-in-eslint-7.0.0
Example:
/* eslint-disable no-new -- this class has a side-effect in the constructor. */
Very relevant for this previously-suggested rule proposal: https://github.com/WordPress/gutenberg/pull/16795

@sageshilling shared features announced in Next.js 9.4.

News Roundup

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

#core-js, #javascript

Jb Audras 4:25 pm on May 12, 2020
Tags: , , , ,   

Auto-updates feature weekly meeting agenda – May 12th, 2020

Next meeting is scheduled on Tuesday May 12, 2020 at 17:00 UTC and will take place on #core-auto-updates Slack channel with the following agenda:

  • Update on core patch
  • Feature plugin’s scope for version 0.8
  • Prettier implementation
  • Open floor: issues & PR / other topics

Got something to propose for the agenda? Please leave a comment below.

#agenda, #auto-update, #core-auto-updates, #feature-plugins, #feature-autoupdates

Pascal Birchler 1:12 pm on May 12, 2020
Tags: , , ,   

XML Sitemaps Meeting: May 12th, 2020

It’s been a while since the last blog post about the XML Sitemaps feature project. Today I’d like to summarize the developments since last month, and also post the agenda for our upcoming meeting.

Updates

  • Version 3.0 (#181)
    A pull request has been opened to add the change log for our next release, which includes a good amount of improvements over the last version. The goal is for this to be one of the last releases before we put our efforts into a merge proposal.
    Most notable changes: important refactorings, rewrite rule fixes, removal of lastmod.
  • Custom elements in sitemap (#151)
    There is no consensus yet about what the API for adding custom elements (beyond lastmod or priority) could look like, especially when dealing with custom namespaces.
  • Custom elements in stylesheet (#152)
    There is still an open PR that tries to make the XSLT stylesheet more dynamic so it automatically displays sitemap elements added by plugins. That means there’s some overlap with the issue mentioned above.
    Interesting side affect: the PR proposes a new esc_xml() function that might be worth looking into.
  • Road towards WordPress core (#164)
    We’re full steam ahead on improving the source code so it better aligns with WordPress core standards, as well as getting feedback from various core teams on the plugin (i.e. polyglots, accessibility, docs). Also, there is now a Trac ticket to reference! See #50117.

Agenda: May 12th

The next meeting will be held on Tuesday, May 12th at 16.00 CEST.

Items on the agenda so far:

  • Version 3.0 (#181)
  • Custom elements
  • Stylesheets
  • Currently open issues and pull requests. Including:
    • Removing trailing slashes on URLs (#134)
    • Sanitizing object subtypes for use in URLs (#166)
    • Adding filter for WP_Query args (#131) (needs owner)
  • Current roadmap status
  • Open floor

Want to add anything to the above? Please leave a comment here or reach out on Slack.

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

#agenda, #feature-plugins, #feature-projects, #xml-sitemaps

Paal Joachim Romdahl 5:23 am on May 12, 2020
Tags: , ,   

Editor Chat Agenda: 13 May, 2020

Facilitator: @andraganescu. Notetaker: @annezazu

This is the agenda for the weekly editor chat scheduled for 2020-05-13 14:00 UTC.

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

  • Gutenberg 8.1.0
  • Monthly Plan & 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

#agenda, #core-editor, #gutenberg

Lara Schenck 2:17 pm on May 11, 2020
Tags: ,   

Chat Summary: 7th May 2020…

CSS Chat Summary: 7th May 2020

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

I (@notlaura) facilitated the meeting.

CSS audit updates

It’s not specifically part of the audit inititive, but let’s celebrate: CSS for unsupported IE versions was removed in commit 47771. 🎉

Color Scheming Updates

@ryelle experimented with custom properties for color schemes in a Gutenberg PR and left comments on the Iterating on Color Schemes ticket, and mentioned that @nrqsnchz & @joedolson will be working on the design and accessibility side of color schemes.

Also for reference is the Dark Mode project which was not merged due to the difficulty in overriding CSS in parts of the admin. Part of the work to do regarding the color schemes initiative is to make it so that we can have dark mode, and a solution that allows control of all colors in the admin.

I mentioned the design systems practice of abstracting colors (the design tokens) into contextually named custom properties, and offered to add a comment to the ticket.

That was all for this week!

#summary #core-css

Timi Wahalahti 12:26 pm on May 11, 2020
Tags: ,   

X-post: WCEU Online 2020 Contributor Day: Submit your introduction videos, office hours times and introductory session needs this week

X-post from +make.wordpress.org/updates: WCEU Online 2020 Contributor Day: Submit your introduction videos, office hours times and introductory session needs this week

Marius L. J. 8:11 pm on May 7, 2020
Tags: ,   

Agenda for May 11th Site Health Meeting

The weekly Site Health meeting will be held on Monday, May 11, 2020, 16:00UTC in #core-site-health on Slack. (a Slack account is required)

During this past weeks dev chat, the item of moving the minimum PHP compatibility up further this year was brought up as a talking point. This will need a collaborative push to move towards. The desire target this time is PHP 7.1 as the minimum supported version, but to do so we will need to come up with a more effective way of encouraging users to do the upgrade.

At the time of writing, WordPress 5.2 or newer require PHP 5.6 to work. On top of that ~25% of all sites running these versions (WordPress 5.2, 5.3 and 5.4) are using PHP 7.0 or lower, that’s too high a number for us to bump the minimum required PHP version to where we want it.

The ServeHappy dashboard widget alerts users with PHP versions lower than 7.0 at this time. An initial step here would be to increase that threshold to 7.2, the currently most popular version. The team is aware that PHP 7.1 is already EOL (End Of Life), and that 7.2 will be the same come January 2021 (See list of supported PHP versions), but this is a marathon so we are taking it in small leaps to not cause unintended disruptions to the userbase.

That said, the dashboard notice likely won’t be enough for a PHP version push this year, that’s why this upcoming meeting will be focused on brainstorming ideas on other approaches that will help this endeavor, as we will have the upcoming WordPress 5.5 release to implement any changes needed to help move towards the goal.

#agenda, #site-health

Andrew Duthie 12:33 pm on May 7, 2020
Tags: ,   

JavaScript Chat Summary: May 5, 2020

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript). Thanks to @cbravobernal for compiling these notes!

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

Visual Testing Revisited

(Slack conversation)

@aduth talks about taking a look to the tool Chromatic. It is integrated with Storybook and seems to be capable of making visual regression tests of isolated components.

Team talks about how important it is to focus and give a little more love to Storybook.

Q comments that will be more important as they focus on 

Chromatic turns your stories into visual test baselines. Each story is rendered in Chrome, Firefox, and Internet Explorer 11 simultaneously then compared to a screenshot of the “last known good state”. Whenever there are UI differences you get notified.

We have to notice that there is already a pull request for end-to-end testing with browserstack for old browsers.

There is a “sponsorship” for Chromatic with Open Source projects. See link

Action:

  • Follow-up on this, or to start experimenting. (needs champion)

Coding Guidelines Documentation

(Slack conversation)

@aduth asks for opinion about these pull requests:

@aduth observed some relation to “language support” and “React components”, since there’s been a handful of requests recently that “X” JavaScript feature be supported in order to make writing class components easier. He is going to merge them in a near future (some are already merged).

Also, the team has committed that Gutenberg will only support TC39 Stage 4 (“Finished”) ECMAScript (JavaScript) language features. 

Action: 

Open Floor

Block IDs

(Slack conversation)

@sageshilling has an issue: when looking at blocks in the post ,they don’t have an id associated with them. Images and reusable blocks have the post_id, but the post_id updates with the page edits. Also, the block attributes has no identifier- that’s unique and constant throughout. With tables we have the unique key, so it’s something that we’re used to having to use as a reference.

Action: 

  • Continue the discussion in a pull request or issue.

Auth Check Interval

(Slack conversation)

@dsix asks for review at #49573 . The issue is that the server-side code was updated to ignore auth_check_interval parameter in the heartbeat request, so that value has no effect.

His assumption, based on the fact that the server-side code was changed to return the auth_check data on every heartbeat, was that the interval was no longer needed.

Action:

  •  Invest more time for testing / feedback. Ping the people involved in the original change.

#core-js, #javascript