Make WordPress Core

Keyboard Shortcuts | Hide comment threads

Upgrade/Install component meeting agenda for August 3, 2021

The next meeting is scheduled on Tuesday, August 3, 2021 at 05:00 PM UTC and will take place on #core-auto-updates Slack channel with the following agenda:

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

#core-auto-updates, #updater, #upgrade-install

CSS Chat Summary: 29 July 2021

The meeting took place here on Slack. @notlaura facilitated and @danfarrow wrote up these notes.

Housekeeping

Custom Properties (#49930)

  • @notlaura shared her draft Make post calling for contributors. UPDATE: The post has now been published here!
  • @Dave Ryan shared a note from his PR about the need for some common colour values – more discussion needed on this
  • @ryelle gave an update on her recent progress:
    • common.css has been updated and pushed to the try/custom-properties branch
    • Making PRs to try/custom-properties is a great way for contributors to add their contributions
    • She is keeping try/custom-properties up-to-date with master
    • Anybody can give feedback on any PRs in that repo
  • @Dave Ryan asked if fallback values should be provided as he’s seen some changes that use them and some that don’t. @ryelle clarified that she had used them in admin-bar.css as admin color schemes don’t apply to the frontend, so the custom properties may not be defined. @Dave Ryan pointed out that the same reasoning applies to the login page too
  • @notlaura suggested that the next few meetings which have work sessions should begin with a quick check in for updates & housekeeping and then straight into the work session

CSS Link Share / Open Floor

Thanks everyone!

#core-css, #summary

Editor Chat Agenda: 4 August 2021

Facilitator and notetaker: @jorgefilipecosta

This is the agenda for the weekly editor chat scheduled for Wednesday, August 04, 2021, 04:00 PM GMT+1.

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

If you are not able to attend the meeting, you are encouraged to share anything relevant for the discussion:

  • 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, #core-editor-agenda, #meetings

A few things for the Open Floor.
1- First item:
The Shortcode block does not have alignment or a way to add a custom CSS. Here is a conversation in slack which would be helpful to take a closer look at: http://wayback.fauppsala.se:80/wayback/20210803145719/https://wordpress.slack.com/archives/C02QB2JS7/p1627590018095900
(Another issue came up during the conversation.)

2- Second item:
The Accordion block has gone a few rounds and not landed yet. I believe it will be helpful to land a component on the backend and a new block on the frontend.

One item for the Open floor from the Mobile Team:

We are planning to add the react-native-webview package dependency to port the preview functionality of the Embed block on native mobile, but it needs yarn during installation (reference). We’d like to propose bumping the Gutenberg requirements to include yarn and wanted to check if that would be a problem. More than happy to consider other suggestions, or open this up for discussion elsewhere, thanks! 🙇‍♂️

A Week in Core – August 2, 2021

Welcome back to a new issue of Week in Core. Let’s take a look at what changed on Trac between July 26 and August 26, 2021.

  • 24 commits
  • 24 contributors
  • 85 tickets created
  • 7 tickets reopened
  • 58 tickets closed

Pending the appointment of the WordPress 5.9 team, a number of tickets have been fixed, waiting for the next minor release(s). No release date is yet available for 5.8.1, but it should arrive in a couple of weeks.

Ticket numbers are based on the Trac timeline for the period above. The following is a summary of commits, organized by component and/or focus.

Code changes

Build/Test Tools

  • Post a message to #core in Slack when a workflow fails – #52644
  • Remove the check for changes to version-controlled files in the Test Old Branch workflow – #53799
  • Revert the test and coding standards changes in [51511]#52644
  • Split packages and blocks to their webpack configs – #53690

Bundled Themes

  • Remove extra trailing spaces from translatable strings in block patterns – #53774

Coding Standards

  • Apply some alignment fixes from composer format#53729
  • Coding Standards: Fix typo in the JS function name for handling the password reset button – #53359
  • Code Modernization: Silence the deprecation warning for missing return type in JsonSerializable_Object#53635
  • Add missing documentation for the minute parameter of WP_Query#53399

Documentation

  • Clarify the @return value for WP_Filesystem_Base::getnumchmodfromh()#53399
  • Correct @return type for WP_Filesystem_Base::getnumchmodfromh()#53793
  • Correct the documented allowed range for the minute and second parameters of WP_Query#53399
  • Document the $wpdb global in WP_Debug_Data::get_mysql_var()#53845
  • Fix typo in the WP_Upgrader::install_package() description – #53399
  • Replace $this in hook param docs with more appropriate names – #53457

Networks and Sites

  • Replace two remaining occurrences of “blog” with “site” in user-facing strings – #53775

Site Health

  • Add some more MySQL information to the Site Health Info screen – #53845

Site Health

  • Standardise site health check status message punctuation – #53594

Taxonomy

  • Pass correct default value for $post_id to wp_terms_checklist() in the posts list table – #43639

Themes

  • Add “Template Editing” to the list of WordPress theme features – #53556, #meta5802
  • Make sure get_theme_mods() always returns an array – #51423

Upgrade/Install

  • Add files for 5.8 to the $_old_files list that were missed – #53702
  • Avoid creating nonce during installation – #53830
  • Skip any node_modules directories when removing Genericons example.html files on update – #52765
  • Store correct result when bulk updating plugins or themes – #53002

Props

Thanks to the 24 people who contributed to WordPress Core on Trac last week: @SergeyBiryukov (3), @desrosj (3), @audrasjb (3), @jrf (2), @johnbillion (2), @donmhico (2), @mukesh27 (2), @afragen (2), @pbiron (1), @ocean90 (1), @WFMattR (1), @aristath (1), @youknowriad (1), @poena (1), @pwtyler (1), @tareiking (1), @bobbingwide (1), @zodiac1978 (1), @xknown (1), @hellofromTonya (1), @sanketchodavadiya (1), @swissspidy (1), @schlessera (1), and @ankitmaru (1).

Congrats and welcome to our 2 new contributors of the week! @pwtyler and @tareiking ♥️

Core committers: @sergeybiryukov (15), @desrosj (5) and @johnbillion (4).

#5-8, #meta5802, #week-in-core

Editor chat summary: Wednesday, 28 July 2021

This post summarizes the latest weekly Editor meeting (agenda, slack transcript), held in the #core-editor Slack channel, on Wednesday, July 28, 2021, 14:00 UTC.

WordPress 5.8

WordPress 5.8 was released on 20th July check out the release post for a complete list of features and enhancements.

Gutenberg 11.1.0

Gutenberg 11.1.0 was released on 21st July check out the release post for a complete list of features and enhancements:

Gutenberg 11.2.0

Gutenberg 11.2.0 RC is now available for testing.

Monthly Plan

The monthly update containing the high-level items that Gutenberg contributors are focusing on for June are:

  • Global Styles.
  • Block-based Widget Editor.
  • Navigation block.
  • Full Site Editing.

For a detailed plan check out monthly priorities post.

Updates on the key projects

@chipsnyder

For the Mobile side of things we have:

  • Soon Working to update the Mobile Gallery Block Refactor with the changes from Web, should be ready this week.
  • Work for the iOS share extension on hold as we investigate some of the technical challenges there
     
    In Progress:
  • Editor Onboarding.
  • Adding search to the block inserter.
  • Embed block.
  • Integration tests.
  • Support GSS Font Settings and specific text color settings.

@annezazu

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.

@youknowriad

  • I’m working on the Flex Layout a bit, and experimenting with multi-layout architecture for inner blocks
  • I’ve also spent some time on performance jobs, tooling around that and I’m planning to continue that a bit
  • Reviewing a number of PRs

@get_dave

@mamaduka

  • Refactored Post Author component for editor. It now only makes one request to render the component instead of four.
  • Deprecated getAuthors data selector in favor of getUsers.
  • Fixed regression in withFontSizes HOC. I would love to get some feedback on this PR and maybe ship with 5.8.1.
  • Now it’s possible to pass context to getUser and similar data selector shortcuts.
  • Worked on flaky “Block Hierarchy Navigation” test issue.
  • Fixed issue when hitting maxLength in FormTokenField component triggered an error

@annezazu

  • I was out last week but am working on a few things this week for the #fse-outreach-experiment including a hallway hangout happening likely tomorrow (to be announced soon), a survey of block theme authors, and the next call for testing.
  • Working to try to update the github template to use forms as well to perhaps make it easier for people to report issues.
  • Hoping to fit in some time to triage too.

Open Floor

@mikeschroder

  • If it’s okay, I’d be interested in shadowing someone close to my timezone (JST, so I’m guessing APAC or EU would work best) on a Gutenberg release, to learn more about what’s involved.
  • I’d eventually love to be able to help with running one, and hoping that would help with learning about the knowledge gaps to fill.

@get_dave

  • Could whoever is running the Gutenberg Plugin release today please let me know how they found the automated changelog feature grouping? I worked on a couple of PRs on that and I’m curious to know whether anything could be improved. My DM’s are open.
  • Also on that note, please can I make a plea for folks to consider being even more proactive in assigning labels to Github Issues? With the correct labels assigned creating the release changelog can be far more automated. I’ve noticed a number of recent PRs without any labels and so I’m hopeful that we can reverse that trend for the benefit of the release leads. Much appreciated.

@mamaduka

  • I try to label the issues, but can do same for PRs as well 

Read complete transcript

#meeting-notes, #core-editor, #editor, #gutenberg, #core-editor-summary

Call for CSS contributors! Help implement custom properties in WP Admin.

WordPress needs your CSS chops!

In #core-css, we have been working for over a year to devise how to implement custom properties for WP Admin in order to allow extended flexibility of color schemes, e.g. dark mode and high contrast. After much deliberation, research, and prototyping, we are now going forward with replacing the current color scheme implementation with custom properties as outlined in ticket #49582, and we need some help!

If you’d like to get started on your own or learn details about this work, we are keeping track of our workflow and collecting information that will serve as future documentation in this Google Doc: WordPress Core CSS custom properties.

Join our Custom Property Work Sessions

We also know that it can take time to understand the nuances of a project enough to contribute, it can be intimidating, and it can be hard to designate the time for it. That’s why we are devoting the next three weekly Core CSS Chats to work time and “office hours”, where experienced folks will be available to help with any issues in Slack.

The dates and times for the CSS Chat: Custom Property Work Session editions of the weekly meeting will be:

  • August 5, 2021 at 21:00 UTC
  • August 12, 2021 at 21:00 UTC
  • August 19, 2021 at 21:00 UTC

Excellent Opportunity for New Contributors

This is a great opportunity to get involved with contributing code to WordPress! The knowledge you’ll need for contributing is:

  • Ability to fork and clone a repo from Github and create your own branch
  • Run commands to start the WordPress development environment
  • Read CSS selectors from a file and find what they refer to in the DOM
  • Understanding of CSS custom properties (a.k.a. CSS variables) syntax

Some helpful links for where to obtain this knowledge:

That said, this knowledge is not required for attending the work sessions. If you run into an issue or have trouble following the doc above, just ask in Slack during one of the meetings, and someone will help.

We hope you will join us to help advance and maintain WordPress’ core stylesheets!

#core-css

Devchat summary, July 28, 2021

A week after the release of WordPress 5.8, @desrosj led a well attended but quick chat on this agenda.

Highlighted blog posts

Jonathan drew the group’s attention to these posts:

He also added a late post of his own:

If you’d like to help with 5.8.xx minor releases, leave a comment on that post.

To-do items on 5.8

Moving on, @desrosj opened one last review of the 5.8 release and asked the group for retrospective comments and other feedback.

In reply, @chanthaboune said she’d likely have her retrospective up later in the day. And she said @matveb will shortly have some thoughts about features to target for 5.9.

Remember, also, that trunk is open now, so if you’re a committer, keep committing whatever you feel is ready! (Ed. note: Plus, we’re also in alpha for 5.9, so whether you’re a committer or not, if you’re passionate about bringing a new feature into Core, now is the time to do what it takes to land it.)

Component maintainers

@sergeybiryukov checked in with news on Build/Test, where ticket #53363 has details on some bug fixes and updated naming to follow established conventions.

On U[grade/Install, Sergey added a second plug for his feedback request on the updater proof of concept highlighted above.

Open Floor

Above, in highlighted posts, you probably noticed that @desrosj asked for comments on his minor-releases post if you want to help with the 5.8.x minors. He actually added that suggestion in Open Floor.

#5-8, #core, #dev-chat, #summary

CSS Chat Agenda: July 29, 2021

This is the agenda for the upcoming CSS meeting scheduled for Thursday July 29 at 21:00PM UTC. The 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, #core-css

WordPress 5.8 ‘Tatum’ Retrospective

A lot of things changed with the way that the WordPress 5.8 release was managed. A retrospective is always a good idea after a project, but in this case I wanted to be sure I cataloged the big changes for anyone who felt that it was different, but couldn’t quite put words to it. I originally shared this with the release team in Slack.

  • The teamwork had a different feeling. Instead of having buddies or cohorts of learning contributors (roughly one-to-one), we put the squad in a public channel to coordinate the work (one-to-many).
  • The release process had a different feeling. We made feature freeze independent of any other type of milestone and also are trying to be more focused about what work is done in each phase.
  • The included features had a different feeling. Instead of flipping the switch on a massive change for everyone, full site editing is being being shipped in smaller, more manageable chunks so it’s easier to catch up and we can iterate as we go.
  • The environment is different. We’ve all been struggling through this pandemic and being isolated from those we care for. Whether we recognize it or not, that has a profound impact on what we choose to do with our spare time, how we are able to meet others where they are, and whether we “grow through” or “bounce back” from hurdles that stand in our way.

Anyone is welcome to participate in this retro, so please take a few moments to fill in the form or leave public feedback in the comments below. It is not anonymous in case I need some clarification, but your email address will not be kept. The form will be open until August 15, 2021.

Thank you everyone for your contribution to this release, and thanks in advance for taking the time to help make future releases even better!

#5-8, #retrospective

I’ve been honored to be part of this release. I really appreciated working with the release squad. It was tense at moments and joyful at others but I think we managed to get a great release in the end.

I took some notes during the process about the things that could potentially be improved.

– A potential theme Lead: The release didn’t include a new theme but it includes changes that could have benefited from a theme lead. A lot of themes needed to be adapted and we could have done potentially a better job at integrating the new possibilities with a dedicated person focused on making sure default themes are as polished as possible. (Theme.json, template mode, new blocks, to cite a few features that require theme enhancements)

– Late feedback: On the Gutenberg side, there’s a lot of work that is done before PRs get merged, reviews, discussions… with the objective of a feature being ready for Core once it’s made stable without big changes. That said, when back porting these PRs into Core, we sometimes receive late feedback about these features as a lot of people only care about Core commits and ignore any activity in Gutenberg itself (understandable as there’s a lot of activity there). That feedback is great but is share a bit late in the process. Often times, the person doing the backport don’t know anything about the backported changes creating blockers and a lot of unnecessary back and forth. Ideally, the backporting should be automatic, meaning at that moment, everything is done and we should require more changes, this ideal means two things: Align practices more and more between core and Gutenberg and encouraging folks to monitor commits in Gutenberg the same way they monitor commits in Core and not wait until things get in Core. A potential middle ground could be to encourage all core contributors to follow Gutenberg release posts and use the Gutenberg plugin more heavily.

– The leads channel: At a very small occasions, there were uninvited non-lead voices discussing in the leads channel. I guess that’s fine but it can sometimes create distractions forcing more DM usage.

– The editor scope is becoming too big for a single lead. As an example the widgets screen could have benefited from having a dedicated lead, fortunately, there were some informal experts there so I didn’t have to chime in there much but I feel for future releases with a scope as large as 5.8, dedicated experts in specific areas would be good, Gutenberg is way more than “editor” right now. Obviously, this depends on the scope of each release, I think a single “Gutenberg” lead was good for most post 5.0 releases.

Thanks 🙂

Thank you for sharing your feedback Riad. I can respond to the part related to the process of backporting PHP changes from the Gutenberg plugin to WordPress core that I helped with. It’s the biggest pain point at the moment that needs major refinements. The current structure of the Gutenberg plugin makes it really hard to locate the changes necessary to bring to WordPress core together with related JavaScript logic. Before anything else, we should make it more transparent in the plugin what’s already in WordPress core, what’s ready to be backported, and what’s still an experiment.

In addition to the challenges with identifying PHP changes that should be moved to the WordPress core from the plugin there were other related issues:

  • the same functions/classes used in the plugin and WordPress core, weren’t properly guarded in the plugin triggering redeclaration errors
  • the name of the functions/methods were too general in the context of WP core – it’s something that could be caught earlier in the PR review process

I also opened an issue in Gutenberg: http://wayback.fauppsala.se:80/wayback/20210803145719/https://github.com/WordPress/gutenberg/issues/33810. Let’s discuss there more in-depth what changes in the plugin might bring us closer to the semi-automated process of backporting.

Hey everyone!

Congrats on the release, and thanks for all your work.

During the release, I wanted to note that I found it really helpful for the release leads channel to be public.

I’m not sure how different this felt as a lead, but as a contributor, it was really helpful both to follow release direction, and to know how best to offer help when issues came up / what was already taken care of.

Consistent minor release squad leaders for each major branch: Trial run retrospective and 5.8.x releases

During the 5.8 release cycle, a Release Lead and Release Deputy was named for all 5.7.x releases in a trial run. The experiment was an attempt to address several pain points that made executing minor releases needlessly difficult. Each of the pain points of the minor release cycle were expanded in detail in the original post.

For the 5.7.x releases, @peterwilsoncc and @audrasjb were named as Release Lead and Release Deputy respectively. In the months between the 5.7 and 5.8 releases, they successfully planned and released 2 minor 5.7.x versions with an average of 4.5 weeks between each. The gap between the final minor release (5.7.2) and 5.8 was 9.7 weeks.

Feedback

In an effort to evaluate how this process went, they were asked for some answers to a handful of questions. Here is some collected feedback from @peterwilsoncc on how the process went.

What went well?

Generally I thought the experiment was successful and it was good to be able to concentrate (and only be expected to concentrate) on the minor releases rather than try to track both major and minor. More specifically:

  • Getting a few more people in the AEST timezone involved than usual helped with coordination.
  • Starting early my time for releases was good for the .1 version as it went longer than expected.
  • Probably should have asked for author rather than contributor permission on w.org/news so I could actually publish the posts I prepared.
  • Having scripts prepped a day in advance was great at reducing stress and allowed for dry-runs (excluding commit).

What went poorly?

  • Night owls or not, I don’t think it was great having me in APAC and @audrasjb in EU working as team leads, everything that was good about release times for me was exactly the reverse for @audrasjb (and @desrosj but to a lesser extent).
  • Better prep on the .1 release could have shortened the time for committing and moving on to the release party.
  • Needed to pull in a couple of people on the release day for the .1 release.
  • Finding someone with mission control access is not easy (especially in timezone). The list of those with permissions is really out of date, and some probably don’t need release permission any more.
  • I didn’t delegate some of the admin stuff well and ended up doing a fair bit at the last minute as a result (on me for not asking).

What did you learn?

  • How to release Gutenberg packages, although doing so on my first production commits to the repository was a little brave.
  • Depending on the number of security backports, and how far back they need to go, release day for a minor can be busier than a major.
  • Process page in the handbook is quite out of date: updated a few steps after each of the two releases.

What support did you receive?

A lot.

  • @gziolo and @isabel_brison helped a great deal with getting the Gutenberg release process down, especially @gziolo by updating the undocumented steps as I asked questions.
  • @audrasjb, @desrosj and @whyisjake with release processes, both in advance and on the day.
  • Code review of shell scripts to attempt to speed up the process.
  • @dd32 with release day stuff, including catching quite a few things I was unaware of on the day.


What support could you have used?

Needed a lot more support from editor team with some planning tasks. The team was consumed with 5.8 and Full Site Editing, so they did not have much time to spare.

What were some responsibilities or tasks you had to take care of that you did not anticipate?

  • Expected I’d need to prep some release day scripts, but didn’t realize how many until I started doing them. Again, probably would have been helped by better delegation
  • Didn’t realize I’d need to do NPM releases at the start but figured it out well before the actual release

Anything else you feel is worth sharing?

Generally I think it went well and was successful.

Continuing the trial in 5.8.x releases

Because the experiment was generally successful, it will be repeated in 5.8.x releases. To reiterate the ideal criteria that was listed in the original proposal, the two contributors serving as release lead and release deputy will be responsible for:

  • Publishing timelines and plans for each minor release.
  • Executing these plans through release day.
  • Coordinating with the Security Team lead to improve the flow of fixes from the team to users.
  • Assembling and requesting help from other volunteers for each release as deemed necessary (docs, test, specific focus areas, etc.).

Ideally, one of these two contributors has a technical background (with the abilities to identify, confirm, test, and approve bug fixes and changes), and the other has a project manager or coordinator background (with the abilities to create release timelines, coordinate contributors, and help unblock efforts).

One additional (potentially optional) criteria would be that either the lead or deputy be a part of the previous major release’s squad, or be very familiar with the changes that were introduced in that major release. This would further increase the speed at which the minor releases are able to fix related bugs, as they are already “up to speed” on the changes.

In recent years, the gap between major releases has been, on average, 3 to 5 months. If necessary, contributors can tag in and out of the role should circumstances change and it becomes necessary.

If you’re interested in volunteering as a Release Lead or Release Deputy for the 5.8.x releases, please comment below!

Props @peterwilsoncc and @audrasjb for their great work during the 5.7.1 and 5.7.2 releases, and @chanthaboune for pre-publish review.

#5-7, #5-8

Thanks for putting our feedback together in this post, @desrosj 🌟

While I plan to focus more on the next major this time, I will be available to help on 5.8.x, at least to prepare releases changelogs…

…which is a painful task as we’ll be releasing 21 versions of WordPress for each security release 😆

That said, I really want to put together the proposal to stop to include changes for very old versions of WordPress. This will be my real main goal during the 5.8.x minor releases cycle 🙂