Tonya Mork 12:54 pm on September 1, 2020
Tags: , ,   

Bug Scrub Schedule for 5.6

With 5.6 officially kicked off, time to schedule the 5.6 sessions. These 5.6 specific ticketticket Created for both bug reports and feature development on the bug tracker. scrubs will happen each week until the final release.

Upcoming Scrubs:

  • 10/29/2020 18:00 UTC
  • 11/5/2020 19:00 UTC
  • 11/9/2020 19:00 UTC day before BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 4
  • 11/16/2020 19:00 UTC day before RC1
  • 11/30/2020 TBD (If Necessary)

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

Past Scrubs:

What about recurring component scrubs and triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. sessions?

The above 5.6 scheduled bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs are separate and in addition.

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

  • Design Triage: Every Tuesday 14:00 UTC in the #design channel (for both coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/).
  • AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Scrub: Every Friday 14:00 UTC in the #accessibility channel.
  • APAC-friendly Scrub: Every Tuesday at 05:00 UTC in the #core channel. This scrub will continue during the cycle, alternating focus between core and editor.
  • Testing Scrub: Every Friday 13:30 UTC in the #core channel.

Want to lead a bug scrub?

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

How? PingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” me (@hellofromtonya) on slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. 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

#core

thelmachido 3:40 pm on October 29, 2020
Tags: , , , ,   

Dev Chat Summary – 28 October 2020

The meeting was facilitated by @thewebprincess while @thelmachido took notes. Full meeting transcript on slack. 

Both groups followed the pre-prepared agenda and started the chat by celebrating the release of WordPress 5.6 Beta 2, please test and review the BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. version and share any bugs/issues.

Announcements

WP Version 5.5.2 is scheduled for release on October 29th

Highlighted Posts

@helen is running code review/commit office hours for 5.6, you can get more information about it here.

@chanthaboune outlined the rationale behind dropping the Widgets screen from 5.6 catch up on that and the plan going forward here.

Dark Mode for Twenty Twenty-One
Discussions are ongoing and the team has outlined some options that your input could help narrow down.

Calls for maintainers and focus leads

PHP 8 call for testing
@sergeybiryukov highlighted again that there is need for more testing on PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 8, we have to expand test coverage and creat tickets for any issues found. A thorough report has been written by @omarreiss, @jrff, and @herregroen about the current state of PHP 8 and its compatibility with WP.

Build/Test Tools
Docker environment was updated to allow for using multiple PHP Unit versions, get more details on that here. (Note: this is currently temporarily reverted to investigate test failures) Also, some changes were made to account for the recently released Composer 2.0.

Upgrade/Install Component Update
@audrasjb is drafting on a dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. for #50907. It should be ready for review by the Docs lead/cohort/mentor.

Open Floor

Take part in the 2020 WP English Survey, if you are interested to see 2019 survey results, or get links to the 2020 survey in French, German, Japanese, Russian, or Spanish, you can find all that here!

Block Pattern Directory Ideas and Discussion
@daisyo surfaced the post for feedback.

@audrasjb is working on a technical proposal for dropping support/security backports for very old versions of WordPress. He is going to publish a Make CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. post and open a ticketticket Created for both bug reports and feature development on the bug tracker. with a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. proposal very soon. The topic should be ready for discussion during the next dev chat. Comments are welcome here. Follow the conversation on slack

Join the team for the next bug scrub on Friday

WP 5.6 Beta 3 is Scheduled for next Monday.

Next Dev Chat meetings

The next meetings will take place on Wednesday, November 4, 2020, 07:00 AM GMT+2 and Wednesday, November 4, 2020, 10:00 PM GMT+2 in the #core SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. 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, #5-5-1, #core, #dev-chat, #summary

Francesca Marano 10:33 am on October 29, 2020
Tags:   

Discussion: align the WordPress release cycle with the industry standard

The standard software release life cycle hasn’t really changed much since the beginning of programming.

WordPress, for the most part, attempts to closely follow the established pattern, with the exception of what can get committed in BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process..

For the past year, there have been conversations in Slack and in the blog about the release cycle. Here is a recap post with a call for feedback.

The WordPress Release Cycle – Today

Each release cycle spans multiple weeks and different phases.

Phase 1: Planning and securing team leads

This period starts as soon as a branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". is created for the previous version (the code is copied from “trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision.” to a new “branch” in the repository), which means that two major WordPress versions are worked on at the same time. For example, active development on WordPress 5.6 started about two weeks prior to the WordPress 5.5 release. 

