Wordpress News

WPTavern: WP Engine Makes Local Pro Free for All Users

Wordpress Planet - Wed, 06/30/2021 - 04:28

WP Engine announced today that Local Pro, the commercial upgrade for its local WordPress development product, is now free for all users. Beginning with version 6.0, all features that formerly required a paid subscription are now available with a free Local account. These include Live Links Pro, Instant Reload, Link Checker, and MagicSync.

“We believe Local Pro features benefit a broader WordPress developer community and we want to deliver the full value of Local to more developers than ever,” WP Engine Senior Vice President Seth Halpern said. “We want to empower the freedom to create on WordPress by making all Local features available for free.”

WP Engine’s recently published research estimates the WordPress economy at $596.7B. The company may be in a better position to gain customers for its hosting products if they make Local completely free, as the tool was designed to seamlessly connect with WP Engine and Flywheel’s hosting. It is currently used by more than 300,000 developers. Over the years Local has gained popularity due to how easy it makes setting up WordPress development and testing environments.

Version 6.0 also introduces Local’s new Cloud Backups add-on, which will allow users to backup to Google Drive or Dropbox. Cloud backups can be restored from the Tools tab. The 6.0 release post details a few features that have been moved to new locations in the interface:

  • MagicSync is now a global preference, and the default push/pull experience can be toggled in the Preferences menu. 
  • Live Links Pro, now Live Links, will be accessible for all users by connecting your Local account.
  • Link Checker and Instant Reload have been moved to the Local Add-ons Library. 
  • Xdebug Add-ons have moved from the Utilities tab into the Tools tab within Local.

Existing Local Pro subscribers will have access to priority support until September 1, 2021. After that time, dedicated ticket support will be discontinued in favor of directing users to the community forums and help docs. WP Engine is offering customers full or prorated refunds, which will be sent out before July 31, 2021.

WPTavern: Add Editor-Only Notes via the Markdown Comment Block WordPress Plugin

Wordpress Planet - Wed, 06/30/2021 - 00:15

Rich Tabor, the Senior Product Manager of WordPress Experience at GoDaddy, tweeted that he had an idea for a new block at the end of last week. Shortly after, the Markdown Comment Block plugin appeared on WordPress.org.

The plugin is a one-off block. It allows users to enter notes directly into the post editor that will not appear on the front end of the site. Tabor said he came up with the idea when working on an article for building single-block plugins.

There are few things I love more than simple plugins with a tight focus, performing a single function. Markdown Comment Block lands in this category.

The plugin creates a new block that works nearly the same as a typical Paragraph block:

Adding inline comments to a post.

Users can change the text color, but they will not have access to the typical Rich Text controls. Those should be unnecessary anyway.

As someone who does long-form writing almost exclusively in Markdown, the block’s use of the double percent-sign syntax for comments intrigued me. Technically, the Markdown spec does not support any sort of special characters for them. It handles HTML comments. However, those appear in the source code on the front end when the document is rendered. I have only seen the %% mark to denote comments in the Inspire Writer app for Windows. Tabor said he had seen the same in Ulysses. The feature also exists in the Iceberg editor for WordPress, which Tabor created alongside Jeffrey Carandang.

The plugin also introduces the %% keyboard shortcut. Typing it directly in the editor will create a new Markdown Comment block.

My primary use case for the plugin would be leaving notes for my later self. However, it could also be handy in users’ publishing flows. The block adds a “Resolve” button to the toolbar. Clicking it deletes the comment.

Clicking the “Resolve” button will delete the block.

The block itself will not likely offer a robust enough feature set for complex workflows. However, pairing it with a plugin like Post Descriptions could round out the experience for larger teams of writers and copyeditors.

The Post Descriptions plugin allows users to add notes on the post level. These notes appear on the post-management screen, letting other team members know when to check an article. However, it may be hard to provide the full context of what issues need to be resolved before publishing. Markdown Comment Block adds an inline comments system, letting team members pass in-text notes.

Theme developers should appreciate that the block uses CSS custom properties too, which makes it easy to overwrite its default style rules. In moments, I was able to make it match my theme:

Custom color, font, and line-height styles.

The --markdown-comment-font-size, --markdown-comment-line-height, and --markdown-comment-color variables are available for theme developers who want to add in support.

The one complaint I had about the block is its title: “Comment.” It is easy to confuse it with the six other comment-related blocks already in the WordPress block list. And, there will only be more in upcoming versions. Giving it a title of “Markdown Comment” would better distinguish it from others.

WPTavern: Add Editor-Only Notes via the Markdown Comment Block WordPress Plugin

Wordpress Planet - Wed, 06/30/2021 - 00:15

Rich Tabor, the Senior Product Manager of WordPress Experience at GoDaddy, tweeted that he had an idea for a new block at the end of last week. Shortly after, the Markdown Comment Block plugin appeared on WordPress.org.

The plugin is a one-off block. It allows users to enter notes directly into the post editor that will not appear on the front end of the site. Tabor said he came up with the idea when working on an article for building single-block plugins.

There are few things I love more than simple plugins with a tight focus, performing a single function. Markdown Comment Block lands in this category.

The plugin creates a new block that works nearly the same as a typical Paragraph block:

Adding inline comments to a post.

Users can change the text color, but they will not have access to the typical Rich Text controls. Those should be unnecessary anyway.

As someone who does long-form writing almost exclusively in Markdown, the block’s use of the double percent-sign syntax for comments intrigued me. Technically, the Markdown spec does not support any sort of special characters for them. It handles HTML comments. However, those appear in the source code on the front end when the document is rendered. I have only seen the %% mark to denote comments in the Inspire Writer app for Windows. Tabor said he had seen the same in Ulysses. The feature also exists in the Iceberg editor for WordPress, which Tabor created alongside Jeffrey Carandang.

The plugin also introduces the %% keyboard shortcut. Typing it directly in the editor will create a new Markdown Comment block.

My primary use case for the plugin would be leaving notes for my later self. However, it could also be handy in users’ publishing flows. The block adds a “Resolve” button to the toolbar. Clicking it deletes the comment.

Clicking the “Resolve” button will delete the block.

The block itself will not likely offer a robust enough feature set for complex workflows. However, pairing it with a plugin like Post Descriptions could round out the experience for larger teams of writers and copyeditors.

The Post Descriptions plugin allows users to add notes on the post level. These notes appear on the post-management screen, letting other team members know when to check an article. However, it may be hard to provide the full context of what issues need to be resolved before publishing. Markdown Comment Block adds an inline comments system, letting team members pass in-text notes.

Theme developers should appreciate that the block uses CSS custom properties too, which makes it easy to overwrite its default style rules. In moments, I was able to make it match my theme:

Custom color, font, and line-height styles.

The --markdown-comment-font-size, --markdown-comment-line-height, and --markdown-comment-color variables are available for theme developers who want to add in support.

The one complaint I had about the block is its title: “Comment.” It is easy to confuse it with the six other comment-related blocks already in the WordPress block list. And, there will only be more in upcoming versions. Giving it a title of “Markdown Comment” would better distinguish it from others.

WPTavern: Add Editor-Only Notes via the Markdown Comment Block WordPress Plugin

Wordpress Planet - Wed, 06/30/2021 - 00:15

Rich Tabor, the Senior Product Manager of WordPress Experience at GoDaddy, tweeted that he had an idea for a new block at the end of last week. Shortly after, the Markdown Comment Block plugin appeared on WordPress.org.

The plugin is a one-off block. It allows users to enter notes directly into the post editor that will not appear on the front end of the site. Tabor said he came up with the idea when working on an article for building single-block plugins.

There are few things I love more than simple plugins with a tight focus, performing a single function. Markdown Comment Block lands in this category.

The plugin creates a new block that works nearly the same as a typical Paragraph block:

Adding inline comments to a post.

Users can change the text color, but they will not have access to the typical Rich Text controls. Those should be unnecessary anyway.

As someone who does long-form writing almost exclusively in Markdown, the block’s use of the double percent-sign syntax for comments intrigued me. Technically, the Markdown spec does not support any sort of special characters for them. It handles HTML comments. However, those appear in the source code on the front end when the document is rendered. I have only seen the %% mark to denote comments in the Inspire Writer app for Windows. Tabor said he had seen the same in Ulysses. The feature also exists in the Iceberg editor for WordPress, which Tabor created alongside Jeffrey Carandang.

The plugin also introduces the %% keyboard shortcut. Typing it directly in the editor will create a new Markdown Comment block.

My primary use case for the plugin would be leaving notes for my later self. However, it could also be handy in users’ publishing flows. The block adds a “Resolve” button to the toolbar. Clicking it deletes the comment.

Clicking the “Resolve” button will delete the block.

The block itself will not likely offer a robust enough feature set for complex workflows. However, pairing it with a plugin like Post Descriptions could round out the experience for larger teams of writers and copyeditors.

The Post Descriptions plugin allows users to add notes on the post level. These notes appear on the post-management screen, letting other team members know when to check an article. However, it may be hard to provide the full context of what issues need to be resolved before publishing. Markdown Comment Block adds an inline comments system, letting team members pass in-text notes.

Theme developers should appreciate that the block uses CSS custom properties too, which makes it easy to overwrite its default style rules. In moments, I was able to make it match my theme:

Custom color, font, and line-height styles.

The --markdown-comment-font-size, --markdown-comment-line-height, and --markdown-comment-color variables are available for theme developers who want to add in support.

The one complaint I had about the block is its title: “Comment.” It is easy to confuse it with the six other comment-related blocks already in the WordPress block list. And, there will only be more in upcoming versions. Giving it a title of “Markdown Comment” would better distinguish it from others.

WPTavern: Add Editor-Only Notes via the Markdown Comment Block WordPress Plugin

Wordpress Planet - Wed, 06/30/2021 - 00:15

Rich Tabor, the Senior Product Manager of WordPress Experience at GoDaddy, tweeted that he had an idea for a new block at the end of last week. Shortly after, the Markdown Comment Block plugin appeared on WordPress.org.

The plugin is a one-off block. It allows users to enter notes directly into the post editor that will not appear on the front end of the site. Tabor said he came up with the idea when working on an article for building single-block plugins.

There are few things I love more than simple plugins with a tight focus, performing a single function. Markdown Comment Block lands in this category.

The plugin creates a new block that works nearly the same as a typical Paragraph block:

Adding inline comments to a post.

Users can change the text color, but they will not have access to the typical Rich Text controls. Those should be unnecessary anyway.

As someone who does long-form writing almost exclusively in Markdown, the block’s use of the double percent-sign syntax for comments intrigued me. Technically, the Markdown spec does not support any sort of special characters for them. It handles HTML comments. However, those appear in the source code on the front end when the document is rendered. I have only seen the %% mark to denote comments in the Inspire Writer app for Windows. Tabor said he had seen the same in Ulysses. The feature also exists in the Iceberg editor for WordPress, which Tabor created alongside Jeffrey Carandang.

The plugin also introduces the %% keyboard shortcut. Typing it directly in the editor will create a new Markdown Comment block.

My primary use case for the plugin would be leaving notes for my later self. However, it could also be handy in users’ publishing flows. The block adds a “Resolve” button to the toolbar. Clicking it deletes the comment.

Clicking the “Resolve” button will delete the block.

The block itself will not likely offer a robust enough feature set for complex workflows. However, pairing it with a plugin like Post Descriptions could round out the experience for larger teams of writers and copyeditors.

The Post Descriptions plugin allows users to add notes on the post level. These notes appear on the post-management screen, letting other team members know when to check an article. However, it may be hard to provide the full context of what issues need to be resolved before publishing. Markdown Comment Block adds an inline comments system, letting team members pass in-text notes.

Theme developers should appreciate that the block uses CSS custom properties too, which makes it easy to overwrite its default style rules. In moments, I was able to make it match my theme:

Custom color, font, and line-height styles.

The --markdown-comment-font-size, --markdown-comment-line-height, and --markdown-comment-color variables are available for theme developers who want to add in support.

The one complaint I had about the block is its title: “Comment.” It is easy to confuse it with the six other comment-related blocks already in the WordPress block list. And, there will only be more in upcoming versions. Giving it a title of “Markdown Comment” would better distinguish it from others.

WPTavern: BuddyPress 9.0 Scheduled for Short Development Cycle to Ship Block-Based Widgets Ahead of WordPress 5.8

Wordpress Planet - Tue, 06/29/2021 - 01:07

BuddyPress 8.0 was just released earlier this month on June 6, but the core development team is gearing up for a short development cycle for 9.0. The release will be specifically targeted at getting BuddyPress core widgets ready for WordPress 5.8’s new block widgets experience. Contributors are aiming to hit the following timeline to ship 9.0 before the next major WordPress release:

  • Beta: July 8.
  • RC: July 12.
  • Final: July 16

BuddyPress entered the world of blocks with the release of version 6.0 in May 2020, allowing users to insert a specific Member or Group into content. Version 7.0, released six months later, introduced blocks for featuring a list of members, a list of groups, and the ability to embed a public activity post. Over the next few weeks, BuddyPress contributors will continue the process of migrating the rest of the BuddyPress component widgets to blocks. These include the following:

  • Blogs Recent Posts Widget: A list of recently published posts from across the network
  • BP Core Login Widget: Shows a Log In form to logged-out visitors, and a Log Out link to those who are logged in
  • BP Core Friends Widget: A dynamic list of recently active, popular, and newest Friends of the displayed member. Widget is only shown when viewing a member profile
  • BP Groups Widget: A dynamic list of recently active, popular, newest, or alphabetical groups
  • BP Core Members Widget: A dynamic list of recently active, popular, and newest members
  • BP Core Recently Active Widget: Profile photos of recently active members
  • BP Core Who’s Online Widget: Profile photos of online users
  • BP Messages Sitewide Notices Widget: Display Sitewide Notices posted by the site administrator

BP Nouveau widgets:

  • BP Latest Activities: Display the latest updates of your community having the types of your choice
  • BP Nouveau Navigation Widget: Displays BuddyPress primary nav in the sidebar of the site. (Must be used as the first widget of the sidebar and only once.)

In addition to building a block for every BuddyPress widget, contributors are aiming to make it possible to transform existing BP widgets into their corresponding BP block.

With the new block widgets screen imminently landing in WordPress, BuddyPress has to make this move forward to keep pace with the progress of the block editor’s march beyond use in the content editor. Otherwise, BuddyPress users would need to disable block widgets with the Classic Widgets plugin in order to maintain access to BuddyPress core widgets.

Contributors are also working on creating a new Follow component, a frequently requested feature which would use the now abandoned BuddyPress Follow plugin as inspiration. The feature will work similar to Twitter following or the Facebook follow button that allows users to see public activity posts for those they are following. The Follow component is being built as a plugin first and will ship with 9.0 if it is ready in time.

WPTavern: BuddyPress 9.0 Scheduled for Short Development Cycle to Ship Block-Based Widgets Ahead of WordPress 5.8

Wordpress Planet - Tue, 06/29/2021 - 01:07

BuddyPress 8.0 was just released earlier this month on June 6, but the core development team is gearing up for a short development cycle for 9.0. The release will be specifically targeted at getting BuddyPress core widgets ready for WordPress 5.8’s new block widgets experience. Contributors are aiming to hit the following timeline to ship 9.0 before the next major WordPress release:

  • Beta: July 8.
  • RC: July 12.
  • Final: July 16

BuddyPress entered the world of blocks with the release of version 6.0 in May 2020, allowing users to insert a specific Member or Group into content. Version 7.0, released six months later, introduced blocks for featuring a list of members, a list of groups, and the ability to embed a public activity post. Over the next few weeks, BuddyPress contributors will continue the process of migrating the rest of the BuddyPress component widgets to blocks. These include the following:

  • Blogs Recent Posts Widget: A list of recently published posts from across the network
  • BP Core Login Widget: Shows a Log In form to logged-out visitors, and a Log Out link to those who are logged in
  • BP Core Friends Widget: A dynamic list of recently active, popular, and newest Friends of the displayed member. Widget is only shown when viewing a member profile
  • BP Groups Widget: A dynamic list of recently active, popular, newest, or alphabetical groups
  • BP Core Members Widget: A dynamic list of recently active, popular, and newest members
  • BP Core Recently Active Widget: Profile photos of recently active members
  • BP Core Who’s Online Widget: Profile photos of online users
  • BP Messages Sitewide Notices Widget: Display Sitewide Notices posted by the site administrator

BP Nouveau widgets:

  • BP Latest Activities: Display the latest updates of your community having the types of your choice
  • BP Nouveau Navigation Widget: Displays BuddyPress primary nav in the sidebar of the site. (Must be used as the first widget of the sidebar and only once.)

In addition to building a block for every BuddyPress widget, contributors are aiming to make it possible to transform existing BP widgets into their corresponding BP block.

With the new block widgets screen imminently landing in WordPress, BuddyPress has to make this move forward to keep pace with the progress of the block editor’s march beyond use in the content editor. Otherwise, BuddyPress users would need to disable block widgets with the Classic Widgets plugin in order to maintain access to BuddyPress core widgets.

Contributors are also working on creating a new Follow component, a frequently requested feature which would use the now abandoned BuddyPress Follow plugin as inspiration. The feature will work similar to Twitter following or the Facebook follow button that allows users to see public activity posts for those they are following. The Follow component is being built as a plugin first and will ship with 9.0 if it is ready in time.

WPTavern: BuddyPress 9.0 Scheduled for Short Development Cycle to Ship Block-Based Widgets Ahead of WordPress 5.8

Wordpress Planet - Tue, 06/29/2021 - 01:07

BuddyPress 8.0 was just released earlier this month on June 6, but the core development team is gearing up for a short development cycle for 9.0. The release will be specifically targeted at getting BuddyPress core widgets ready for WordPress 5.8’s new block widgets experience. Contributors are aiming to hit the following timeline to ship 9.0 before the next major WordPress release:

  • Beta: July 8.
  • RC: July 12.
  • Final: July 16

BuddyPress entered the world of blocks with the release of version 6.0 in May 2020, allowing users to insert a specific Member or Group into content. Version 7.0, released six months later, introduced blocks for featuring a list of members, a list of groups, and the ability to embed a public activity post. Over the next few weeks, BuddyPress contributors will continue the process of migrating the rest of the BuddyPress component widgets to blocks. These include the following:

  • Blogs Recent Posts Widget: A list of recently published posts from across the network
  • BP Core Login Widget: Shows a Log In form to logged-out visitors, and a Log Out link to those who are logged in
  • BP Core Friends Widget: A dynamic list of recently active, popular, and newest Friends of the displayed member. Widget is only shown when viewing a member profile
  • BP Groups Widget: A dynamic list of recently active, popular, newest, or alphabetical groups
  • BP Core Members Widget: A dynamic list of recently active, popular, and newest members
  • BP Core Recently Active Widget: Profile photos of recently active members
  • BP Core Who’s Online Widget: Profile photos of online users
  • BP Messages Sitewide Notices Widget: Display Sitewide Notices posted by the site administrator

BP Nouveau widgets:

  • BP Latest Activities: Display the latest updates of your community having the types of your choice
  • BP Nouveau Navigation Widget: Displays BuddyPress primary nav in the sidebar of the site. (Must be used as the first widget of the sidebar and only once.)

In addition to building a block for every BuddyPress widget, contributors are aiming to make it possible to transform existing BP widgets into their corresponding BP block.

With the new block widgets screen imminently landing in WordPress, BuddyPress has to make this move forward to keep pace with the progress of the block editor’s march beyond use in the content editor. Otherwise, BuddyPress users would need to disable block widgets with the Classic Widgets plugin in order to maintain access to BuddyPress core widgets.

Contributors are also working on creating a new Follow component, a frequently requested feature which would use the now abandoned BuddyPress Follow plugin as inspiration. The feature will work similar to Twitter following or the Facebook follow button that allows users to see public activity posts for those they are following. The Follow component is being built as a plugin first and will ship with 9.0 if it is ready in time.

WPTavern: BuddyPress 9.0 Scheduled for Short Development Cycle to Ship Block-Based Widgets Ahead of WordPress 5.8

Wordpress Planet - Tue, 06/29/2021 - 01:07

BuddyPress 8.0 was just released earlier this month on June 6, but the core development team is gearing up for a short development cycle for 9.0. The release will be specifically targeted at getting BuddyPress core widgets ready for WordPress 5.8’s new block widgets experience. Contributors are aiming to hit the following timeline to ship 9.0 before the next major WordPress release:

  • Beta: July 8.
  • RC: July 12.
  • Final: July 16

