Make WordPress Core

Keyboard Shortcuts | Hide comment threads

Dev Chat Summary: July 21, 2021

@desroj led the weekly meeting at 20:00 UTC. Here is the meeting agenda.

Link to 20:00 UTC <dev-chat> in #core on Making WordPress Slack

Notable news and blog posts

WordPress 5.8 was released yesterday(July 20, 2021)! The new release was downloaded 7.7 million times in a little over 24 hours.

What’s next in Gutenberg?

What’s new in Gutenberg 11.1.0?

Requests for Feedback

Component Team Updates

Build/Test Tools

  • Ongoing modernization of PHPUnit tests. #53363
  • PHP_CodeSniffer updated to 3.6 (with PHP 8 support) #53477

Auto-Updates

Themes

Open Floor

  • @desroj highlighted a bug in the Multisite Filesystem API that was requested to be prioritized in 5.9.
  • @chanthaboune raised a discussion about Making WordPress Slack — what we can/should use it for. Should #core be the default channel? Should some other Slack channel be created to greet new users (who may or may not have context entering Slack that it is mostly a working environment)? This was a lively discussion, please add more thoughts in the comments below!
  • While it’s been a fairly quiet (some might say too quiet) and smooth release, @chanthaboune encouraged the hosting (and greater) community to check-in with support folks and report back any trends. @johnbillion also noted a handful of tickets about Widgets have been opened related to “widget customisation and logic plugins.”

Watch For

Interested in volunteering for upcoming WordPress releases? Please comment below and team reps will reach out!

Props to @dryanpress for taking these #summary notes!

#dev-chat

CSS Chat Agenda: July 22, 2021

This is the agenda for the upcoming CSS meeting scheduled for Thursday July 22 at 21:00PM UTC.