During this phase, the release leadRelease Lead The community member ultimately responsible for the Release. discusses features for the next release of WordPress. Contributors get involved with that discussion. The release lead will identify focus leads for each of the features. Information is gathered from different sources to put together a scope and schedule, followed by a kickoff post.

Phase 2: Development work begins

The kick-off post (see an example from WordPress 5.6) marks the beginning of structured, organised work towards Beta. The length of the period might vary, based on what was achieved during the period before the announcement and what is planned for the release.

Focus leads assemble teams and work on their assigned features. Regular chats are scheduled to ensure the development keeps moving forward.

Phase 3: Beta 

Betas are released and beta-testers are asked to start reporting bugs. No more commits for new enhancements or feature requests are allowed for the rest of the release.

WordPress generally plans for multiple betas.

Phase 4: Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta).

In WordPress, release candidates are considered code complete, so no new source code is introduced unless it is to fix regressions or serious bugs discovered during RC. Even then, every commit during this phase needs sign-off from two CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers.

This means hard-freeze on all strings, including those in the About page. It is important to do so to allow the Polyglots team to have enough time to translate it.

During this phase, a new branch will be created thus starting a new release cycle while we are finishing the current.

Phase 5: Launch

This is the final version that is launched and available for update through the dashboard or via download.

How to align the WordPress release cycle with the industry standard

With this in mind, here are the changes that could be put in place to align the WordPress release cycle with the traditional software release cycle.

Phase 1: Preliminary Planning

Stays the same in terms of tasks. Can be renamed “Preliminary planning” for brevity and clarity.

Phase 2: Alpha

While traditionally priority has been given to enhancements and new features, it would be beneficial to address also all the bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.-fixes that are planned for inclusion in the version of WordPress people are working on. 

Changes

  • Rename to “Alpha” for brevity and clarity.
  • All the bugs that people want to see fixed in the next release need to be addressed in this phase and not postponed to Beta.

Phase 3: Beta

This is where WordPress differs from the standard. 

Historically, 

Beta phase generally begins when the software is feature complete but likely to contain a number of known or unknown bugs.

Wikipedia

Beta is essentially for testing and fixing bugs discovered after the release of Beta 1 (so bugs introduced in Alpha).

Changes

  • Hard freeze on Beta (ETA code and strings), except for the About page.
  • The tickets that were not committed and are still on the milestone at the time of Beta 1 release party, should be moved to a later release, even if they are bugfixes.

Benefits

  • Virtually no new bugs are introduced during Beta. This means focus on testing and subsequent bug fixing. 
  • More efforts and resources could be allocated to beta-testing. 
  • Beta and RC could be and should be fewer and shorter. This is because we address only bug fixes that emerged during beta testing. 
  • Aligning to the norm makes it easier for new people to join since they are used to a certain procedure and they won’t be confused by the way releases are done in WordPress.

Phase 4: Release Candidate

No changes

Phase 5: General Release

Stays the same in terms of tasks. Can be renamed to “General Release” for clarity.

It’s your turn!

Disclaimer: even if everyone is on board, nothing will change for the current release cycle, WordPress 5.6, because we are already in Beta. 

Please post feedback on:

  1. Name changes for Phase 1, 2 and 5
  2. All bug-fixes milestoned to be addressed in Alpha and not postponed to Beta 
  3. Reserving Beta for testing and fixing bugs discovered by testing

Deadline: November 17th, the date scheduled for Release Candidate 1 of WordPress 5.6 and, potentially, when trunk gets branched for 5.7.

Thanks!

Props @azaozz, @davidbaumwald, @joostdevalk and @ireneyoast for providing historical and technical knowledge on release cycle procedures, and @chanthaboune and @jeffpaul for editing suggestions.

#release-process

Andrea Middleton 11:51 pm on October 28, 2020
Tags: ,   

X-post: Block Pattern Directory ideas and discussion

X-comment from +make.wordpress.org/meta: Comment on Block Pattern Directory ideas and discussion

annezazu 9:18 pm on October 28, 2020
Tags: ,   

Editor chat summary: 28 October, 2020

This post summarizes the latest weekly Editor meeting (agenda, slack transcript). This meeting was held in the #coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-editor SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel on 2020-10-28 14:00 UTC and was moderated by @annezazu.