BuddyPress entered the world of blocks with the release of version 6.0 in May 2020, allowing users to insert a specific Member or Group into content. Version 7.0, released six months later, introduced blocks for featuring a list of members, a list of groups, and the ability to embed a public activity post. Over the next few weeks, BuddyPress contributors will continue the process of migrating the rest of the BuddyPress component widgets to blocks. These include the following:

  • Blogs Recent Posts Widget: A list of recently published posts from across the network
  • BP Core Login Widget: Shows a Log In form to logged-out visitors, and a Log Out link to those who are logged in
  • BP Core Friends Widget: A dynamic list of recently active, popular, and newest Friends of the displayed member. Widget is only shown when viewing a member profile
  • BP Groups Widget: A dynamic list of recently active, popular, newest, or alphabetical groups
  • BP Core Members Widget: A dynamic list of recently active, popular, and newest members
  • BP Core Recently Active Widget: Profile photos of recently active members
  • BP Core Who’s Online Widget: Profile photos of online users
  • BP Messages Sitewide Notices Widget: Display Sitewide Notices posted by the site administrator

BP Nouveau widgets:

  • BP Latest Activities: Display the latest updates of your community having the types of your choice
  • BP Nouveau Navigation Widget: Displays BuddyPress primary nav in the sidebar of the site. (Must be used as the first widget of the sidebar and only once.)

In addition to building a block for every BuddyPress widget, contributors are aiming to make it possible to transform existing BP widgets into their corresponding BP block.

With the new block widgets screen imminently landing in WordPress, BuddyPress has to make this move forward to keep pace with the progress of the block editor’s march beyond use in the content editor. Otherwise, BuddyPress users would need to disable block widgets with the Classic Widgets plugin in order to maintain access to BuddyPress core widgets.

Contributors are also working on creating a new Follow component, a frequently requested feature which would use the now abandoned BuddyPress Follow plugin as inspiration. The feature will work similar to Twitter following or the Facebook follow button that allows users to see public activity posts for those they are following. The Follow component is being built as a plugin first and will ship with 9.0 if it is ready in time.

WPTavern: Diving Into WordPress 5.8’s New Widgets Screen

Wordpress Planet - Mon, 06/28/2021 - 23:52

It has been a while since I have touched widgets. Once the site editor landed in the Gutenberg plugin, I almost exclusively dropped the old sidebar paradigm and moved to block templates. Reactivating old themes and jumping into the widgets screen felt like time-traveling into a bygone era.

After months of being deeply embedded within block themes, it is hard to imagine moving back to the sidebar widgets system that most WordPress users are still using today.

WordPress 5.8 is slated to ship with a small taste of bringing blocks outside of the content editor. However, it can feel like a surface-level refresh of a dying system, one that does not always work.

Block-based widgets are part of the transitional phase between classic WordPress and the future, which centers on a complete site editor. Once the bulk of themes are built atop blocks, the need for widgets will wane. The site editor and block themes do not support the old sidebar system. Instead, users will be able to place blocks anywhere.

Last October, I asked the question: Are Block-Based Widgets Ready To Land in WordPress 5.6? At the time, the widgets screen was expected to launch with the final release of 2020. However, the development team pulled back on the feature’s inclusion, primarily because the customizer implementation was sub-par.

Asking the same question of WordPress 5.8, my answer is mostly the same. It is time to ship the current feature and prepare for a future without widgets. There are so many components that are far more exciting around the corner. The primary user-experience issues will linger around until users have moved on to block themes.

I have long been in the camp of starting from a clean slate for block themes, letting widgets die out. However, the path WordPress has chosen is to create this stepping stone for users who may be on traditional themes for a while. It provides an opportunity to use blocks outside of the editor, which may be a leap forward for many.

With the vast number of libraries, one-off blocks, and support from plugin authors, users have a wealth of block choices at their fingertips. Right now, if there is no equivalent widget, those users can only ever use those blocks in their content. Within a block-widget system, that limitation does not exist.

It also lifts some burdens from developers. Those who want to shed some of their old code and go all-in on blocks can begin considering deprecating or retiring widgets.

Transitioning to the new Widgets screen should feel simple to users familiar with the WordPress content editor. Inserting blocks is the same. The difference is that each sidebar has its own container.

Widgets screen with a Gallery block in the Footer sidebar.

The range of blocks within core WordPress could also let users drop some of their widgets-based plugins. One of the most popular types of widgets over the years has been for handling post lists. There are dozens of such plugins and an untold number of themes that include one. Coupled with WordPress 5.8’s Query Loop block, users can now recreate many of those widgets themselves.

Custom post list using the Query Loop block.

Much of this depends on the theme’s design support of blocks and whether it will accommodate anything other than traditional widgets.

Customizer support for block widgets is lightyears ahead of where it was just a few short months ago. However, it feels awkward at best. There is a deep feeling of not belonging. While it was a remarkable programming feat to make the two features work together, the user experiences are nearly a decade apart.

Editing a Heading block in the customizer.

Despite the customizer providing a live preview, the Widgets screen in the WordPress admin gives the necessary workspace. Trying to squeeze the block editor into the tiny customize controls panel was never going to be an ideal experience, and it still is not. It gets the job done, but I recommend the traditional widgets screen for fewer headaches.

Problems Remain

In the eight months since I first dived into the block-based widgets, the system has been overhauled. However, the potential issues I brought up remain. Just dropping blocks into a sidebar can have mixed results. For example, compare a Legacy Widget to Heading and Latest Comments blocks in the footer sidebar of the popular OceanWP theme:

Mismatched headings and colors.

The issue is that WordPress treats every block as a widget. Traditionally, widgets have had both a title and content. Blocks have no such concept. A Heading followed by something like a Paragraph, Latest Comments, or another block has no special meaning in the block system. They are all treated separately.

This issue is in full view when adding blocks to the default Twenty Twenty-One WordPress theme:

Block treated as widget in Twenty Twenty-One footer sidebar.

Notice the Heading and Latest Comments blocks are columnized because they are seen as separate widgets.

To address this, users must add multiple blocks into a Group block if they want them treated as a single “widget.” It is a simple matter, but it could still be a usability hurdle for some.

Even with a fix in place, there is no guarantee that blocks will appear as the widgets the theme author intended.

I long ago gave up on the hope that there would be better handling for block widgets. The Classic Widgets plugin is available for those who need it, and theme authors can opt-out. These are necessary tools for an experience that can range from downright awesome to utterly broken.

Bringing blocks outside of the content editor for traditional theme users is probably necessary for the transition, but the current site editor experience already feels much smoother than block widgets. The long-term focus should be on moving away from the dated concept of widgets and into a WordPress front-end 100% built on blocks.

WPTavern: Diving Into WordPress 5.8’s New Widgets Screen

Wordpress Planet - Mon, 06/28/2021 - 23:52

It has been a while since I have touched widgets. Once the site editor landed in the Gutenberg plugin, I almost exclusively dropped the old sidebar paradigm and moved to block templates. Reactivating old themes and jumping into the widgets screen felt like time-traveling into a bygone era.

After months of being deeply embedded within block themes, it is hard to imagine moving back to the sidebar widgets system that most WordPress users are still using today.

WordPress 5.8 is slated to ship with a small taste of bringing blocks outside of the content editor. However, it can feel like a surface-level refresh of a dying system, one that does not always work.

Block-based widgets are part of the transitional phase between classic WordPress and the future, which centers on a complete site editor. Once the bulk of themes are built atop blocks, the need for widgets will wane. The site editor and block themes do not support the old sidebar system. Instead, users will be able to place blocks anywhere.

Last October, I asked the question: Are Block-Based Widgets Ready To Land in WordPress 5.6? At the time, the widgets screen was expected to launch with the final release of 2020. However, the development team pulled back on the feature’s inclusion, primarily because the customizer implementation was sub-par.

Asking the same question of WordPress 5.8, my answer is mostly the same. It is time to ship the current feature and prepare for a future without widgets. There are so many components that are far more exciting around the corner. The primary user-experience issues will linger around until users have moved on to block themes.

I have long been in the camp of starting from a clean slate for block themes, letting widgets die out. However, the path WordPress has chosen is to create this stepping stone for users who may be on traditional themes for a while. It provides an opportunity to use blocks outside of the editor, which may be a leap forward for many.

With the vast number of libraries, one-off blocks, and support from plugin authors, users have a wealth of block choices at their fingertips. Right now, if there is no equivalent widget, those users can only ever use those blocks in their content. Within a block-widget system, that limitation does not exist.

It also lifts some burdens from developers. Those who want to shed some of their old code and go all-in on blocks can begin considering deprecating or retiring widgets.

Transitioning to the new Widgets screen should feel simple to users familiar with the WordPress content editor. Inserting blocks is the same. The difference is that each sidebar has its own container.

Widgets screen with a Gallery block in the Footer sidebar.

The range of blocks within core WordPress could also let users drop some of their widgets-based plugins. One of the most popular types of widgets over the years has been for handling post lists. There are dozens of such plugins and an untold number of themes that include one. Coupled with WordPress 5.8’s Query Loop block, users can now recreate many of those widgets themselves.

Custom post list using the Query Loop block.

Much of this depends on the theme’s design support of blocks and whether it will accommodate anything other than traditional widgets.

Customizer support for block widgets is lightyears ahead of where it was just a few short months ago. However, it feels awkward at best. There is a deep feeling of not belonging. While it was a remarkable programming feat to make the two features work together, the user experiences are nearly a decade apart.

Editing a Heading block in the customizer.

Despite the customizer providing a live preview, the Widgets screen in the WordPress admin gives the necessary workspace. Trying to squeeze the block editor into the tiny customize controls panel was never going to be an ideal experience, and it still is not. It gets the job done, but I recommend the traditional widgets screen for fewer headaches.

Problems Remain

In the eight months since I first dived into the block-based widgets, the system has been overhauled. However, the potential issues I brought up remain. Just dropping blocks into a sidebar can have mixed results. For example, compare a Legacy Widget to Heading and Latest Comments blocks in the footer sidebar of the popular OceanWP theme:

Mismatched headings and colors.

The issue is that WordPress treats every block as a widget. Traditionally, widgets have had both a title and content. Blocks have no such concept. A Heading followed by something like a Paragraph, Latest Comments, or another block has no special meaning in the block system. They are all treated separately.

This issue is in full view when adding blocks to the default Twenty Twenty-One WordPress theme:

Block treated as widget in Twenty Twenty-One footer sidebar.

Notice the Heading and Latest Comments blocks are columnized because they are seen as separate widgets.

To address this, users must add multiple blocks into a Group block if they want them treated as a single “widget.” It is a simple matter, but it could still be a usability hurdle for some.

Even with a fix in place, there is no guarantee that blocks will appear as the widgets the theme author intended.

I long ago gave up on the hope that there would be better handling for block widgets. The Classic Widgets plugin is available for those who need it, and theme authors can opt-out. These are necessary tools for an experience that can range from downright awesome to utterly broken.

Bringing blocks outside of the content editor for traditional theme users is probably necessary for the transition, but the current site editor experience already feels much smoother than block widgets. The long-term focus should be on moving away from the dated concept of widgets and into a WordPress front-end 100% built on blocks.

WPTavern: Diving Into WordPress 5.8’s New Widgets Screen

Wordpress Planet - Mon, 06/28/2021 - 23:52

It has been a while since I have touched widgets. Once the site editor landed in the Gutenberg plugin, I almost exclusively dropped the old sidebar paradigm and moved to block templates. Reactivating old themes and jumping into the widgets screen felt like time-traveling into a bygone era.

After months of being deeply embedded within block themes, it is hard to imagine moving back to the sidebar widgets system that most WordPress users are still using today.

WordPress 5.8 is slated to ship with a small taste of bringing blocks outside of the content editor. However, it can feel like a surface-level refresh of a dying system, one that does not always work.

Block-based widgets are part of the transitional phase between classic WordPress and the future, which centers on a complete site editor. Once the bulk of themes are built atop blocks, the need for widgets will wane. The site editor and block themes do not support the old sidebar system. Instead, users will be able to place blocks anywhere.

Last October, I asked the question: Are Block-Based Widgets Ready To Land in WordPress 5.6? At the time, the widgets screen was expected to launch with the final release of 2020. However, the development team pulled back on the feature’s inclusion, primarily because the customizer implementation was sub-par.

Asking the same question of WordPress 5.8, my answer is mostly the same. It is time to ship the current feature and prepare for a future without widgets. There are so many components that are far more exciting around the corner. The primary user-experience issues will linger around until users have moved on to block themes.

I have long been in the camp of starting from a clean slate for block themes, letting widgets die out. However, the path WordPress has chosen is to create this stepping stone for users who may be on traditional themes for a while. It provides an opportunity to use blocks outside of the editor, which may be a leap forward for many.

With the vast number of libraries, one-off blocks, and support from plugin authors, users have a wealth of block choices at their fingertips. Right now, if there is no equivalent widget, those users can only ever use those blocks in their content. Within a block-widget system, that limitation does not exist.

It also lifts some burdens from developers. Those who want to shed some of their old code and go all-in on blocks can begin considering deprecating or retiring widgets.

Transitioning to the new Widgets screen should feel simple to users familiar with the WordPress content editor. Inserting blocks is the same. The difference is that each sidebar has its own container.

Widgets screen with a Gallery block in the Footer sidebar.

The range of blocks within core WordPress could also let users drop some of their widgets-based plugins. One of the most popular types of widgets over the years has been for handling post lists. There are dozens of such plugins and an untold number of themes that include one. Coupled with WordPress 5.8’s Query Loop block, users can now recreate many of those widgets themselves.

Custom post list using the Query Loop block.

Much of this depends on the theme’s design support of blocks and whether it will accommodate anything other than traditional widgets.

Customizer support for block widgets is lightyears ahead of where it was just a few short months ago. However, it feels awkward at best. There is a deep feeling of not belonging. While it was a remarkable programming feat to make the two features work together, the user experiences are nearly a decade apart.

Editing a Heading block in the customizer.

Despite the customizer providing a live preview, the Widgets screen in the WordPress admin gives the necessary workspace. Trying to squeeze the block editor into the tiny customize controls panel was never going to be an ideal experience, and it still is not. It gets the job done, but I recommend the traditional widgets screen for fewer headaches.

Problems Remain

In the eight months since I first dived into the block-based widgets, the system has been overhauled. However, the potential issues I brought up remain. Just dropping blocks into a sidebar can have mixed results. For example, compare a Legacy Widget to Heading and Latest Comments blocks in the footer sidebar of the popular OceanWP theme:

Mismatched headings and colors.

The issue is that WordPress treats every block as a widget. Traditionally, widgets have had both a title and content. Blocks have no such concept. A Heading followed by something like a Paragraph, Latest Comments, or another block has no special meaning in the block system. They are all treated separately.

This issue is in full view when adding blocks to the default Twenty Twenty-One WordPress theme:

Block treated as widget in Twenty Twenty-One footer sidebar.

Notice the Heading and Latest Comments blocks are columnized because they are seen as separate widgets.

To address this, users must add multiple blocks into a Group block if they want them treated as a single “widget.” It is a simple matter, but it could still be a usability hurdle for some.

Even with a fix in place, there is no guarantee that blocks will appear as the widgets the theme author intended.

I long ago gave up on the hope that there would be better handling for block widgets. The Classic Widgets plugin is available for those who need it, and theme authors can opt-out. These are necessary tools for an experience that can range from downright awesome to utterly broken.

Bringing blocks outside of the content editor for traditional theme users is probably necessary for the transition, but the current site editor experience already feels much smoother than block widgets. The long-term focus should be on moving away from the dated concept of widgets and into a WordPress front-end 100% built on blocks.

Gutenberg Times: Theme.json for WordPress Theme Authors – demo and Live Q & A w/ Daisy Olson, Tammie Lister and Jeff Ong

Wordpress Planet - Sat, 06/26/2021 - 17:23

On June 24th, we hosted Gutenberg Times Live Q & A on the topic “Theme.json for Theme Authors – Getting started with theme development for Full-site Editing” It was a great pleasure and privilege to have Daisy Olson, developer advocate at Automattic, Tammie Lister, design lead at Extendify and Jeff Ong, code wrangler at Automattic on the show.

Jeff Ong prepared a demo for us, and then attendees had some interesting questions our panelists answered. You can read the transcript below.

WordPress 5.8 will come with the infrastructure and foundation to control the block editor and theme settings via the configuration file theme.json. JSON is a universal data format that is readable to PHP and JavaScript alike.

Themes no longer have to pretend that they’re plugins.

Tammie Lister Resources about theme.json and themes for Full-site editing

During the show, we mentioned a few places where you can dive in and learn more about theme.json.

You can read an Introducing theme.json in WordPress 5.8 by Andre Maneiro on the Core Make blog.

You can read up on the details specifications in the Block Editor Handbook: Global Settings & Styles (theme.json).

A good way to get started and see the configuration in action is to study the themes available in the Theme Experiments repository on GitHub.

Another fantastic way to get your feet wet is to heed the Call for Testing #8 out of the FSE outreach program. Anne McCarthy has some interesting tasks for you.

Tammie Lister started a new blog and shared her thoughts on theme.json and why she is excited again for theme development. Theme.json inspires

The Gutenberg team is in ongoing discussion about various topics. Two were raised during the Live Q & A. Both could use your opinion and ideas.

Themes for Full-site Editing in the WordPress.org repository

Transcript

This transcript is still a work in progress – Birgit

Birgit Pauli-Haack: Well, and then we can start the webinar here. The webinar is now live and welcome to our 28th Gutenberg live Q and A on this June 24th. My name is Birgit Pauli-Haack and I am your host for today’s discussion. Thank you all for watching, and it’s great to have you. And while you all come in, use the chat window to tell us where you are and where you’re watching from. 

And today we will discuss a new way to configure themes, that is black themes, with global styles and settings file theme.json. And it will enable theme developers to centralize all the block-based settings, color palettes, font sizes, and other block-based customizations. This way you will also control which of the other block features the theme supports or does not support. 

So that’s my simple mind’s description of the new features and I’m so thrilled to have three experts on the show to go beyond this simple explanation and help theme developers to get started. I’m extremely honored to have Daisy Olsen, developer advocate at Automatic and WordPress contributor. Hey, good to have you. Also Jeff Ong, code wrangler at Automatic.

Jeff Ong: Hello.

Birgit Pauli-Haack: Thanks for being here. And at last but not at least Tammie Lister, design lead at Extendify.

Tammie Lister: Hello.

Birgit Pauli-Haack: We’ll do some proper introduction in less than a minute. I just have a few housekeeping notes. So after the introduction, we’ll have a first round robin question and then we see a demo. Jeff was working really hard on it and I think he was the only one repairing hard for this live Q and A. And then we’ll discuss the different angles and how they get started. And then, of course, answer your question.

Speaking of questions, how do you pose your questions? There’s a Q and A on the bottom of the screen, a kind of icon. You click on that and write your question. And for those watching on YouTube use the chat window next to the video player. And so saying hi. Hi, Victor. From Buenos Aires in Argentina. Awesome. Thank you for being here. All right. When you do comments and questions, so please be kind even if you disagree. 

This is a family endeavor. All right. Well, I’m thrilled you all agreed dear panelists to come on the show and I get an hour to talk with you about your work. So, Daisy, tell us a little bit about you, where are you’re located and what is it that you do as developer advocate on the purpose project and at Automatic?

Daisy Olsen: Yeah. I’m Daisy Olsen and I live in New Hampshire in the United States. It’s a beautiful day here right now unlike some parts of this country that are really hot. We got the cool weather over here this week. So as a developer advocate, I talk about WordPress a lot.

I get out and do workshops, teach classes, write documentation and just stay involved and close to the projects development so that I know what’s going on theoretically and can share that out particularly with plugin and theme developers as well as agencies and freelancers and things like that.

Birgit Pauli-Haack: Awesome. So glad you’re here. Thank you. So, Tammie, thank you for coming back to the show. It’s been over three years. The last time you were on the show was just after Gutenberg was merged into Core and you were one of the three leads with Matias Ventura and Joen Asmussen. 

And you shared a lot about the journey of Gutenberg and the philosophy behind it. So I will put the link to the show into the show notes for you who have been coming later to Gutenberg. But this year you joined the WordPress product company Extendify. So what do you do there?

Tammie Lister: First of all, has it been three years? That goodness. Time flies. So in Extendify I focus on design. So our solutions extend the editor. And then the aim is to make it even more usable for people’s purpose that they want to use it for. And I’m really, really excited about that.

