 So on behalf of the organizers and volunteers, I'd like to welcome you all to Word Camp Vancouver 2023. I would also like to acknowledge that we're gathered today on the traditional ancestral and unceded territory of the Coast Salish peoples, including the territories of the Musqueam, Squamish, and Slewa Tiff nations. The theme of Word Camp Vancouver this year is Connected Again. This is the first Word Camp Vancouver in four years, and as a WordPress community, we are thankful that we're finally able to reconnect to Word Camp. Can I see a show of hands for people who are at their first Word Camp? So keep your hands raised for just a minute, and I want everyone who isn't raising their hand to look around and make a point of meeting at least one of the people raising their hands, because they're part of our WordPress community now, and we want them to feel welcome. Word Camps have a code of conduct to provide a friendly, safe, and welcoming environment for everyone. This means being considerate, respectful, and collaborative. If you have an issue or see an issue with a code of conduct, please talk to a volunteer organizer. There will always be an organizer at the registration area throughout the day. Coffee and tea can be found in front of the theater, this room, where the sponsor tables are. This is also where lunch is going to be served, which I believe starts at 12. To connect to the Wi-Fi, you can use the UBC visitor network and just scroll down and agree to the terms and it'll let you in. We would also like to thank all of our sponsors this year, and in particular our Gold sponsors. Those will be Affinity Bridge, Blue Host, GoDaddy, Jetpack, Simple Hosting, SiteGround, and Weglot. Word Camp is an all-volunteer conference. None of the speakers, volunteers, or organizers are paid to be here. So if you get the chance, thank them for the time and effort to make this possible. Now I'd like to introduce our first speaker. This is Flynn O'Connor. He's a web developer at UBC, and he's going to be talking about block themes today. And I think I'll hand it over to him. If anyone in here is thinking it's just for the opening remarks, you will not offend Flynn. If you're going to one of the other talks, just a heads up, so feel free to move around. Okay, thank you. Can everyone hear me? Good morning everyone. Thank you for coming here on a somewhat rainy Saturday. It's going to be a good experience. As you said, my name is Flynn O'Connor, and I work for UBC. And today we're going to be going over some of the main parts of a block theme from a developer and agency perspective. I currently work for UBC, but I have over 10 years of working with agencies. I ran a small developer co-op that would come in and provide WordPress-specific developer experience for agencies that did not have full-time developers. So I've got a lot of experience working with designers and agencies and creating custom WordPress sites. And so I want to bring some of that experience today and help us kind of look at new workflows and how we can use block themes to make WordPress themes in the future. I'd like to start by acknowledging that we are on the unceded territory of the Coast Salish people, which, as mentioned previously, is the Musqueam, Squamish, Stolo, and Soleil-Waututh nations. And so for the goal for today, there's three main things I want to do here. I want to give developers and content creators new to block themes a better understanding of what a block theme is made of and what we can actually do in it. I want to explore the theme JSON file, which is a new part of WordPress theming, and it's a very powerful tool that people don't always understand what you can do with them. And then I want to expand a bit on what we can do with blocks and block patterns. And I also want to talk about style variations that are things that are a little bit under-talked about within theme development right now. I want to see how we can use these to kind of supercharge how we create new sites for our users and our clients. So I've been using the same kind of workflow, and I've seen a lot of agencies using the same kind of workflow for a long time, where the client or the designer provides you with a design brief or design files, whether it's Photoshop or Figma, and you kind of review those files, and then developers typically have to think about the designs and interpret them in a way where we can use those designs and control them within the CMS. And so we interpret them and we think about how we can create new custom metafields, use the WordPress content area, how we can basically allow people with less tech-savvy understandings create and manage the content that the design has laid out for them. Now this can be with just standard WordPress and the content editor, but oftentimes you'll be using things like advanced custom fields, Divi, Elementor, a lot of these different page builders. And this has been something that has been fairly prominent in our industry for over a decade. It's just based on how each agency's technical acumen is, they have different ways of interpreting it and going with it. And a very common way of looking at it is we often focus on, like, the pages. We look at page templates and how to create major components of a website. So oftentimes when we're building a site, we think about the home page, an about page, a contact page, and maybe other elements of the site that is important to our clients. Sometimes it's teams, sometimes it's major products they use or services, things like that. And all of which are things that we want the users and our clients to control. And we think about these as a whole and we never actually think about how we can break these up. And what happened in 2019-2020 is WordPress started to shift. We started to change how things were going and it started with the Gutenberg editor that was originally just for content. We started looking at the block editor and as we've evolved, WordPress in 6.2 and 6.3 has expanded that editor out. So it's not just the content. We're now able to control and manage everything on the site within this editor experience. And with that we have to start rethinking what a theme is and what it's controlling and what we are giving our clients the ability to change and edit. So as before it was a lot of what we were theming and building were PHP files with some CSS and JavaScript for visual changes and dynamic experience. But now with a lot of the new tools being brought in, there's many different things that we wouldn't normally think about in our workflow that can be very powerful and helpful for us in building out our themes. Our themes are not just PHP files. They're these configuration files like ThemeJSON that I'll get into later. It's the blocks and how we style the blocks and we start exploring block templates after this. And it's just a lot of different tools that allow us to provide the starting point for our users. But then the themes will then be not necessarily what they end up with. With the Gutenberg and the site editor now people can change so much that what you give them and what ends up launching might be something completely different based on what our clients' comfortability is with editing their content. So to start off we'll talk about block templates. And with block templates there's a bit of a shift where if you look at some of the newer themes, a lot of the files are not actually PHP files. A lot of the files are now HTML files. They copy the template hierarchy of naming, but the syntax and what we write in there is very different. And it's important to remember that these templates, when we create them, can and will likely be overridden by the user. So like I said, we're just providing them a starting point. So for those who maybe have not had a ton of experience with the block editor, I just want to kind of give people a quick rundown here about what the basic block grammar is. And the block grammar is something that you can see already in the Gutenberg editor if you go into CodeView. And so we have what we call HTML comments that are used to store what's referred to as JSON objects. And so we have here any block in WordPress will always start with this HTML comment and then a WP comma or colon and then the name of the block. And so oftentimes if you start working with block themes, you'll start to see that some of these blocks are simply a single line comment with just a name and calling that will then bring in information. It's very similar to how we used to have PHP functions like there is a block for the post title, which is very similar to the PHP function where just the title, the Gutenberg block editor has one where it's WP colon post title. For some blocks, we will have content wrapped in them. And so the HTML comments act almost like divs where they kind of wrap around the content you're adding. So you have the opening of the block here, for example, then you have the content and then you have the closing where it's just a similar forward slash and then the name of the block. So it's very simple and it's consistent within the Gutenberg editor as well as in our theme files. So here's an example of like a really basic theme could look like. Much like original kind of what I've heard to as classic themes, themes need really just two pieces. They need a style.css file. And that file more important than the styles of self is the meta information at the top. Those comments are what is used to help WordPress understand the information about that theme. And then after that, it needs a single index file, but it's not an index.php. It's an index.html found within the templates directory. And it's important to understand that the templates directory is where we store all of our block templates. WordPress works in a way where if you don't have a functions.php file, if you have that template directory, WordPress just assumes you're a block editor. It does a lot of things for you automatically. The thing is if we wanted just a simple structure, I could have just made this a lightning talk and be done in like seven minutes. But what we really need is we want to explore how our templates look like and what we can add to them. And our templates can follow the same basic structure of what we're used to. We're able to create an index file.html. We're able to create a page.html. If you're familiar with the template hierarchy within WordPress, most of those root-level templates can be created in HTML much like we used to do in PHP. And as you can see here is my examples. Can we see the button here? Yeah. So this is an example of what the index.html page would look like when it's a very basic version. And if you've used the Gutenberg editor before, it's a lot of this is exactly what you would create in a post or page using the Gutenberg editor. What you might not see in there is this part up here, which is the WP template part. So this is a block that we can actually use to pull in other files just like we would do with get template part in our PHP calls with classic themes. The template parts share a similar structure to what we have before where we have the slug. And the slug needs to kind of match the name of the file. As you can see here, you would have a parts directory. And in that parts directory, that is where you would keep all of your template parts. And the slug needs to match the name of the file here. So I'd have a header.html and I could have a footer.html. And within those, those are simply just pieces of code that we're going to be reusing across different templates. So much like we would do in our classic themes, we would call header and footer consistently. But one thing you won't see in here is you won't see sidebars anymore because one thing that's important to note is that with the block editor, we can now add content in very many different ways. So we no longer need widget areas the same way we did in the past. Instead, we can just add different block components in different areas of our site. And within our main templates, we can create our header, our footer. We can have a secondary area and then people can add whatever blocks they want in there. They are not limited to just widgets anymore. So one thing I want to touch on is that one of the major additions that we as developers are not maybe fully exploring yet, but I highly encourage you to do so, is the site editor which was added in WordPress 6.2 has dramatically changed what we and also less code savvy users can work with. The site editor allows us to edit any of the templates in our theme. And when it does this, it does it in a non-destructive way. What we're able to do is give our users ability to customize the templates we give them. And then rather than overwriting our files, it saves those into the database. Now these are, the site editor will change templates that are not associated to specific posts or pages. There's also something buried within the UI for this that's called the template editor. And we're able to create custom templates for individual posts and pages. So if you have a unique layout for say your about page, you can create a custom template for that and assign it into an individual page. And that page template will overwrite anything else associated with it. And the template editor will allow your users to change and alter that. And it's important to remember too that these are all saved in the database. So your theme files will always be a starting point. So if they mess it up, all they have to do is erase their changes and it goes back to the original theme file that you provided for them. So there's a lot more of a allowance of sharing of the content. Whereas before with classic themes, the PHP files were something that our users were never able to really touch unless God forbid we gave them access to the theme editor of options. But more often now, we can give them a starting point and they can control it in the exact same way that we are building our block theme templates. So while our block templates will provide a lot of structure and control over the larger pages, we still need to consider the blocks themselves. We can't rely on the same blocks again and again. The variation in blocks is what allows us as theme developers and designers the ability to provide consistent content blocks with enough visual diversity to allow the people in power to create dynamic websites. This allows us to maintain a predictable flow of content. Based on the unique needs of your projects, you might have to alter blocks in several different ways. The three main ones I'm going to talk about today are block styles, block variations, and I'm referring to extending blocks but what this really is is just adding custom attributes to our blocks. Each of these has their own pros or cons based on your user's needs as well as the level of development complexity you want to get into. So block styles are a simple way to define different visual representations of the same block. A good example of this that comes with core is that when you use the button block there is a standard button but there's also a rounded and this allows you to do different visual representations of similar content. It's important to understand though that with these block styles not every style is going to sorry, let me rephrase that one style is applicable to each block at any one time. You can't have one block having two different styles at the same time. The other thing that's important to understand is that within the current Gutenberg experience in the admin UI if you create too many custom block styles the UI can be very very cluttered. So if you need to create multiple block styles it might be something where you consider different more complex options for your content editors. So block variations allow theme editors the ability to signify to users when something is similar but is using things just a little bit different. So we might have a block that works in certain contexts but we also want to provide a different variation and we don't want it to be rested in the original block. We want to separate it out as a completely different option within the theme editor's admin screen and so when we create a custom block variation we can take our existing block relabel it but also redefine what a starting point is. We can define what content is in it if it supports inner content. A good example of this is media text block. So in one of the sites I work on sometimes people are using the media text block for very simple things but in a couple of instances they're using the media text block as a spotlight area for their content. So I created a block variation that would allow them to select that and it would already have predefined title and description and all they have to do is change that content and add an image. So it gives them a unique version of that block that is significantly different in its function but works with the same admin interface. Another example of this is the embed block. So typically with the embed block we use that for embedding third-party content but more often than not we're using the YouTube block we're using the Twitter slash X block we're using one of the other ones but all of those different embed blocks are simply block variations of the original core embed block. If you need more variation and the variation is not fully related for instance you have different colors but also different border styles or background styles and it's something that is not really achievable with the core UI functions you might want to consider looking at custom block attributes. With the custom block attributes you can have multiple different combinations of styles and settings that you would not be able to do with a basic block style. Say for this example here on the screen I have three different pattern colors and I have three different combinations or something else. If you were to combine every single different variation of that that would be like six to seven different variations. So for block styles you would just have this huge list of different options that would be very convoluted whereas with extending the attributes here you can use this to use the combinations much more easily for your users. If you want to get a bit more advanced so while the way we handle templates may look different in the block theme it still holds many similarities to the classic way and how we do theming but ThemeJSON is where we begin to enter new waters and how you previously handle aspects of the theme changes dramatically in here. One of the main things that WordPress is working to shift towards is more of controlling theme through configuration and ThemeJSON is the keystone in themeing. The ThemeJSON has two major sections that we'll talk about today. It has the settings which defines the controls within our blocks and it creates new options. We can change a number of different settings I'll go into that shortly and then styles which we can use to define the fonts, the colors of not just the blocks themselves but elements within the theme. So within the ThemeJSON settings we are able to define controls available to content editors within the admin. We can remove certain settings we can remove certain controls or we can add certain controls and we can define the content of our sites. This is an important thing that people don't actually understand is that previously we would define our layout in our CSS but WordPress now offers the ability to define the width of your content and this is important because when creators are using your sites they might have different options where they want to go wide or full width and other things like that and by defining that in our ThemeJSON we are automatically giving the UI admin an understanding of this is the constraints we want to work with them. We can also do things like change how many pallets we use for our colors and what kind of different options and it's important to understand that with ThemeJSON this is a living file and that in the iteration of WordPress there are things that are being added to ThemeJSON. Before developers would look at a design and decide what kind of custom fields and what other ways they might be able to achieve the designs and how they would want to add content to allow their site to be presented like the designs but now we need to start considering more how can the blocks that WordPress provides us achieve the designs that we're working in and how can those blocks be used in a way to match the designs but also give the users and our clients more flexibility to do anything they want beyond the designs. The designs in our files should be a starting point for our users and our clients and if we build thinking about this from the starting point we will allow people much more control and hopefully a much more positive experience assuming they know how to use a block editor. So an example of what we can do with JSON settings here is I'm taking the core heading file here and I'm saying, okay, I want to change this. I want so I work for UBC and UBC has a very particular brand color scheme they have and we're very strict on it so if people use the wrong blue if it's not the UBC blue we let them know. So an example of what we might want to do in our ThemeJSON file is we might want to set it up so that our heading files we don't want to allow them, if you've used the editor file or the Gutenberg editor you'll know that there are certain color pickers so we don't want to allow them the free wheel color picker where they can choose any color and so here I'm just setting that to false I'm saying custom colors get that out of here and I'm saying default palette so WordPress comes with a default palette I'm saying I want that out of here as well and instead what I'm doing is I'm adding a setting here and I'm saying here's the palette I want to change colors that match the brand I'm working with so that way when our users are making pages and they're adding headings they would only ever have the option of using our brand colors and not going too crazy with their colors this can also be very important if your site has a very unique style and you want to make sure that your text maintains accessibility constraints because we don't want people to change colors if they don't understand the idea of contrast and accessibility so one thing that I think is maybe not fully considered yet and I'm really hoping to champion this more in the future is whenever we create a new setting for a color a gradient font size spacing other things like that in the theme JSON file WordPress is taking those values and they will parse them and create CSS variables on both the front end and the back end and not only are we doing that within our core settings we are also giving the option in the settings area of theme JSON to add custom values of any type that we can use in CSS so this is an example of it where I've created custom UBC font sizes and colors and then I pass them the theme JSON and if you then inspect your site you will see that WordPress generates CSS variables by default WordPress will always have the CSS variables with like hyphen hyphen wp and then the second section defines the context of it and then the final area would be the actual value of the what we refer to as the slug of these custom areas so these are really important because when we create these CSS variables we're able to take them and then reuse them throughout our theme JSON so if you've defined your theme JSON and it creates these CSS variables you can then take those if you know where you want to apply them and put them all into your theme JSON stylings and settings and make it very consistent in a way where all you have to do if you want to say change your color down the road you change that color in one place it alters that CSS variable and that change is reflected throughout your theme JSON and thus your theme it's very powerful when we think about how we style and develop so with the theme JSON styles we are looking to define the styling of any block within Gutenberg and this is not the same as what the user creates when they're altering the styles we're defining the starting styles for our blocks but not only the blocks where the theme JSON also allows us to define certain element styles we can define all of the headings links I think what else was there pseudo selectors buttons and with the pseudo selectors we can change hover and active and things like that so we're able to define these styles within this theme JSON and make it consistent because in some cases some of these links will not necessarily be managed within our block editor for example when we add theme we add menus the links in there are not going to be necessarily controlled the same way that regular button links would be in our theme editor so this allows us to style them consistently across all iterations of this example so when we're utilizing theme JSON to handle controlling the styles of blocks we can take a large leap from a different mindset from where we would build pages and posts with a PSD or a Figma file and then style install.css this is what I was talking about earlier and this is an example of it where we can now map out these styles in a much more controlled and contained way so here's an example of me using that CSS variable in my elements where I know every h1 across my site I want it to be a custom font size consistently and this is really important because this allows us to maintain certain kind of flow of sizing and content consistency that will allow us to be a better experience for the people visiting these sites so I'm going to switch over now to global style variations and this is very related because if you look in say the 2023 theme you'll see that there is a directory called styles and in there is several different JSON files and these are referred to as global style variations and what global style variations are are essentially extra themed JSON files but what they're meant to do is they're meant to give separate variations of your site and they can override your original theme JSON file in any number of ways you can kind of redefine the color palettes you can change the font sizes you can enable or disable different settings that you've added in the core one this gives you a way to create a theme that can have multiple different versions of that theme this is especially helpful for people that are building say a multi site that are going to have different iterations of the site but using the same theme and they want to provide people with a much faster starting point to making their site look unique but still using the same core block structure any settings and styles that are not specifically overwritten are inherited from the parent theme JSON and anything that is not in our themes JSON file will actually provide the theme JSON file that is in core WordPress your theme will need a styles directory as I showed here and then what we do is we just add the name of our we add the name of our style variant and then in here it can have as much or as little as you want to kind of customize the look and feel so thank you for bearing with me we're almost done I just want to talk a little bit more about this so we're going back to the blocks with block patterns if you've used them before you understand they're just a series of blocks that we use to kind of give people a starting point and it's really helpful for our clients especially when we know that our clients are going to be doing the same thing again and again and again so an example would be like landing pages we can create custom landing pages that allows them to kind of turbo charge a content creation by having everything laid out and they can then edit them however they want to we can also use block patterns and assign them strictly to custom post types so for example say you have a team or case study post type you can create a block pattern that would be the whole layout for that page and all people have to do is just enter the content in however they see and the nice thing is it's laid out how it's going to look on the front end whereas in previous classic themes if you're using things like a Divi builder or using ACF with custom grouping and whatnot you might get a general sense of what you're looking at but it's not going to match the layout of what you're going to put out there in the end and with the block patterns and the block themes you have a better understanding of what it's going to look like on the front end and the back end so block patterns can be registered within a functions file yes block themes can use function files and they can use PHP in fact block pattern template files have to be PHP and this is because any block pattern has to register using PHP comments so that WordPress can understand that this is a block theme or block pattern I should say and it has certain attributes that needs to be used the two core ones we need is the title this is the description that people are going to see using it in the editor and then the slug and the slug is important because that is going to be what is used in the editor but also we can call these patterns in our themes and similar to how I showed you previously where we did WP colon and then a block this slug is basically creating a new block name that you could call in your templates you can also create block patterns and define them with a category which is referred to as post content and what this does it tells you it tells WordPress this block pattern is going to take over the entire page so if you've ever seen a site where when you create a new poster page and a pop-up shows up and says which template do you want to use that is what that block pattern is doing so you can create these and give your users the option to select different patterns to start with but keep in mind that not everyone likes this kind of very abrupt pop-up so you can disable that in your theme so thank you very much we've gone through a ton at a really kind of like high level kind of breeze over things block themes are so so powerful but they're not for everyone we have like I said been using a very common workflow for a decade and it's can be very tough to shift from the old way of doing things to a new way of doing things and there sometimes needs to be a business case for it but I can honestly say having worked with block themes now for about two years that they are such a better experience for our clients when they're done right and when we are training our clients how to use them and the power of what they're doing we give them more variety we give them more control and we can still give them some kind of guide rails and keep them kind of within the sandbox and not going with their own style so I know that some people get terrified of giving clients all the control in the world because sometimes people just do whatever they want with it and that's not what we want but when block themes are done right they are such a great experience and they don't have to be done today if you don't use them today that's fine if you have something that works for you keep doing that but I highly encourage you to continue to explore this and look at this I'm gonna tweet out or X out my slides and so I have a bunch of references in here that I highly encourage you to look at explore it and if you want to do it there's actually a plugin here called the create block theme plugin and you can install that on a WordPress site and just go into the site editor create a bunch of templates in the editor and then using that block theme plugin just click export and without touching a single line of code you will have created a block theme through your editor so there is a lot of amazing options here that we have just begin to understand and we want to help people understand and explore them more in the future thank you very much so we are going to be moving on to the Q&A section now so if anybody has a question I can just ask you guys to raise your hands and I will come over to you with a mic and you can ask your question and Flynn will be able to respond to you hi two quick questions one it looks like with the index.html is there anything in that besides comments would you actually do any content in it or is it just happens to be named .html so the question is the index.html having anything other than the WordPress comments and the answer is yes you can treat it like a standard HTML file so because of the size of my slide I couldn't expand on it but you can actually wrap your WordPress blocks in standard HTML so you can do like divs you can do like main footer and other elements like that you can put in content you can put in HTML tags anything like that I wouldn't encourage you to put in content unless you absolutely do not want them to edit it which then yeah for sure but yes you can put in anything in HTML that you would normally put in an HTML file very good and then the second question at the end you talked about a black theme creation plugin can you open black themes and edit them with that or is it only read write or is it write only so that actually yes it can do that so if you have a block theme already installed and you open that plugin it will allow you to edit it but keep in mind you don't need that plugin to edit the block theme but what that does is any edits you make in that theme that is already pre-existing that plugin will allow you to export that changed theme as a brand new theme or as a child theme or overwrite the existing one if you install it and you look there is actually several different options it will give you for that thank you the reason I was I'm terrified like people are worried about letting their clients edit their content I'm really afraid of letting my clients edit JSON files oh yeah no I would recommend that I don't even want to learn JSON syntax so anyway thank you very much you're welcome I'm just curious about you're talking about custom styling in the blocks how that would fit with like sass all compilers it just replaced that completely in the theme development that's a challenge that I'm currently working with as well too in our work I kind of see it as replacing it because honestly CSS is now at a place where we almost don't need sass anymore we already have variables it sounds like nesting is coming into native CSS fairly soon too I think the only thing sass still has that I don't think CSS is going to fully get is mixins so I think it will change it in a lot of ways you can still combine it into your sass files by harnessing the CSS variables that it generates so if you use those CSS variables you could then use that in your sass files still you have to kind of think about how do I map that into my sass workflow yeah yes with the JSON theme variations so is that basically kind of like creating a challenge in the JSON it's kind of in this weird gray area where it's not kind of a child theme it's a little bit more limited because child themes can actually do more than what you do in just the global style variations but it's kind of halfway there like it is in a lot of ways it is creating, it's inheriting everything that's in the main site and all you're doing is changing some of the settings and the styles so you could only really change where it's available in the JSON and then if you wanted to change more than that would you still need a different theme you would do a child theme yes yeah because like and in some cases too like if you have a third party theme you can't add a global style variation into that theme because if you update it your variation is gone so a good example of when you need to use a child theme is the 2023 theme disables the drop cap option in the paragraph tech so in some cases when people actually need the drop cap they create a child theme which is just a theme JSON file re-enabling that setting and that's it hi a variation on the question here in terms of like a development workflow are there any tools or a direction where you can selectively export a template change to the file system so I'm thinking of like I don't want to do the whole theme I've already got the theme out there I just I've made a change now I want to export that yeah because there's a real challenge right now with version control and these kind of block theme editing that's still a real kind of challenge in some development workflows I can't recall to talk my head if the block theme plugin allows you to export specific files you might have to export the entire thing and just do a diff comparison but yeah that's the one challenge right now that people have voiced is that block themes are great but when you start incorporating people using the site editor and then trying to put their changes into version control there hasn't been a kind of agreed upon workflow for how to do that consistently yet but that's kind of like hopefully something we'll see in the near future thank you not right behind you speaking about version control there a revision control on the theme editor like so if a person goes in makes a change as a developer can go back and see what changes have been made and kind of cherry pick those as well so unfortunately I have a revisions turned off on my site so I haven't actually checked if they can do that in the site editor I will double check that and try to get back to you if I can but I'm not sure if it actually supports that right now yes John yeah so the question is can you extend a classic type theme with a lot of this functionality and the answer is yes the there's functionality that you can add to classic themes where you add support for site editor or you add support for certain other elements of this and then you can have the templates with HTML and you can have the template parts using the HTML and you can even have a theme JSON file they're referred to as kind of like a hybrid themes so you can have a bit of both in there it just sometimes can run into conflicts with certain stylistic aspects from what I've seen but yes it's definitely possible it's something they're working to make sure that people if they're not able to completely commit to a new block theme style they can add a lot of that same control within their theme but still have more of the classic templating that you're currently using yes so a suggestion for starter theme I would say the 2023 theme if you're looking for something that already has some opinionated stuff but outside of that honestly if you want to do your own starter theme I would say install the plugin that I mentioned and you start building some templates that you know you need and go from there there's actually also a website here called full site editing and the full site editing website has a link to a starter theme block theme generator so you can go there and generate one from there as well too that will have a structure that they recommend any other questions yes one of the things I found frustrating with the block themes is how it handles responsive movement of the blocks and such what is the best way to implement any specific responsive design that you want to do is there any blocks in particular you're talking about or just in general how things stack on responsive pretty much how things stack spacing between elements I can't think of anything specifically so there are spacing settings within the theme json file and there's two areas where the theme json supports a certain amount of flexibility font size and spacing both support fluid movement like you can do fluid typography in the theme json font sizes and then in the spacing section which controls spacing between and in blocks that can use a function I believe it's called a clamp where you can kind of specify a min max and it can then provide you different spacing depending on the size so that would be two areas where I would maybe suggest I know there's still some challenges with certain blocks like I know I've had some challenges in the past with some blocks like the median text where we don't always want the image to stack on the top there's still some challenges there but I would say working with font sizing and spacing is a good place to start for helping your site be more friendly on mobile how about accessibility in these blocks how does that factor in? with accessibility block themes are a bit more interesting because they rely more on the clients and our users to understand proper accessibility when it comes to contrast but also the order of elements making sure you're h1s and you're h2s and all that kind of stuff and we as theme developers can specify font sizes start with that are actually of a proper size so people with reading disabilities can read them at a right size when it comes to screen readers I believe that a lot of the blocks are fairly accessible now I don't know if we have things like the skip to menu which we used to have in underscores and things like that in block themes yet I think it's something that is still being worked on I'm fairly certain there's an accessibility team I think it's become more of a conversation where we have with both developers but also the clients and understanding that when you're creating content make sure you do it in a way where you're using proper color contrast you're using proper sizing and just being aware of what is needed for accessibility alright thank you very much everyone enjoy the rest of your day