This post summarizes the latest bi-weekly Block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.-Based Theme meeting, held in the #themereview Slack 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 Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ project as related to development of Block-Based Themes geared to support Full Site Editing. Moderated by @kjellr.
Important Project Links
Global Styles Update
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 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 sidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. 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 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 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 <header 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.
@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 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 core 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 plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party (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 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:
/* Content width */
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 Short for Full Site Editing, a project for the Gutenberg plugin and the editor where a full page layout is created using only blocks. 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 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 meta 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 migration 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 API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. approach shown by @aristath instead of just adding a header.html 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 UI 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 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.