So it means that people can have the best experience from the content they’re creating, to the layout, the patterns, the styles, whatever that the editor enables, that’s really what I’m focusing on. So it’s a interesting new challenge to do. And you have blew my brain with that time span. You really have. That’s awesome.

Birgit Pauli-Haack: Well, it’s also over three years that Gutenberg times us. So I’ve been part of that journey so for so long.

Tammie Lister: Congrats.

Birgit Pauli-Haack: Nothing really held my attention for so long. And normally I get really bored. Well, I’m also really happy that Extendify took over Editor Plus from Munir Kumal and the EditorsKit from Jeffrey Carandang. So, those have a more sustainable way now to access because both Munir and Jeffrey seem to have… Munir joined you, but Jeffrey moved on to be a consultant at , I think, 10up.

Tammie Lister: It’s so really exciting. 

Birgit Pauli-Haack: Yeah. I imagine. So thank you also to Jeff Ong for joining us today as well. You’re a code wrangler in Automatic and what have you been working on lately except for the demo. I know about that.

Jeff Ong: Well, first, thank you for having me and hosting this. Awesome to be here. I feel very honored to be with three on-time contributors. So super cool. At Automattic, I’ve been working on theme development, pretty solely focused on that for the last year. And my background is not in WordPress. 

So it’s kind of been an interesting journey to transition and learn about the ecosystem and really coming at a transitory time figuring out how do we kind of move into this new block-based paradigm? How do we make themes that work with the block editor really well and can hopefully unlock more creativity for just really great design. And I can tell you what sites again. Well, making new themes and figuring out how to do that with the latest version of Gutenberg, which turns out every day.

Birgit Pauli-Haack: So the viewers follow Jeff Ong, he’s going to teach you how to do things with the Block Editor. And we will soon see a little demo of that. It’s what Daisy said, “What you did in five minutes, I taught a course on that in three hours.” So it’s going to be a little fast paced today. 

What will change most for the theme developers when building themes for full-site editing?

But before we head into media’s raised, I would like to ask each of you, so what do you think will change most for the theme developers when building themes? These are for agency building custom themes for the clients or for theme shops rolling out new themes to sell. Do you want to start, Tammie?

Tammie Lister: Yeah. That’s interesting because I think perhaps it’s a change if you wanted to be a change. Because lots of this is an opt-in, as is the way. WordPress, the best way to opt-in. I go back to a lot of times that this is a freeing of things and I think it brings an opportunity that has pros and cons, ups and downs with opportunities.

But plug-ins themes no longer have to pretend that they’re plugins and they no longer have to be everything and have to be things that they weren’t intended to be in the first. So I think that that is a challenge in itself because there’s a certain way that you maybe thought you had to do things and now you don’t have to work around things. We often have to work around things in WordPress. 

And if you don’t have to work around it, it can feel a little bit peculiar, but once you realize you don’t have to do that, it’s actually really awesome. But you have to realize you don’t have to and that WordPress was getting in the way. I also think as a result there’s going to be a space for more creativity, and this can also be really to challenging because maybe you were limited to what you could do creativity wise because of just the confinements of the space and the confinements of what you could do before. 

And it’s going to open things again to a lot more people. And a lot more people who maybe didn’t have access to a theme developer with experience who knew the exact ins and outs of it. So I think that’s a challenge because new people in this space, new creativity. But honestly I think it’s a good thing. It’s just if you want to and you’re open to it and you can kind of explore those new ways, but I don’t think it’s a change that you have to make. I think that’s the thing.

Birgit Pauli-Haack: Awesome. Thank you. Daisy, what do you think?

Daisy Olsen: So I think I would agree with Tammie that the barrier of entry for a new theme designer. And I think that’s one of the key things is it’s bringing the design back to theming. Theming over time became very functional. We had a lot of theme companies that were trying to make their themes as flexible, powerful and feature-ful as possible to reach a wide variety of people.

And I think that we can see some opportunity for vertically oriented designs coming out where you have a theme that is geared towards a restaurant or geared towards, I don’t know, a salon or a certain kind of a business or even a personal site.

And I think that there’s a lot of opportunity to be able to have a lot of variety out there in the marketplace so that when someone asks you inevitable question, because this was probably the most common question when I was working for a thing company is which theme is best for this? 

I’m doing this kind of a site, which themes should I use. And it could make it so, well, here are five that are really geared towards what you’re trying to do instead of, oh, you can use any of them. You just have to do all this work to get it to look bright.

Birgit Pauli-Haack: Yeah. That’s a good point. Thank you. Jeff?.

Jeff Ong: Definitely, from a design perspective, it’s super exciting. I want to highlight maybe a little bit more from the development side. This seems like the biggest opportunity or clearest opportunity to ensure that your theme is integrated with the editor. That the things that you’re doing with the editor and your ability to customize it to control what presets and options are available there to the users of the theme, this is the theme [inaudible 00:12:27].

It’s a unifying kind of idea and single point of truth. Talking about theme.json and even just this whole concept of how do we bring the experience together. I think we have an opportunity to do that and that’s going to change even in some small level. Even if your theme.json cloud just as a few settings. You can take it slow like Tammie was saying. Incorporate parts of it because to me you have this new contract now that can really unify things and bring things together from a lot of disparate parts and pieces.

Birgit Pauli-Haack: Lots to think about. And I agree with all of you. I had this pleasure last year that I took over themes from agencies and they were so powerful and all the things that normally a plug-in will do, custom post types and rigid and all that. It’s all in one place and we won’t be able to change a theme at all. 

So now this is definitely going to make life a lot easier for site owners as well So lots to think about and listening to you is quite inspiring to kind of think, oh, well how many direction can my brain go now? But, Jeff, are you ready for your demo? I think it would be helpful for all the people here on the call to see what it’s all about and how it kind of gets started.

Jeff Ong: Yes. We have 10 minutes roughly. Yes. Can you see my screen? 

Birgit Pauli-Haack: We can see your screen. Yes.

Demo: Configuring the block editor with theme.json file

14.02

Jeff Ong: So we have a blank theme here and I just want to kind of go over some, not going to cover everything, but some of the key parts of that theme.json introduces and show how that impacts a blank theme and also the editor. So hopping over to my code editor. I have my theme.JSON here. This is a really basic, simple theme and nothing going on yet. 

In here I’m going to go ahead and the first thing I want to talk about are the settings of your theme.JSON. Settings are kind of what control or give you the ability to configure the editor and what kind of customization options are present to a user and the theme. The only thing I have right now is the layout, which we’ll get to in a second. But let’s say I want to add some color options here.

Previously it would be done in the functions PHP. I have kind of a few sheets over here. Sorry. I need to hide these meeting control. I’m going to copy a color palette from this. I’m going to set a palette that’s going to become available to me in my theme. I go to edit the same post. In here I see my cornso, my orange, red, and color blue that’s become available to me. 

What’s pretty interesting about this is before you would have had to kind of go into functions at this whole palette and then also define the class name, something like this to actually apply those styles. Let’s say I want this heading to be orange, update it. Show it here. I get all this cool stuff for free. This class was generated for me by Gutenberg using this preset and that I have defined meeting controls defined here in my palette options. 

Another cool thing or interesting about the possibility here is within the same configuration. Let’s say I’m the theme designer. I have the option right now to change the color to kind of anything I want. The powerful thing about theme.json at this time is it can actually turn something like this off. I actually don’t want people or my users to be able to change anything, change the color palette.

But let’s go ahead and reset this back here. Turned off custom colors within theme.json. And then back here you’ll see that option has disappeared. So inaccessible color combinations or just color combinations that you don’t want to be available. You can turn that off. This is just one of the options that are available. Color is just one of the options that you can customize.

You can also take a look at something like typography. I think I can find some font sizes here. Refresh. I can see now that those presets were available, are now available to me. I can do the same thing again here too. Say I don’t actually want people to be able to change all sides here. As a designer I know it’s best and I don’t want people putting in random font sizes. 

So disable that and now only my presets are available too. Oh, by the way, this content is just kind of some standard block-based content. Again, I’m getting all of this kind of for free or for free in a way by just applying some preset values here. Well, I think the next thing that I wanted to cover is going into the last thing. I’ll cover it within the settings because you can actually change these per block. 

Remember we were looking at color before. I could add a color key to the paragraph block and actually say, just kidding. I want to allow you to be able to change the color of paragraph blocks. Just the paragraph blocks. I can open up the whole thing. So within here now I can see, oh, I can actually change just for paragraph blocks. I go up to my heading. This custom color is not available. This color option is not available. 

If you want to I could also supply a custom palette. I’m not going to do that, but could say if you wanted a specific palette that’s just applied for paragraph blocks. That would be how you do it. So I think that’s it for settings. I’m going to go ahead and collapse this now and move on to the styles key of our theme.json. And now within here I can start to define some files. 

Remember our colors from up here from the palette. I can go ahead and because I know that WordPress is generating CSS variables based on these palettes, I can go ahead and start to use those within the styles application of the style section of my theme.json. So with the preset color, put orange red. See what else do. These are going to apply at the top level. So this is going to apply to everything.

Say I only wanted, for instance, my headings to be… Let’s make this. Do the same thing in here and say, ah, I just want, actually, let’s just make my paragraph colors black. So, again, what I’ve done here is I’ve set my global kind of text color to this orange red was preset, which was provided by WordPress and generated here to the entire text. And then actually I can go in and target specific block, set the settings for that as well. 

I think we are close. I just want to show, well, if you’re editing this, something that’s also probably going to happen and mess this up. It should throw some kind of an error here yet. Notice there when decoding theme.json. So that’ll let you know there’s something going on because it’s pretty easy tip something up here. 

And I think that’s just a small note is we’ll likely encounter that if you’re configuring keys and nested objects trying to figure out how each of those apply. You pause here for a second. I guess the last thing I want to cover too is the concept of elements. So within here, any h2 that I have is going to be applied a specific style here. So I have the same because [inaudible 00:24:24] can appear outside of blocks or links, for example.

These are restricted to a specific set at the moment. So let’s just say text. So, again, because this is not actually rendered as a pocket and an element and that can appear anywhere. That’s something that I can target with this kind of top level elements select here. Everything else here you can target with the name of the block. 

That is most of what I wanted to cover pretty fast, but again all of the settings that you can find here or that I’m going over, there’s way more than just color. There’s spacing, typography and all of that can be found in documentation that Birgit, I think she shared it here. So that I want to open it up. And I guess there are questions. If there are specific parts that anyone would want to go into in a little more detail. Happy to do that.

Daisy Olsen: Thank you, Jeff. 

Birgit Pauli-Haack: Thank you, Jeff. This was awesome. Do you want to just say something?

Daisy Olsen: Yeah. I just wanted to say that maybe we could just talk about layout real quick because I think that’s going to be a big one for 5.8.

Jeff Ong: Yeah. And I kind of skipped over. It was the first thing that was in here. Yes. Layout key is a way for you to quickly define the default, the width of your content within WordPress or within here. So if you see here, if I don’t define this layout, a lot of my content is just going to be full width by default. 

You can supply two values here. Content size, it’s just going to be the default width. You can also define, I think it’s, what is it? Wide size. Wide width. Nothing happened there because I hadn’t provided it. Maybe there’s a better way to show that with cover block. 

Birgit Pauli-Haack: Nice. I like it. 

Jeff Ong: Pretty cool. You can, I mean, alignment coming together and within a unified system reliably layout content with starting here is pretty powerful stuff I’d say.

Birgit Pauli-Haack: Yeah. Awesome. So I shared in the chat window, if you haven’t seen it, the documentation link where you can read up about the theme.json as a whole. When you say, Daisy, that that’s the layout will be important for 5.8, which part of it would be, where does it come into play?

Daisy Olsen: So with 5.8 with the custom template functionality that’s coming where you can basically create a custom template for an entire page or a post that would cover your header as well as your content. If you need to have these setting set for the width, especially the content size for it but preferably also wide so that your site knows how wide it should be. 

Otherwise you get kind of the facts that Jeff showed where it was the full width of the page. It didn’t have anything to contain it down to the width that you want. So for any theme that wants to use the template editor would benefit from having a theme.json file that even if it only has the one thing in it, it would be good way to take advantage of it.

Birgit Pauli-Haack: Yeah. It’s an excellent tip. Thank you, Daisy. You heard it here first. So we already got some questions in our Q and A, but I just wanted to have one question for Jeff before. That’s my prerogative as a host, I get the first question. So if I understood it correctly, so until now, theme.json comes into play I had to create many different places or touch many different places to make a color palette work.

So, I had to put it in my functions.php and then I also have to put it in my style sheet. Is [inaudible 00:30:04] that I don’t have to do this anymore, or do I still have to put it into my style sheet, or is it automatically created with when I put the color palette in the theme.json?

Jeff Ong: It is wonderful question. It is automatically created. This is all that that style sheet looks like since this is one of the big very exciting aspects of a theme.json. It’s that it’s managing this for you. And then also I think more down the line by providing colors and styles in this way. And then also by applying the styles here you can guarantee that those blocks are going to integrate properly.

It’s like the styles for those blocks are going to be more closely tied and actually in how the block is implemented. So no more writing styles that are overwriting that we’re having to target specific nested blocks. And so there’s tons of complications to this and there’s a lot more room to mature and develop, but I think that’s one of the parts I’m most excited about. To your point, there’s one place now where I can define my palette and show how it should be applied. I don’t have to go into two different places to do it.

Birgit Pauli-Haack: All right. Well, let’s go to the questions. Victor Kane, from the beginning of the show has already put them in and he’s particular interested in finding out about the workflow using them theme.json. So one is the best editing alternative for VS Code formatting, and then the second one was the possibility for exporting interactive selections to clipboard and code. I’m not quite sure I understand the question. Maybe you understand it, Jeff Daisy, Tammie.

Tammie Lister: Personally. So I think this is a personal choice. I’m going to start with an answer and then go to… I use VS Code, so I may not be able to give the right answer there. I would be curious to know what you don’t want in VS Code, and I think that that’s the thing. This opens up personal… I’m going to be really bad at reading the response in chat whilst talking. So I’m going to be a little bit pertinent and kind of speak first. I’m sorry, I’ll get back to it.

It’s your personal choice how you write and then you can kind of go back to it. So the thing that I did, this was my workflow, it has been my workflow so far, and I think this is the thing, we’re all finding our own new workflows with these new toys that we’re playing with. So what I’ve been doing is I’ve been using theme.json. 

I’ve actually been setting up variables using SAS that have been then pulling in root variables into my theme.json so that I can pull them through. That’s a weird way to do it. That’s strange, but the reason being, it means I can reuse and keep things separately. But I’m sure that everybody on this call has their own little workflows that they are kind of working from.

Daisy Olsen: My approach to that was actually the opposite that I was using my theme.json to set all of my variables so that I didn’t need SAS, which I think for those that never quite got their head wrapped around preprocessed CSS, it might be a way to simplify things for those that prefer it that way.

Birgit Pauli-Haack: Awesome. 

Tammie Lister: I think it’s what you’re cozy with, right? And I think that’s the thing. This can adapt to what was your cozy blanket of coding, and you don’t have to lose that yet, I think.

Birgit Pauli-Haack: All right. So Victor commented on that. If I get the results, I want interactively with the global settings panel on the right-hand side of the editor, can I export that to a theme.json format?

Daisy Olsen: The answer is not right now. I think there’s discussion in the teams about maybe building it, but it hasn’t been the highest priority because everything needs to work first before we start working on an exporter. But there are other parts of that can be exported in that full site editing experience that can be exported. So I think it would be a natural progression to add the ability to do a theme.json export.

Birgit Pauli-Haack: Yes. Definitely there will be.

Tammie Lister: From the very beginning, there were designs in global style. Sorry. The reason I know is that was one thing I did partake on. There was exporting. So I have a feeling if we all wanted to play some little happy bets, there will be exploiting at some point.

Birgit Pauli-Haack: Yeah. But if we all bet on the same thing, it’s not really bet, right? Victor, as always, you’re a little bit ahead of the time. So and from Jan Horna, from the Czech Republic, it’s very hot by now there. 

He has two questions as a theme developer, one, is the theme.json supposed to include all the styling, formatting definitions and replaced the CSS style? And I think we’d take it one at a time. So we talked a little bit about it from my question, but would it replace? You could still do all those styling in the style sheets as you want, right?

Daisy Olsen: And I think there are some things that will remain in other styling, but you could use the variables that you set or the properties that you set in your theme.json in your CSS. So they can work together. But I don’t think that theme.json, at least right now, will not completely replace an entire site’s design, especially if you have a very complex design.

Why do we want to rewrite CSS in JSON

Jeff Ong: Yeah. And this was one of my first questions and honestly, skepticism early on of the proposal around this, is CSS is great. Why do we want to rewrite CSS in JSON. And then it slowly, I mean, other people are obviously smarter than me understood this quickly. It’s not about rewriting all of CSS. There’s definitely going to be aspects of your site, especially if you have taking, like you’re saying, more complicated designs that will remain in CSS. 

But this is about creating, I think, more of the foundational elements and understanding how the blocks will interact with your styles and having that single point of contact, I think is most important. So I think for me, at least it’s more about the foundational elements that are going to be placed and managed this way than replacing your entirety of your styles. Because this great. 

Things like animations and transformation, and this is all really powerful stuff that I don’t imagine, really, at least in the super near future, having a big part of theme.json. To the question about, will you be able to save an export a theme.json from global styles? I think this is a really important thing to keep in mind is what I just showed you is kind of unnatural. I don’t imagine a future necessarily where theme developers are writing raw JSON.

It’s really, there’s not a great experience for it. It’s a configuration file. And so the more, to points that have already been raised, it’s about we’re in this phase now because we need to kind of identify and get it to work, and then we can kind of build an ecosystem around what would a really cool UI look like to generate one of these files? Is it native directly to global styles? How do we start to imagine those interfaces so the theme developers or theme designers can really get to the core of this experience too?

Birgit Pauli-Haack: All right. Well, thank you. Good point. You wanted to say something.

Tammie Lister: Yeah. I was just going to say over time, CSS has gained so much. So I didn’t know about anyone else, but I had a block.css file that was getting bigger and bigger of supporting blocks and doing things. And something I’ve noticed that I can do is throw that file away, and I couldn’t be happier because what I can do now is lean into these defaults. I’m still going to have some lines of CSS, the output by whatever, a preprocessor, whatever, my happy little whatever. 

Because everyone has got their own way and we should have our own way of doing it. But it’s a foundation, and it means that we’re not having to work around the editor or find different ways of doing it. I set up naturally a hack file for the editor out of habit. I haven’t filled it with anything yet in the latest theme I’ve been working on. 

I’m delighted if I never fill that up with anything on the next theme, because it means that the new way we’re doing things hasn’t had me to work around that. I can just use the foundation and create a really awesome experience on top of it. And that’s what we should be doing. We should be working with the editor, not having to work around it, or using not important like it was going out of fashion to go over control of it. It was this awkward middle ground we were working in trying to make things fit that paradigm. 

Birgit Pauli-Haack: And I think that fits right into the next question from Jan Horna again, and he says so as a block theme developer, should I focus from a strategic point of view on theme.json block styles, or block patterns. In other words, how do I differentiate? It’s kind of a high-level question there.

Daisy Olsen: I would say all of the above. They’re all important things. And your block styles are part of theme.json, I would say. But block patterns are really a powerful partner to the theme.json, that you can create building blocks for a site where you’ve got some really amazing very specific designed elements that could be used for different things on a site. So if you’re creating a commercial application that’s going to go out to a wide audience, they can be more generic. 

But if you have a client and you’re working as a freelancer or in an agency where you have a site that needs to have access to these things that they’re going to use more than once, patterns are a fantastic way to do that, where most of the work is done for them. They don’t have to reconfigure everything from the ground up every time they want to create something similar to what they’ve done before.

What happens when you update the color palette? Will saved blocks have the new colors?

Birgit Pauli-Haack: Thank you. And Spencer McCormick in the chat had a question. So what happens when you update the color palette or similar, for example, if you have a primary and secondary colors, when you update and change the palette colors, will saved blocks have the new colors? That’s an interesting question. Thank you, Spenser.

Daisy Olsen: I can answer that to some extent. If you think of your palette as named colors, if you give the different hex code to the same name, it should apply to the site. But if you give it a new name, then that’s a new element, and it won’t apply to anything that already had an old name attached to it.