Announcements

  • Gutenberg 9.2.2 was released on October 26th.
  • WordPress 5.6 Beta 2 was released on October 27th! Please install on a test site, play around, try to break everything, report bugs, and all that good stuff: 
  • WordPress 5.5.2 is coming to your WordPress site on October 29th.

Monthly Plan & Key Project Check-in

For context, here’s the overarching plan for October.

Widgets Screen Update shared by @andraganescu

The focus for the people previously working on this screen is now mostly on 5.6 efforts. However, there still is work around advancing various widgets project related issues. For example, @zieladam‘s PR about fixing concurrency related issues, something which became apparent while working on the widgets editor.

Reminder: the widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. core sync chat is suspended until 5.6 has been released!

Global Styles Update shared by @nosolosw

Global styles has advanced nicely this month with @jorgefilipecosta doing great work related to user-provided color palettes, etc. We’re now going to have a stronger focus on tighten things up to work great with the TwentyTwentyOne blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. based theme. Some of the items in the first wave of work will also be moved to the “future” iteration at this point.

Full Site Editing Update shared by @vindl

Full Site Editing – Navigation update:

  • Search feature for the navigation component has been merged. The next step is integrating it with the site editor.
  • It’s now possible to create new templates from the navigation sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. that correspond to default ones from template hierarchy.
  • We shipped the RTL support for the navigation component.
  • PR for creating template parts from multiple blocks selection has been merged.
  • There is a proposed framework PR for introducing a custom status for templates provided by themes (or plugins) as HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. files, which haven’t been customized by the user yet.

In other news:

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.  Remember: don’t just focus on code contributions!

@nosolosw

Mainly focused on fixing issues raised in BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 and will continue to help with that, but will also come back at global styles work.

@aaroncampbell

Was trying to verify whether Single Column Functionality, which looks like it made it into 9.2, is going into WP 5.6. As a result, this small screen display issue was put in the 5.6 must-have project board to be triaged.

@annezazu

Wrangled some quicker doc updates: glossary terms to include more block based items, triage instructions to include tables for clarity & reasons for closing, and updated the Versions in WordPress doc for 5.6 (need to do the same for 5.5.2). Outside of that, helped clear out a bit of a backlog for unlabeled items, did some FSE testing/bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. reporting, and started gathering resources for the contributor working group effort!

@youknowriad

Starting to work on more FSE tasks: trying to streamline the flows to enable/disable FSE themes. Still working on documentation for 5.6 new APIs and dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase.. Hoping to have time to chime in on this thread soon.

@mkaz

Has been working on improving e2e tests.

Open Floor

Should we bail on e2e tests after a single failure? Raised by @mkaz.

Marcus has been working on trying to improve tests and asked the group for thoughts on whether we should bail on e2e tests after a single failure as it’s not clear if there’s value in doing so. This is particularly the case for GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ Actions to keep running all the tests after an error happens. After a quick discussion with people sharing their differing approaches to handling failures, @youknowriad summed up the root issue nicely: “I feel the issue is not that we run the whole suite on github but more that the tests actually fail…What we should do is actually take the time to fix the failures even if we’re not responsible for them”.

What should be included in the next “What’s Next” in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ post? Raised by @daisyolsen.

@nosolosw made sure to link to the previous update around Global Styles. @youknowriad mentioned both that writing Dev Notes should be mentioned for preparing for 5.6 and that he personally would like to see a greater focus on FSE related work.

Is the current plan to use PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 files instead of static HTML files for FSE? Raised by @johnstonphilip.

@youknowriad once more swooped in to share that there’s an exploration along those lines being done here.

#core-editor #core-editor-summary
Dee Teal 3:44 am on October 28, 2020
Tags: ,   

Dev Chat Agenda: October 28th 2020:

Here is the #agenda for this week’s meetings happening at:
Wednesday, 28 October 2020, 0500UTC and Wednesday, 28 October 2020, 2000UTC .

  • Announcements –
    • BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 2 of 5.6 released – please test and review and bring any issues/bugs to chat to discuss
    • WP 5.5.2 minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. planned for Thursday, 29 October 2020 1700UTC details here
  • Highlighted blogblog (versus network, site) posts
  • Calls from component maintainers and/or focus leads
  • Open Floor
    If you have something else you want to include to the agenda, please mention it in the comments below.

The #dev-chat meetings will be held on Wednesday, 28 October 2020, 05:00UTC and Wednesday, 28 October 2020, 2000UTC. 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

