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 dayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/.
  3. Removal of the Featured themes tab in the theme directory
  4. Full Site Editing Road map: Requirements for blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. 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 BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.-Based Theme meeting, held in the #themereview SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., on Wednesday, February 5, 2020, 16:00 UTC. These meetings coordinate collaboration in the development evolution of the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 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.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. 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 CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. 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 GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ 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 betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. site editor. Everything lives within a single sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. 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 ExcerptExcerpt An excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox.
  • Post Author
  • Post Date
  • Post comments form
  • Post comments count
  • Post comments
  • Featured ImageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts.

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 <headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.>, <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 loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop..

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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party (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 CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. 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/UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. 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 metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. 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 migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. 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 APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. approach shown by @aristath instead of just adding a header.htmlHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. 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 UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing.. 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 releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software.?

@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 blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.-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 PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. templates and a lot of settings in the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. 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 GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/.

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 headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. 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:

/**
 * 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. 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 widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user.-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?

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 BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.-based Theme efforts in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/:
  • Show & Tell: Block styling with CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. 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

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 SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. 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