Jeff Ong: There is a hefty discussion related to this question on the naming of colors in the way that Gutenberg wants to supply a default palette or a default set of named colors so that you could reliably… What we’re seeing I think is that I think patterns have been wanting to rely on specific colors across kind of, so you can guarantee oh, when corn flour shows up it’s always going to be corn flour. 

It’s always going to be available. There’s a lot of complication and nuance around it. But if, I think today, to answer your question, like Daisy is saying, today, if I were to supply a value or a named value here and then change it or take it out of my palette, then that would break the experience or it would no longer be applied to that.

And that’s part of the challenge, how do we reliably solve for that? How do we give theme office the tools to figure that out. But now if they set a custom color, if you set a custom color on an element or a block, then that will remain because it’s a specific X value, but the class names will go away though, if they’re supplied by the theme.

Birgit Pauli-Haack: So great discussions. And I’m probably going to share, and if it’s one issue where that discuss the theme team every week kind of shares all the things that are discussed and that need input from the community or other theme developers on their make blog. 

So that is definitely a place to go to chime in and we’ll find all the discussions that are happening. And then chime in in the ones that you find important and that you are worried about. So Tim Bowen has the question, how does the theme.json handle responsive sizes for font sizes especially. Responsive sizes.

Daisy Olsen: By default, I’m not sure.

Birgit Pauli-Haack: You’ve stomped the panelists. Yes, we did it.

Tammie Lister: I mean, you can use not just pixel values for your fonts, so-

Daisy Olsen: That’s what I was going to say. 

Tammie Lister: … that helps. And I think it’s a work in progress. So things like responsive and breakpoints. But the now answer is you don’t have to just use pixels. And Jeff just gave a great leak.

Jeff Ong: I just dropped the issue in that has not seen a lot of activity around it, but the idea of media. So the first part of your question on font sizes, there are ways of calculating this where they’re not pixel values tied to specific viewports. You could supply a calculated value, for example, in your small… that is based on a viewport size. 

So it’s kind of a paradigm shift or design paradigm shift of getting away from you must be 12 pixels under below 600 pixel viewport width, to more of are we okay with kind of a fluid typography kind of system? That being said, there are instances where you need media queries, and that is not currently… I don’t know how actively that’s being worked on right now. But a wonderful thing open to contributors.

Birgit Pauli-Haack: So Patty has a comment and a question after that, Patty O’Hara, I most often develop custom themes for clients and hand them off for the clients to update the content. And playing around with new tools, I’m excited to start using them, but don’t want to give access to global standards to anyone with admin access. Will the granularity of permissions changes so that I can block access to changing fonts and colors from within the admin?

Tammie Lister: I think this amazing thing happens in where also Jeff showed some of the control you can do. So in the demo, there was some control that you can do. But my process is a history of configurability and being able to do that be it in code, or be it in a plugin. But I honestly think we need to be a little bit cautious. This is my personal opinion here, and we need to maybe embrace allowing people to do styling. 

You can set boundaries, you can set branding boundaries, you can set pallets, you can set topography. But we need to move away a little bit from having such pixel fixated control in that sense and think about safely within boundaries, expression of these tools. And that people can create really amazing things, and you can maintain branding that way, and it can empower someone. 

These themes are becoming style guides, and that’s something that is known in the corporate world and used within that space as well. It’s a term, but it’s kind of democratizing design in that sense in giving people all these tools to play with, and I think it’s a huge change in the way that we’ve done things, but I think it’s really, really important and really, really empowering to the people that are using our themes.

Birgit Pauli-Haack: That’s a good advocacy for set it free. Thank you.

Tammie Lister: But you’re allowed to have boundaries. I think you can set it free, but be comfortable about some boundaries. I think sometimes when we say set it free, it can be scary because we don’t say you’re allowed to have some boundaries, but with pallets and with these style guides, that’s what you’re saying. You’re saying I’m making these good decisions for you and you can choose from this platform of good decisions. And that’s kind of awesome. I think,

Birgit Pauli-Haack: Yeah. I like the plea for block patterns that Daisy just a couple of minutes had that block patterns also give you the possibility or the option to actually provide different facets of how a section can be organized or styled within the style design system that you build with the block add on. 

And so I think that there is a lot of creativity that will come from that as well. So Tim Bowen is brave and contemplating, is it safe to use the theme.json now for a project launching in August? Would we just activate the Gutenberg plugin and add JSON file? Or is there more to it? I would love to move away from our functions in Editor.js method probably as soon as possible. So what would we say to Tim?

Daisy Olsen: The theme is not a block theme, as in it doesn’t use HTML templates, then I probably wouldn’t put the Gutenberg plugin on a production website, unless you are ready to deal with unexpected things happening. But placing your theme.json file in your classic theme on the 5.8 beta or release candidate that will be coming, I would start testing there and see if the things that you’re putting in your theme.json file work with 5.8 on a classic theme. That’d be my suggestion.

Tammie Lister: I think if it’s launching in August, that means 5.8 should be out. She tries to check her mental calendar. So I think tests. I, personally, am okay. I would consider it if it was going into a site, but I would also want to know how many users were using it, what their levels was, what they were doing, what they were going to create, and how they were going to do it. So it’s a… this is not legal advice. I feel that there should be [inaudible 00:50:36] advice that I can be. 

Birgit Pauli-Haack: Don’t try this at home. 

Tammie Lister: But by then, 5.8 should be out.

Birgit Pauli-Haack: Yeah. 5.8 comes out July 20th, that’s at least the schedule for that. So we ran out of questions right now one the Q and A sessions here. Well, you’re welcome, Tim. Good luck with that, and let us know. Is there more to the setting it up besides just activating the plugin or adding the JSON file. Well, back to kind of using it and editing. 

When there are already themes available in the theme repository that use the full set up for full site editing and use all the template parts and templates with the blocks, and header blocks, and photo blocks, and all that. But I’m not quite sure of that yet. Be careful about the using the Gutenberg plugin in production. It always has a few hiccups there.

So it wasn’t the first time ever that I retreated to the last version when I had one and had to wait till one, two, or three point releases to come out. So I’m hesitant to say do it in production. Test it as much as possible. So I have a lot of things on my screen, but not the right thing. Here, so it is. Oh, Ryan, we are pretty good time wise. 

So, I don’t have an additional… So, when we say how to get started, what was the first thing most difficult part for you for learning, or was there a mind shift until it clicked? Just to kind of get away from a fear of learning something new, and was there something when you go back ages on the theme.json thing.

Tammie Lister: So for me, it was realizing it wasn’t as hard as I maybe mentally thought it was. It was just the same with learning anything. You always think it’s going to be super hard, or at least with me, I read like dev doc and I’m like… My brain makes that noise. And then I just letting my theme be lighter. Letting it take the weight of that, giving up control, which as someone that’s maybe a bit of an old themer, giving up control of things, that’s an interesting process to go through. 

But it’s really important embracing those foundations. And when you do, there’s that mind shift of creating in the editor. That was the moment that… And I’m still going through the process. I think it’s a process, and it’s a process as these tools are evolving. We’re talking about be gentle, they’re in production. These tools are still evolving and working. 

If you are using these tools now before it’s released, then you’re going to hit bugs and report them. But that’s the thing. This theme.json also… the moment I kind of, the Jenga box, the blocks fell in my brain was I stopped seeing it as global stars. And I knew it wasn’t just global stars, but I felt it wasn’t just global stars and this felt like it could be the backbone of my theme, and it felt like it wasn’t everything in my theme, but it felt like it could be the backbone, is the best way I can describe it. 

And I could hang my theme from it. And we’ve hung our theme from functions.php wrongly, I think. So it was just that change from PHP to doing it all in the editor and creating and seeing that JSON. It just was free, and it’s more in line with how things are made outside WordPress, which I think is delightful.

Birgit Pauli-Haack: Any comments from you that you want to add, Daisy?

Daisy Olsen: So when I first started working with a theme.json file, I found that I had to… So there’s a whole section called styles, and I had to realign my thinking about what that meant, because what it’s saying is there are style settings in your blocks or for your site level depending on how it’s being applied, and what you’re doing is configuring the defaults for it. 

So if I think of the theme.json file as a default file, then it helped me frame it so that I’m not necessarily replacing my CSS depending on… I mean, I’m letting theme.json do the heavy lifting, kind of like Tammie said, but then I can take it further if I feel like I need to, or I want to. So I like thinking of it as a configuration file or a defaults file.

Birgit Pauli-Haack: That’s a good point. Jeff, do you have any stories how I came about?

Jeff Ong: It’s been really helpful to pair on it with people, to work on a theme with someone. I think if my team at Automattic. It’s a very culture of collaboration, and if you have the opportunity to say, “I’m having trouble with this. Would you want to work on this?” With someone like that, because this definitely can be a head bashing kind of why is this not being applied? 

I literally just wrote color green. Why is it not green? It can be so frustrating dealing with that. So to have someone just to look at your code and be like “Oh, you missed a comma or actually you need an extra key there” is really, really helpful for something like this.

Birgit Pauli-Haack: Oh yeah. So well, I think we’re coming to the end of our show. This has been very interesting and inspiring. So thank you all so much. And for those who want to dive into at a guided kind of testing session, Anne McCarthy, who, as you might know, runs the Full Site Editing Outreach program, she’s about to post the eighth call for testing, and it will all be about the theme.json file.

So as soon as it’s out, I will share a link in the show notes. And of course, also if you subscribed to our Gutenberg Times newsletter, you will definitely be informed about that. So at this point, I only have two more questions for our panelists. So do you have any announcements that you couldn’t get out before and you want the people to keep in mind? And if people want to get in touch with you, what would be the best way. Tammie, you want to start?

Tammie Lister: Yeah. So I’m comatose in all the things. I’m pretty easy to find in a good way. And I love chatting to people. So please do. I think my thing to say would be remember all of what happening now you can help shape. Just because we’ve sat here talking about it doesn’t mean we know anything more than you? It just means we’ve poked it and we’ve played around with the code. 

So do that. Start exploring it. And it’s a lot more accessible than it ever was. It’s starting to be more accessible. There’s more documentation than there ever was coming out. And if you care about what happens with themes or you ever cared about what happens to themes, and maybe you could have that reignited, start to join the conversation. And I guess my final point would be, I think my hope is to see this experimentation come back to themes. 

I think we forgot about that a little bit and we need to have some fun again in these. We used to have so much fun in WordPress themes, and I look forward to not just themes to have a purpose, but just themes that are art, themes that are just wacky experiments, and start enjoying theming and make some art. I’m really excited to see what things people create and use them just for one day even. That’d be amazing.

Birgit Pauli-Haack: Yeah. So Jeff, anything you want to have people keep in mind, and how to get in contact with you.

Jeff Ong: Yeah. Contact at J-F-F-N-G. And I guess keeping in mind, I’m just building on the last thing Tammie said, perhaps find a way to have fun with it and get curious about it, and try it. There’s really to me, a fundamental tendance of learning about something or you just have, how do I get curious about this thing? How do I play with it and have fun? And that’s going to be the most important thing to keep in at the center.

Birgit Pauli-Haack: Thank you, Jeff, and thank you so much for the audio work on the demo. Daisy.

Daisy Olsen: I’m Daisy Olsen on most things, Olsen with an E, and I would say that as far as what you can do as the next step if you’re interested in learning more about this, is go to… I’m pretty sure that Birgit has a link to this somewhere, the theme experiments repository on GitHub in the WordPress space has things that other people have done or are working on. 

So I love to see examples of something in action to help me learn more about it and to see what other people have done. So I would say go check out something.json files in there and see what people have come up with.

Birgit Pauli-Haack: Awesome. Thank you so much. So big thank you to Daisy, Jeff, and Tammie to come today and make your time. A big thank you also for the viewers with all your great questions. I think we got a great array of it. And if you have more questions, you can always send them to me via email to pauli@gutenbergtimes.com, and I’ll get you the answers.

And the recording of the show will be available in a few minutes on our YouTube channel. And I’ll share all the links then also in the video description. And within a few days, we will have also a transcript that we will publish on the Gutenbergtimes.com. So be well, good-bye, and good luck. That was fun. Thank you.

Jeff Ong: Thank you, everyone.

Gutenberg Times: Theme.json for WordPress Theme Authors – demo and Live Q & A w/ Daisy Olson, Tammie Lister and Jeff Ong

Wordpress Planet - Sat, 06/26/2021 - 17:23

On June 24th, we hosted Gutenberg Times Live Q & A on the topic “Theme.json for Theme Authors – Getting started with theme development for Full-site Editing” It was a great pleasure and privilege to have Daisy Olson, developer advocate at Automattic, Tammie Lister, design lead at Extendify and Jeff Ong, code wrangler at Automattic on the show.

Jeff Ong prepared a demo for us, and then attendees had some interesting questions our panelists answered. You can read the transcript below.

WordPress 5.8 will come with the infrastructure and foundation to control the block editor and theme settings via the configuration file theme.json. JSON is a universal data format that is readable to PHP and JavaScript alike.

Themes no longer have to pretend that they’re plugins.

Tammie Lister Resources about theme.json and themes for Full-site editing

During the show, we mentioned a few places where you can dive in and learn more about theme.json.

You can read an Introducing theme.json in WordPress 5.8 by Andre Maneiro on the Core Make blog.

You can read up on the details specifications in the Block Editor Handbook: Global Settings & Styles (theme.json).

A good way to get started and see the configuration in action is to study the themes available in the Theme Experiments repository on GitHub.

Another fantastic way to get your feet wet is to heed the Call for Testing #8 out of the FSE outreach program. Anne McCarthy has some interesting tasks for you.

Tammie Lister started a new blog and shared her thoughts on theme.json and why she is excited again for theme development. Theme.json inspires

The Gutenberg team is in ongoing discussion about various topics. Two were raised during the Live Q & A. Both could use your opinion and ideas.

Themes for Full-site Editing in the WordPress.org repository

Transcript

This transcript is still a work in progress – Birgit

Birgit Pauli-Haack: Well, and then we can start the webinar here. The webinar is now live and welcome to our 28th Gutenberg live Q and A on this June 24th. My name is Birgit Pauli-Haack and I am your host for today’s discussion. Thank you all for watching, and it’s great to have you. And while you all come in, use the chat window to tell us where you are and where you’re watching from. 

And today we will discuss a new way to configure themes, that is black themes, with global styles and settings file theme.json. And it will enable theme developers to centralize all the block-based settings, color palettes, font sizes, and other block-based customizations. This way you will also control which of the other block features the theme supports or does not support. 

So that’s my simple mind’s description of the new features and I’m so thrilled to have three experts on the show to go beyond this simple explanation and help theme developers to get started. I’m extremely honored to have Daisy Olsen, developer advocate at Automatic and WordPress contributor. Hey, good to have you. Also Jeff Ong, code wrangler at Automatic.

Jeff Ong: Hello.

Birgit Pauli-Haack: Thanks for being here. And at last but not at least Tammie Lister, design lead at Extendify.

Tammie Lister: Hello.

Birgit Pauli-Haack: We’ll do some proper introduction in less than a minute. I just have a few housekeeping notes. So after the introduction, we’ll have a first round robin question and then we see a demo. Jeff was working really hard on it and I think he was the only one repairing hard for this live Q and A. And then we’ll discuss the different angles and how they get started. And then, of course, answer your question.

Speaking of questions, how do you pose your questions? There’s a Q and A on the bottom of the screen, a kind of icon. You click on that and write your question. And for those watching on YouTube use the chat window next to the video player. And so saying hi. Hi, Victor. From Buenos Aires in Argentina. Awesome. Thank you for being here. All right. When you do comments and questions, so please be kind even if you disagree. 

This is a family endeavor. All right. Well, I’m thrilled you all agreed dear panelists to come on the show and I get an hour to talk with you about your work. So, Daisy, tell us a little bit about you, where are you’re located and what is it that you do as developer advocate on the purpose project and at Automatic?

Daisy Olsen: Yeah. I’m Daisy Olsen and I live in New Hampshire in the United States. It’s a beautiful day here right now unlike some parts of this country that are really hot. We got the cool weather over here this week. So as a developer advocate, I talk about WordPress a lot.

I get out and do workshops, teach classes, write documentation and just stay involved and close to the projects development so that I know what’s going on theoretically and can share that out particularly with plugin and theme developers as well as agencies and freelancers and things like that.

Birgit Pauli-Haack: Awesome. So glad you’re here. Thank you. So, Tammie, thank you for coming back to the show. It’s been over three years. The last time you were on the show was just after Gutenberg was merged into Core and you were one of the three leads with Matias Ventura and Joen Asmussen. 

And you shared a lot about the journey of Gutenberg and the philosophy behind it. So I will put the link to the show into the show notes for you who have been coming later to Gutenberg. But this year you joined the WordPress product company Extendify. So what do you do there?

Tammie Lister: First of all, has it been three years? That goodness. Time flies. So in Extendify I focus on design. So our solutions extend the editor. And then the aim is to make it even more usable for people’s purpose that they want to use it for. And I’m really, really excited about that.

So it means that people can have the best experience from the content they’re creating, to the layout, the patterns, the styles, whatever that the editor enables, that’s really what I’m focusing on. So it’s a interesting new challenge to do. And you have blew my brain with that time span. You really have. That’s awesome.

Birgit Pauli-Haack: Well, it’s also over three years that Gutenberg times us. So I’ve been part of that journey so for so long.

Tammie Lister: Congrats.

Birgit Pauli-Haack: Nothing really held my attention for so long. And normally I get really bored. Well, I’m also really happy that Extendify took over Editor Plus from Munir Kumal and the EditorsKit from Jeffrey Carandang. So, those have a more sustainable way now to access because both Munir and Jeffrey seem to have… Munir joined you, but Jeffrey moved on to be a consultant at , I think, 10up.

Tammie Lister: It’s so really exciting. 

Birgit Pauli-Haack: Yeah. I imagine. So thank you also to Jeff Ong for joining us today as well. You’re a code wrangler in Automatic and what have you been working on lately except for the demo. I know about that.

Jeff Ong: Well, first, thank you for having me and hosting this. Awesome to be here. I feel very honored to be with three on-time contributors. So super cool. At Automattic, I’ve been working on theme development, pretty solely focused on that for the last year. And my background is not in WordPress. 

So it’s kind of been an interesting journey to transition and learn about the ecosystem and really coming at a transitory time figuring out how do we kind of move into this new block-based paradigm? How do we make themes that work with the block editor really well and can hopefully unlock more creativity for just really great design. And I can tell you what sites again. Well, making new themes and figuring out how to do that with the latest version of Gutenberg, which turns out every day.

Birgit Pauli-Haack: So the viewers follow Jeff Ong, he’s going to teach you how to do things with the Block Editor. And we will soon see a little demo of that. It’s what Daisy said, “What you did in five minutes, I taught a course on that in three hours.” So it’s going to be a little fast paced today. 

What will change most for the theme developers when building themes for full-site editing?

But before we head into media’s raised, I would like to ask each of you, so what do you think will change most for the theme developers when building themes? These are for agency building custom themes for the clients or for theme shops rolling out new themes to sell. Do you want to start, Tammie?

Tammie Lister: Yeah. That’s interesting because I think perhaps it’s a change if you wanted to be a change. Because lots of this is an opt-in, as is the way. WordPress, the best way to opt-in. I go back to a lot of times that this is a freeing of things and I think it brings an opportunity that has pros and cons, ups and downs with opportunities.

But plug-ins themes no longer have to pretend that they’re plugins and they no longer have to be everything and have to be things that they weren’t intended to be in the first. So I think that that is a challenge in itself because there’s a certain way that you maybe thought you had to do things and now you don’t have to work around things. We often have to work around things in WordPress. 

And if you don’t have to work around it, it can feel a little bit peculiar, but once you realize you don’t have to do that, it’s actually really awesome. But you have to realize you don’t have to and that WordPress was getting in the way. I also think as a result there’s going to be a space for more creativity, and this can also be really to challenging because maybe you were limited to what you could do creativity wise because of just the confinements of the space and the confinements of what you could do before. 

And it’s going to open things again to a lot more people. And a lot more people who maybe didn’t have access to a theme developer with experience who knew the exact ins and outs of it. So I think that’s a challenge because new people in this space, new creativity. But honestly I think it’s a good thing. It’s just if you want to and you’re open to it and you can kind of explore those new ways, but I don’t think it’s a change that you have to make. I think that’s the thing.

Birgit Pauli-Haack: Awesome. Thank you. Daisy, what do you think?