The meeting will be held in the #core-css channel in the Making WordPress Slack.

  • Housekeeping
  • Custom Properties (#49930)
    • Discussion as needed
    • Work time
  • Open Floor + CSS Link Share

If there’s any topic you’d like to discuss, please leave a comment below!

#agenda, #core-css

Editor chat summary: 21 July, 2021

This post summarizes the weekly editor chat meeting (agenda here) held on Wednesday, July 21, 2021 at 02:00 PM UTC on Slack. Moderated by @andraganescu.

Announcements

Monthly Priorities & Key Project Updates

Block based Widget Editor

As the project has landed in core, there is now a new tracking issue set up for things identified by the community as great follow up work to improve on it.

Mobile Team

  • Shipping: Block picker search and first iteration of the embed block will be shipping in the next release.
  • In Progress: Scoping the next phase of Global Style Support work focusing on text-related styles.

Task Coordination

@ntsekouras

  • Landed SegmentedControl (PR: 31937)
  • I’m working on porting some more components from g2 and will make explorations for more layout integrations. Related Riad’s PR (PR: 33359)

@torounit

  • I am working on refactoring HierarchicalTermSelector (PR: 33418)

@zieladam

@mamaduka

  • Started refactoring FlatTermSelector into a functional component and utilize core data module for fetching terms.
  • While working on this discovered a few minor issues with the “Most Used Terms” component, which should be fixed now.
  • Also, now users with author roles should be able to set featured images uploaded by other users.

@aristath

  • Autogenerate headings anchors – PR: 30825.
  • Allow enqueing multiple stylesheets per-block – PR: 32510.

@getdave

  • I improved the build tooling by automatically grouping changelog items by feature when it is build on CI PR: 33229.

@ajlende

  • Cropping for the site logo needs reviewers PR: 31607.
  • Working on duotone enhancements we can discuss more during open floor PR: 33466.
  • Related bug fix for cover block spacing ui PR: 33560.

Open Floor

A test file was added to WP Core in 5.6.0, but added incorrectly, which means that the tests effectively were never run. I’m trying to fix that, but am now finding that 7 out of the 20 tests are failing. Raised by @jrf

We need someone with good knowledge of global styles to help figuring out if the test’s problem is on the PHP or JS side of the global styles.

@torounit surfaced issue 33589

This is probably a bug introduced by the recent work on the “select all” behavior in the block editor.

@ntsekouras surfaced a problem in PR: 1483 – It seems there will be the need for WP version check in patterns

The problem lies that patterns can have blocks with shape that is not supported in a WP version, but themes are also checked against WP version that are compatible. This isn’t the same WP version usually.

@ajlende asked if more people think it might be beneficial to have a system to that allow block supports to detect placeholder state.

General support for the idea was offered.

@mikeschroder raised PR: 32516 and asked if this direction is a good approach.

Looking forward for feedback from folks who know the rich-text package and can provide advice. Does that seem along the right lines for a fix?

#core-editor, #core-editor-summary

[Request for feedback] Updater Proof of Concept

Over the past month, @aristath and @sergeybiryukov have been working on a proof of concept to solve the two first outcomes highlighted in the Updater Initiative scope post.

They drew inspiration from the http://wayback.fauppsala.se:80/wayback/20210725150943/https://wordpress.org/plugins/rollback-update-failure/ plugin and tried to address a few tickets.

They created a proof of concept that can be found in a draft PR on http://wayback.fauppsala.se:80/wayback/20210725150943/https://github.com/WordPress/wordpress-develop/pull/1492/files and does the following:

  • Add new arguments to hook_extra passed by plugin and theme updates to ensure we can rollback to the correct version.
  • After a plugin/theme is successfully downloaded and extracted, the old plugin/theme folder is moved to wp-content/upgrade/rollback/plugins/PLUGIN or wp-content/upgrade/themes/THEME wp-content/upgrade/rollback/themes/THEME (thanks Paul Bigai for catching that)
  • If the plugin/theme was successfully installed, the backup of the previous version we kept in wp-content/upgrade/rollback/ is deleted.
  • If the plugin/theme was not successfully installed, then we cleanup any remnants of files in wp-content/plugins/PLUGIN (or the corresponding folder for themes), and then we move the backup we kept in the rollbacks folder back to its original location.
  • Adds info in the site-health screen, to make sure the rollback folder is writable (or can be created if it doesn’t exist)

That is the basic concept. The team ran some tests, helped by @peona as well and it seems to be working.

The main difference with the rollback-update-failure plugin is that this solution moves the plugin/theme folders instead of zipping/unzipping them. This change should help to make the implementation a bit lighter/safer on shared hosts with limited resources.

Before moving forward, I would like to ask the Upgrade/Install Maintainers to have a look at this and discuss together, in the comments of this post, if you agree with this change, if it works, etc…

I am not setting a deadline for the comments, but ideally, I would like to be able to write a merge proposal for 5.9 so I will review the post in mid-JulyAugust (thanks @meher for pointing out that we are at the end of July already 😂) and nudge a bit more 😉

Thank you all for your help and feedback!

Thanks @ipstenu for the peer review

#updater

Just my first feedback there are any plans like a filter to disable the rollback feature?

I am looking this as security stuff, as usually you update to remove old versions of themes or plugins affected. Also if they are not enabled they can be sources of troubles or have php files that can be called outside wordpress.

I think that something that ensure this is required like htaccess rules to disable the execution of those php file is important or zip those files.

What’s next in Gutenberg? Site Editing status check (Late July-August 2021)

WordPress 5.8 is already here, an exciting release marked by the inclusion of many Full Site Editing features that have been big-picture focuses in recent times. Because of this important achievement, in contrast to normal monthly updates, this post seeks to review the status of Full Site Editing and summarize the next high-level focuses within Gutenberg Phase 2.


Full Site Editing is the lighthouse goal for phase 2 of Gutenberg. As such, it’s good to remember it is a collection of projects that allow site editing with blocks, bringing powerful capabilities for a smooth editing experience.

WordPress 5.8 includes some of these Full Site Editing projects and features; while some of them will continue as ongoing focuses for subsequent Gutenberg releases (⚒️), others can be considered stable and enter a maintenance phase (✅)

Without further ado, let’s look at the current status of the milestones that have guided Full Site Editing work in the last months and the updated scope for Site Editing.

Site Editing Infrastructure and UI

The Site Editing Infrastructure and UI provide foundational work for the rest of FSE projects, mainly in the Site/Template Editor, Template parts, and the numerous APIs that support work around Full Site Editing.

The first two iterations of the site editor milestone introduced editing block themes and all their template files. The ongoing third one offers the possibility of creating custom block templates in classic themes and is available in WordPress 5.8 for those themes that opt-in to the site editing experience. Work will continue to finalize the Site Editor naming and placement: the current Site Editor as we know it in the Gutenberg plugin may evolve for better navigation flows and interactions.

Thanks to feedback from different FSE Outreach Program testing rounds, the next focus for site experience and tooling improvement include:

Overview Issues: ✅ Part 1, ✅ Part 2, ⚒️ Part 3

Global Styles

Global Styles comprises two major areas that fall underneath the global styles umbrella: centralized theme configuration and an interface for manipulating visual aspects of blocks globally.

Theme configuration absorbs things like declaring color palettes, presets, different supports and settings, and toggle on or off the available block design tools (typography, colors, dimensions, etc.). All of this can be managed through the theme.json configuration file and is one of the key features available in WordPress 5.8. After a few iterations and open testing, this feature is considered stable and moved to a maintenance phase.

The other major part of global styles is the user interface to make edits to blocks globally. With theme.json in place, the next release cycle will have the Global Styles UI as one of its main focuses, allowing users to tweak the theme easily. Color handling will be an important focus, not only to better theme switch but also to seamlessly integrate color palettes with patterns.

⚒️ Global Styles Overview Issue

Theme Blocks

To support the theme building needs outside of the template and template parts infrastructure, there was a need to create many new blocks centered around theme functions. WordPress 5.8 brings several of these blocks, from Site Title, Site Tagline, and Site Logo that allow users to configure site settings with blocks, to the post-related blocks such as Post Title and Post Date, to be used inside a Query Loop to display post data.

Although new theme blocks may be added as the need arises and the existing ones will receive incremental upgrades, the basics of this milestone are complete.

Theme blocks Overview Issue

Query Loop Block

Among the theme blocks, the Query Loop Block has been a significant area of the site editing focus in the past months, deserving its own milestone. Taking some of the block API infrastructures to the limit, such a powerful block has proven challenging to expose at a user level. As a result of the feedback collected in the FSE Outreach Program, the block has been renamed to clear confusion, and usability enhancements have been implemented before launching it in WordPress 5.8.

With the Query Loop foundations in place, the next iterations will seek to ease the user interactions and flows, even more, thanks to two fundamental Gutenberg tools – block patterns and block variations. The former will continue to help set the inner block structure and content. In contrast, the latter will present the powerful Query Loop’s features in the form of preconfigured blocks and consolidate similar blocks to use the Query Loop Block as their underlying mechanism.

Query Loop Block Overview Issue

Navigation Block

Along with the Query Loop Block, the Navigation Block is another theme block that stands out as a project in its own right. This block has seen great improvements in the last few months, from improved overlays to responsive menus. New blocks are available as well, such as the Home Link block. Shortly, we will see the Navigation block house whole new kinds of blocks thanks to the recent frontend markup adjustments that allow blocks other than links in an accessible way.

Because of its key role in building rich theme blocks, the Navigation Block will be one primary focus during the next WordPress release cycle. Apart from more blocks being available inside the Navigation Block, customization options – such as configuring dropdown behavior or adding fullscreen variants – are an area that seeks improvement. These customizations should be design-driven due to the multiple layouts nested navigation menus can have.

⚒️ Navigation Block Tracking Issue

Site Editing Gradual adoption

Full Site Editing represents a new paradigm in site and theme building in the well-established WordPress ecosystem, and as such, providing the right tools is key to gradual adoption. Tools like the Widgets Editor and Navigation Editor bring block editing capabilities to traditional features that can’t take full advantage of their native block counterpart implementation.

WordPress 5.8 brings the power of blocks to both the Block Widgets Editor and the Customizer. Users will be able to add blocks in widget areas, add widgets and blocks with live preview, and schedule and share directly from the Customizer.

Because blocks can now be added to widget areas, developers are encouraged to phase out their widgets in favor of blocks, which are more intuitive and can be used in more places. Developers can allow users to easily migrate a Legacy Widget block containing a specific widget to a block or multiple blocks. 

On the other hand, the Navigation Editor has also seen its share of iterative improvements in the last months. Together with the Navigation Block, it will remain an ongoing focus for the next WordPress release cycle.

Widgets Editor Tracking Issue

⚒️ Navigation Editor Tracking Issue

Smoothing block interactions

As mentioned with regards to Query and Navigation blocks, the complexity of the editor increases as site editing capabilities are introduced with advanced block structures and customization options. This highlights the need to expand our APIs and interactions — which are well suited for simple block structures — to better support container blocks.

To address some of this, the List View introduced in Gutenberg 10.7, and WordPress 5.8 aims to help navigate these advanced structures more efficiently and should continue evolving further in the future. Internally, the List View is powered by a component available in the post editor List View and advanced blocks like Navigation; all features and blocks having a list of blocks will benefit from the improvements made to this component.

Another challenging editing experience with the increased number of container and inner blocks is adjusting parent block settings when editing a child block.  Users often need to switch between different child and parent blocks to change settings like layout or positioning. In turn, it is necessary to explore Toolbar absorption mechanisms that allow parent blocks to expose their toolbar on their children.

Patterns everywhere

At this stage, it is no secret that block patterns represent considerable potential for users to add many blocks with different preset layouts and settings easily. By using patterns, users don’t need to individually add blocks to achieve rich representations in headers, columns, or Query blocks, as patterns act as a jumpstart blueprint that can be tweaked and adjusted to the user’s needs. 

An example of the improved interaction block patterns is demonstrated by the Query block, which allows users to select block patterns in its placeholder state. This is just the tip of the iceberg in terms of the ways patterns can leverage the editing experience, and as such, efforts will continue improving pattern insertion capabilities.

Thanks to the recently released Block Pattern Directory, patterns can be copied and pasted into the block editor; upcoming Gutenberg iterations will connect and retrieve patterns from this directory, allowing users to choose from huge amounts of beautiful patterns without leaving the editor. Both to ease navigating the big number of patterns users will be able to choose from and accommodate increased pattern complexity and richness, such as in Query or Header patterns, revisiting the pattern insertion UI will be an ongoing focus in the months to come.

 ⚒️ Pattern Insertion Tracking Issue

Design Tools

Several design tools are needed to ​​ensure a wide range of exquisitely crafted patterns can support powerful settings and rich block customizations. These encompass all tools related to the appearance of blocks and range from colors, typography, alignments, and positioning to filters like duotone, cropping, and background media and will need to integrate seamlessly with theme.json mechanics.

Going further, controls like font size, even if exposed as single values to users in the UI, are built behind the scenes to accommodate different viewport ranges. Apart from providing access to the underlying mechanisms through theme.json, responsive-previewing and device-specific editing will be necessary to support this.

To support the ever-increasing number of tools, the sidebar, while secondary in some regards to the block canvas and toolbar, will need to accommodate many of these tools, whereas the Component System will provide a shared design language between all these controls.

⚒️ Design Tools Overview Issue


How to follow along with Gutenberg

Here’s an overview of different ways to keep up with Gutenberg and the Full Site Editing project. There is also an index page of Gutenberg development-related posts and an updated Site Editing overview issue that breaks down the upcoming work into more concrete next steps.

Ways to Get Involved

While the above items are our focuses, don’t forget that you can always help with triage, testing issues, good first issues, and reviewing PRs. In particular, if you’re interested in helping with triage but don’t know where to start, there’s a course on Learn WordPress for how to do triage on GitHub! Check it out and join us.

Hearing your feedback is crucial to drive upcoming priorities and iterate on our work, so you are more than welcome to join our Full Site Editing Outreach Program!

If there’s anything we can do to make contributing easier, let us know in the comments or #core-editor chats. While we can’t promise to fix everything, we’d appreciate being aware of any blockers.


Props to @javiarce for creating the images, and to @cbringmann and @mcsf for reviewing the post.

#core-editor #gutenberg-next #gutenberg #full-site-editing

What’s new in Gutenberg 11.1.0? (21 July)

Two weeks have passed since the last Gutenberg release, which means a new version is available! Gutenberg 11.1 adds the ability to edit a block border easily, enables drag and drop support for the List View component, and includes many bug fixes centered around the Widgets Editor and Block Library.

Block supports: border

Take an early look at custom block borders! When borders are enabled in a theme.json file, and a block declares that it supports it with the block supports API, a new block panel is available that lets us change the border radius, width, style, color, and border units.

Set and style custom block borders

List View drag and drop

Intuitively move and reorder blocks using drag and drop in the List View.

Use the persistent list view to reorder blocks

11.1.0

Enhancements

  • Admin panel available as PWA. (33102, 33310)
  • Block Breadcrumbs: Small chevron icon for breadcrumb separators. (33042)
  • Block Library:
    • Columns Block:
      • Add stack on mobile setting to allow for columns without mobile breakpoints. (31816)
      • Add the percent unit to the default units in Core. (33468)
    • Latest posts: Remove grey color for dark themes. (33325)
    • List Block: Add link color control to list block. (33185)
    • Post Terms Block: Add a “separator” attribute to post-terms block. (32812)
    • RSS Block: Update block styles. (33294)
    • Tag Cloud Block:
      • Add ability to change number of tags shown. (32201)
      • Remove editor style so editor matches frontend. (33289)
  • Design Tools, Border:
    • Add support for custom border units. (33315)
    • Update border support UI. (31585)
    • Set border style none when border width zero. (32080)
  • Link Editing: Add Unlink button to LinkControl popover. (32541)
  • List View: Enable drag and drop in List View. (33320)
  • Widget Editor: Adds auxiliary class names for editor styles. (33388)
  • General UI:
    • Block Settings Menu: Don’t render ‘Move to’ if there is only one block. (33158)
    • Disable ‘Post Publish’ button if saving non-post entities. (33140)
    • Preferences: Polish labels and consolidate options in preferences. (33133)

New APIs

  • REST API: Block editor settings endpoint. (33128)
  • UI Components: Add a SearchControl component and reuse across the UI. (32935)

Performance

  • Improve List View performance. (33320)
  • Pattern Directory: Caching updates. (33052)

Accessibility

  • Improve high contrast mode rendering of icon buttons. (33062)

Bug Fixes

  • Block Breadcrumbs: Fix breadcrumbs html structure and React warnings. (33159)
  • Block Editor:
    • Move layout styles to document head (instead of rendering inline). (32083)
    • Warn only in edit implementation when using useBlockProps. (33380)
    • Iframe: Remove reset styles. (33204)
  • Block Library:
    • Buttons Block: Remove green background color in button preview. (33116)
    • Embed Block: Include missing attributes when upgrading embed block. (33235)
    • Image Block:
      • Improve “can switch to cover” check. (33095)
      • Fix replace link control styling. (33326)
    • Query Loop Block:
      • Prevent entering invalid values in the Query Loop block configuration. (33285)
      • Update getTermsInfo() to workaround parsing issue for translatable strings. (33341)
    • Search Block:
      • Fix search block button position dropdown accessibility/UX issues. (33376)
      • Update search block to handle per corner border radii. (33023)
    • Site Title: Decode entities in site title. (33323)
    • Home Link: Remove padding. (33461)
    • Post Except: Fix excerpt_more filter conflict and remove wordCount attribute. (33366)
  • Design Tools:
    • Color: Prevent color panel from showing as empty. (33369)
    • Duotone:
      • Avoid rendering duplicate stylesheet and SVG. (33233)
      • Update conditions to hide duotone panel. (33295)
    • Theme.json
      • Allow themes to provide empty values for color.duotone and spacing.units. (33280)
      • Specify what settings can be part of settings.layout. (33303)
  • Rich text:
    • Fix format deregistration. (31518)
    • Autocomplete: Reset state for empty text. (33450)
    • Run input rules after composition end. (33416)
  • Site Editor: Close navigation sidebar when all posts clicked. (33393)
  • Slash Inserter: Fix slash command focus style. (33084)
  • Widgets Editor:
    • Fix moving inner blocks in the Widgets Customizer. (33243)
    • Fix inserter size on Widgets Editor header. (33118)
    • Merge conflicting wp.editor objects into a single, non-conflicting module. (33228)
    • Retrieve latest widgets before loading sidebars. (32997)
  • Writing flow:
    • Allow select all from empty selection. (33446)
    • Attempt to fix preview end-to-end failure. (33467)
  • Components:
    • Suggestion List: Check if a node exists to scroll into view. (33419)
    • Navigation component: Fix item handling onClick twice. (33286)
  • Editor: Extract snackbars into a separate component. (33355)

Experiments

  • Component System:
    • Promote g2 Popover as Flyout. (32197)
    • Add useControlledValue. (33039)
    • Add normalizeArrowKey. (33208)
    • Add mergeEventHandlers. (33205)
    • Add useCx. (33172)
    • Add useLatestRef hook. (33137)
    • Remove @emotion/css from Divider. (33054)
  • Navigation Block:
    • Add Color Options for Submenus. (31149)
    • Change Navigation block markup on front end only. (30551)
    • Improve handling of open overlay. (32886)
    • Menu item placeholder inheritance. (32512)
    • Pass block attributes with rendering with location. (33043)
    • Refactor of navigation block rendering using location attribute. (33244)
  • Global Styles:
    • Cover against non existing styles. (33127)
    • Missing link color on style properties to css var mapping. (33150)
    • Preset variables not being user on the site editor. (33149)

Documentation

  • Admin PWA: Make readme private. (33216)
  • Handbook:
    • Block API:
      • Apply enhancements included in WordPress 5.8. (33252)
      • Clarify the type of apiVersion in block metadata. (33249)
      • Fixes a typo in the documentation for block supports. (33247)
    • Block Editor API: Changes to support multiple admin screens in WP 5.8. (33262)
    • Custom Block Editor: Fixed bad image syntax and bold text. (32897)
    • Fix API documentation for data reference guides. (33384)
    • Plugin Release: Update Gutenberg release documentation to clarify release post workflow. (33328)
    • theme.json:
      • Add examples and highlight backward compatibility. (33421)
      • Update theme.json documentation for WordPress 5.8. (33131)
      • Fix codetabs syntax in theme.json documentation. (33417)
    • Use markdown headings instead of links for API declarations. (33381)
  • Update documentation for link color in WordPress 5.8. (33162)
  • Packages:
    • Add PanelBody for InspectorControls. (33227)
    • Correct wrong setState call. (32808)
    • Remove withState HOC references. (33173, 33222, 33259)

Code Quality

  • Avoid calling gutenberg_ functions within code shipped through WordPress Core. (33331)
  • Block Editor:
    • Refactor the user autocompleter to avoid apiFetch and rely on the data module. (33028)
    • Warn when useBlockProps hook used with a wrong Block API version. (33274)
  • Block Library:
    • Image Block: Fix uncaught error. (24334)
    • Latest Posts Block: Refactor to drop apiFetch usage in favor of using the data module. (33063)
    • Template Part Block: Remove unnecessary function exists check on wp_filter_content_tags. (33182)
  • Components:
    • BlockNavigation: Restructure the BlockNavigation component. (31892)
    • Box Control: Rename VerticalHorizontalInputControls to AxialInputControls. (33016)
    • GradientPicker: Stabilises GradientPicker and CustomGradientPicker components. (31440)
    • Toolbar: Enforce isAlternate on ToolbarDropdownMenu. (33129)
    • ZStack: Remove @emotion/css from ZStack. (33053)
  • Packages: Hoist dependencies for WordPress packages. (33387)
  • Plugin: Remove deprecated APIs that are no longer supported in version 11.0. (33258)

Tools

  • Testing:
    • Add basic Site Title block coverage. (32868)
    • Add some functionality to createUser and deleteUser. (33067)
    • Enable previously skipped widgets tests. (33121)
    • Skipping more end-to-end tests. (33353)
    • Skip unstable end-to-end tests. (33352)
    • Switch to new puppeteer APIs for emulating conditions. (33410)
    • Update end-to-end tests to use new puppeteer drag and drop api. (33386)
  • Dependencies:
    • Update CopyWebpackPlugin to v6. (33220)
    • Upgrade Husky to 7.0.0 and git ignorance improved. (33183)
    • Upgrade Puppeteer to 10.1. (33327)
    • Upgrade Storybook to v6.3. (33219)
  • NPM Packages: Introduce release types to npm publishing script. (33329)
  • Plugin: Introduce tools folder with configuration files. (33281)
  • Workflows:
    • Release Workflow: Remove “experimental” status from WP 5.8 stable items. (33214)
    • Re-enable manually triggered workflows on forks. (32821)
    • Use NPM caching built into action/setup-node. (33190)

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~36,000 words, ~1,000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience but is adequate for spotting variations in performance.

VersionLoading TimeKeyPress Event (typing)
Gutenberg 11.16.38s26.12ms
Gutenberg 11.06.06s29.55ms
WordPress 5.78.52s36.26ms

Kudos to all the contributors that helped with the release! 👏

Thanks to @javiarce for creating the release post assets, @cbringmann for proofreading, and @priethor, @youknowriad, and @get_dave for guiding me through this release!

#block-editor, #core-editor, #gutenberg, #gutenberg-new

Admin panel available as PWA. (33102, 33310)

For PWA, I’m going to be working on adopting the ability to add the admin to the homescreen as part of the PWA feature plugin. See pwa-wp#569.

Dev Chat Agenda for July 21, 2021

Here is the agenda for this week’s developer meeting to occur at Wednesday, July 21, 2021 at 08:00 PM UTC.

Blog Post Highlights

5.8 Schedule Review

Components check-in and status updates

  • Check-in with each component for status updates.
  • Poll for components that need assistance.

Open Floor

Do you have something to propose for the agenda, or a specific item relevant to the usual agenda items above?

Please leave a comment, and say whether or not you’ll be in the chat, so the group can either give you the floor or bring up your topic for you accordingly.

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

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

I should be around to ask this during open floor, but I figured I’d share here first in case folks want to give it an early look.

While working on the conditionally showing/hiding the duotone toolbar based on block attributes/state, @talldanwp suggested that it might be beneficial to have a system to do this for other block supports features.

Is this something that other folks think would be beneficial? Or is the current approach (in #33466 and #33560) using simple component state enough for other block support UI moving forward?

If people think it would be beneficial, what should the scope of the API be? Should it be able to handle things like the cover block padding UI? Or is handling only the case of setup/placeholder state all it needs to be?

Whoops, I meant this for the #core-editor-agenda. I’ll be asking this there instead if anyone still has some thoughts to share about it.

Hey there, in case I don’t make it in time (again), there is a ticket I would like to move into spotlight: http://wayback.fauppsala.se:80/wayback/20210725150943/https://core.trac.wordpress.org/ticket/52241

It is around since 5.6. Causing an easily reproduceable infinite loop in Multisites under Windows Server installations (as the comments describe it). It also happens on NON-Windows installations on certain edge cases. We ran into the latter case on our Linux + nginx setup.

This might / should be considered as a blocker or critical IMHO. Because it breaks default WP installations in default usecases (accessing media library functions in WP-Admin) which should be considered fully supported. Or isn’t it?
From what the ticket looks like, most of the work might be already there with a patch and fix suggestions. Might any friendly core commiter be able to take a look?

Thanks 🙂

I have a more general WordPress project question, but thought this was a good place to start.

I know that in the Core channel the topic is about building the software not building with the software. Would it make sense for us to have a channel that’s specifically for those sorts of conversations?

Editor Chat Agenda: 21 July 2021

Facilitator and notetaker: @andraganescu

This is the agenda for the weekly editor chat scheduled for Wednesday, July 21, 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

I should be around to ask this during open floor, but I figured I’d share here first in case folks want to give it an early look.

While working on the conditionally showing/hiding the duotone toolbar based on block attributes/state, @talldanwp suggested that it might be beneficial to have a system to do this for other block supports features.

Is this something that other folks think would be beneficial? Or is the current approach (in #33466 and #33560) using simple component state enough for other block support UI moving forward?

If people think it would be beneficial, what should the scope of the API be? Should it be able to handle things like the cover block padding UI? Or is handling only the case of setup/placeholder state all it needs to be?

For Task Coordination, or maybe open floor due to the question in the “This Week” item? However you think it’s best handled!

Last Week, was excited to get this Accessibility-related PR in:
http://wayback.fauppsala.se:80/wayback/20210725150943/https://github.com/WordPress/gutenberg/pull/33534

This Week:
Have been looking into http://wayback.fauppsala.se:80/wayback/20210725150943/https://github.com/WordPress/gutenberg/pull/32516 again.
Related: http://wayback.fauppsala.se:80/wayback/20210725150943/https://github.com/WordPress/gutenberg/issues/31515 and http://wayback.fauppsala.se:80/wayback/20210725150943/https://github.com/WordPress/gutenberg/issues/28842

The fix in the PR works, but isn’t ideal, as it leaves an empty `style` attribute. Another option that I see is to `delete` the attribute, but that doesn’t seem ideal either.

I don’t know the rich-text package well, so I wanted to check in with y’all.
It looks like this could be fixed in `createElementHTML()` by checking for and handling `undefined` attributes, but I’m not sure if this behavior is intentional?

Here’s an example commit with a potential fix, and the way the other PR would be able to be fixed if it existed:
http://wayback.fauppsala.se:80/wayback/20210725150943/https://github.com/getsource/gutenberg/commit/29873db49be173e39955320973a50f41721985ef

I didn’t want to make it a PR like that, because it contains two separate changes, but thought it would help explain the problem.

Does this seem along the right lines for a fix? Would love any recommendations.

A Week in Core – July 19, 2021

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

  • 37 commits
  • 35 contributors
  • 53 tickets created
  • 15 tickets reopened
  • 51 tickets closed

Please note that WordPress 5.8 will be released tomorrow on Tuesday July 20, 2021 🌟

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

Application Passwords

  • Improve various user-facing and developer-facing terminology – #53503, #53691

Build/Test Tools

  • Update the caniuse browser data and regenerate CSS#53277
  • Clean up skipping conditions and requirements for various tests – #53009
  • Correct the test for autosaving a post with Ajax – #53363
  • Replace assertContains() with assertStringContainsString() when used with strings – #53363, #46149
  • Require the WP_REST_Test_Controller class in WP_REST_Controller tests – #53363
  • Reset $current_screen global between tests to avoid cross-test interdependencies – #53431
  • Use more appropriate assertions in rest_sanitize_request_arg() tests – #53363
  • Use more appropriate assertions in various tests – #53123, #53363
  • Use more appropriate assertions in various tests – #53363
  • Use more appropriate assertions in various tests – #53363
  • Use more appropriate assertions in various tests – #53363
  • Use more appropriate assertions in various tests – #53363
  • Use more appropriate assertions in various tests – #53363
  • Use more appropriate assertions in various tests – #53363
  • Use more appropriate assertions in various tests – #53363

Bundled Themes

  • Revert the [51372] update to block patterns in bundled themes – #53617

Coding Standards

  • Fix WPCS issue in [51404]#53363
  • Use the correct formatting for multi-line comments

Customizer

  • Don’t always set normalizedTransitionendEventName to null#53562

Documentation

  • Correct documentation for wp_get_post_parent_id()#53399
  • Synchronize the $post_id argument description for some post and attachment functions – #53399
  • Various documentation fixes following [51129]#44314

Editor

  • Second round of package updates ahead of RC3
  • Backport fixes targetted for WordPress 5.8 RC4 – #53397
  • Include the fixes targetted for WordPress 5.8 RC3 – #53397

Help/About

  • Update the About page for 5.8 – #52775
  • Update the About section for 5.8 – #52775

Media

  • Document edge cases with the new image_editor_output_format filter#5366, #53668, #35725
  • Fix JS error in Media Library when infinite scroll enabled – #53672
  • When resizing WebP images set the compression to “lossy” by default. Fixes a bug where the compression was set to “lossless” when the uploaded WebP images have extended file format (VP8X) – #53653

Privacy

  • Ensure the copy button actually copies the suggested privacy policy text – #53652, #52891

Upgrade/Install

  • Add additional files to $_old_files for 5.8 – #53367

Widgets

  • Prevent widgets unintentionally being moved to the inactive sidebar#53657
  • Replace wp.editor references in the legacy text widget#53437
  • Use wp_sidebar_description() to retrieve a sidebar’s description#53646
  • Validate HTML before saving block widgets

Props

Thanks to the 35 people who contributed to WordPress Core on Trac last week: @desrosj (6), @SergeyBiryukov (4), @jrf (3), @peterwilsoncc (3), @hellofromTonya (3), @adamsilverstein (2), @javiarce (2), @talldanwp (2), @zieladam (2), @timothyblynjacobs (2), @mikeschroder (2), @antpb (1), @denisco (1), @milana_cap (1), @karmatosed (1), @audrasjb (1), @nao (1), @kevin940726 (1), @noisysocks (1), @jorbin (1), @johnbillion (1), @mukesh27 (1), @kapilpaul (1), @youknowriad (1), @ianmjones (1), @mcsf (1), @get_dave (1), @ellatrix (1), @walbo (1), @dd32 (1), @htmgarcia (1), @linux4me2 (1), @mmxxi (1), @wildworks (1), and @spacedmonkey (1).

Congrats and welcome to our 3 new contributors of the week! @htmgarcia, @linux4me2, and @mmxxi ♥️

Core committers: @sergeybiryukov (16), @desrosj (12), @youknowriad (2), @ryelle (2), @johnbillion (1), @joedolson (1), @azaozz (1), @mikeschroder (1), and @peterwilsoncc (1).

#5-8, #week-in-core

WordPress 5.8 Release Day Process

We’re less than 24 hours away from WordPress 5.8! If you would like to help with the final steps of the release, here is how you can join in.

The current plan is to start the release process at Tuesday, July 20, 2021 at 03:00 PM UTC in the #core Slack channel.

The major version release process can take a bit more time than the Betas or Release Candidates do, particularly if we run into any last minute issues that need to be addressed.

The Release Process

We will be working through the Major Version Release process for anyone who wants to follow along. Earlier today the pre-final release dry run was coordinated in #core (Slack archive).

How You Can Help

A key part of the release process is checking that the ZIP packages work on all the different server configurations available. If you have some of the less commonly used servers available for testing (IIS, in particular), that would be super helpful. Servers running older versions of PHP and MySQL will also need testing.

There are two ways to help test the package:

In particular, testing the following types of installs and updates would be much appreciated:

  • Does a new WordPress install work correctly? This includes running through the manual install process, as well as WP-CLI or one-click installers.
  • Test upgrading from 4.0.33, 4.9.18, 5.7.2, and 5.8 RC 4 as well as any other versions possible
  • Remove wp-config.php file and test fresh install
  • Test single site and multisite/network (both subdirectory and subdomain) installs
  • Does it upgrade correctly? Are the files listed in $_old_files removed when you upgrade?
  • Does Multisite upgrade properly?

Finally the following user flows, on desktop and mobile, would be great to validate work as expected:

  • Publish a post, including a variety of different blocks.
  • Comment on the post.
  • Install a new plugin/theme, or upgrade an existing one.
  • Change the site language.
  • If you’re a plugin developer, or if there are complex plugins you depend upon, test that they’re working correctly.

You can even start this early, by running the WordPress 5.8 RC4 packages, which are built using the same method as the final packages.

#5-8, #release-process

The upgrade core has a lot of changes I’m looking forward to. Thank you team.