Jake Spurlock 6:42 pm on October 27, 2020  

WordPress 5.5.2 Coming October 29th

As we get deeper into the WordPress 5.6 release cycle, the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team wanted to get out a few updates related to the 5.5 release. Right now there are 10 issues in the milestone, and a handful of Gutenberg updates.

This release is slated for October 29th, 17:00UTC.

annezazu 6:12 pm on October 27, 2020
Tags: ,   

Editor Chat Agenda: 28 October, 2020

Facilitator and notetaker @annezazu

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

This meeting is held in the #coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-editor channel in the Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

  • GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 9.2.2
  • WordPress 5.6 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 2
  • Monthly Plan for October 2020 and key project updates. For the updates, the discussion will focus on what is being done and help that is needed:
    • Global Styles & Editor focused APIs
    • WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. 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

Jorge Costa 5:29 pm on October 26, 2020
Tags: , , , , ,   

Editor chat summary: Wednesday, 21 October 2020

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

GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 9.2 and WordPress 5.6 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1

@jorgefilipecosta announced Gutenberb 9.2 was released some hours before: https://make.wordpress.org/core/2020/10/21/whats-new-in-gutenberg-21-october/.

Regarding WordPress 5.6 Beta it was released on the previous day as planned: https://wordpress.org/news/2020/10/wordpress-5-6-beta-1/.

Unfortunately the WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. Blocks were not part of the WordPress release. More context is available at https://core.trac.wordpress.org/ticket/51506#comment:13.

@jorgefilipecosta referred that there is a must-have board that contains the issues that should be addressed before the next WordPress release https://github.com/WordPress/gutenberg/projects/48. Some of these issues are not yet assigned to anyone so it is a good opportunity for someone looking to contribute and have an impact on the next WordPress release.

Monthly plan updates

Full Site Editing – Navigation – @vindl

  • Pages selector dropdown has been removed in #25620. This functionality is now accessible through the navigation sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme., similar to templates.
  • The initial version of Document Settings dropdown in site editor has been completed. It contains basic template info and a button to view all templates.
  • Work is in progress for adding new functionality to the navigation sidebar, most notably the search feature, template creation flow, and RTL support.
  • Hover interaction for template parts is on hold after latest round of design feedback and will have to be reworked or abandoned.
  • Old PR for converting blocks selection to template part has been picked up again and updated.

