Theme Review Team

Keyboard Shortcuts | Hide comment threads

Theme Review Team Meeting Agenda for February 25

Theme review team (TRT) conducts a meeting on the second and fourth Tuesday of the month. Along with the fixed agendas, we have open floor meeting at the end where you can ask or share anything related to themes.

We encourage all members and anyone interested to attend.

Channel: #themereview | Time: Tuesday, 25th February 2020, 18:00 CET

Meeting Agenda

  1. Weekly updates
  2. Recap of the online contributor day
  3. Removal of the Featured themes tab in the theme directory
  4. Full Site Editing Road map: Requirements for block based themes
  5. Open Floor

The discussion about the meeting agenda can be held in the comments below. You are encouraged to propose the topic for the agenda.

Meetings usually last around 60 minutes. Attend and share your valuable feedback and suggestions.

Block-Based Themes chat summary: 19 Feb 2020

This post summarizes the latest bi-weekly Block-Based Theme meeting, held in the #themereview Slack, on Wednesday, February 5, 2020, 16:00 UTC. These meetings coordinate collaboration in the development evolution of the Gutenberg project as related to development of Block-Based Themes geared to support Full Site Editing. Moderated by @kjellr.

Important Project Links

Global Styles Update

@kjellr Some recent full-site editing work affects themes. The first one is this PR 20047 by @nosolosw — Consolidate overall Global Styles mechanics in the server. This PR is a foundational step for the Global Styles work. It lets themes start specifying global values in  experimental-theme.json file. There are a couple example PRs in the `theme-experiments` repository to show how that would work. Technically, what this all does is convert the JSON into CSS variables, which will be able to change on the fly from in the Global Styles interface. It’s still very early, but it’s a good time to take a look and discuss in GitHub PR 17  and  PR 22

Speaking of the Global Styles interface I’d like to highlight PR 20061 by @itsjonq which introduces an initial interface for Global Styles in the beta site editor. Everything lives within a single sidebar for now. Like the Gutenberg PR noted above, this is an early foundational piece. It’s a good starting point for later work.

New Full-Site Editing Blocks

@kjellr These will all come in handy for block-based themes. Many of these have been merged in already, but I wanted to list them all so that we’re all up to date. These are already available for use in block-based themes.

Some of the new blocks that have been merged in recently include:

  • Post Title
  • Post Content
  • Post Excerpt
  • Post Author
  • Post Date
  • Post comments form
  • Post comments count
  • Post comments
  • Featured Image

The post tags one is still in the works. Here’s a good place to follow along.

Semantic Tags in Gutenberg Blocks

@kjellr  There’s also an effort going on to figure out how Gutenberg blocks should render semantic tags like <header>, <main>, <section>, <aside>, and <footer>. This is a great structural question allowing blocks to render semantic tags for full-site editing.  Follow along here at Issues 20200. There’s already a PR as well.

Query Block

@kjellr  A major new block that’s being worked on is the Query block – PR 20106. This will be the driving force behind archive pages or really anything with a list of posts on it. The query block is the equivalent of the loop.

Theme Demo: Go

This is a time for us all to learn a bit about how others are building block-friendly themes today. @richtabor is going to tell us a bit about how and why the Go theme uses CSS variables, and how that made it easier to style blocks.

@richtabor I’m here to share about the Go Theme from my team at GoDaddy: why we made it, what’s now possible with Go (and potentially core themes in the future), and how it works. We wanted to develop an experimental design system where folks may easily adapt Go by modifying, or even add a whole new style. Pretty much an initial concept of what Global Styles is aiming for. This means that with WordPress, one theme (Go), and one plugin (CoBlocks – though you don’t have to use a block plugin) – you can make all the themes here. Some of my favorite website demos are:

Now onto how the design styles work. Currently we’re leveraging the Customizer for much of the heavy lifting of the user-facing design choices – though we’ll migrate the theme to global styles as soon as it’s stable. We provide five different design styles, which can be swapped out at any time. These design styles are built using CSS variables (custom properties) and are defined within the theme – although are easily manipulated anywhere (as the nature of CSS variables). And we do have fallbacks in place, so not every variable needs defining within a design style – making things simple to manipulate

Here’s an example of what the Modern design style looks like in code:

:root {

    /* Content width */
    --go--max-width: 38rem;
    --go--max-width--alignwide: 90rem;

What’s particularly great about using CSS variables is that these style declarations are not only easily manipulated/overwritten when necessary but they’re easy enough to provide within the block editor, making one-to-one visual editing MUCH simpler to implement. Here’s a look to the screen shot in Slack into the editor of the same website I previewed in the Customizer above. Pretty much one-to-one visually

Global Styles will be defined a bit differently, although in theory — they should perform similarly to what we have in Go — a set of declarations that define a site’s design that may be overwritten by the end user. It’s not block-based yet, but an experiment of what global styles could be capable of. We’ll port over to FSE and global styles as soon as it’s stable.

If we extend the idea of Global Styles a bit more, like the following experiment, perhaps WordPress makes way for something like this in core

In this video, we’re declaring a site’s spacing/rhythm using a singular control. Note that the control/UX in the experiment above is just to show how setting spacing could work in theory, not how we’ll implement it at all.

So that’s what we’ve been working on, experimenting on a design style system that’s portable, easily manageable, but ultimately empowers folks to publish beautiful websites that looks and feels right to them.

Transitioning Legacy Themes

@aristath discussed ideas for transitioning older themes to block-based themes. He published a great post. While experimenting with block-based themes it’s becoming more and more clear that there is no easy way for themes to be “updated” to take advantage of FSE. It’s either a new theme or nothing. And though that’s OK looking 5 years in the future, it’s not OK for businesses and authors that have spent countless hours building solid products and a user base of thousands. There are 2 ways to look at this situation:

  • It is an opportunity to start fresh. No baggage, no nothing. It’s a new beginning for everyone – which will benefit new authors.
  • No way forward for existing themes – which is bad for existing authors.

That’s not to say that existing themes MUST convert to block-based. They will surely continue to work the way they are for many years. But some themes will definitely want to. And we want to avoid issues of the past where every theme tries to reinvent the wheel and 90% of them are doing it wrong. That’s why we’re suggesting in that post that a library be built, allowing themes that wish to upgrade to do it in a consistent fashion, using a method that we properly test and implement.

We’d love your feedback on the post so we can figure out how to move forward. It won’t be an easy task, but we feel a lot of existing theme authors will benefit from something like that. So far there is no code to look at, just ideas and experiments, so feel free to share your thoughts 

Q & A

CSS vars are becoming the norm, so we should encourage them. But so far I don’t think we dropped IE11 support. What about that?

@dingo_d

@richtabor IE 11 support is tricky. We do have fallbacks in place – also utilizing polyfills – though the end result is not the best.

@johnstonphilip There was a lot of discussion on polyfills for IE 11 in this GitHub Issue 19611 My understanding of the takeaway there is that ie11 should work, but it doesn’t have to be pretty

@kjellr There’s also some relevant discussion that happened in the CSS Meeting in #core-css last week.

@aristath Saying a theme “supports” IE11 is not the same as saying that IE11 will display things the same way a less-than-10-year-old browser will display them. The way most of us treat IE is that things need to function properly, users must be able to use the site and interact with it. But if the color scheme for example is not the same or the paddings are different because css-vars are not supported then I’m fine with that. Most users are.

I was building my first block based theme today. The site title block is not fully developed yet? I don’t understand either what will happen with translations.

@acalfieri

@kjellr The site title block should be available as of today PR 17207

Are there any plans for dropping IE11 support in the near future?

@acosmin

@dingo_d There was a discussion in meta regarding dropping IE support, and we cannot do that completely (not for a number of years at least) because some companies are pretty much tied down to use IE (corporate mostly).

@kjellr  In general, it sounds like the IE11 question doesn’t have an answer yet, but folks are all in agreement that some sort of fallback is required.

Reading through the migration proposal from @aristath this still has theme authors creating site templates in Gutenberg and then copy/paste the resulting block code. What is the point in the migration/script if that is the exact same process for creating a Block Based theme? Before running the migration, it seems a new theme has been created, no? The “migration” simply takes into account existing user settings. Simple example: If on my current theme I have defined that the background-color of the copyright area is red, then I want on the new version my background-color to remain red.

@BMO

@aristath The “migration” simply takes into account existing user settings. Simple example: If on my current theme I have defined that the background-color of the copyright area is red, then I want on the new version my background-color to remain red.

What’s the benefit of using an API approach shown by @aristath instead of just adding a header.html template in the old theme?

@kjellr 

@aristath  Your theme will still have a header.html. But in your header.html you’re defining the initial state of the header, correct? So basically what users see when they first install a theme, with its default settings. But on my site I don’t use the defaults… I went in the customizer and changed colors, font-sizes or whatever other settings my theme has. When I update the theme on my site, it should not reset everything. That’s where the “migration” part comes in. It will help users of existing themes not lose their settings when/if they update a theme.

@kjellr Ah ok, I think that makes sense. I think that’s something global styles would solve though, right? Since you’d specify those new colors/font sizes/etc via global styles too? Or I guess with your approach, you could not have to do that?

@aristath it depends…. If I have a setting on my theme “Top-header/Side-Header”, then the structure of the blocks would change. A migration could take care of that if the theme-author writes if this setting is set to side-header, then inject this template

@allancole  What was the process used in the Go theme to determine which style rules would be CSS-variable-ized? And related to that, what happens when replacing the available variables isn’t enough to achieve a certain design? Can the variables be extended or do you resort back to normal CSS?

@allancole 

@richtabor  Customizer settings will likely have to be mapped into styles manually (other than core defined settings) Most design-level choices are variables, though fallbacks are available on most variables so that each design styles doesn’t have to have a lot of variables designed – only what they need.

Have there any conversations around having a block based theme’s .html files listed in `Admin -> Appearance -> Templates`? This would make it easier for a user to open a copy/clone of the template, make their changes, then save as a new template override. Right now, a user would have to know the name of the .html file, create a new template with the same slug, then start from scratch. I also know that the Beta Site Editor is solving for parts of this, but is there value in seeing all of the templates listed out?

@BMO 

@kjellr  I could be wrong, but I think that’s the goal. I’m pretty sure I saw a PR about that and for Template Parts. I think discussion is here Issues 20252 I also checked with @epiqueras, who noted that the Appearance sections are just for development. Eventually this will all be available contextually within the full-site editing UI. I believe “Appearance” > “Templates” is just a temporary home.

We covered a lot of new template blocks but what about navigation? It is in the plugin (experimental) but using it is still not a good user experience. Is this planned for later than 5.4 release?

@dingo_d

@kjellr  There is a lot of iteration planned for that block which is part of the reason it was left out of the upcoming release. See the full post here. 

The next meeting is Wednesday, March 4, 2020, 16:00 UTC.

A plan to ease transition to block-based themes

2 weeks ago we had our first meeting for the future of WordPress themes, also known as block-based themes. In that meeting, we discussed how future themes will be structured and touched on the way they can be built.

The future is bright, but there are thousands of themes that are not built as block-based themes. These will continue to function properly for years, WordPress has always been a platform that embraced backwards-compatibility and very rarely (if ever) deprecates functionality.

It is inevitable that some existing themes will want to take advantage of the new structure and benefits that Full Site Editing has to offer. The problem is that it is a significantly different implementation to what we currently use, and there is no easy way to transition to that new structure.

This is where this post comes in: Figuring out a plan to ease the transition to block-based themes in a way that makes sense. Start a discussion with theme-authors and find a way to move forward.

Current WordPress themes use PHP templates and a lot of settings in the Customizer to define colors, typography options, settings that change the markup of some areas etc. Future themes, however, will not have PHP templates. Instead, templates will be defined in .html files containing a “preset” for how blocks will be arranged on the screen. Users will be able to override these “presets” and edit them in their editor. Most of the Customizer’s duties will be handled by the global-styles implementations currently being worked-on in Gutenberg.

So, how do we ease migrating from hardcoded PHP templates to a blocks structure?

As a first idea, we have started experimenting with code that will allow authors to define an upgrade path. So if they have a simple header that has the following components:

  • Green background
  • White text
  • Site-logo on the left
  • Navigation on the right

then that could be translated to the editor as a group block with green background and white text, containing 2 columns; In the 1st column we can have the site-logo block and on the 2nd column a navigation block.

A theme author wanting to transition to a blocks-based structure would do something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
/**
 * Return markup with blocks.
 *
 * Takes existing settings and migrates them to a blocks structure.
 *
 * @return string
 */
function mytheme_get_header_blocks_migration_markup() {
 
    // Open group block.
    $open_group = '<!-- wp:group {"backgroundColor":"' . get_theme_mod( 'header_background', '#fff' ) . '","textColor":"' . get_theme_mod( 'header_text_color', '#000' ) . '","align":"full"} --><div class="wp-block-group alignfull has-text-color has-background"><div class="wp-block-group__inner-container">';
 
    // Open columns block.
    $open_columns = '<!-- wp:columns --><div class="wp-block-columns">';
 
    // Build 1st column.
    $first_column = '<!-- wp:column {"width":33.33} --><div class="wp-block-column" style="flex-basis:33.33%"></div><!-- /wp:column -->';
 
    // Build 2nd column.
    $second_column = '<!-- wp:column {"width":66.66} --><div class="wp-block-column" style="flex-basis:66.66%"></div><!-- /wp:column --></div>';
 
    // Close columns & group.
    $closer = '<!-- /wp:columns --></div></div><!-- /wp:group -->';
 
    return $open_group . $open_columns . $first_column . $second_column . $closer;
}
 
// Migrate header template-part.
new \WPTRT\Blocks_Migration( [
    'content' => mytheme_get_header_blocks_migration_markup(),
    'slug'    => 'header',
] );

The above code is a simple and incomplete example, but it does show the basis of this idea:
We created the structure we needed in the editor using core blocks.

Then we switch our editor from “Visual Editor” to “Code Editor”, and we have our blocks code there. We can take that code, put it in a function and replace the variables we need. In our case that meant using the header_background and header_text_color settings, retrieved using get_theme_mod(). In our example theme we can then remove these settings from the Customizer since they will now be controlled from the blocks.

After the author creates the blocks-based markup, they can call the migration class. When this class runs in our example, it will do the following:

  1. Check if there is a template-part with the slug we have defined.
  2. If a template-part with that slug exists, then exit early, there’s nothing to do here since either the user has created their own header (in which case we don’t want to overwrite it), or the migration has already run. If a template-part with the defined slug does not exist, then move on to the next step.
  3. Create a new template post (that is a post in the templates custom post-type that full-site editing will use), and add the contents in there.

Once the migration script creates the header template-part post, that is going to override the “preset” .html template that we have in our theme.
When a user first installs the theme (new installations), they will use the preset (which will contain the defaults and is a basis which users can then customize).
When a user upgrades their installation to the blocks-based version, the theme will retrieve their Customizer settings, build the markup based on what the author has written and created the post which will override the “preset”.

Most things that themes use already exist as blocks in core, or are getting added to make the Full-Site Editing easier.
But there will be things that cannot be directly ported.
One of these things is widgets. Since core widgets already exist as blocks, it is possible to translate them to that new structure. However 3rd-party widgets that don’t exist as blocks will not be easy to be auto-detected and translated.

So far we are running some tests with simple structures and we can say that it is possible to build something to ease transitioning existing themes to block-based themes. But before we start building a proof of concept implementation that we can iterate on and experiment with, we need your assistance and feedback.

What are the things that you feel Full-Site editing would need to have in order for theme-authors to be able to build themes?

If you have ideas on how to ease the transition from widget-areas to blocks, we’d love to hear them.

Other than non-core widgets, do you foresee issues with converting existing themes to block-based?

The biggest question to me is why? Why do we need to migrate old themes? Why we can’t just start creating new block-based themes?

Of course you can start building new block-based themes, and there is no need to migrate old themes.
However, some people/businesses have invested years building their themes and their brand. These people will probably want to make the transition to block-based themes without losing their current user-base.
There is no need to transition to block-based themes. But there is (or rather will be since block-based themes are still a WIP and experimental) the desire from many theme-authors to do so, and it is our responsibility and privilege to help.

It’s great to see work on a migration process. Thanks for sharing these ideas, for the proposed migration API, and for reaching out for feedback. It’s great that this is being developed in the open.

New themes vs upgrades
I’m from the Genesis team, and — even though it’s early days and we’re still making plans for full site editing — our current migration path centered around installing new block-based themes with full site editing support, rather than upgrading existing themes.

It’s not realistic for theme developers to promise users that we’ll be able to map existing theme sections and hard-coded PHP templates to blocks in the way this post proposes.

We cannot say, “we’ll migrate your templates automatically” because users edit their themes directly (by editing the source) and indirectly (via parent themes, plugins, the Additional CSS section, and more).

At best, theme developers can only hope to map the original theme structure to blocks. We can’t guess how that content may have been edited or modified externally, so any migration callbacks may not be true to the current state of the site.

What if users could be guided through the migration instead?
Is there a genuine need for an upgrade and migration path at the theme level where theme developers attempt to auto map content to blocks? Or could the migration path look more like:

  • Theme authors create new themes with full-site-editing theme support.
  • Users switch to that theme.
  • A “Welcome to Full Site Editing” page educates the user about what’s new and how they now edit parts of their site. This could display a list of widget areas from their old theme and explain how to migrate them to block areas.
  • We provide tooling to import widgets into block areas where possible, and prompt users to do this from the “Welcome” page, and when they first edit a block template or template part.

This has several benefits:

  • It gives control to users.
  • It teaches users how full site editing works at a time when they care to have that info (“I’ve just switched theme; how do I edit parts of my site now?”).
  • It reduces the burden on theme developers to provide a magical migration path and to support automated migrations that go badly.
  • It gives the WordPress community a consistent migration story: “to get started with full site editing, switch to a theme with full site editing support and follow the guide at Dashboard → Full Site Editing”.
  • Theme authors don’t have to maintain a single codebase with support for “classic” sites and full site editing. (There are several challenges with this, like providing documentation for both user types, and for trying to develop and maintain approximate feature parity between the two models that now live as one mutant theme.)

It has some downsides too:

  • The user may have to do more work and be willing to learn. (At least by making this a theme switch instead of a theme upgrade, they may be more educated about the differences. They won’t upgrade a WP.org theme as part of general maintenance and suddenly learn that everything has changed and they no longer know how to edit their site.)
  • The site may not display as it originally did while the user is migrating widgets and other areas.
  • Can a WP.org theme dev with a non-block based theme create a new block-based one while maintaining the old one, but keep the theme name if they choose to? (Or would they be forced to create a new name and slug for their block-based theme?)

Overall, though, users know better than theme developers how they want their website to look and function. If the purpose of full site editing is to give users full control over their sites, let users have full control of their sites, starting with the migration process.

Guiding users through the migration process does make a lot of sense. Thank you for sharing your insights 🙂

This is a good idea, but I’d be careful with stabilizing an API like this until we have a much better understanding of theme needs in the wild.

Non-supported widgets can use the Legacy Widget block.

This is a good idea, but I’d be careful with stabilizing an API like this until we have a much better understanding of theme needs in the wild.

So far it’s just an idea, we wanted to get feedback from the community before we commit to something like this.
It’s not so much an API… more like a simple class that will do the following:

  • Check if a post in the defined post-type exists with the slug we want to create
  • Add a new post in the templates post-type if it doesn’t already exist, with the content that authors define.

That’s all… The theme-authors will be responsible for actually writing the contents of the migrated templates, and that will be the same no matter what happens. I mean in 90% of themes the “copyright-area” in the footer can be interpreted as a group block with a background-color and a paragraph block inside that, usually with text coming from a customizer option.

Of course it’s too soon to tackle headers etc, things are still very fluid. But we can start thinking of ways to implement things and be prepared 🙂

Non-supported widgets can use the Legacy Widget block.

I must have missed that one, I didn’t even know it existed. That’s perfect!

This needs to live in text files based in the theme. Encoding the string inside the PHP will get real messy fast. If there were also a built-in way to update these blocks via Gutenberg, then devs/designers could test and save the blocks out.

Without this, it will become just as riddled with pain as the current template process.

Oh definitely… In most cases it’s likely it will simply use the .html templates that themes will have anyway. The snippet posted was simply an example to convey the logic, not an actual implementation. 🙂

Block-based Themes Meeting Agenda for February 19

Below is the agenda for this week’s Block-based Themes meeting.

Time: Wednesday, February 19th 2020, 16:00 UTC
Channel: #themereview

Agenda

  • Welcome
  • Status updates for Block-based Theme efforts in Gutenberg:
  • Show & Tell: Block styling with CSS variables in the Go theme (@richtabor)
  • Questions & Discussion

If you have any questions you’d like to see raised at this week’s meeting, or any topics or demos you’d like to see in future meetings, please share below.

We also need a volunteer to take notes!

#agenda

The title says Feb 17, the time says Feb 19.
Can you pick one?

Theme Review Day – The theme review team is planning for an online contributors day

As we all know that, WC Asia 2020 is canceled due to fear of the spread of the disease caused by the new coronavirus COVID-19. 

Contributors’ day for the WC Asia 2020 was scheduled for Friday, February 21. The theme review team did lots of preparation to make it awesome. Unfortunately, we are not able to apply those ideas this time.

The theme review team is planning for an online contributors day for themes on the same day. In the online presence of Moderators and Reps, reviewers from all around the globe can join the theme review channel on Slack and start contributing.

Time: Friday, 21st February 2020, 05:00 UTC

Channel: #themereview 

For more information, you can ask in #themereview channel on slack.

We encourage all members and anyone interested to attend.

#WCASIA #wcasia #themes