Make WordPress Core

Keyboard Shortcuts | Hide comment threads
Tonya Mork 12:54 pm on September 1, 2020

Bug Scrub Schedule for 5.6

With 5.6 officially kicked off, time to schedule the 5.6 sessions. These 5.6 specific ticket scrubs will happen each week until the final release.

Past Scrubs:

Upcoming Scrubs:

Check this schedule often, as it will change to reflect the latest information.

Other 5.6 component or specific scrubs?

What about recurring component scrubs and triage sessions?

The above 5.6 scheduled bug scrubs are separate and in addition.

For your reference, here are some of the recurring sessions:

  • Design Triage: Every Monday 16:30 UTC at #design
  • Gutenberg Design Triage: Every Tuesday 16:00 UTC at #design
  • Accessibility Scrub: Every Friday 14:00 UTC at #accessibility
  • APAC-friendly Bug Scrub: Every Tuesday at 05:00 UTC at #core will continue during the cycle, alternating focus between core and editor.

Want to lead a bug scrub?

Did you know that anyone can lead a bug scrub at anytime? Yes, you can!

How? Ping me (@hellofromtonya) on slack and let me know the day and time you’re considering as well as the report or tickets you want to scrub.

Planning one that’s 5.6-focused? Awesome! We’ll add it to the schedule here along with your name. You’ll get well deserved props in the weekly Dev Chat, as well as in the #props Slack channel!

Where can you find tickets to scrub? All open tickets for 5.6, in order of priority, can be found here. Tickets that haven’t seen any love in a while are in particular need. Those can be found in this query.

Need a refresher on bug scrubs? Checkout Leading Bug Scrubs in the core handbook.

Questions?

Have a question, concern, or suggestion? Want to lead a bug scrub? Please leave a comment or reach out directly to me (@hellofromtonya) on slack.

#5-6, #bug-scrub

Andrew Ozz 10:44 pm on June 29, 2020

Updating jQuery version shipped with WordPress

This has been a long time coming; the Trac ticket #37110 is already few years old.

Following the recommendations of the jQuery team, the updating has to happen in stages:

  1. Remove jQuery Migrate 1.x. This is planned for WordPress 5.5.
  2. Update to the latest version of jQuery and add the latest jQuery Migrate. This is tentatively planned for WordPress 5.6 depending on test results. Updating to the latest jQuery UI, version 1.12.1, is also planned for 5.6.
  3. Remove jQuery Migrate. This is tentatively planned for WordPress 5.7 or later, depending on testing.

As planned, a Test jQuery Updates plugin was released to make it easy to test different versions of jQuery, jQuery Migrate, and jQuery UI. Please install it and thoroughly test if everything works as expected, especially on the front-end, or at the settings pages of other WordPress plugins.

How to help with testing

The plugin has a settings screen found under the Plugins menu in WordPress admin. Different versions of the jQuery libraries can be selected there for testing. Please test by:

  1. Disabling jQuery Migrate, and leaving jQuery and jQuery UI at the default versions (for WordPress 5.5).
  2. Selecting jQuery 3.5.1, enabling jQuery Migrate, and selecting jQuery UI 1.12.1 (for WordPress 5.6).
Test jQuery Updates settings screen, under the Plugins menu.

Updating your code

To get ready for this jQuery update, it’s important that you update your code. The migrate plugin will assist you in identifying issues. Additionally, the jQuery Core 3.0 Upgrade Guide and 3.5 Upgrade Guide provide detailed information about what has changed. As the browser supported list is also updated, this is also a great time for you to revisit what versions of browsers are supported by your themes and plugins.

See a bug?

If you find a bug in Test jQuery Updates, or if you run into a jQuery related issue, please report it at http://wayback.fauppsala.se:80/wayback/20200929170053/https://github.com/WordPress/wp-jquery-update-test. If the issue is with a default script in WordPress, please open a new ticket on Trac.

Thanks @andreamiddleton, @annezazu, and @jorbin for helping with this post.

#5-5, #jquery

#dev-notes

Francesca Marano 4:16 pm on September 29, 2020

Test scrub for WordPress 5.6

