Summary of Hallway Hangout on what’s next in Gutenberg

This is a summary of a Hallway Hangout that was first announced on Make Core. The aim was to have a shared space where we could chat about what’s being worked on to provide broader awareness to more WordPress contributors and get feedback. The hope is that by coming together early before the next 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. period to talk about different features, we can, as a community, flush out concerns sooner, help more folks get involved, and find ways to work better together. Thank you to the 18 folks who joined and to @saxonafletcher and @richtabor for demoing. 

Video Recording:

Demos:

The first hour or so covered demos of features with a few questions mixed throughout. What follows is a high level description of the demo topic with links to GitHubGitHub 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/ issues to dive into more and questions asked and answered related to the topic. To make it easier to follow, I also tried my best to split each demo into each section so folks can pick and choose to engage as they’d like. This doesn’t include the full footage but it includes the relevant bits for demoing.

Theme Style Presets

Rich quickly went through at a high level theme style variations, using Twenty Twenty-Four theme as a use case. He then went through abstracting color and typography styles (more than just fonts and includes things like letter spacing) as their own presets. This work was initially merged in a recent PR and works with all existing themes today that support style variations. Going forward, there are some technical details to iron out along with potentially evolving the experience to better support themes with a large set of variations. For a greater view of this general area, dive into the Colors and typeset presets from theme style variations overview issue

Section Styles

Rich recapped the 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. style variations mechanism and how you can register variations via theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. for multiple blocks at a time, including a demo of how this functionality would work in the editor to allow for “section styles”. This isn’t inventing anything new but modifying existing functionality of block styles. The biggest new functionality is that you can assign a variation to multiple blocks and to child blocks at one time. For Rich’s demo, switching between variations changed the styling for Group, Column, and Columns blocks. Overall, this work for 6.6 is being tracked here with the biggest PR still underway to extend block style variations as a mechanism to support this.

Q: For light/dark in the block styles demo, how are these configured differently than a block style or block variation?

Reusing block style variation and applying it to all child/nested blocks too. With all of those combinations, can still granularly change things. It’s make theme.json more portable across themes. 

Q: Are there any naming conventions needed for consistency of colors?

Any theme can decide what these variations look like so it doesn’t matter what the color slugs are that a theme uses. In previous themes, base and contrast were primary color slugs used but any other color combinations you can’t guarantee. This allows the theme to define what combinations of colors work well and the theme styles that variation rather than guessing and match up different slugs. 

We briefly touched on the many related issues there are around color naming as a broader topic: #29568 & #53996 & 39372.

Q: Is the theme.json you are showing available to look at somewhere?

Yes. Here’s the relevant, new bits from Rich’s demo:

{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 2,
"title": "Section Styles",
"styles": {
"blocks": {
"variations": {
"colorway-1": {
"supportedBlockTypes": [
"core/group",
"core/columns"
],
"color": {
"background": "var(--wp--preset--color--theme-2)",
"text": "var(--wp--preset--color--theme-3)"
},
"blocks": {
"core/separator": {
"color": {
"text": "var(--wp--preset--color--theme-3)"
}
},
"core/heading": {
"elements": {
"link": {
"color": {
"text": "var(--wp--preset--color--theme-3)"
}
}
}
}
},
"elements": {
"link": {
"color": {
"text": "var(--wp--preset--color--theme-3)"
}
},
"button": {
"color": {
"background": "var(--wp--preset--color--theme-3)",
"text": "var(--wp--preset--color--theme-1)"
},
":hover": {
"color": {
"background": "var(--wp--preset--color--theme-4)",
"text": "var(--wp--preset--color--theme-1)"
}
}
},
"heading": {
"color": {
"text": "var(--wp--preset--color--theme-3)"
}
}
}
},
"colorway-2": {
"supportedBlockTypes": [
"core/group",
"core/columns"
],
"color": {
"background": "var(--wp--preset--color--theme-4)",
"text": "var(--wp--preset--color--theme-2)"
},
"blocks": {
"core/separator": {
"color": {
"text": "var(--wp--preset--color--theme-2)"
}
},
"core/heading": {
"elements": {
"link": {
"color": {
"text": "var(--wp--preset--color--theme-1)"
}
}
}
}
},
"elements": {
"link": {
"color": {
"text": "var(--wp--preset--color--theme-2)"
}
},
"caption": {
"color": {
"text": "var(--wp--preset--color--theme-2)"
}
},
"button": {
"color": {
"background": "var(--wp--preset--color--theme-1)",
"text": "var(--wp--preset--color--theme-4)"
},
":hover": {
"color": {
"background": "#FFFFFFE3",
"text": "var(--wp--preset--color--theme-4)"
}
}
},
"heading": {
"color": {
"text": "var(--wp--preset--color--theme-1)"
}
}
}
},
"colorway-3": {
"supportedBlockTypes": [
"core/group",
"core/columns"
],
"color": {
"background": "var(--wp--preset--color--theme-5)",
"text": "var(--wp--preset--color--theme-2)"
},
"blocks": {
"core/separator": {
"color": {
"text": "var(--wp--preset--color--theme-1)"
}
},
"core/heading": {
"elements": {
"link": {
"color": {
"text": "var(--wp--preset--color--theme-1)"
}
}
}
}
},
"elements": {
"link": {
"color": {
"text": "var(--wp--preset--color--theme-2)"
}
},
"caption": {
"color": {
"text": "var(--wp--preset--color--theme-2)"
}
},
"button": {
"color": {
"background": "var(--wp--preset--color--theme-3)",
"text": "var(--wp--preset--color--theme-1)"
},
":hover": {
"color": {
"background": "var(--wp--preset--color--theme-4)",
"text": "var(--wp--preset--color--theme-1)"
}
}
},
"heading": {
"color": {
"text": "var(--wp--preset--color--theme-1)"
}
}
}
}
}
}
}
}

