XML Sitemaps Meeting: April 14th, 2020

Meeting Recap: April 7th

For reference, check out the previous blog post from April 7th:

What we’ve discussed last week:

  • Plugin Conflicts (#146)
    We reached the conclusion that such conflicts are actually a non-issue. Plugins are expected to override the default sitemap functionality. For consistency reasons, we keep the wp- prefix.
  • Last modified date (#145)
    There is one open question on the PR to keep lastmod for object types that support it out of the box (i.e. posts).
    Current status: needs reviews.
  • Rewrite Rules (#147)
    A change was proposed to improve the way rewrite rules are registered for sitemaps. This would avoid having to flush rewrite rules when custom providers are added.
    Current status: needs contributors / reviews.
  • Roadmap
    WordPress 5.5 is ought to be released in August. We settled on the following roadmap for sitemaps:
    • Fix remaining big issues – April
    • Refactor code to be closer to WP core standards, add safeguards so nothing breaks after merge – April
    • Publish Merge proposal – May
  • Extensibility
    It was suggested to add a filter for the <urlset> element’s attributes so that plugins could easily add namespaced elements to a sitemap (e.g. for image sitemaps).

Agenda: April 14th

The next meeting will be held on Tuesday, April 14th at 16.00 CET.

Items on the agenda so far:

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

Editor Chat Agenda: 15th April, 2020

Note taker and facilitator: @ajitbohra

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

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

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

X-post: Accessibility Team Chat Changes for Daylight Savings Time

X-post from +make.wordpress.org/accessibility: Accessibility Team Chat Changes for Daylight Savings Time

X-post: Accessibility Team meeting notes – April 10, 2020

X-post from +make.wordpress.org/accessibility: Accessibility Team meeting notes – April 10, 2020

Core Team Chat Changes for Daylight Savings Time

As @audrasjb noted in last night’s Dev Chat summary, three meetings will start one hour earlier, beginning next Wednesday, April 15.

That’s because all the countries who switch to Daylight time have done that. The US is traditionally the beginning of a four-week process that ends early in April. The process reverses in the fall.

The Core devchat will start at 20:00 UTC, or 8 pm UTC, on Wednesdays.

That in turn will push the New Contributor meeting and the Release Model Working Group meeting, which alternate Wednesdays immediately beforehand, to 19:00 UTC, or 7:00 pm UTC.

The Release Model Working Group will meet on April 15, and the New Contributor meeting will see you on April 22.

So mark your calendar accordingly, and the teams hope to see you there!

In the meantime, if you celebrate a spring holiday, please accept the community’s wishes for a happy, healthy and safe occasion.

#devchat, #meeting-changes

CSS Chat Agenda: 9nd April…

CSS Chat Agenda: 9nd April 2020

This is the agenda for the upcoming CSS meeting scheduled for Thursday, April 9, 2020, 5:00 PM EDT.

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!

  • CSS audit status update
  • Open floor

#agenda, #core-css

Devchat meeting summary – April 8, 2020

@audrasjb facilitated the chat on this agenda.

Full meeting transcript on Slack

Announcements

Upcoming Releases

Next minor release: WP 5.4.1

While there is no release planning for the moment, there is already 12 tickets in the milestone.

2 tickets are labelled with major severity. It will probably lead to a point release in few weeks.

@whyisjake will run a first bug scrub for WP 5.4.1 on Thursday April 9, 2020 at 20:00 UTC.

@marybaum volunteered to run another bug scrub on Friday.

Next major release: WP 5.5

There is currently 27 tickets with early keyword in the milestone. Those tickets need to be merged as soon as possible.

@davidbaumwald will run a first bug scrub for WP 5.5 on Tuesday April 14, 2020 at 19:00 UTC.

Component maintainers updates

@afragen shared a number of tickets for theme compatibility that still need eyes and are marked early. All have working patches and need further testing.

@audrasjb pointed out that the Auto-updates team needs a cross-team discussion about wording and specifically concerning the action links text labels. Design and Accessibility teams could help, and of course everyone interested. Design & Wording validation is the main goal for the next version of the feature plugin.

@garrett-eclipse shared that the Privacy team has a multisite focus in 5.5 so any people from Network/multisite component is welcome to assist.

Daylight saving time: devchat meeting time change

As Daylight saving time already started for every countries/locales on our planet 🌏 the devchat meeting time will be adjusted from 21:00 UTC to 20:00 UTC.

The next meeting will be held on Wednesday April 15, 2020 at 20:00 UTC.

@marybaum is going to publish a specific announcement about this adjustment.

#5-4-1, #5-4, #5-5, #dev-chat, #devchat

WordPress 5.5: Call for Tickets

With 5.4 released, let’s officially kick-off 5.5! As we do with each release, we want to fix bugs, add new tools and make WordPress the best user experience. The blocker editor (and full site editing) are still at the top of the WordPress goals list, but what other tickets do you think need some attention in this release cycle?

Share Your Feedback!

  • What do you want to see included in 5.5?
  • What are current UX pain points?
  • What features can we add or iterate on?
  • Component Maintainers: what tickets of yours do you think will be ready to ship in 5.5 and need some review/feedback/approval/etc?

Note: Adding your ticket here won’t necessarily guarantee inclusion. But no one can fix things they can’t see, so bravely share your thoughts!

#5-5

Lazy-loading of images is in core

As planned, the patch for adding loading attribute to img tags is now committed to core (see #44427).

Based on preliminary testing there seem to be no conflicts with most plugins that implement lazy-loading for images. Nevertheless the authors of these plugins are strongly advised to test them in trunk (WordPress 5.5-alpha) and confirm their plugins work as expected.

It would also be very beneficial to the users if the plugins that implement lazy-loading are updated to utilize the new Core functionality and filters, and to use the new loading HTML attribute. Please see https://html.spec.whatwg.org/multipage/embedded-content.html#attr-img-loading and https://html.spec.whatwg.org/multipage/urls-and-fetching.html#lazy-loading-attributes.

A dev note with more details on the implementation and how to customize the behavior will be published closer to the WordPress 5.5 release.

#feature-lazyloading

Auto-updates feature meeting summary: April 7th, 2020

These are the weekly notes for the WP Auto-updates team meeting that happened on Tuesday April 7th, 2020, based on this agenda. You can read the full transcript on the core-auto-updates Slack channel.

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.4 🌹

As a reminder, version 0.4 was released one week ago and contains all the core functionalities of the project. The team opened a call for testers on Make/Tests.

Version 0.5 scope and timeline

For the moment, there are 5 PRs merged into milestone 0.5.

The main goal of version 0.5 is to iterate on design and wording. There is a bunch of design focused issues, but the idea is to iterate on links colors and wording first.

All the attendees think all the links should be blue and text should be black. Indeed, red links are used for destructive actions in WordPress core, and it’s not relevant for auto-updates disabling. So let’s get rid of red links and green “Auto-updates enabled”. Let’s just use blue for links and black for text. This change will be part of 0.5.

About wording, @audrasjb wanted to point out that “auto-update” (don’t forget the hyphen) is the official wording for the feature in WordPress as it has been validated ahead of the Feature Plugin with WP project leads.

 @pbiron pointed out his concerns about removing any filters on the plugins screens, especially the “Auto-update disabled” filter, as it’s really useful to see what plugins are not auto-updated. The team agreed that this filter is not going to be removed.

How to avoid conflicts with third party plugins?

@ronalfy pointed out, from a third-party standpoint, that if a plugin uses a custom option for storing updates, it’d be nice to be able to sync the two through actions and filters. So if WordPress enables an auto-update, the plugin can hook into that action and update their own list accordingly. The same would be useful for filters when retrieving options so the plugin could theoretically merge the two. Ideally third-parties could just use WordPress options, but there’s backwards compatibility issues there.

For reference, see issue #63 and pull request #66.

@timothyblynjacobs added that being able to add bits to the auto update column itself would be useful as well.

Next steps:

  • Add an action hook on auto-update enabling and disabling for each theme/plugin.
  • Add a hook to filter the auto-update column content itself.

Discussion/decision concerning AJAX handling in the Feature Plugin

While this is not a top priority, it’s a nice to have. The team agreed to target version 0.6 for this enhancement.

Discussion about the labels used for enabling/disabling auto-updates

There is a proposal to change the current action links labels.

@pbiron and @audrasjb pointed out that on/off and “plain” Enable/Disable (without “auto-updates”) could be too easily confused with Activate/Deactivate (even with them being in the Automatic Updates column).

There is definitely a need for a cross-team discussion about the best wording for those links.

Meeting time and Daylight Saving Time

The team agreed to move the meeting time from 18:00 UTC to 17:00 to follow Daylight Saving Time.

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