As part of the 5.6 release, we’ll be hosting test scrubs starting this Friday, October 2, 2020 at 01:30 PM UTC in the #core channel on Slack.

During the first meeting, we will go over the goal of the scrubs and make sure everyone is set up for testing.

During the upcoming scrubs, we’ll go through this Trac report: http://wayback.fauppsala.se:80/wayback/20200929170053/https://core.trac.wordpress.org/tickets/needs-testing, addressing 5.6 tickets first.

#5-6, #bug-scrub, #test

Dee Teal 8:32 am on September 29, 2020

Dev Chat Agenda: September 30th 2020

Here is the #agenda for this week’s meetings happening at:
Wednesday, September 30, 2020 at 05:00 AM UTC and Wednesday, September 30, 2020 at 08:00 PM UTC .

Please share any items you’d like to include in the comments below.
* Announcements

The #dev-chat meetings will be held on Wednesday, September 30, 2020 at 05:00 AM UTC and Wednesday, September 30, 2020 at 08:00 PM UTC. These meetings are held in the #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack .

#5-6, #agenda

Jan Thiel 8:52 am on September 29, 2020

Something I would like to add for the open floor: http://wayback.fauppsala.se:80/wayback/20200929170053/https://core.trac.wordpress.org/ticket/19879

Small change proposal regarding the quota calculation caching in Multisites. The ticket is around for some years now with no obvious reason why it is stale and wasn’t pursued further.
Implementing it would be a massive performance improvement for sites with huge media libraries and/or slow file systems like NFS using the WordPress Quota system.

Tonya Mork 10:09 pm on September 28, 2020

5.6 Bug Schedule Changes for the Week of Sept 28, 2020

Please note some scheduling changes for this week.

Cancelled Scrub:

Unfortunately, today’s APAC-friendly bug scrub, scheduled for Tuesday, September 29, 2020 at 04:00 AM UTC, is being cancelled.

New Scrub:

A new 5.6 ticket (aka bug) scrub is scheduled for Thursday, October 1, 2020 at 05:00 PM UTC. Focus of this scrub will be 5.6 enhancement and features that haven’t been active in awhile. Here’s the list that will be used for this scrub. It’ll happen in the #core channel on Slack. Come join us.

The full schedule for 5.6 scrubs can be found here.

Props to @meaganhanes for proofreading and @davidbaumwald for review.

#5-6, #bug-scrub

Mel Choyce-Dwan 7:31 pm on September 28, 2020

TT1 Chat Summary: 28 September 2020

Full meeting transcript here on Slack. I (@melchoyce) facilitated the meeting.

Housekeeping

Because this was our first meeting, I focused largely on introducing the theme and giving a brief introduction on how people can contribute. I specifically called out:

  • Good first bug
  • Help needed
  • …and reviewing PRs! PR review is a great way to keep progress moving for the project, and a great way for new contributors to get acquainted with the default theme creation process and code standards.

Q&A

We moved on to questions next.

@metodiew asked if people should open a new issue before making a PR. @jffng replied that opening a new PR is fine, but if someone has specific questions that needs discussion, open an issue.

Next up, @joyously asked about the build process. We determined that it needs more documentation for new contributors, and there’s an existing developer documentation issue people can add questions and ideas to. We also discussed the need for more clarity around what parts of the build process will make it into core.

@bgnicolepaschen had a question about the starter content being included with the theme. This is a topic currently under discussion, and more input is appreciated. We discussed using female artists, and even the possibility of using art from our community members.

@joyously brought up the idea of including a sidebar with the theme. I volunteered to create some mockups so we could explore adding a sidebar template to the FSE version of the theme, which we’ll be working on after Beta 1. This will be a great opportunity to explore the best way of adding sidebars to fully block-based themes.

Next up, we talked about where to discuss questions, comments, etc. about the theme — on Slack, or in GitHub? I said either is fine, and recommended that if we have conversations in Slack, we summarize them on GitHub.

Lastly, we clarified browser support and talked a little about bug gardening.

Please join us Friday, October 2, 2020 at 04:00 PM UTC for our next bug scrub!

#bundled-theme, #twenty-twenty-one

annezazu 6:32 pm on September 28, 2020

Editor Chat Agenda: 30 September, 2020