Daisy Olsen: So I think I would agree with Tammie that the barrier of entry for a new theme designer. And I think that’s one of the key things is it’s bringing the design back to theming. Theming over time became very functional. We had a lot of theme companies that were trying to make their themes as flexible, powerful and feature-ful as possible to reach a wide variety of people.

And I think that we can see some opportunity for vertically oriented designs coming out where you have a theme that is geared towards a restaurant or geared towards, I don’t know, a salon or a certain kind of a business or even a personal site.

And I think that there’s a lot of opportunity to be able to have a lot of variety out there in the marketplace so that when someone asks you inevitable question, because this was probably the most common question when I was working for a thing company is which theme is best for this? 

I’m doing this kind of a site, which themes should I use. And it could make it so, well, here are five that are really geared towards what you’re trying to do instead of, oh, you can use any of them. You just have to do all this work to get it to look bright.

Birgit Pauli-Haack: Yeah. That’s a good point. Thank you. Jeff?.

Jeff Ong: Definitely, from a design perspective, it’s super exciting. I want to highlight maybe a little bit more from the development side. This seems like the biggest opportunity or clearest opportunity to ensure that your theme is integrated with the editor. That the things that you’re doing with the editor and your ability to customize it to control what presets and options are available there to the users of the theme, this is the theme [inaudible 00:12:27].

It’s a unifying kind of idea and single point of truth. Talking about theme.json and even just this whole concept of how do we bring the experience together. I think we have an opportunity to do that and that’s going to change even in some small level. Even if your theme.json cloud just as a few settings. You can take it slow like Tammie was saying. Incorporate parts of it because to me you have this new contract now that can really unify things and bring things together from a lot of disparate parts and pieces.

Birgit Pauli-Haack: Lots to think about. And I agree with all of you. I had this pleasure last year that I took over themes from agencies and they were so powerful and all the things that normally a plug-in will do, custom post types and rigid and all that. It’s all in one place and we won’t be able to change a theme at all. 

So now this is definitely going to make life a lot easier for site owners as well So lots to think about and listening to you is quite inspiring to kind of think, oh, well how many direction can my brain go now? But, Jeff, are you ready for your demo? I think it would be helpful for all the people here on the call to see what it’s all about and how it kind of gets started.

Jeff Ong: Yes. We have 10 minutes roughly. Yes. Can you see my screen? 

Birgit Pauli-Haack: We can see your screen. Yes.

Demo: Configuring the block editor with theme.json file

14.02

Jeff Ong: So we have a blank theme here and I just want to kind of go over some, not going to cover everything, but some of the key parts of that theme.json introduces and show how that impacts a blank theme and also the editor. So hopping over to my code editor. I have my theme.JSON here. This is a really basic, simple theme and nothing going on yet. 

In here I’m going to go ahead and the first thing I want to talk about are the settings of your theme.JSON. Settings are kind of what control or give you the ability to configure the editor and what kind of customization options are present to a user and the theme. The only thing I have right now is the layout, which we’ll get to in a second. But let’s say I want to add some color options here.

Previously it would be done in the functions PHP. I have kind of a few sheets over here. Sorry. I need to hide these meeting control. I’m going to copy a color palette from this. I’m going to set a palette that’s going to become available to me in my theme. I go to edit the same post. In here I see my cornso, my orange, red, and color blue that’s become available to me. 

What’s pretty interesting about this is before you would have had to kind of go into functions at this whole palette and then also define the class name, something like this to actually apply those styles. Let’s say I want this heading to be orange, update it. Show it here. I get all this cool stuff for free. This class was generated for me by Gutenberg using this preset and that I have defined meeting controls defined here in my palette options. 

Another cool thing or interesting about the possibility here is within the same configuration. Let’s say I’m the theme designer. I have the option right now to change the color to kind of anything I want. The powerful thing about theme.json at this time is it can actually turn something like this off. I actually don’t want people or my users to be able to change anything, change the color palette.

But let’s go ahead and reset this back here. Turned off custom colors within theme.json. And then back here you’ll see that option has disappeared. So inaccessible color combinations or just color combinations that you don’t want to be available. You can turn that off. This is just one of the options that are available. Color is just one of the options that you can customize.

You can also take a look at something like typography. I think I can find some font sizes here. Refresh. I can see now that those presets were available, are now available to me. I can do the same thing again here too. Say I don’t actually want people to be able to change all sides here. As a designer I know it’s best and I don’t want people putting in random font sizes. 

So disable that and now only my presets are available too. Oh, by the way, this content is just kind of some standard block-based content. Again, I’m getting all of this kind of for free or for free in a way by just applying some preset values here. Well, I think the next thing that I wanted to cover is going into the last thing. I’ll cover it within the settings because you can actually change these per block. 

Remember we were looking at color before. I could add a color key to the paragraph block and actually say, just kidding. I want to allow you to be able to change the color of paragraph blocks. Just the paragraph blocks. I can open up the whole thing. So within here now I can see, oh, I can actually change just for paragraph blocks. I go up to my heading. This custom color is not available. This color option is not available. 

If you want to I could also supply a custom palette. I’m not going to do that, but could say if you wanted a specific palette that’s just applied for paragraph blocks. That would be how you do it. So I think that’s it for settings. I’m going to go ahead and collapse this now and move on to the styles key of our theme.json. And now within here I can start to define some files. 

Remember our colors from up here from the palette. I can go ahead and because I know that WordPress is generating CSS variables based on these palettes, I can go ahead and start to use those within the styles application of the style section of my theme.json. So with the preset color, put orange red. See what else do. These are going to apply at the top level. So this is going to apply to everything.

Say I only wanted, for instance, my headings to be… Let’s make this. Do the same thing in here and say, ah, I just want, actually, let’s just make my paragraph colors black. So, again, what I’ve done here is I’ve set my global kind of text color to this orange red was preset, which was provided by WordPress and generated here to the entire text. And then actually I can go in and target specific block, set the settings for that as well. 

I think we are close. I just want to show, well, if you’re editing this, something that’s also probably going to happen and mess this up. It should throw some kind of an error here yet. Notice there when decoding theme.json. So that’ll let you know there’s something going on because it’s pretty easy tip something up here. 

And I think that’s just a small note is we’ll likely encounter that if you’re configuring keys and nested objects trying to figure out how each of those apply. You pause here for a second. I guess the last thing I want to cover too is the concept of elements. So within here, any h2 that I have is going to be applied a specific style here. So I have the same because [inaudible 00:24:24] can appear outside of blocks or links, for example.

These are restricted to a specific set at the moment. So let’s just say text. So, again, because this is not actually rendered as a pocket and an element and that can appear anywhere. That’s something that I can target with this kind of top level elements select here. Everything else here you can target with the name of the block. 

That is most of what I wanted to cover pretty fast, but again all of the settings that you can find here or that I’m going over, there’s way more than just color. There’s spacing, typography and all of that can be found in documentation that Birgit, I think she shared it here. So that I want to open it up. And I guess there are questions. If there are specific parts that anyone would want to go into in a little more detail. Happy to do that.

Daisy Olsen: Thank you, Jeff. 

Birgit Pauli-Haack: Thank you, Jeff. This was awesome. Do you want to just say something?

Daisy Olsen: Yeah. I just wanted to say that maybe we could just talk about layout real quick because I think that’s going to be a big one for 5.8.

Jeff Ong: Yeah. And I kind of skipped over. It was the first thing that was in here. Yes. Layout key is a way for you to quickly define the default, the width of your content within WordPress or within here. So if you see here, if I don’t define this layout, a lot of my content is just going to be full width by default. 

You can supply two values here. Content size, it’s just going to be the default width. You can also define, I think it’s, what is it? Wide size. Wide width. Nothing happened there because I hadn’t provided it. Maybe there’s a better way to show that with cover block. 

Birgit Pauli-Haack: Nice. I like it. 

Jeff Ong: Pretty cool. You can, I mean, alignment coming together and within a unified system reliably layout content with starting here is pretty powerful stuff I’d say.

Birgit Pauli-Haack: Yeah. Awesome. So I shared in the chat window, if you haven’t seen it, the documentation link where you can read up about the theme.json as a whole. When you say, Daisy, that that’s the layout will be important for 5.8, which part of it would be, where does it come into play?

Daisy Olsen: So with 5.8 with the custom template functionality that’s coming where you can basically create a custom template for an entire page or a post that would cover your header as well as your content. If you need to have these setting set for the width, especially the content size for it but preferably also wide so that your site knows how wide it should be. 

Otherwise you get kind of the facts that Jeff showed where it was the full width of the page. It didn’t have anything to contain it down to the width that you want. So for any theme that wants to use the template editor would benefit from having a theme.json file that even if it only has the one thing in it, it would be good way to take advantage of it.

Birgit Pauli-Haack: Yeah. It’s an excellent tip. Thank you, Daisy. You heard it here first. So we already got some questions in our Q and A, but I just wanted to have one question for Jeff before. That’s my prerogative as a host, I get the first question. So if I understood it correctly, so until now, theme.json comes into play I had to create many different places or touch many different places to make a color palette work.

So, I had to put it in my functions.php and then I also have to put it in my style sheet. Is [inaudible 00:30:04] that I don’t have to do this anymore, or do I still have to put it into my style sheet, or is it automatically created with when I put the color palette in the theme.json?

Jeff Ong: It is wonderful question. It is automatically created. This is all that that style sheet looks like since this is one of the big very exciting aspects of a theme.json. It’s that it’s managing this for you. And then also I think more down the line by providing colors and styles in this way. And then also by applying the styles here you can guarantee that those blocks are going to integrate properly.

It’s like the styles for those blocks are going to be more closely tied and actually in how the block is implemented. So no more writing styles that are overwriting that we’re having to target specific nested blocks. And so there’s tons of complications to this and there’s a lot more room to mature and develop, but I think that’s one of the parts I’m most excited about. To your point, there’s one place now where I can define my palette and show how it should be applied. I don’t have to go into two different places to do it.

Birgit Pauli-Haack: All right. Well, let’s go to the questions. Victor Kane, from the beginning of the show has already put them in and he’s particular interested in finding out about the workflow using them theme.json. So one is the best editing alternative for VS Code formatting, and then the second one was the possibility for exporting interactive selections to clipboard and code. I’m not quite sure I understand the question. Maybe you understand it, Jeff Daisy, Tammie.

Tammie Lister: Personally. So I think this is a personal choice. I’m going to start with an answer and then go to… I use VS Code, so I may not be able to give the right answer there. I would be curious to know what you don’t want in VS Code, and I think that that’s the thing. This opens up personal… I’m going to be really bad at reading the response in chat whilst talking. So I’m going to be a little bit pertinent and kind of speak first. I’m sorry, I’ll get back to it.

It’s your personal choice how you write and then you can kind of go back to it. So the thing that I did, this was my workflow, it has been my workflow so far, and I think this is the thing, we’re all finding our own new workflows with these new toys that we’re playing with. So what I’ve been doing is I’ve been using theme.json. 

I’ve actually been setting up variables using SAS that have been then pulling in root variables into my theme.json so that I can pull them through. That’s a weird way to do it. That’s strange, but the reason being, it means I can reuse and keep things separately. But I’m sure that everybody on this call has their own little workflows that they are kind of working from.

Daisy Olsen: My approach to that was actually the opposite that I was using my theme.json to set all of my variables so that I didn’t need SAS, which I think for those that never quite got their head wrapped around preprocessed CSS, it might be a way to simplify things for those that prefer it that way.

Birgit Pauli-Haack: Awesome. 

Tammie Lister: I think it’s what you’re cozy with, right? And I think that’s the thing. This can adapt to what was your cozy blanket of coding, and you don’t have to lose that yet, I think.

Birgit Pauli-Haack: All right. So Victor commented on that. If I get the results, I want interactively with the global settings panel on the right-hand side of the editor, can I export that to a theme.json format?

Daisy Olsen: The answer is not right now. I think there’s discussion in the teams about maybe building it, but it hasn’t been the highest priority because everything needs to work first before we start working on an exporter. But there are other parts of that can be exported in that full site editing experience that can be exported. So I think it would be a natural progression to add the ability to do a theme.json export.

Birgit Pauli-Haack: Yes. Definitely there will be.

Tammie Lister: From the very beginning, there were designs in global style. Sorry. The reason I know is that was one thing I did partake on. There was exporting. So I have a feeling if we all wanted to play some little happy bets, there will be exploiting at some point.

Birgit Pauli-Haack: Yeah. But if we all bet on the same thing, it’s not really bet, right? Victor, as always, you’re a little bit ahead of the time. So and from Jan Horna, from the Czech Republic, it’s very hot by now there. 

He has two questions as a theme developer, one, is the theme.json supposed to include all the styling, formatting definitions and replaced the CSS style? And I think we’d take it one at a time. So we talked a little bit about it from my question, but would it replace? You could still do all those styling in the style sheets as you want, right?

Daisy Olsen: And I think there are some things that will remain in other styling, but you could use the variables that you set or the properties that you set in your theme.json in your CSS. So they can work together. But I don’t think that theme.json, at least right now, will not completely replace an entire site’s design, especially if you have a very complex design.

Why do we want to rewrite CSS in JSON

Jeff Ong: Yeah. And this was one of my first questions and honestly, skepticism early on of the proposal around this, is CSS is great. Why do we want to rewrite CSS in JSON. And then it slowly, I mean, other people are obviously smarter than me understood this quickly. It’s not about rewriting all of CSS. There’s definitely going to be aspects of your site, especially if you have taking, like you’re saying, more complicated designs that will remain in CSS. 

But this is about creating, I think, more of the foundational elements and understanding how the blocks will interact with your styles and having that single point of contact, I think is most important. So I think for me, at least it’s more about the foundational elements that are going to be placed and managed this way than replacing your entirety of your styles. Because this great. 

Things like animations and transformation, and this is all really powerful stuff that I don’t imagine, really, at least in the super near future, having a big part of theme.json. To the question about, will you be able to save an export a theme.json from global styles? I think this is a really important thing to keep in mind is what I just showed you is kind of unnatural. I don’t imagine a future necessarily where theme developers are writing raw JSON.

It’s really, there’s not a great experience for it. It’s a configuration file. And so the more, to points that have already been raised, it’s about we’re in this phase now because we need to kind of identify and get it to work, and then we can kind of build an ecosystem around what would a really cool UI look like to generate one of these files? Is it native directly to global styles? How do we start to imagine those interfaces so the theme developers or theme designers can really get to the core of this experience too?

Birgit Pauli-Haack: All right. Well, thank you. Good point. You wanted to say something.

Tammie Lister: Yeah. I was just going to say over time, CSS has gained so much. So I didn’t know about anyone else, but I had a block.css file that was getting bigger and bigger of supporting blocks and doing things. And something I’ve noticed that I can do is throw that file away, and I couldn’t be happier because what I can do now is lean into these defaults. I’m still going to have some lines of CSS, the output by whatever, a preprocessor, whatever, my happy little whatever. 

Because everyone has got their own way and we should have our own way of doing it. But it’s a foundation, and it means that we’re not having to work around the editor or find different ways of doing it. I set up naturally a hack file for the editor out of habit. I haven’t filled it with anything yet in the latest theme I’ve been working on. 

I’m delighted if I never fill that up with anything on the next theme, because it means that the new way we’re doing things hasn’t had me to work around that. I can just use the foundation and create a really awesome experience on top of it. And that’s what we should be doing. We should be working with the editor, not having to work around it, or using not important like it was going out of fashion to go over control of it. It was this awkward middle ground we were working in trying to make things fit that paradigm. 

Birgit Pauli-Haack: And I think that fits right into the next question from Jan Horna again, and he says so as a block theme developer, should I focus from a strategic point of view on theme.json block styles, or block patterns. In other words, how do I differentiate? It’s kind of a high-level question there.

Daisy Olsen: I would say all of the above. They’re all important things. And your block styles are part of theme.json, I would say. But block patterns are really a powerful partner to the theme.json, that you can create building blocks for a site where you’ve got some really amazing very specific designed elements that could be used for different things on a site. So if you’re creating a commercial application that’s going to go out to a wide audience, they can be more generic. 

But if you have a client and you’re working as a freelancer or in an agency where you have a site that needs to have access to these things that they’re going to use more than once, patterns are a fantastic way to do that, where most of the work is done for them. They don’t have to reconfigure everything from the ground up every time they want to create something similar to what they’ve done before.

What happens when you update the color palette? Will saved blocks have the new colors?

Birgit Pauli-Haack: Thank you. And Spencer McCormick in the chat had a question. So what happens when you update the color palette or similar, for example, if you have a primary and secondary colors, when you update and change the palette colors, will saved blocks have the new colors? That’s an interesting question. Thank you, Spenser.

Daisy Olsen: I can answer that to some extent. If you think of your palette as named colors, if you give the different hex code to the same name, it should apply to the site. But if you give it a new name, then that’s a new element, and it won’t apply to anything that already had an old name attached to it.

Jeff Ong: There is a hefty discussion related to this question on the naming of colors in the way that Gutenberg wants to supply a default palette or a default set of named colors so that you could reliably… What we’re seeing I think is that I think patterns have been wanting to rely on specific colors across kind of, so you can guarantee oh, when corn flour shows up it’s always going to be corn flour. 

It’s always going to be available. There’s a lot of complication and nuance around it. But if, I think today, to answer your question, like Daisy is saying, today, if I were to supply a value or a named value here and then change it or take it out of my palette, then that would break the experience or it would no longer be applied to that.

And that’s part of the challenge, how do we reliably solve for that? How do we give theme office the tools to figure that out. But now if they set a custom color, if you set a custom color on an element or a block, then that will remain because it’s a specific X value, but the class names will go away though, if they’re supplied by the theme.

Birgit Pauli-Haack: So great discussions. And I’m probably going to share, and if it’s one issue where that discuss the theme team every week kind of shares all the things that are discussed and that need input from the community or other theme developers on their make blog. 

So that is definitely a place to go to chime in and we’ll find all the discussions that are happening. And then chime in in the ones that you find important and that you are worried about. So Tim Bowen has the question, how does the theme.json handle responsive sizes for font sizes especially. Responsive sizes.

Daisy Olsen: By default, I’m not sure.

Birgit Pauli-Haack: You’ve stomped the panelists. Yes, we did it.

Tammie Lister: I mean, you can use not just pixel values for your fonts, so-

Daisy Olsen: That’s what I was going to say. 

Tammie Lister: … that helps. And I think it’s a work in progress. So things like responsive and breakpoints. But the now answer is you don’t have to just use pixels. And Jeff just gave a great leak.

Jeff Ong: I just dropped the issue in that has not seen a lot of activity around it, but the idea of media. So the first part of your question on font sizes, there are ways of calculating this where they’re not pixel values tied to specific viewports. You could supply a calculated value, for example, in your small… that is based on a viewport size. 

So it’s kind of a paradigm shift or design paradigm shift of getting away from you must be 12 pixels under below 600 pixel viewport width, to more of are we okay with kind of a fluid typography kind of system? That being said, there are instances where you need media queries, and that is not currently… I don’t know how actively that’s being worked on right now. But a wonderful thing open to contributors.

Birgit Pauli-Haack: So Patty has a comment and a question after that, Patty O’Hara, I most often develop custom themes for clients and hand them off for the clients to update the content. And playing around with new tools, I’m excited to start using them, but don’t want to give access to global standards to anyone with admin access. Will the granularity of permissions changes so that I can block access to changing fonts and colors from within the admin?

Tammie Lister: I think this amazing thing happens in where also Jeff showed some of the control you can do. So in the demo, there was some control that you can do. But my process is a history of configurability and being able to do that be it in code, or be it in a plugin. But I honestly think we need to be a little bit cautious. This is my personal opinion here, and we need to maybe embrace allowing people to do styling. 

You can set boundaries, you can set branding boundaries, you can set pallets, you can set topography. But we need to move away a little bit from having such pixel fixated control in that sense and think about safely within boundaries, expression of these tools. And that people can create really amazing things, and you can maintain branding that way, and it can empower someone. 

These themes are becoming style guides, and that’s something that is known in the corporate world and used within that space as well. It’s a term, but it’s kind of democratizing design in that sense in giving people all these tools to play with, and I think it’s a huge change in the way that we’ve done things, but I think it’s really, really important and really, really empowering to the people that are using our themes.

Birgit Pauli-Haack: That’s a good advocacy for set it free. Thank you.

Tammie Lister: But you’re allowed to have boundaries. I think you can set it free, but be comfortable about some boundaries. I think sometimes when we say set it free, it can be scary because we don’t say you’re allowed to have some boundaries, but with pallets and with these style guides, that’s what you’re saying. You’re saying I’m making these good decisions for you and you can choose from this platform of good decisions. And that’s kind of awesome. I think,

