This post summarizes the weekly editor chat meeting on Wednesday, 21 October 2020, 14:00 UTC held in Slack.
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/ 9.2 and WordPress 5.6 Beta 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 Widget 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 sidebar 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 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. (https://github.com/WordPress/gutenberg/pull/26279) a needs review.
- Query block enhancements(loading and no results messages, focus Query on insertion)
- 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 API 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:
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 GitHub GitHub is a website that offers online implementation of git repositories that 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.
- Woking on a new image-related feature: duotone filter 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.
- 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.
- Tried to help a bit with core 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).
- 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
- 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 bug 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
- 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 HTML 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.
- 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
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.
Testing daily builds of the plugin.zip (for now published on Gutenberg Times).
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.
- 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, UI User interface, dev) via Zoom sessions
Open floor
Updating WordPress trunk 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 plugin 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 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 blocker 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 (PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher changes) can’t be automated.
Multi-line Code blocks 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.
@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 accessibility 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
