This post summarizes the weekly editor chat meeting on Wednesday, 12 January 2022, 14:00 UTC held in Slack.
WordPress and Gutenberg 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/ Releases
@jorgefilipecosta started the chat by saying Gutenberg 12.3 was released on the 5 of January. Details related to the Gutenberg release can be read in this post. The notable features are new blocks one can use and the gap and typography support additions to the group block 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..
Regarding the WordPress release, @jorgefilipecosta said the RC2 was released on 11 of January and things are going smoothly with the WordPress release. The final WordPress 5.9 version is planned for 25 of January 2022.
From the editor side on 5.9 must-have board we still have 9 to-do items and 3 items are in progress.
Native mobile app
- Line-height issue on Android
- Link picker freeze when virtual keyboard is hidden
- Text formatting issue when backspace is used
- Cover block regression 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. related to the color settings
- Final tweaks in the GSS Font size/color implementation
- Finalizing reliability improvements of the mobile translations pipeline
Template editor, site editor, and styles
Two PR’s were submitted (#1, #2) that implement code editing for edit site and the ability to copy the template content. These PR’s when merged will bring UI parity between the site editor and post editor.
Regarding the styles project the focus was on testing things and improving what we have in the core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. by fixing some bugs, improving the escaping of some parts, and fixing missed backports.
Worked on bringing parity between site editor and post editor. For the next week plans on:
WordPress 6.0 project board
@paaljoachim shared the following:
As there are issues that are punted from WP 5.9. Will it be helpful to get a project board up as soon as possible for WP 6.0 to be sure that punted issues and other issues are handled early? Similar to how Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. has a tag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) for 6.0 early tickets.
@jorgefilipecosta answered that we don’t have a board for 6.0 because the assumption is everything that is being worked on will be part of 6.0.
Block editor dependency on user endpoints
@tomjn shared the following:
I had hoped to raise a subject I wanted to talk about last week but I will not be around tomorrow. I’d much appreciate anybody who can look into the issue of the editor making the invalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. assumption that the user is always logged in and always has a usable active session.
This has crippled Frontenberg but also doesn’t account for expired WP sessions, cancelled sessions, etc, and does not have an appropriate fallback ( it results in a partial code editor view ). Default behaviour in WordPress has always been to show a modal dialog with the login window, and past Gutenberg behaviour has been to assume the user cannot publish and adjust the UI User interface accordingly e.g. submit for review rather than publish/update. It’s also prior precedent that these types of REST request are bundled with the initial page load to avoid the additional request so there are performance consequences
@jorgefilipecosta said this seems like an issue we should address. We just need someone to work on the fix.
@tomjn said that his hunch at the moment is that getEntityRecords handles this and the same pattern would work for getCurrentUser but it’s mainly speculation. If that’s the case the fix is simple.
Typography settings consitency and list block class
@luminuu shared the following:
While testing the 5.9 RC1, I came across the inconsistency of the font family selection at the typography settings. It was reverted from the paragraph block but it is still in use in some other blocks. To avoid confusion with users, I suggested to remove the font family setting from the other blocks as well. Please have a look and share your thoughts: https://github.com/WordPress/gutenberg/issues/37826
I also want to request some help with the PR https://github.com/WordPress/gutenberg/pull/36676 as I’m struggling to have the checks running through properly. This PR is related to an issue of the 5.9 Must Have project: https://github.com/WordPress/gutenberg/issues/37388
@jorgefilipecosta said that regarding #37826 @ntsekouras created a PR to address it. Regarding #36676 the addition of a class to the list block was discussed as part of the fix to the issue #37388. @oandregal proposed an alternative fix and left his thoughts after the chat in this comment.
Unexpected style warnings
@joostdevalk shared the following:
Hey team! I have a problem I want to submit to you all.
- In this PR an error was introduced that is thrown when Gutenberg thinks styles are not added properly.
- As becomes clear from the content of the errors, only styles added by blocks or themes are taken into account. However, plugins can add styles as well. At Yoast we add a style sheet to add styling to our metabox A post metabox is a draggable box shown on the post editing screen. Its purpose is to allow the user to select or enter information in addition to the main post content. This information should be related to the post in some way..
- We haven’t changed the way we include those styles in years, but suddenly console errors started showing up. Even though nothing breaks functionally, errors are thrown, which means people will start blaming us if something actually breaks.
- In this PR the level of the errors was lowered to warnings.
- In October, Ella drafted a PR that would make sure no warnings were thrown anymore.
- Because this was quite a big PR, it was decided to extract the fix related to the warnings to a separate PR. This PR has been open since about a month.
- Earlier this week, the PR was removed from the
WordPress 5.9 Must-Haves project board.
We’d really like to have Ella’s PR merged into 5.9 to prevent warnings from being thrown, to prevent support load and getting the blame for broken things that are unrelated to us.
I’m a little worried about including the fix in RC 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). that hasn’t been well tested.Maybe we should remove the warning from 5.9; since plugins that add CSS Cascading Style Sheets. files to the editor have no way to fix it. And as @joostdevalk mentioned, it will just increase support overhead.Then we can try and ship #37466 in the point 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..
At this point, the warning does more harm than good. The intention behind it is good, but if we can’t fix the current implementation for 5.9, then temporarily removing these warnings makes sense
@jorgefilipecosta we can have a PR disabling the warnings and discuss in more detail on the PR.
Escaping in bocks
@fabiankaegy said the following:
I just quickly wanted to throw in this discussion I opened regarding how block should handle late escaping the content of inner blocks in dynamic blocks here: https://github.com/WordPress/gutenberg/discussions/37823It is something that keeps popping up in for example WordPress VIP code reviews and there isn’t really any guidance in the docs or in the core codebase.
@jorgefilipecosta added that the issues arise when a block outputs any information the user can manipulate like attributes. Any kind of output containing use information should be escaped as close to the output as possible. Following the WordPress principle of sanitizing sooner escaping late. @jorgefilipecosta ended the subject by sharing that @getdave is making some improvements to how core escapes information.