Birgit Pauli-Haack: Yeah. I like the plea for block patterns that Daisy just a couple of minutes had that block patterns also give you the possibility or the option to actually provide different facets of how a section can be organized or styled within the style design system that you build with the block add on. 

And so I think that there is a lot of creativity that will come from that as well. So Tim Bowen is brave and contemplating, is it safe to use the theme.json now for a project launching in August? Would we just activate the Gutenberg plugin and add JSON file? Or is there more to it? I would love to move away from our functions in Editor.js method probably as soon as possible. So what would we say to Tim?

Daisy Olsen: The theme is not a block theme, as in it doesn’t use HTML templates, then I probably wouldn’t put the Gutenberg plugin on a production website, unless you are ready to deal with unexpected things happening. But placing your theme.json file in your classic theme on the 5.8 beta or release candidate that will be coming, I would start testing there and see if the things that you’re putting in your theme.json file work with 5.8 on a classic theme. That’d be my suggestion.

Tammie Lister: I think if it’s launching in August, that means 5.8 should be out. She tries to check her mental calendar. So I think tests. I, personally, am okay. I would consider it if it was going into a site, but I would also want to know how many users were using it, what their levels was, what they were doing, what they were going to create, and how they were going to do it. So it’s a… this is not legal advice. I feel that there should be [inaudible 00:50:36] advice that I can be. 

Birgit Pauli-Haack: Don’t try this at home. 

Tammie Lister: But by then, 5.8 should be out.

Birgit Pauli-Haack: Yeah. 5.8 comes out July 20th, that’s at least the schedule for that. So we ran out of questions right now one the Q and A sessions here. Well, you’re welcome, Tim. Good luck with that, and let us know. Is there more to the setting it up besides just activating the plugin or adding the JSON file. Well, back to kind of using it and editing. 

When there are already themes available in the theme repository that use the full set up for full site editing and use all the template parts and templates with the blocks, and header blocks, and photo blocks, and all that. But I’m not quite sure of that yet. Be careful about the using the Gutenberg plugin in production. It always has a few hiccups there.

So it wasn’t the first time ever that I retreated to the last version when I had one and had to wait till one, two, or three point releases to come out. So I’m hesitant to say do it in production. Test it as much as possible. So I have a lot of things on my screen, but not the right thing. Here, so it is. Oh, Ryan, we are pretty good time wise. 

So, I don’t have an additional… So, when we say how to get started, what was the first thing most difficult part for you for learning, or was there a mind shift until it clicked? Just to kind of get away from a fear of learning something new, and was there something when you go back ages on the theme.json thing.

Tammie Lister: So for me, it was realizing it wasn’t as hard as I maybe mentally thought it was. It was just the same with learning anything. You always think it’s going to be super hard, or at least with me, I read like dev doc and I’m like… My brain makes that noise. And then I just letting my theme be lighter. Letting it take the weight of that, giving up control, which as someone that’s maybe a bit of an old themer, giving up control of things, that’s an interesting process to go through. 

But it’s really important embracing those foundations. And when you do, there’s that mind shift of creating in the editor. That was the moment that… And I’m still going through the process. I think it’s a process, and it’s a process as these tools are evolving. We’re talking about be gentle, they’re in production. These tools are still evolving and working. 

If you are using these tools now before it’s released, then you’re going to hit bugs and report them. But that’s the thing. This theme.json also… the moment I kind of, the Jenga box, the blocks fell in my brain was I stopped seeing it as global stars. And I knew it wasn’t just global stars, but I felt it wasn’t just global stars and this felt like it could be the backbone of my theme, and it felt like it wasn’t everything in my theme, but it felt like it could be the backbone, is the best way I can describe it. 

And I could hang my theme from it. And we’ve hung our theme from functions.php wrongly, I think. So it was just that change from PHP to doing it all in the editor and creating and seeing that JSON. It just was free, and it’s more in line with how things are made outside WordPress, which I think is delightful.

Birgit Pauli-Haack: Any comments from you that you want to add, Daisy?

Daisy Olsen: So when I first started working with a theme.json file, I found that I had to… So there’s a whole section called styles, and I had to realign my thinking about what that meant, because what it’s saying is there are style settings in your blocks or for your site level depending on how it’s being applied, and what you’re doing is configuring the defaults for it. 

So if I think of the theme.json file as a default file, then it helped me frame it so that I’m not necessarily replacing my CSS depending on… I mean, I’m letting theme.json do the heavy lifting, kind of like Tammie said, but then I can take it further if I feel like I need to, or I want to. So I like thinking of it as a configuration file or a defaults file.

Birgit Pauli-Haack: That’s a good point. Jeff, do you have any stories how I came about?

Jeff Ong: It’s been really helpful to pair on it with people, to work on a theme with someone. I think if my team at Automattic. It’s a very culture of collaboration, and if you have the opportunity to say, “I’m having trouble with this. Would you want to work on this?” With someone like that, because this definitely can be a head bashing kind of why is this not being applied? 

I literally just wrote color green. Why is it not green? It can be so frustrating dealing with that. So to have someone just to look at your code and be like “Oh, you missed a comma or actually you need an extra key there” is really, really helpful for something like this.

Birgit Pauli-Haack: Oh yeah. So well, I think we’re coming to the end of our show. This has been very interesting and inspiring. So thank you all so much. And for those who want to dive into at a guided kind of testing session, Anne McCarthy, who, as you might know, runs the Full Site Editing Outreach program, she’s about to post the eighth call for testing, and it will all be about the theme.json file.

So as soon as it’s out, I will share a link in the show notes. And of course, also if you subscribed to our Gutenberg Times newsletter, you will definitely be informed about that. So at this point, I only have two more questions for our panelists. So do you have any announcements that you couldn’t get out before and you want the people to keep in mind? And if people want to get in touch with you, what would be the best way. Tammie, you want to start?

Tammie Lister: Yeah. So I’m comatose in all the things. I’m pretty easy to find in a good way. And I love chatting to people. So please do. I think my thing to say would be remember all of what happening now you can help shape. Just because we’ve sat here talking about it doesn’t mean we know anything more than you? It just means we’ve poked it and we’ve played around with the code. 

So do that. Start exploring it. And it’s a lot more accessible than it ever was. It’s starting to be more accessible. There’s more documentation than there ever was coming out. And if you care about what happens with themes or you ever cared about what happens to themes, and maybe you could have that reignited, start to join the conversation. And I guess my final point would be, I think my hope is to see this experimentation come back to themes. 

I think we forgot about that a little bit and we need to have some fun again in these. We used to have so much fun in WordPress themes, and I look forward to not just themes to have a purpose, but just themes that are art, themes that are just wacky experiments, and start enjoying theming and make some art. I’m really excited to see what things people create and use them just for one day even. That’d be amazing.

Birgit Pauli-Haack: Yeah. So Jeff, anything you want to have people keep in mind, and how to get in contact with you.

Jeff Ong: Yeah. Contact at J-F-F-N-G. And I guess keeping in mind, I’m just building on the last thing Tammie said, perhaps find a way to have fun with it and get curious about it, and try it. There’s really to me, a fundamental tendance of learning about something or you just have, how do I get curious about this thing? How do I play with it and have fun? And that’s going to be the most important thing to keep in at the center.

Birgit Pauli-Haack: Thank you, Jeff, and thank you so much for the audio work on the demo. Daisy.

Daisy Olsen: I’m Daisy Olsen on most things, Olsen with an E, and I would say that as far as what you can do as the next step if you’re interested in learning more about this, is go to… I’m pretty sure that Birgit has a link to this somewhere, the theme experiments repository on GitHub in the WordPress space has things that other people have done or are working on. 

So I love to see examples of something in action to help me learn more about it and to see what other people have done. So I would say go check out something.json files in there and see what people have come up with.

Birgit Pauli-Haack: Awesome. Thank you so much. So big thank you to Daisy, Jeff, and Tammie to come today and make your time. A big thank you also for the viewers with all your great questions. I think we got a great array of it. And if you have more questions, you can always send them to me via email to pauli@gutenbergtimes.com, and I’ll get you the answers.

And the recording of the show will be available in a few minutes on our YouTube channel. And I’ll share all the links then also in the video description. And within a few days, we will have also a transcript that we will publish on the Gutenbergtimes.com. So be well, good-bye, and good luck. That was fun. Thank you.

Jeff Ong: Thank you, everyone.

Gutenberg Times: Theme.json for WordPress Theme Authors – demo and Live Q & A w/ Daisy Olson, Tammie Lister and Jeff Ong

Wordpress Planet - Sat, 06/26/2021 - 17:23

On June 24th, we hosted Gutenberg Times Live Q & A on the topic “Theme.json for Theme Authors – Getting started with theme development for Full-site Editing” It was a great pleasure and privilege to have Daisy Olson, developer advocate at Automattic, Tammie Lister, design lead at Extendify and Jeff Ong, code wrangler at Automattic on the show.

Jeff Ong prepared a demo for us, and then attendees had some interesting questions our panelists answered. You can read the transcript below.

WordPress 5.8 will come with the infrastructure and foundation to control the block editor and theme settings via the configuration file theme.json. JSON is a universal data format that is readable to PHP and JavaScript alike.

Themes no longer have to pretend that they’re plugins.

Tammie Lister Resources about theme.json and themes for Full-site editing

During the show, we mentioned a few places where you can dive in and learn more about theme.json.

You can read an Introducing theme.json in WordPress 5.8 by Andre Maneiro on the Core Make blog.

You can read up on the details specifications in the Block Editor Handbook: Global Settings & Styles (theme.json).

A good way to get started and see the configuration in action is to study the themes available in the Theme Experiments repository on GitHub.

Another fantastic way to get your feet wet is to heed the Call for Testing #8 out of the FSE outreach program. Anne McCarthy has some interesting tasks for you.

Tammie Lister started a new blog and shared her thoughts on theme.json and why she is excited again for theme development. Theme.json inspires

The Gutenberg team is in ongoing discussion about various topics. Two were raised during the Live Q & A. Both could use your opinion and ideas.

Themes for Full-site Editing in the WordPress.org repository

Transcript

This transcript is still a work in progress – Birgit

Birgit Pauli-Haack: Well, and then we can start the webinar here. The webinar is now live and welcome to our 28th Gutenberg live Q and A on this June 24th. My name is Birgit Pauli-Haack and I am your host for today’s discussion. Thank you all for watching, and it’s great to have you. And while you all come in, use the chat window to tell us where you are and where you’re watching from. 

And today we will discuss a new way to configure themes, that is black themes, with global styles and settings file theme.json. And it will enable theme developers to centralize all the block-based settings, color palettes, font sizes, and other block-based customizations. This way you will also control which of the other block features the theme supports or does not support. 

So that’s my simple mind’s description of the new features and I’m so thrilled to have three experts on the show to go beyond this simple explanation and help theme developers to get started. I’m extremely honored to have Daisy Olsen, developer advocate at Automatic and WordPress contributor. Hey, good to have you. Also Jeff Ong, code wrangler at Automatic.

Jeff Ong: Hello.

Birgit Pauli-Haack: Thanks for being here. And at last but not at least Tammie Lister, design lead at Extendify.

Tammie Lister: Hello.

Birgit Pauli-Haack: We’ll do some proper introduction in less than a minute. I just have a few housekeeping notes. So after the introduction, we’ll have a first round robin question and then we see a demo. Jeff was working really hard on it and I think he was the only one repairing hard for this live Q and A. And then we’ll discuss the different angles and how they get started. And then, of course, answer your question.

Speaking of questions, how do you pose your questions? There’s a Q and A on the bottom of the screen, a kind of icon. You click on that and write your question. And for those watching on YouTube use the chat window next to the video player. And so saying hi. Hi, Victor. From Buenos Aires in Argentina. Awesome. Thank you for being here. All right. When you do comments and questions, so please be kind even if you disagree. 

This is a family endeavor. All right. Well, I’m thrilled you all agreed dear panelists to come on the show and I get an hour to talk with you about your work. So, Daisy, tell us a little bit about you, where are you’re located and what is it that you do as developer advocate on the purpose project and at Automatic?

Daisy Olsen: Yeah. I’m Daisy Olsen and I live in New Hampshire in the United States. It’s a beautiful day here right now unlike some parts of this country that are really hot. We got the cool weather over here this week. So as a developer advocate, I talk about WordPress a lot.

I get out and do workshops, teach classes, write documentation and just stay involved and close to the projects development so that I know what’s going on theoretically and can share that out particularly with plugin and theme developers as well as agencies and freelancers and things like that.

Birgit Pauli-Haack: Awesome. So glad you’re here. Thank you. So, Tammie, thank you for coming back to the show. It’s been over three years. The last time you were on the show was just after Gutenberg was merged into Core and you were one of the three leads with Matias Ventura and Joen Asmussen. 

And you shared a lot about the journey of Gutenberg and the philosophy behind it. So I will put the link to the show into the show notes for you who have been coming later to Gutenberg. But this year you joined the WordPress product company Extendify. So what do you do there?

Tammie Lister: First of all, has it been three years? That goodness. Time flies. So in Extendify I focus on design. So our solutions extend the editor. And then the aim is to make it even more usable for people’s purpose that they want to use it for. And I’m really, really excited about that.

So it means that people can have the best experience from the content they’re creating, to the layout, the patterns, the styles, whatever that the editor enables, that’s really what I’m focusing on. So it’s a interesting new challenge to do. And you have blew my brain with that time span. You really have. That’s awesome.

Birgit Pauli-Haack: Well, it’s also over three years that Gutenberg times us. So I’ve been part of that journey so for so long.

Tammie Lister: Congrats.

Birgit Pauli-Haack: Nothing really held my attention for so long. And normally I get really bored. Well, I’m also really happy that Extendify took over Editor Plus from Munir Kumal and the EditorsKit from Jeffrey Carandang. So, those have a more sustainable way now to access because both Munir and Jeffrey seem to have… Munir joined you, but Jeffrey moved on to be a consultant at , I think, 10up.

Tammie Lister: It’s so really exciting. 

Birgit Pauli-Haack: Yeah. I imagine. So thank you also to Jeff Ong for joining us today as well. You’re a code wrangler in Automatic and what have you been working on lately except for the demo. I know about that.

Jeff Ong: Well, first, thank you for having me and hosting this. Awesome to be here. I feel very honored to be with three on-time contributors. So super cool. At Automattic, I’ve been working on theme development, pretty solely focused on that for the last year. And my background is not in WordPress. 

So it’s kind of been an interesting journey to transition and learn about the ecosystem and really coming at a transitory time figuring out how do we kind of move into this new block-based paradigm? How do we make themes that work with the block editor really well and can hopefully unlock more creativity for just really great design. And I can tell you what sites again. Well, making new themes and figuring out how to do that with the latest version of Gutenberg, which turns out every day.

Birgit Pauli-Haack: So the viewers follow Jeff Ong, he’s going to teach you how to do things with the Block Editor. And we will soon see a little demo of that. It’s what Daisy said, “What you did in five minutes, I taught a course on that in three hours.” So it’s going to be a little fast paced today. 

What will change most for the theme developers when building themes for full-site editing?

But before we head into media’s raised, I would like to ask each of you, so what do you think will change most for the theme developers when building themes? These are for agency building custom themes for the clients or for theme shops rolling out new themes to sell. Do you want to start, Tammie?

Tammie Lister: Yeah. That’s interesting because I think perhaps it’s a change if you wanted to be a change. Because lots of this is an opt-in, as is the way. WordPress, the best way to opt-in. I go back to a lot of times that this is a freeing of things and I think it brings an opportunity that has pros and cons, ups and downs with opportunities.

But plug-ins themes no longer have to pretend that they’re plugins and they no longer have to be everything and have to be things that they weren’t intended to be in the first. So I think that that is a challenge in itself because there’s a certain way that you maybe thought you had to do things and now you don’t have to work around things. We often have to work around things in WordPress. 

And if you don’t have to work around it, it can feel a little bit peculiar, but once you realize you don’t have to do that, it’s actually really awesome. But you have to realize you don’t have to and that WordPress was getting in the way. I also think as a result there’s going to be a space for more creativity, and this can also be really to challenging because maybe you were limited to what you could do creativity wise because of just the confinements of the space and the confinements of what you could do before. 

And it’s going to open things again to a lot more people. And a lot more people who maybe didn’t have access to a theme developer with experience who knew the exact ins and outs of it. So I think that’s a challenge because new people in this space, new creativity. But honestly I think it’s a good thing. It’s just if you want to and you’re open to it and you can kind of explore those new ways, but I don’t think it’s a change that you have to make. I think that’s the thing.

Birgit Pauli-Haack: Awesome. Thank you. Daisy, what do you think?

Daisy Olsen: So I think I would agree with Tammie that the barrier of entry for a new theme designer. And I think that’s one of the key things is it’s bringing the design back to theming. Theming over time became very functional. We had a lot of theme companies that were trying to make their themes as flexible, powerful and feature-ful as possible to reach a wide variety of people.

And I think that we can see some opportunity for vertically oriented designs coming out where you have a theme that is geared towards a restaurant or geared towards, I don’t know, a salon or a certain kind of a business or even a personal site.

And I think that there’s a lot of opportunity to be able to have a lot of variety out there in the marketplace so that when someone asks you inevitable question, because this was probably the most common question when I was working for a thing company is which theme is best for this? 

I’m doing this kind of a site, which themes should I use. And it could make it so, well, here are five that are really geared towards what you’re trying to do instead of, oh, you can use any of them. You just have to do all this work to get it to look bright.

Birgit Pauli-Haack: Yeah. That’s a good point. Thank you. Jeff?.

Jeff Ong: Definitely, from a design perspective, it’s super exciting. I want to highlight maybe a little bit more from the development side. This seems like the biggest opportunity or clearest opportunity to ensure that your theme is integrated with the editor. That the things that you’re doing with the editor and your ability to customize it to control what presets and options are available there to the users of the theme, this is the theme [inaudible 00:12:27].

It’s a unifying kind of idea and single point of truth. Talking about theme.json and even just this whole concept of how do we bring the experience together. I think we have an opportunity to do that and that’s going to change even in some small level. Even if your theme.json cloud just as a few settings. You can take it slow like Tammie was saying. Incorporate parts of it because to me you have this new contract now that can really unify things and bring things together from a lot of disparate parts and pieces.

Birgit Pauli-Haack: Lots to think about. And I agree with all of you. I had this pleasure last year that I took over themes from agencies and they were so powerful and all the things that normally a plug-in will do, custom post types and rigid and all that. It’s all in one place and we won’t be able to change a theme at all. 

So now this is definitely going to make life a lot easier for site owners as well So lots to think about and listening to you is quite inspiring to kind of think, oh, well how many direction can my brain go now? But, Jeff, are you ready for your demo? I think it would be helpful for all the people here on the call to see what it’s all about and how it kind of gets started.

Jeff Ong: Yes. We have 10 minutes roughly. Yes. Can you see my screen? 

Birgit Pauli-Haack: We can see your screen. Yes.

Demo: Configuring the block editor with theme.json file

14.02

Jeff Ong: So we have a blank theme here and I just want to kind of go over some, not going to cover everything, but some of the key parts of that theme.json introduces and show how that impacts a blank theme and also the editor. So hopping over to my code editor. I have my theme.JSON here. This is a really basic, simple theme and nothing going on yet. 

In here I’m going to go ahead and the first thing I want to talk about are the settings of your theme.JSON. Settings are kind of what control or give you the ability to configure the editor and what kind of customization options are present to a user and the theme. The only thing I have right now is the layout, which we’ll get to in a second. But let’s say I want to add some color options here.

Previously it would be done in the functions PHP. I have kind of a few sheets over here. Sorry. I need to hide these meeting control. I’m going to copy a color palette from this. I’m going to set a palette that’s going to become available to me in my theme. I go to edit the same post. In here I see my cornso, my orange, red, and color blue that’s become available to me. 

What’s pretty interesting about this is before you would have had to kind of go into functions at this whole palette and then also define the class name, something like this to actually apply those styles. Let’s say I want this heading to be orange, update it. Show it here. I get all this cool stuff for free. This class was generated for me by Gutenberg using this preset and that I have defined meeting controls defined here in my palette options. 

Another cool thing or interesting about the possibility here is within the same configuration. Let’s say I’m the theme designer. I have the option right now to change the color to kind of anything I want. The powerful thing about theme.json at this time is it can actually turn something like this off. I actually don’t want people or my users to be able to change anything, change the color palette.