Full Site Editing – Navigation – @ntsekouras

  • The Add sticky support in Query blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. (https://github.com/WordPress/gutenberg/pull/26279) a needs review.
  • Query block enhancements(loading and no results messages, focus Query on insertion)

Global Styles – @jorgefilipecosta

Widgets Screen – @zieladam

  • We are regrouping on #feature-widgets-block-editor to figure out what’s next – anyone interested in this project is welcome to join.
  • Widgets-related work had some positive effects such as widgets APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. endpoints or bringing in support for batch requests in WordPress (props especially to @timothybjacobs and @Jonny Harris).

Task coordination

@jasmussen

Submitted the following PR’s:

@annezazu

Shipped the Block Editor Release Process for Major Releases with major props to our host @jorgefilipecosta and @tellthemachines, reported 13 Widgets Screen related issues to GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/, and lots of additional testing including with the latest for FSE.

@ajlende

  • Woking on a new image-related feature: duotone filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. support #26361.
  • Some of the menu stuff is blocked by #26115 (which @ajlende is currently working on).
  • Cover block support is blocked by #25171.

@mapk

  • Query block
    • Introducing placeholder screen.
    • Creating a new post from block.
    • Swap out patterns for block.
  • Widgets screen
    • Going through feedback and helping with design related issues.

@youknowriad

  • Tried to help a bit with coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. package updates and patches for 5.6.
  • Started working on documentation for the new APIs in 5.6.
  • Doing some prototyping related to FSE.
  • Helped a bit with e2e tests (please help there if you have time, we’re not on a great stop at the moment).

@zieladam

@mcsf

  • Focused a lot on rethinking our Block Supports implementation, starting with 26111, then discussing details with @youknowriad and @nosolosw in 26192 and follow-up PRs
  • PR reviews in general

@ntsekouras

  • Add sticky support in Query block(https://github.com/WordPress/gutenberg/pull/26279) – needs review
  • Query block enhancements(loading and no results messages, focus Query on insertion)
  • Recognize and convert old or derivative block types to their canonical form(https://github.com/WordPress/gutenberg/pull/26147)
  • 5.6 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes

@jorgefilipecosta

  • Proposed a PR to generate preset classes on the client-side https://github.com/WordPress/gutenberg/pull/26224.
  • Proposed a PR to use the block settings on the global styles block panel instead of the global ones https://github.com/WordPress/gutenberg/pull/26319.
  • Merged the pass of dynamic editor settings to the block editor on the edit site screen.
  • Iterated and merged the video text tracks functionality.
  • Iterated and merged the columns and group block templateLock control functionality.
  • Fixed a timezone issue that was considered critical and will be backported for older versions. Did an audit to the way we format dates on the frontend and suggested a general fix (we still have issues currently when we use formats with a complete timestamp like ‘c’ used for time HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. elements)
  • Did some PR reviews.

For the next week, will see how we can proceed regarding date-time, review the related PRs, etc. Will improve the font size presets (having global styles rely on pixel values for font sizes exclusively is not a good idea). See what can be done regarding identifying if a block instance matches a global style selector (for cases like headings). Will continue the iterations on the PR’s that are open and do some PR reviews.

@vcanales

  • PR for moving away from momentjs and into date-fns: https://github.com/WordPress/gutenberg/pull/25782 — Needs review, all input appreciated — Most tests passing, and @vcanales is currently testing and trying to fix this issue related to post schedule date mismatch, with the library swapped out.

@frankklein

Got two FSE bug fix PRs open:

  • Template part generation fix (i.e. do not use text domain): https://github.com/WordPress/gutenberg/pull/26275 already reviewed, and ready for merge.
  • Fix theme exports (these don’t work at all at the moment) https://github.com/WordPress/gutenberg/pull/26268

@nosolosw

His focus has been lately on various things that were important to land on 5.6. Plans to get back to FSE/GS work this week.

@bph

Testing daily builds of the plugin.zip (for now published on Gutenberg Times).

@karmatosed

Now options iterations are in 5.6, moving to beyond those for next releases. Also shepherding 5.6 and picking up some little pieces along way.

@itsjonq

  • Continued with G2 Components explorations, with a focus on supporting Design Tools (starting with Typography)
  • Building in features like CSS validation and smarter unit parsing (e.g. px, or vmax) to expand Gutenberg’s abilities to handle custom values (as Global Styles evolves)
  • Continued knowledge sharing of all sorts (G2, design, UIUI User interface, dev) via Zoom sessions

Open floor

Updating WordPress trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. editor more frequently

@clorith said:

Continuous Gutenberg releases in trunk.Currently, changes to the Gutenberg pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party generally get merged to core a few days before beta-1 of a major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. going out.

In that time period, months have likely to have passed, and the plugin would have had multiple releases (taking the 5.5 as an example, 9 releases of Gutenberg were bundled, the same rungs true of WP 5.4, 10 releases made it into 5.3). That’s a lot of changes, not all of them obvious, but having all of them land right before beta makes it harder to test their interaction purely in core, and separate between experimental plugin stuff, and what is actually planned for core.I would like to see a continuous integration between the two projects, I’ve outlined a proposed running timeline to get the discussion started around this:- Plugin has a new version releases

– The changes live in the plugin for 3 weeks

– After these 3 weeks the changes are merged to trunk

– Feedback on trunk/core can be provided on the features on how they work without all the other bells and whistles of the plugin.I chose the arbitrary number of 3 weeks, as that gives ample time to get plugin feedback from those using the plugin for testing, while also not keeping changes away from core for “too long”, and also doesn’t lead to excessive extra work for committers tasked with Gutenberg chores (ideally, I’d love a 2 week turnover, as I feel that gives ample time for plugin feedback, but this is what we’re here to discuss 🙂 )

@youknowriad said that our official plan is to actually merge after each release with trunk. The only blockerblocker A bug which is so severe that it blocks a release. is that  we don’t  have the resources to do so. And added that the part that can be automated is already automated: updating the packages and the e2e tests against core. The rest (PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 changes) can’t be automated.

Multi-line Code blocks regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5.

@getdave said:

There is a regression in the latest Gutenberg release on the Code block (and possibly also the Classic Block) where formatting is completely broken.

https://github.com/WordPress/gutenberg/issues/26301

It looks like this was introduced by changing from PlainText to the RichText component. All the link breaks are now returned as br tags which causes everything to render on a single line.

My personal website for example now shows all my code snippets in one unformatted long line which isn’t great (at all).

Not sure how complex this is to fix, but should we look to address it as a high(ish) priority?

@jorgefilipecosta said he thinks @ellatrix  is already aware of this issue and looking into a solution.

Should we have an issue per PR?

@paaljoachim said:

It seems fairly easy today to create a PR and have someone review and have it merged without even someone from design or accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) have gone through the PR. The question that comes up… should all PRs have an associated issue?

As it seems an issue will have greater visibility and it is easier I believe for someone to add the correct labels to get it looked at.

@jorgefilipecosta and @youknowriad manifested their thoughts against the idea of forcing an issue per PR.

It seems the biggest issue is having PR’s without labels that don’t get the deserved attention, and we should all make sure our PR’s are properly labelled. In case you have PR’s open please verify if all of them include labels.

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

Dan Farrow 1:45 pm on October 24, 2020
Tags: ,   

CSS Chat Summary: 22 October 2020

The meeting took place here on Slack. @danfarrow (me!) facilitated, standing in for @notlaura.

Housekeeping

There were no housekeeping items this week.

CSSCSS Cascading Style Sheets. Audit (#49582)

@ryelle reminded us that we have a basic report available on Github. General feedback on the content would be welcome!

@kburgoine posited adding a link to the report to ticketticket Created for both bug reports and feature development on the bug tracker. #26350: !important audit to show some progress on that issue.

@ryelle suggested holding off as the report’s presentation is likely to change soon, and @danfarrow added that, as part of his styling contributions, he’ll be adding in-page links which would allow us to link directly to the !important section of the report.

Color Scheming (#49999)

@ryelle reminded us that she has an environment set up for testing her reduced-colors branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch".:

If you’re comfortable setting up a dev environment, you can run this branch; but if you just want to see a demo, you can log into this test site. The username & password are:

username: color-author
password: fPj1ugpm5SMlRR^Evf%zg5)f

(fyi, that’s just an author-level account, and if anything starts getting spammy I’ll reset the password)

There is a dashboard note on the test site showing details of how to contribute.

@ryelle went on to share a Slack post from @helen which clarified an issue which had probably already been lurking at the back of our minds:

Yeah this is unfortunately really hard to judge without (dun dun dun) visual regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. testing…

We had a brief chat about that particular rabbit hole. @kburgoine mentioned being impressed by percy.io‘s githubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ integration, and @danfarrow mentioned recently enjoying backstop.js.

The discussion concluded with two suggestions:

  1. It would be useful at some point to recap the current landscape of visual regression testing in WordPress in order to judge the feasibility
  2. The colors project could perhaps be put on a back-burner for the time being until 5.6 is released in December and we could focus our attentions on the CSS audit

CSS links share + Open floor

@ryelle posted a call for testing Twenty Twenty-One as a good place for CSS folks to help out, with PRs to review and issues up for grabs. The 5.6 betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. would also benefit from your attention – get those issues while they’re hot!

@kburoine shared a link to a very entertaining CSS Tricks article from John Rhea who hand-coded daily CSS animations for 60 days on the theme of zombies.

@danfarrow shared a link to the proposed CSS nesting syntax which would make CSS a bit more SASSy.

Finally @danfarrow concluded the meeting by thanking everybody in #core-css for being so welcoming & supportive since he first attended back in June 2020.

Thanks everybody for attending!

#summary

Helen Hou-Sandi 11:02 pm on October 22, 2020  

Code review/commit office hours for 5.6

I will be running daily office hours for the rest of the 5.6 cycle in an effort to get more code reviewed and committed. These are to complement scheduled bug scrubs and are specifically meant to focus on reviewing and hopefully committing patches for the release cycle, not triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. or future wishlist items. My hope is that by defining specific hours people who have more structured schedules will be able to carve out that time as needed, and that other committers will be able to plan to join as much as they can.

Here are the hours I have planned, noting that in the cases where they overlap with a scheduled bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrub I will just stop early or start late.

  • Monday-Thursday from 16:30 UTC to 18:30 UTC
  • Fridays from 14:30 UTC to 16:00 UTC

Since the time shortcodeShortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site. doesn’t seem to manage just times without a date, here is when the next 5 are in your timezone (2 hours long Monday-Thursday, 1.5 hours on Friday):

I recognize that these times may not work very well for certain timezones, as I am but one person, and encourage committers in those time zones to see if there’s an opportunity there to band together and hold additional regularly scheduled code review/commit office hours.