Q: Are these essentially class-based? i.e. will these style variations still work with CSSCSS Cascading Style Sheets. files (and JSON at the same time)?

Yes, class based like other block style variations.

Zoomed out view

Rich demoed the work being done around zoomed out editing which emphasizes patterns rather than editing blocks, allowing you to quickly build with patterns (reorder, delete, apply section styles, shuffle). There are some UXUX User experience considerations to figure out, including ensuring the mode is invoked at the right time and drag & drop works well. The work done here could also apply in the future to the experience of adding a new page or even onboarding into WordPress. It’s unclear right now whether it’s something that will be a toggle to use as you want or a view that’s offered in targeted moments (ie global styles or inserting patterns). 

Q: By zooming out for the pattern view – does that mean that patterns aren’t still useful for smaller groups of blocks (i.e. wanting to add a CTA pattern to a column)?

These patterns are still useful! This new option is simply offering a different context and allowing you to engage with patterns in a different way. This is also something to figure out how to do to provide a level to add patterns to a specific section. 

Q: I’m missing the purpose of the shuffle button. What if it was a button the showed all relevant patterns to replace the current one with?

It’s an exploration to see if it’s viable and it might not be where we end up. Of note, shuffling just goes to the next pattern rather than a random pattern. We talked at this point about different ways of interacting with patterns, including replacing patterns in the Inspector or selecting patterns from a modal (query loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. block) or shuffling. 

Advancing data views

Saxon demoed the latest work around Data Views including a new list view layout type for posts, new default views for templates, and the efforts done to merge patterns & template parts. He discussed being able to set custom views and how useful that will be especially in an enterprise context when lots of folks are working across content. He also shared a figma prototype showing what it might look like with products, rather than posts/pages, to show a custom post typeCustom Post Type WordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept. experience. 

As part of this broader work, the Details and Inspector are being unified to simplify both where to find information and the steps to get to editing (without the Details panel, you can go straight into the editing experience). We discussed extensibility, namely around the APIs currently being private but how the work is being tackled with extensibility at its coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. For folks who want to explore today, they can bundle the data view styles in their plugin. In looking ahead, we also talked about responsiveness improvements and how consumers of these components can decide how to define the experience, including any default views or custom views. 

Q: That preview of the “product custom fields” as a screen you see before the editor – how does that design relate to the modal for legacy metaboxes that is also happening?

Ideally any data values associated with a post type should be actionable within data views, including generating fields for data. Currently, the data views work is looking at ways to quick edit and bulk edit when selecting multiple items. In some cases, this might be done by editing in the Inspector. There needs to be a broader discussion to define what’s shown in each view vs in the inspector instead of at the bottom. In some cases, there are benefits for things that require more space, like products, to having a more detail style view as a middle step, to allow for editing rather than having something on the bottom or side where you’re trying to edit something in a smaller space. 

As part of this answer, we also talked about the upcoming developer hours on alternatives to custom metaboxes. 

Q: Are we able to control where our custom post type appears in the 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. order?

Not yet! Need to figure out more technical details, including around routing

Overrides in synced patterns