But let’s go ahead and reset this back here. Turned off custom colors within theme.json. And then back here you’ll see that option has disappeared. So inaccessible color combinations or just color combinations that you don’t want to be available. You can turn that off. This is just one of the options that are available. Color is just one of the options that you can customize.

You can also take a look at something like typography. I think I can find some font sizes here. Refresh. I can see now that those presets were available, are now available to me. I can do the same thing again here too. Say I don’t actually want people to be able to change all sides here. As a designer I know it’s best and I don’t want people putting in random font sizes. 

So disable that and now only my presets are available too. Oh, by the way, this content is just kind of some standard block-based content. Again, I’m getting all of this kind of for free or for free in a way by just applying some preset values here. Well, I think the next thing that I wanted to cover is going into the last thing. I’ll cover it within the settings because you can actually change these per block. 

Remember we were looking at color before. I could add a color key to the paragraph block and actually say, just kidding. I want to allow you to be able to change the color of paragraph blocks. Just the paragraph blocks. I can open up the whole thing. So within here now I can see, oh, I can actually change just for paragraph blocks. I go up to my heading. This custom color is not available. This color option is not available. 

If you want to I could also supply a custom palette. I’m not going to do that, but could say if you wanted a specific palette that’s just applied for paragraph blocks. That would be how you do it. So I think that’s it for settings. I’m going to go ahead and collapse this now and move on to the styles key of our theme.json. And now within here I can start to define some files. 

Remember our colors from up here from the palette. I can go ahead and because I know that WordPress is generating CSS variables based on these palettes, I can go ahead and start to use those within the styles application of the style section of my theme.json. So with the preset color, put orange red. See what else do. These are going to apply at the top level. So this is going to apply to everything.

Say I only wanted, for instance, my headings to be… Let’s make this. Do the same thing in here and say, ah, I just want, actually, let’s just make my paragraph colors black. So, again, what I’ve done here is I’ve set my global kind of text color to this orange red was preset, which was provided by WordPress and generated here to the entire text. And then actually I can go in and target specific block, set the settings for that as well. 

I think we are close. I just want to show, well, if you’re editing this, something that’s also probably going to happen and mess this up. It should throw some kind of an error here yet. Notice there when decoding theme.json. So that’ll let you know there’s something going on because it’s pretty easy tip something up here. 

And I think that’s just a small note is we’ll likely encounter that if you’re configuring keys and nested objects trying to figure out how each of those apply. You pause here for a second. I guess the last thing I want to cover too is the concept of elements. So within here, any h2 that I have is going to be applied a specific style here. So I have the same because [inaudible 00:24:24] can appear outside of blocks or links, for example.

These are restricted to a specific set at the moment. So let’s just say text. So, again, because this is not actually rendered as a pocket and an element and that can appear anywhere. That’s something that I can target with this kind of top level elements select here. Everything else here you can target with the name of the block. 

That is most of what I wanted to cover pretty fast, but again all of the settings that you can find here or that I’m going over, there’s way more than just color. There’s spacing, typography and all of that can be found in documentation that Birgit, I think she shared it here. So that I want to open it up. And I guess there are questions. If there are specific parts that anyone would want to go into in a little more detail. Happy to do that.

Daisy Olsen: Thank you, Jeff. 

Birgit Pauli-Haack: Thank you, Jeff. This was awesome. Do you want to just say something?

Daisy Olsen: Yeah. I just wanted to say that maybe we could just talk about layout real quick because I think that’s going to be a big one for 5.8.

Jeff Ong: Yeah. And I kind of skipped over. It was the first thing that was in here. Yes. Layout key is a way for you to quickly define the default, the width of your content within WordPress or within here. So if you see here, if I don’t define this layout, a lot of my content is just going to be full width by default. 

You can supply two values here. Content size, it’s just going to be the default width. You can also define, I think it’s, what is it? Wide size. Wide width. Nothing happened there because I hadn’t provided it. Maybe there’s a better way to show that with cover block. 

Birgit Pauli-Haack: Nice. I like it. 

Jeff Ong: Pretty cool. You can, I mean, alignment coming together and within a unified system reliably layout content with starting here is pretty powerful stuff I’d say.

Birgit Pauli-Haack: Yeah. Awesome. So I shared in the chat window, if you haven’t seen it, the documentation link where you can read up about the theme.json as a whole. When you say, Daisy, that that’s the layout will be important for 5.8, which part of it would be, where does it come into play?

Daisy Olsen: So with 5.8 with the custom template functionality that’s coming where you can basically create a custom template for an entire page or a post that would cover your header as well as your content. If you need to have these setting set for the width, especially the content size for it but preferably also wide so that your site knows how wide it should be. 

Otherwise you get kind of the facts that Jeff showed where it was the full width of the page. It didn’t have anything to contain it down to the width that you want. So for any theme that wants to use the template editor would benefit from having a theme.json file that even if it only has the one thing in it, it would be good way to take advantage of it.

Birgit Pauli-Haack: Yeah. It’s an excellent tip. Thank you, Daisy. You heard it here first. So we already got some questions in our Q and A, but I just wanted to have one question for Jeff before. That’s my prerogative as a host, I get the first question. So if I understood it correctly, so until now, theme.json comes into play I had to create many different places or touch many different places to make a color palette work.

So, I had to put it in my functions.php and then I also have to put it in my style sheet. Is [inaudible 00:30:04] that I don’t have to do this anymore, or do I still have to put it into my style sheet, or is it automatically created with when I put the color palette in the theme.json?

Jeff Ong: It is wonderful question. It is automatically created. This is all that that style sheet looks like since this is one of the big very exciting aspects of a theme.json. It’s that it’s managing this for you. And then also I think more down the line by providing colors and styles in this way. And then also by applying the styles here you can guarantee that those blocks are going to integrate properly.

It’s like the styles for those blocks are going to be more closely tied and actually in how the block is implemented. So no more writing styles that are overwriting that we’re having to target specific nested blocks. And so there’s tons of complications to this and there’s a lot more room to mature and develop, but I think that’s one of the parts I’m most excited about. To your point, there’s one place now where I can define my palette and show how it should be applied. I don’t have to go into two different places to do it.

Birgit Pauli-Haack: All right. Well, let’s go to the questions. Victor Kane, from the beginning of the show has already put them in and he’s particular interested in finding out about the workflow using them theme.json. So one is the best editing alternative for VS Code formatting, and then the second one was the possibility for exporting interactive selections to clipboard and code. I’m not quite sure I understand the question. Maybe you understand it, Jeff Daisy, Tammie.

Tammie Lister: Personally. So I think this is a personal choice. I’m going to start with an answer and then go to… I use VS Code, so I may not be able to give the right answer there. I would be curious to know what you don’t want in VS Code, and I think that that’s the thing. This opens up personal… I’m going to be really bad at reading the response in chat whilst talking. So I’m going to be a little bit pertinent and kind of speak first. I’m sorry, I’ll get back to it.

It’s your personal choice how you write and then you can kind of go back to it. So the thing that I did, this was my workflow, it has been my workflow so far, and I think this is the thing, we’re all finding our own new workflows with these new toys that we’re playing with. So what I’ve been doing is I’ve been using theme.json. 

I’ve actually been setting up variables using SAS that have been then pulling in root variables into my theme.json so that I can pull them through. That’s a weird way to do it. That’s strange, but the reason being, it means I can reuse and keep things separately. But I’m sure that everybody on this call has their own little workflows that they are kind of working from.

Daisy Olsen: My approach to that was actually the opposite that I was using my theme.json to set all of my variables so that I didn’t need SAS, which I think for those that never quite got their head wrapped around preprocessed CSS, it might be a way to simplify things for those that prefer it that way.

Birgit Pauli-Haack: Awesome. 

Tammie Lister: I think it’s what you’re cozy with, right? And I think that’s the thing. This can adapt to what was your cozy blanket of coding, and you don’t have to lose that yet, I think.

Birgit Pauli-Haack: All right. So Victor commented on that. If I get the results, I want interactively with the global settings panel on the right-hand side of the editor, can I export that to a theme.json format?

Daisy Olsen: The answer is not right now. I think there’s discussion in the teams about maybe building it, but it hasn’t been the highest priority because everything needs to work first before we start working on an exporter. But there are other parts of that can be exported in that full site editing experience that can be exported. So I think it would be a natural progression to add the ability to do a theme.json export.

Birgit Pauli-Haack: Yes. Definitely there will be.

Tammie Lister: From the very beginning, there were designs in global style. Sorry. The reason I know is that was one thing I did partake on. There was exporting. So I have a feeling if we all wanted to play some little happy bets, there will be exploiting at some point.

Birgit Pauli-Haack: Yeah. But if we all bet on the same thing, it’s not really bet, right? Victor, as always, you’re a little bit ahead of the time. So and from Jan Horna, from the Czech Republic, it’s very hot by now there. 

He has two questions as a theme developer, one, is the theme.json supposed to include all the styling, formatting definitions and replaced the CSS style? And I think we’d take it one at a time. So we talked a little bit about it from my question, but would it replace? You could still do all those styling in the style sheets as you want, right?

Daisy Olsen: And I think there are some things that will remain in other styling, but you could use the variables that you set or the properties that you set in your theme.json in your CSS. So they can work together. But I don’t think that theme.json, at least right now, will not completely replace an entire site’s design, especially if you have a very complex design.

Why do we want to rewrite CSS in JSON

Jeff Ong: Yeah. And this was one of my first questions and honestly, skepticism early on of the proposal around this, is CSS is great. Why do we want to rewrite CSS in JSON. And then it slowly, I mean, other people are obviously smarter than me understood this quickly. It’s not about rewriting all of CSS. There’s definitely going to be aspects of your site, especially if you have taking, like you’re saying, more complicated designs that will remain in CSS. 

But this is about creating, I think, more of the foundational elements and understanding how the blocks will interact with your styles and having that single point of contact, I think is most important. So I think for me, at least it’s more about the foundational elements that are going to be placed and managed this way than replacing your entirety of your styles. Because this great. 

Things like animations and transformation, and this is all really powerful stuff that I don’t imagine, really, at least in the super near future, having a big part of theme.json. To the question about, will you be able to save an export a theme.json from global styles? I think this is a really important thing to keep in mind is what I just showed you is kind of unnatural. I don’t imagine a future necessarily where theme developers are writing raw JSON.

It’s really, there’s not a great experience for it. It’s a configuration file. And so the more, to points that have already been raised, it’s about we’re in this phase now because we need to kind of identify and get it to work, and then we can kind of build an ecosystem around what would a really cool UI look like to generate one of these files? Is it native directly to global styles? How do we start to imagine those interfaces so the theme developers or theme designers can really get to the core of this experience too?

Birgit Pauli-Haack: All right. Well, thank you. Good point. You wanted to say something.

Tammie Lister: Yeah. I was just going to say over time, CSS has gained so much. So I didn’t know about anyone else, but I had a block.css file that was getting bigger and bigger of supporting blocks and doing things. And something I’ve noticed that I can do is throw that file away, and I couldn’t be happier because what I can do now is lean into these defaults. I’m still going to have some lines of CSS, the output by whatever, a preprocessor, whatever, my happy little whatever. 

Because everyone has got their own way and we should have our own way of doing it. But it’s a foundation, and it means that we’re not having to work around the editor or find different ways of doing it. I set up naturally a hack file for the editor out of habit. I haven’t filled it with anything yet in the latest theme I’ve been working on. 

I’m delighted if I never fill that up with anything on the next theme, because it means that the new way we’re doing things hasn’t had me to work around that. I can just use the foundation and create a really awesome experience on top of it. And that’s what we should be doing. We should be working with the editor, not having to work around it, or using not important like it was going out of fashion to go over control of it. It was this awkward middle ground we were working in trying to make things fit that paradigm. 

Birgit Pauli-Haack: And I think that fits right into the next question from Jan Horna again, and he says so as a block theme developer, should I focus from a strategic point of view on theme.json block styles, or block patterns. In other words, how do I differentiate? It’s kind of a high-level question there.

Daisy Olsen: I would say all of the above. They’re all important things. And your block styles are part of theme.json, I would say. But block patterns are really a powerful partner to the theme.json, that you can create building blocks for a site where you’ve got some really amazing very specific designed elements that could be used for different things on a site. So if you’re creating a commercial application that’s going to go out to a wide audience, they can be more generic. 

But if you have a client and you’re working as a freelancer or in an agency where you have a site that needs to have access to these things that they’re going to use more than once, patterns are a fantastic way to do that, where most of the work is done for them. They don’t have to reconfigure everything from the ground up every time they want to create something similar to what they’ve done before.

What happens when you update the color palette? Will saved blocks have the new colors?

Birgit Pauli-Haack: Thank you. And Spencer McCormick in the chat had a question. So what happens when you update the color palette or similar, for example, if you have a primary and secondary colors, when you update and change the palette colors, will saved blocks have the new colors? That’s an interesting question. Thank you, Spenser.

Daisy Olsen: I can answer that to some extent. If you think of your palette as named colors, if you give the different hex code to the same name, it should apply to the site. But if you give it a new name, then that’s a new element, and it won’t apply to anything that already had an old name attached to it.

Jeff Ong: There is a hefty discussion related to this question on the naming of colors in the way that Gutenberg wants to supply a default palette or a default set of named colors so that you could reliably… What we’re seeing I think is that I think patterns have been wanting to rely on specific colors across kind of, so you can guarantee oh, when corn flour shows up it’s always going to be corn flour. 

It’s always going to be available. There’s a lot of complication and nuance around it. But if, I think today, to answer your question, like Daisy is saying, today, if I were to supply a value or a named value here and then change it or take it out of my palette, then that would break the experience or it would no longer be applied to that.

And that’s part of the challenge, how do we reliably solve for that? How do we give theme office the tools to figure that out. But now if they set a custom color, if you set a custom color on an element or a block, then that will remain because it’s a specific X value, but the class names will go away though, if they’re supplied by the theme.

Birgit Pauli-Haack: So great discussions. And I’m probably going to share, and if it’s one issue where that discuss the theme team every week kind of shares all the things that are discussed and that need input from the community or other theme developers on their make blog. 

So that is definitely a place to go to chime in and we’ll find all the discussions that are happening. And then chime in in the ones that you find important and that you are worried about. So Tim Bowen has the question, how does the theme.json handle responsive sizes for font sizes especially. Responsive sizes.

Daisy Olsen: By default, I’m not sure.

Birgit Pauli-Haack: You’ve stomped the panelists. Yes, we did it.

Tammie Lister: I mean, you can use not just pixel values for your fonts, so-

Daisy Olsen: That’s what I was going to say. 

Tammie Lister: … that helps. And I think it’s a work in progress. So things like responsive and breakpoints. But the now answer is you don’t have to just use pixels. And Jeff just gave a great leak.

Jeff Ong: I just dropped the issue in that has not seen a lot of activity around it, but the idea of media. So the first part of your question on font sizes, there are ways of calculating this where they’re not pixel values tied to specific viewports. You could supply a calculated value, for example, in your small… that is based on a viewport size. 

So it’s kind of a paradigm shift or design paradigm shift of getting away from you must be 12 pixels under below 600 pixel viewport width, to more of are we okay with kind of a fluid typography kind of system? That being said, there are instances where you need media queries, and that is not currently… I don’t know how actively that’s being worked on right now. But a wonderful thing open to contributors.

Birgit Pauli-Haack: So Patty has a comment and a question after that, Patty O’Hara, I most often develop custom themes for clients and hand them off for the clients to update the content. And playing around with new tools, I’m excited to start using them, but don’t want to give access to global standards to anyone with admin access. Will the granularity of permissions changes so that I can block access to changing fonts and colors from within the admin?

Tammie Lister: I think this amazing thing happens in where also Jeff showed some of the control you can do. So in the demo, there was some control that you can do. But my process is a history of configurability and being able to do that be it in code, or be it in a plugin. But I honestly think we need to be a little bit cautious. This is my personal opinion here, and we need to maybe embrace allowing people to do styling. 

You can set boundaries, you can set branding boundaries, you can set pallets, you can set topography. But we need to move away a little bit from having such pixel fixated control in that sense and think about safely within boundaries, expression of these tools. And that people can create really amazing things, and you can maintain branding that way, and it can empower someone. 

These themes are becoming style guides, and that’s something that is known in the corporate world and used within that space as well. It’s a term, but it’s kind of democratizing design in that sense in giving people all these tools to play with, and I think it’s a huge change in the way that we’ve done things, but I think it’s really, really important and really, really empowering to the people that are using our themes.

Birgit Pauli-Haack: That’s a good advocacy for set it free. Thank you.

Tammie Lister: But you’re allowed to have boundaries. I think you can set it free, but be comfortable about some boundaries. I think sometimes when we say set it free, it can be scary because we don’t say you’re allowed to have some boundaries, but with pallets and with these style guides, that’s what you’re saying. You’re saying I’m making these good decisions for you and you can choose from this platform of good decisions. And that’s kind of awesome. I think,

Birgit Pauli-Haack: Yeah. I like the plea for block patterns that Daisy just a couple of minutes had that block patterns also give you the possibility or the option to actually provide different facets of how a section can be organized or styled within the style design system that you build with the block add on. 

And so I think that there is a lot of creativity that will come from that as well. So Tim Bowen is brave and contemplating, is it safe to use the theme.json now for a project launching in August? Would we just activate the Gutenberg plugin and add JSON file? Or is there more to it? I would love to move away from our functions in Editor.js method probably as soon as possible. So what would we say to Tim?

Daisy Olsen: The theme is not a block theme, as in it doesn’t use HTML templates, then I probably wouldn’t put the Gutenberg plugin on a production website, unless you are ready to deal with unexpected things happening. But placing your theme.json file in your classic theme on the 5.8 beta or release candidate that will be coming, I would start testing there and see if the things that you’re putting in your theme.json file work with 5.8 on a classic theme. That’d be my suggestion.

Tammie Lister: I think if it’s launching in August, that means 5.8 should be out. She tries to check her mental calendar. So I think tests. I, personally, am okay. I would consider it if it was going into a site, but I would also want to know how many users were using it, what their levels was, what they were doing, what they were going to create, and how they were going to do it. So it’s a… this is not legal advice. I feel that there should be [inaudible 00:50:36] advice that I can be. 

Birgit Pauli-Haack: Don’t try this at home. 

Tammie Lister: But by then, 5.8 should be out.

Birgit Pauli-Haack: Yeah. 5.8 comes out July 20th, that’s at least the schedule for that. So we ran out of questions right now one the Q and A sessions here. Well, you’re welcome, Tim. Good luck with that, and let us know. Is there more to the setting it up besides just activating the plugin or adding the JSON file. Well, back to kind of using it and editing. 

When there are already themes available in the theme repository that use the full set up for full site editing and use all the template parts and templates with the blocks, and header blocks, and photo blocks, and all that. But I’m not quite sure of that yet. Be careful about the using the Gutenberg plugin in production. It always has a few hiccups there.

So it wasn’t the first time ever that I retreated to the last version when I had one and had to wait till one, two, or three point releases to come out. So I’m hesitant to say do it in production. Test it as much as possible. So I have a lot of things on my screen, but not the right thing. Here, so it is. Oh, Ryan, we are pretty good time wise. 

So, I don’t have an additional… So, when we say how to get started, what was the first thing most difficult part for you for learning, or was there a mind shift until it clicked? Just to kind of get away from a fear of learning something new, and was there something when you go back ages on the theme.json thing.

Tammie Lister: So for me, it was realizing it wasn’t as hard as I maybe mentally thought it was. It was just the same with learning anything. You always think it’s going to be super hard, or at least with me, I read like dev doc and I’m like… My brain makes that noise. And then I just letting my theme be lighter. Letting it take the weight of that, giving up control, which as someone that’s maybe a bit of an old themer, giving up control of things, that’s an interesting process to go through. 

But it’s really important embracing those foundations. And when you do, there’s that mind shift of creating in the editor. That was the moment that… And I’m still going through the process. I think it’s a process, and it’s a process as these tools are evolving. We’re talking about be gentle, they’re in production. These tools are still evolving and working. 

If you are using these tools now before it’s released, then you’re going to hit bugs and report them. But that’s the thing. This theme.json also… the moment I kind of, the Jenga box, the blocks fell in my brain was I stopped seeing it as global stars. And I knew it wasn’t just global stars, but I felt it wasn’t just global stars and this felt like it could be the backbone of my theme, and it felt like it wasn’t everything in my theme, but it felt like it could be the backbone, is the best way I can describe it. 