Facilitator and notetaker @annezazu

This is the agenda for the weekly editor chat scheduled for Wednesday, September 30, 2020 at 02:00 PM UTC

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

  • Gutenberg 9.1
  • Check in on the 5.6 Project board
  • Monthly Plan review for September 2020 and key project updates with a sneak peak of October 2020 monthly plan. This will be time to focus on current issues, what is being done, and where help that is needed.
    • Global Styles
    • Navigation screen and Navigation block
    • Widgets screen
    • Customizer screen
    • Full Site Editing
  • Task Coordination
  • Open Floor

Even if you can’t make the meeting, you’re encouraged to share anything relevant for the meeting in the comments below:

  • 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.

#core-editor #core-editor-agenda

Dan Farrow 3:59 pm on September 28, 2020

CSS Chat Summary: 24 September 2020

Full meeting transcript here on Slack. @notlaura facilitated the meeting.

Housekeeping

@notlaura asked for a volunteer to help share the responsibility of writing up meeting notes. @danfarrow (me!) & @ryelle offered to help.

@ryelle cleared up a query from @kburgoine about the /here command in Slack

CSS Audit (#49582)

@danfarrow reported some progress running @ryelle‘s CSS audit tool with @notlaura‘s report generation patch, in order to work on styling the HTML output.

@ryelle is merging some of @notlaura‘s updates in smaller chunks, which means the PR needs to be rebased. @notlaura‘s next step will be to complete the rebase so that the audit PR can be merged. Templating updates could then continue in a new PR.

@ryelle hopefully resolved an issue about the property-values audit not running by pointing out that, when specifying which audits to run, the --all flag doesn’t include the property-values audit.

@ryelle has added some tests to the audits for which there was much appreciation.

Color Scheming (#49999)

@ryelle reported some great progress following her post on Make WordPress Design and the subsequent Slack discussion in #design.

The outcome is that we’re using the right color list currently, and we got a volunteer to help check out the updated screens in use.

@ryelle‘s next step is to set up a dev site in order to share the color scheme updates for feedback.

Open floor

@notlaura asked if anyone knew of discussion of color functions being added to CSS. @ryelle posted a link to a w3c working draft for implementing a color-adjust function which includes possible solutions including color-contrast, color-mix, brightness() and relative color syntax

Thanks to everybody who attended this week!

#core-css, #summary

Joost de Valk 11:33 am on September 26, 2020

Proposal: A font enqueue API for WP core

The themes team is proposing for themes to require local web font loading. The reasoning behind that is one of privacy, usability and speed. But web font loading is hard. The reason a large portion of sites on the web uses Google Fonts is that Google Fonts makes it relatively easy. The package the themes team has made to make local font loading easier is a very nice step in the right direction. I propose we go one step further and add an API to embed fonts to core.

The simple gist of the proposal is this: we should implement wp_enqueue_font. Building that so that fonts are always loaded the same way allows us to continuously improve the way we load fonts as the standards evolve.

This trac ticket elaborates with a very elaborate and specific proposal on what it should do and how it should work in my and @jonoaldersonwp‘s mind. The aforementioned themes team post also provides a lot of context. We would like to hear your feedback on whether this is a good idea and whichever concerns you might have!

Props @sergeybiryukov, @aristath, @adamsilverstein for reviewing.

Mikel King 6:15 pm on September 28, 2020

So how would this work with something like Adobe Fonts where their licensing, for even their “free” fonts, explicitly prohibits local loading?

Joost de Valk 6:22 pm on September 28, 2020

Well I guess you shouldn’t use it with theirs then 🙂

Mikel King 7:40 pm on September 28, 2020

Bringing it up as the language above says “requiring”. Thanks for clarifying.

Believe me I really don’t like Adobe fonts, their licensing is extremely oppressive.

Jon Brown 6:27 pm on September 28, 2020

This sounds great.

The one thing that comes to mind as a theme dev is that site owners love being able to pick from the entire catalog of google fonts. I’m presuming this isn’t going to magically provide a UI to download those fonts to local though and that’s still going to be theme/plugin territory to do.

I do see reviewing the trac ticket the idea is this action can be used to load local or remote fonts, cool, but I do wish the it included an example of using TypeKit or GoogleFonts remotely. Because while sure local is prefered, my hunch is it’s going to be used far more to load from a remote library, rather than static local copy.

Joost de Valk 6:29 pm on September 28, 2020

I’m presuming this isn’t going to magically provide a UI to download those fonts to local though and that’s still going to be theme/plugin territory to do.

While that UI isn’t going to magically exist, it’s going to be a lot easier to build that plugin now…

I do see reviewing the trac ticket the idea is this action can be used to load local or remote fonts, cool, but I do wish the it included an example of using TypeKit or GoogleFonts remotely

That should certainly be in the documentation too when this is done, agreed.

Jon Brown 6:29 pm on September 28, 2020

And… just found the Theme teams code here http://wayback.fauppsala.se:80/wayback/20200929170053/https://github.com/WPTT/webfont-loader so aparently yes to download google fonts at least

Carike 9:07 am on September 29, 2020

Very excited to see the consolidation of thoughts and projects here. 😀 Cross-functional teams rock.

Loading assets locally seems to me to be the sane default.
While I do believe that site owners / admins should be able to easily utilize CDNs if they want to (extend-ability), this should require some explicit action (e.g. installing a plugin featuring some concise, plain-language disclosures). Calls should not be made without any awareness that it is happening [or any reasonably easy way to turn it off!].

A related concern is the use of the Noto font family by the block editor.
Particularly as the calls to Google’s CDN are very difficult to find / block / remove.
Ari created a small code-snippet to remove the related dependencies.
This is something that should be more widely available.
I second Jan’s suggestion that Ari should submit it as a plugin and I hope that it will form part of a collection of privacy-related snippets as time goes on.
However, a fonts API would presumably make it possible to use locally hosted Google fonts as part of Core as well. 😀

John Huebner 2:26 pm on September 29, 2020

I think this is a great idea. When it comes to improving site performance one on my biggest headaches is the loading of fonts, especially the loading of the same font, or different versions of the font , multiple times (ala font-awesome). The main issue with it being loaded multiple times is that developers each use their own handle for enqueuing and that they also do not enqueue them on the right hook (for example using wp_print_styles or admin_print_scripts) causing me to do back flips figuring out how to remove them so that I can ensure the most current version is loaded and loaded locally while dequeuing an ever expanding list of handles. I honestly don’t care about the details of how it’s done, but it needs to deal with this issue, if not then we’ve gained nothing.

Lara Schenck 5:23 pm on September 24, 2020

CSS Chat Agenda: 24 September 2020

Note: One hour before the meeting this week, @kburgoine will lead the core CSS triage! Triages are every other week one hour before the weekly chat, at 4pm EDT.

This is the agenda for the upcoming CSS meeting scheduled for Thursday, September 24, at 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!

  • Housekeeping
    • Need a volunteer to help write up meeting summaries
  • Updates
    • CSS Audit (#49582) – Report generation
    • Color Scheming (#49999) – Feedback from design on color list
  • Open floor + CSS link share

#agenda, #core-css

thelmachido 5:18 pm on September 24, 2020

Dev Chat Summary – 23 August 2020

Greetings! Here’s what happened in Core Wednesday, September 23, 2020, 07:00 AM GMT+2 and Wednesday, September 23, 2020, 10:00 PM GMT+2 on the #agenda.

0500 core devchat

@thewebprincess led the discussion in the meeting was a bit slow the team decided to run a bug scrub. Find the full Slack archive here.

2000 core devchat

@laurora facilitated the chat and @thelmachido took notes. Find the Full Slack archive here.

Announcements

To see an overview of what’s happening keep an eye on make/updates, we’ve got quarterly updates from the team coming soon.

Highlighted blog posts

Dual licensing Gutenberg under GPL v2.0 and MPL v2.0
We need to gather feedback on the proposal to dual-license Gutenberg under GNU General Public License, v2 (GPL v2) and the Mozilla Public License v2.0 (MPL v2.0). Please share your perspective on the proposal from Maxime by adding comments to the post.

Introducing the next WordPress default theme – Twenty Twenty One Weekly meetings on the theme will start on Monday 28 September at 15:00 in #core-themes. @chanthaboune clarified that the team will be shipping one theme, based on Seedlet, bundled with the release and they will be exploring a second FSE theme, after the first is stable, that is not bundled with the release. Besides what was discussed in 5.6 planning post, FSE will now be done in the Gutenberg Plugin as a beta feature. See what the team said in the full slack discussion and another on-going discussion is going to be opened on make/core.

Proposal on REST API Authentication / Application Passwords
George Stephanis has put together a proposal for this, the hoped timeline for this proposal is version 5.6 but the team is not yet certain. There have been attempts to get other authentication mechanisms to a considerable state but none have been proposed for core as yet. See what the team contributed to the discussion in slack. The discussion from here on out will be on #core-passwords even though they had temporarily been in #core-restapi. Feel free to join the discussion there.

How gather updates from component maintainers & focus leads
Go through the post and share your opinion on the best way to gather updates as we are getting closer to release. Please share your perspective by commenting on the post by Wednesday 30 September.

Facebook embeds being deprecated
How will cached embed look after the deprecation date?. There is need to test and collect data on how the JS scripts included in the embed will look after deprecation. How will the marketing crew share this information and more broadly with users as a whole?. These are some of the discussions that will be wrapped up in the comment section of the post.

Component maintainers

Build/Test Tools
Continued work on PHP 8 support. With quite a few fixes to unit tests and some fixes to core, this brings the tests from 87 errors and 331 failures on PHP 8 a couple of weeks ago (when the work has just started) to only 5 errors and 17 failures now (still to be addressed). Ticket #50913 includes most of the progress on this, some work was also done in other related tickets here.

For I18N component one change was committed this week. The Default Language network option in Multisite now has a language icon next to it. View ticket #51359.

Menus & Widgets have a couple of tickets that are waiting for committers to have a look at them.

Upgrades & Install the first patch for Major Core auto-updates ticket has been added, also there are a couple of tickets that are waiting for committers to have a look at them.

Additional eyes needed on testing and review for backlog on the Privacy component.

No updates of note this week from Date/Time, Permalinks or Site Health.

Open Floor

@ramiy put together a Post & Infographic on WordPress release facts & stats.

@enricocarraro is working towards making WordPress Strict CSP-compatible. Inline scripts refactoring #39941 and Inline event handlers and JavaScript URIs refactoring #32067. If anyone could review his PR that would be greatly appreciated.

Next Dev Chat meetings

The next meetings will take place on Wednesday, September 30, 2020, 07:00 AM GMT+2 and Wednesday, September 30, 2020, 20:00 PM GMT+2 in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account. 

#5-5-1, #5-5-2, #5-6, #dev-chat, #summary

Lara Schenck 5:17 pm on September 24, 2020

CSS Chat Summary: 17 September 2020

Housekeeping

Reminder that next week will be the core CSS bug scrub, this time led by @kburgoine and starting at 4pm EDT on Sept. 24 (one hour before the weekly chat). The bug scrubs (a.k.a. triages) are a great way for new contributors to get involved!

CSS Audit (#49582)

I’ve been working on a branch that displays the audit data in Github pages. The initial version can be seen here and the work in progress pull request is here. The next steps for the PR are getting documentation in place about generating reports, and styling the template.

More important, as @ibdz noticed – it looks like the audit for properties and values is not running, so we definitely need to get the data for about font-sizes and pixel usage into the report.

Color Scheming (#49999)

@ryelle drafted a post to for Make design about the color replacements work so far, specifically to ask what color list we should use, and to start gather folks who would be interested in testing the replacements once a list has been decided on.

Open floor + CSS link share

I shared a link about the ::marker pseudo-element that allows us to style list bullets with CSS. It does not have full browser support yet, but is definitely a feature that can be used with @supports feature queries.

Thanks to @CodeXplorer and @ibdz for being enthusiastic first time attendees!

#core-css, #summary

Welcome

Welcome!

The WordPress core development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:

Communication

We use Slack for real-time communication. Contributors live all over the world, so there are discussions happening at all hours of the day.

Our core development meetings are every Wednesday at 05:00 UTC and 20:00 UTC in the #core channel on Slack. Anyone can join and participate or listen in!