Saxon went through what synced patterns are along with how overrides function, allowing you to edit a part of a synced pattern while keeping the rest in sync, and showcased a synced pattern with overrides and contentOnly editing enabled. This work is being tracked for 6.6 after being punted from 6.5. As part of this overall feature, we also discussed advancing contentOnly editing to create a simpler editing experience by surfacing more top level sections rather than needing to work about the block hierarchy and providing easy access to edit specific aspects in the inspector. 

Q: Would like to hear thoughts on pattern overrides/content locking working with blocks that use repeatable inner blocks (lists, buttons, etc)? 

This touches on a common limitation of these kinds of tools and is captured in a related GitHub issue. We talked about how, in the future, you can add overrides for all inner blocks as a way to work around this but, for now, this limitation remains. For example, you could make a grid block overrideable with all children within it inheriting the same.

Block connections

Saxon demoed block connections with an example post type called “Events” with a custom template with a handful of blocks connected to custom fields (location, venue). Right now, this connection has to be made in code including for what’s planned for 6.6 but there’s a larger vision that includes how this could be edited in the interface in the future. For 6.6 though, the ability to edit the custom fieldCustom Field Custom Field, also referred to as post meta, is a feature in WordPress. It allows users to add additional information when writing a post, eg contributors’ names, auth. WordPress stores this information as metadata. Users can display this meta data by using template tags in their WordPress themes. visually is planned. Saxon demoed this by editing the custom field directly in an individual event post and showing how it was updated in the posts lists automatically. Saxon also showed how the data will all remain in sync if you have the custom field displayed in multiple places. As a final demo, Saxon showed a Query Loop block querying through the events post type and how he can simply copy/paste the blocks with custom fields into the Query Loop to reuse the functionality there. 

Q: Do these fields have to be registered somewhere or are they automatically detected/available by adding it via the code editor?

Yes, they need to be registered and be “non-protected”. Here’s part 1 and part 2 of a developer blogblog (versus network, site) post on connecting custom fields for more information.  

Q: What field types (text, select, relationship) is this expected to support when introduced? For custom fields and block binding. 

For 6.5, the following are supported: 

  • Paragraph: content.
  • Heading: content.
  • Image: URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org, alt, and title.
  • Button: text, URL, linkTarget, rel.

Grid layout

Saxon showed the work in progress layout improvements for the Grid layout option. There are two modes in Grid: auto (set minimum column width and can’t manually set items) and manual (set number of columns, set number of rows, and manually set items). Once a grid is placed in manual mode, you can reposition them and create new items. Saxon discussed the explorations around being able to “pin to grid” as a way to say that a grid item should never move and how with manual mode this idea of pinning would go away leaving everything to be seen as pinned to the grid manually. This makes manual mode more complex and, for something more structured, that’s where auto mode would be used. A big part of the entire feature is figuring out the best default experience for folks. If you want to follow this work, there’s now a 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 for discussions: #feature-grid

Q: Any thoughts on how some of these more unique grid layouts will work on mobile?

There are lots of various discussions around how best to do this and we need to be smart initially around how to stack items, like stack on mobile for columns.

Q: Can we overlap items?

Not yet. There’s a limit in place to prevent that. You can create overlapping items but for v1 we will limit how you can do that. The end goal is you can in the future.

Additional questions

Q: Summarizing a question asked live –  where do I get new information about what’s coming up, especially outside of the technical resources? What do I have to follow? 

We talked about how all levels of communication are needed from longer tutorials to quick reels to user friendly resources to deeply technical walkthroughs. This is a “forever problem” that cuts across how information is found on the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ website to release resources to the entire experience of using WordPress. We talked about how the media corps work might help with this too. 

Q: How do we feel about the fact that the Fonts 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. exist while also encouraging theme builders to ship fonts so that variations (typography) are available in global styles? Themes are sometimes shipping 50 fonts. How much do we ship? Should a theme ship with no font? A lot of these themes are huge! This is a more philosophical question. 

We talked about how we could potentially reconcile these so declaring a font family in theme.json could potentially bring it into the site editor but that, in general, fonts should still provide presets for users. Ideally, it can all be connected to the font library to keep fonts in one place but we shouldn’t make users go hunting for fonts and themes should be opinionated in how they want folks to use it. 

Q: I’d love to hear if anyone has a fix for this issue I’m dealing with regarding caching and style variations.  tldr the style variations cache doesn’t clear, so you have to switch back and forth between variations to clear it while working on a new theme.

Please chime in on the issue if you think you can help! None of us on the call had a good answer for it as it mainly requires a workaround rather than a fix that can be shipped as it’s a known limitation. 

#gutenberg, #hallway-hangout, #outreach, #site-editor