And I could hang my theme from it. And we’ve hung our theme from functions.php wrongly, I think. So it was just that change from PHP to doing it all in the editor and creating and seeing that JSON. It just was free, and it’s more in line with how things are made outside WordPress, which I think is delightful.

Birgit Pauli-Haack: Any comments from you that you want to add, Daisy?

Daisy Olsen: So when I first started working with a theme.json file, I found that I had to… So there’s a whole section called styles, and I had to realign my thinking about what that meant, because what it’s saying is there are style settings in your blocks or for your site level depending on how it’s being applied, and what you’re doing is configuring the defaults for it. 

So if I think of the theme.json file as a default file, then it helped me frame it so that I’m not necessarily replacing my CSS depending on… I mean, I’m letting theme.json do the heavy lifting, kind of like Tammie said, but then I can take it further if I feel like I need to, or I want to. So I like thinking of it as a configuration file or a defaults file.

Birgit Pauli-Haack: That’s a good point. Jeff, do you have any stories how I came about?

Jeff Ong: It’s been really helpful to pair on it with people, to work on a theme with someone. I think if my team at Automattic. It’s a very culture of collaboration, and if you have the opportunity to say, “I’m having trouble with this. Would you want to work on this?” With someone like that, because this definitely can be a head bashing kind of why is this not being applied? 

I literally just wrote color green. Why is it not green? It can be so frustrating dealing with that. So to have someone just to look at your code and be like “Oh, you missed a comma or actually you need an extra key there” is really, really helpful for something like this.

Birgit Pauli-Haack: Oh yeah. So well, I think we’re coming to the end of our show. This has been very interesting and inspiring. So thank you all so much. And for those who want to dive into at a guided kind of testing session, Anne McCarthy, who, as you might know, runs the Full Site Editing Outreach program, she’s about to post the eighth call for testing, and it will all be about the theme.json file.

So as soon as it’s out, I will share a link in the show notes. And of course, also if you subscribed to our Gutenberg Times newsletter, you will definitely be informed about that. So at this point, I only have two more questions for our panelists. So do you have any announcements that you couldn’t get out before and you want the people to keep in mind? And if people want to get in touch with you, what would be the best way. Tammie, you want to start?

Tammie Lister: Yeah. So I’m comatose in all the things. I’m pretty easy to find in a good way. And I love chatting to people. So please do. I think my thing to say would be remember all of what happening now you can help shape. Just because we’ve sat here talking about it doesn’t mean we know anything more than you? It just means we’ve poked it and we’ve played around with the code. 

So do that. Start exploring it. And it’s a lot more accessible than it ever was. It’s starting to be more accessible. There’s more documentation than there ever was coming out. And if you care about what happens with themes or you ever cared about what happens to themes, and maybe you could have that reignited, start to join the conversation. And I guess my final point would be, I think my hope is to see this experimentation come back to themes. 

I think we forgot about that a little bit and we need to have some fun again in these. We used to have so much fun in WordPress themes, and I look forward to not just themes to have a purpose, but just themes that are art, themes that are just wacky experiments, and start enjoying theming and make some art. I’m really excited to see what things people create and use them just for one day even. That’d be amazing.

Birgit Pauli-Haack: Yeah. So Jeff, anything you want to have people keep in mind, and how to get in contact with you.

Jeff Ong: Yeah. Contact at J-F-F-N-G. And I guess keeping in mind, I’m just building on the last thing Tammie said, perhaps find a way to have fun with it and get curious about it, and try it. There’s really to me, a fundamental tendance of learning about something or you just have, how do I get curious about this thing? How do I play with it and have fun? And that’s going to be the most important thing to keep in at the center.

Birgit Pauli-Haack: Thank you, Jeff, and thank you so much for the audio work on the demo. Daisy.

Daisy Olsen: I’m Daisy Olsen on most things, Olsen with an E, and I would say that as far as what you can do as the next step if you’re interested in learning more about this, is go to… I’m pretty sure that Birgit has a link to this somewhere, the theme experiments repository on GitHub in the WordPress space has things that other people have done or are working on. 

So I love to see examples of something in action to help me learn more about it and to see what other people have done. So I would say go check out something.json files in there and see what people have come up with.

Birgit Pauli-Haack: Awesome. Thank you so much. So big thank you to Daisy, Jeff, and Tammie to come today and make your time. A big thank you also for the viewers with all your great questions. I think we got a great array of it. And if you have more questions, you can always send them to me via email to pauli@gutenbergtimes.com, and I’ll get you the answers.

And the recording of the show will be available in a few minutes on our YouTube channel. And I’ll share all the links then also in the video description. And within a few days, we will have also a transcript that we will publish on the Gutenbergtimes.com. So be well, good-bye, and good luck. That was fun. Thank you.

Jeff Ong: Thank you, everyone.

WPTavern: Major Revamp Coming to GitHub Issues

Wordpress Planet - Sat, 06/26/2021 - 03:49

This week GitHub unveiled new features that will be included in a total revamp of GitHub Issues, including project tables that are similar to spreadsheets, custom fields, a keyboard driven command palette, improved task lists, and issue forms. The new project table view is an alternative to project boards, allowing users to filter, sort, and group issues and pull requests. Project managers can customize the table with custom fields and saved views.

GitHub is also making it easier to manage issues that include subtasks. Users can now add lists and the issue will automatically track the status with a progress indicator.

Issues forms are now in beta for public repositories. Many open source projects currently use Markdown issue templates and encourage contributors to provide more details by removing the placeholder text and replacing it with their own. Maintainers can now set up YAML configured forms with required fields and instructions to better guide the process.

The revamped Issues feature is being updated to provide a bridge between the planning tools and the problems the tools were created to solve. Mario Rodriguez, Head of Product for GitHub Enterprise, explained why they are evolving GitHub Issues in the beta announcement:

As teams and projects grow, the way you work evolves. Tools that hard-code a specific methodology are too rigid and complex to flex to whatever the moment demands. Often, we find ourselves creating a spreadsheet or pulling out a notepad, just to have the freedom to think. But then our planning is disconnected from where the work happens and quickly goes stale.

The WordPress project hasn’t yet moved away from Trac but most of Gutenberg development happens on GitHub. It’s also the most popular repository hosting site for WordPress theme and plugin authors. Contributors to these projects may soon see some of these features in action for personal accounts and organizations that opt into the beta.

The new GitHub Issues is expected to be out of beta later this year. GitHub plans to bundle it for free, along with the new project planning capabilities, with its Free, Pro, Team, and Enterprise plans.

WPTavern: Major Revamp Coming to GitHub Issues

Wordpress Planet - Sat, 06/26/2021 - 03:49

This week GitHub unveiled new features that will be included in a total revamp of GitHub Issues, including project tables that are similar to spreadsheets, custom fields, a keyboard driven command palette, improved task lists, and issue forms. The new project table view is an alternative to project boards, allowing users to filter, sort, and group issues and pull requests. Project managers can customize the table with custom fields and saved views.

GitHub is also making it easier to manage issues that include subtasks. Users can now add lists and the issue will automatically track the status with a progress indicator.

Issues forms are now in beta for public repositories. Many open source projects currently use Markdown issue templates and encourage contributors to provide more details by removing the placeholder text and replacing it with their own. Maintainers can now set up YAML configured forms with required fields and instructions to better guide the process.

The revamped Issues feature is being updated to provide a bridge between the planning tools and the problems the tools were created to solve. Mario Rodriguez, Head of Product for GitHub Enterprise, explained why they are evolving GitHub Issues in the beta announcement:

As teams and projects grow, the way you work evolves. Tools that hard-code a specific methodology are too rigid and complex to flex to whatever the moment demands. Often, we find ourselves creating a spreadsheet or pulling out a notepad, just to have the freedom to think. But then our planning is disconnected from where the work happens and quickly goes stale.

The WordPress project hasn’t yet moved away from Trac but most of Gutenberg development happens on GitHub. It’s also the most popular repository hosting site for WordPress theme and plugin authors. Contributors to these projects may soon see some of these features in action for personal accounts and organizations that opt into the beta.

The new GitHub Issues is expected to be out of beta later this year. GitHub plans to bundle it for free, along with the new project planning capabilities, with its Free, Pro, Team, and Enterprise plans.

WPTavern: Major Revamp Coming to GitHub Issues

Wordpress Planet - Sat, 06/26/2021 - 03:49

This week GitHub unveiled new features that will be included in a total revamp of GitHub Issues, including project tables that are similar to spreadsheets, custom fields, a keyboard driven command palette, improved task lists, and issue forms. The new project table view is an alternative to project boards, allowing users to filter, sort, and group issues and pull requests. Project managers can customize the table with custom fields and saved views.

GitHub is also making it easier to manage issues that include subtasks. Users can now add lists and the issue will automatically track the status with a progress indicator.

Issues forms are now in beta for public repositories. Many open source projects currently use Markdown issue templates and encourage contributors to provide more details by removing the placeholder text and replacing it with their own. Maintainers can now set up YAML configured forms with required fields and instructions to better guide the process.

The revamped Issues feature is being updated to provide a bridge between the planning tools and the problems the tools were created to solve. Mario Rodriguez, Head of Product for GitHub Enterprise, explained why they are evolving GitHub Issues in the beta announcement:

As teams and projects grow, the way you work evolves. Tools that hard-code a specific methodology are too rigid and complex to flex to whatever the moment demands. Often, we find ourselves creating a spreadsheet or pulling out a notepad, just to have the freedom to think. But then our planning is disconnected from where the work happens and quickly goes stale.

The WordPress project hasn’t yet moved away from Trac but most of Gutenberg development happens on GitHub. It’s also the most popular repository hosting site for WordPress theme and plugin authors. Contributors to these projects may soon see some of these features in action for personal accounts and organizations that opt into the beta.

The new GitHub Issues is expected to be out of beta later this year. GitHub plans to bundle it for free, along with the new project planning capabilities, with its Free, Pro, Team, and Enterprise plans.

WPTavern: FSE Outreach Round #8: A Developer-Centric Call for Testing Theme JSON Configuration

Wordpress Planet - Sat, 06/26/2021 - 03:30

Round #8 of the Full Site Editing (FSE) Outreach Program began yesterday. Instead of the user-centric call for testing features from the UI, program lead Anne McCarthy asks that volunteers dive into code. The new adventure is all about testing theme.json files.

The twist is likely to limit the pool of usual volunteers. However, it could open it up to an audience that may have been sitting on the sideline for the previous tests: theme developers.

Before jumping headfirst theme JSON files, we should probably all get on the same page.

I have been calling theme.json the tipping point between the old WordPress and the new WordPress. When version 5.0 of the core platform launched in late 2018, it was a revolutionary step forward, but not on the surface. A new editor is just a new editor. Some will love it; others will hate it. And, it was more often clunky than not. For the most part, WordPress was still WordPress.

The core software was due for an upending. Newer technologies were not only democratizing publishing in their own ways, but they were also bringing that same concept to design.

The introduction of blocks was merely foundational. The new editor was an imperfect tool, often feeling like the proverbial round peg being shoved into a square hole.

The only way to live out the early vision of the Gutenberg project was to continue bridging the gap between what the user sees in the admin and what gets output on the front end. That is what the theme.json file is all about. It is a translator that allows users, themes, and WordPress to all speak the same language.

What does this mean exactly?

From a user’s viewpoint, they see all sorts of controls for changing their blocks. Color, font size, alignment, and other options are tools that allow them to customize their content.

Customizing a profile card for my cat using block options.

There are severe limitations with what is possible in the current system. Theme authors can register a handful of options. Outside of that, the theme and block systems can feel like they are pitted against each other for control.

That is where the theme.json file comes in. It allows themes and WordPress to get on the same page, creating a standardized system that improves the user experience.

This file that lives a theme’s root folder hands over the power to configure dozens of presets (e.g., color and font options), custom CSS properties, and default styles for blocks and HTML elements.

It also gives themers the power to enable or disable specific features. For example, developers can turn off the ability for users to set a custom font size but provide access to their perfect scale of choices that fit into the design’s vertical rhythm.

However, it will move beyond the simple configuration of blocks in the content editor. When the global styles system launches alongside the site editor in the future, users will customize many of the presets and overwrite the default block styles. Because everyone is speaking that same language, fewer conflicts arise.

As designer Tammie Lister pointed out in her piece for Ephermeral Themes, Theme.json inspires, themes have been stuck. The software, the community, has put too much responsibility on the shoulders of themers over the years. They have had to innovate and build the systems that should have been coming from WordPress. Not only did the core platform need to be turned on its head, but the design system deserved an overhaul.

“I am very aware that saying ‘first major theme process to core’ in years is quite a statement,” wrote Lister. “Theme.json to me is that though. I don’t say this ignoring iterations and improvements, WordPress is a project flowing with the energy of those. However, themes were on life support stuck in a land when the rest of front end development was moving on. It wasn’t for some trying to change that, mostly when they did the time wasn’t right and as it didn’t come from core it was always a harder change.”

It is time for a new front-end design era. But, first, we must test.

Testing Theme JSON Real-world theme.json file.

The more I journeyed into this call for testing, the more I realized it did not feel right for me. Over the past couple of months, I have already been in the thick of working from the theme.json file. I know most of the little quirks and see the gaps. The tricks for working with it feel second nature to me.

I have performed all of the beginner and intermediate steps dozens upon dozens of times. I have already filed tickets for any issues I have run into. Or, someone else has already beat me to the punch.

Those stages of this testing round need fresh eyes. The best feedback will be from theme authors who will be viewing the problems through a different pair of lenses. If you are in this group, there is no time like the present to test and provide feedback.

The advanced stage calls for recreating a classic theme using theme.json. It is best to stick with something simple. Otherwise, you could be looking at a weeks-long experiment. McCarthy recommends Twenty Twenty or Storefront. I have already been performing this song and dance too. My test project was an old theme that I gutted and turned into a block theme.

There is one overarching issue that I keep coming back to. It is that theme authors must work from a JSON file at all.

I understand the “why” behind using JSON. It is a universal format that we can pass around from JavaScript to PHP. Third-party APIs can understand it.

However, I am currently sitting on top of 900+ lines of code in my theme.json. I have heard from a couple of other theme authors who have been doing deep work with similar numbers. I expect it to only grow.

“Number of lines” is not necessarily some metric where a specific total is a dividing point between “good” or “bad.” The problem is that comments are not allowed in JSON files. One of the cornerstones of sound development is documenting code. Skipping out on documentation of a few dozen lines is not so bad. However, when you speed past 900, things can get out of hand.

Plus, at a certain point, you start wanting to split pieces into their own groups. This much code is begging for better organization.

The thing that is currently missing is a PHP layer for theme authors to use. Remember, JSON is a universal format. It is easy to convert PHP to JSON and vice-versa. Building in this layer for theme authors would accomplish two things:

  1. They can organize what will likely be 1,000s of lines of code.
  2. It will be easier to transition to the new system.

The latter point is likely the most salient. PHP has been the language of theming since the theming has been around. Developers know it and are comfortable using it, and WordPress should meet them in the middle. If we are closing gaps, this is the one that needs filling before more configuration possibilities are added and theme.json files balloon into unwieldy, 5,000-line behemoths.

WPTavern: FSE Outreach Round #8: A Developer-Centric Call for Testing Theme JSON Configuration

Wordpress Planet - Sat, 06/26/2021 - 03:30

Round #8 of the Full Site Editing (FSE) Outreach Program began yesterday. Instead of the user-centric call for testing features from the UI, program lead Anne McCarthy asks that volunteers dive into code. The new adventure is all about testing theme.json files.

The twist is likely to limit the pool of usual volunteers. However, it could open it up to an audience that may have been sitting on the sideline for the previous tests: theme developers.

Before jumping headfirst theme JSON files, we should probably all get on the same page.

I have been calling theme.json the tipping point between the old WordPress and the new WordPress. When version 5.0 of the core platform launched in late 2018, it was a revolutionary step forward, but not on the surface. A new editor is just a new editor. Some will love it; others will hate it. And, it was more often clunky than not. For the most part, WordPress was still WordPress.

The core software was due for an upending. Newer technologies were not only democratizing publishing in their own ways, but they were also bringing that same concept to design.

The introduction of blocks was merely foundational. The new editor was an imperfect tool, often feeling like the proverbial round peg being shoved into a square hole.

The only way to live out the early vision of the Gutenberg project was to continue bridging the gap between what the user sees in the admin and what gets output on the front end. That is what the theme.json file is all about. It is a translator that allows users, themes, and WordPress to all speak the same language.

What does this mean exactly?

From a user’s viewpoint, they see all sorts of controls for changing their blocks. Color, font size, alignment, and other options are tools that allow them to customize their content.

Customizing a profile card for my cat using block options.

There are severe limitations with what is possible in the current system. Theme authors can register a handful of options. Outside of that, the theme and block systems can feel like they are pitted against each other for control.

That is where the theme.json file comes in. It allows themes and WordPress to get on the same page, creating a standardized system that improves the user experience.

This file that lives a theme’s root folder hands over the power to configure dozens of presets (e.g., color and font options), custom CSS properties, and default styles for blocks and HTML elements.

It also gives themers the power to enable or disable specific features. For example, developers can turn off the ability for users to set a custom font size but provide access to their perfect scale of choices that fit into the design’s vertical rhythm.

However, it will move beyond the simple configuration of blocks in the content editor. When the global styles system launches alongside the site editor in the future, users will customize many of the presets and overwrite the default block styles. Because everyone is speaking that same language, fewer conflicts arise.

As designer Tammie Lister pointed out in her piece for Ephermeral Themes, Theme.json inspires, themes have been stuck. The software, the community, has put too much responsibility on the shoulders of themers over the years. They have had to innovate and build the systems that should have been coming from WordPress. Not only did the core platform need to be turned on its head, but the design system deserved an overhaul.

“I am very aware that saying ‘first major theme process to core’ in years is quite a statement,” wrote Lister. “Theme.json to me is that though. I don’t say this ignoring iterations and improvements, WordPress is a project flowing with the energy of those. However, themes were on life support stuck in a land when the rest of front end development was moving on. It wasn’t for some trying to change that, mostly when they did the time wasn’t right and as it didn’t come from core it was always a harder change.”

It is time for a new front-end design era. But, first, we must test.

Testing Theme JSON Real-world theme.json file.

The more I journeyed into this call for testing, the more I realized it did not feel right for me. Over the past couple of months, I have already been in the thick of working from the theme.json file. I know most of the little quirks and see the gaps. The tricks for working with it feel second nature to me.

I have performed all of the beginner and intermediate steps dozens upon dozens of times. I have already filed tickets for any issues I have run into. Or, someone else has already beat me to the punch.

Those stages of this testing round need fresh eyes. The best feedback will be from theme authors who will be viewing the problems through a different pair of lenses. If you are in this group, there is no time like the present to test and provide feedback.

The advanced stage calls for recreating a classic theme using theme.json. It is best to stick with something simple. Otherwise, you could be looking at a weeks-long experiment. McCarthy recommends Twenty Twenty or Storefront. I have already been performing this song and dance too. My test project was an old theme that I gutted and turned into a block theme.

There is one overarching issue that I keep coming back to. It is that theme authors must work from a JSON file at all.

I understand the “why” behind using JSON. It is a universal format that we can pass around from JavaScript to PHP. Third-party APIs can understand it.

However, I am currently sitting on top of 900+ lines of code in my theme.json. I have heard from a couple of other theme authors who have been doing deep work with similar numbers. I expect it to only grow.

“Number of lines” is not necessarily some metric where a specific total is a dividing point between “good” or “bad.” The problem is that comments are not allowed in JSON files. One of the cornerstones of sound development is documenting code. Skipping out on documentation of a few dozen lines is not so bad. However, when you speed past 900, things can get out of hand.

Plus, at a certain point, you start wanting to split pieces into their own groups. This much code is begging for better organization.

The thing that is currently missing is a PHP layer for theme authors to use. Remember, JSON is a universal format. It is easy to convert PHP to JSON and vice-versa. Building in this layer for theme authors would accomplish two things:

  1. They can organize what will likely be 1,000s of lines of code.
  2. It will be easier to transition to the new system.

The latter point is likely the most salient. PHP has been the language of theming since the theming has been around. Developers know it and are comfortable using it, and WordPress should meet them in the middle. If we are closing gaps, this is the one that needs filling before more configuration possibilities are added and theme.json files balloon into unwieldy, 5,000-line behemoths.

Pages