Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--in the shed--Rupert. With me is Chris--in the booth--Coyier. Hey, Chris. How are you doing today?

Chris Coyier: I thought you'd be like, "Chris--index.php--Coyier!"

Dave: Well, I was going to say--

Chris: Dave--sidebar.php--Rupert.

Dave: I'm a little out of the WP post loop.

Chris: Yeah?

Dave: So, if you could help me--

Chris: Yeah.

Dave: --and bring in a guest to help me with that, that would be super useful.

Chris: Yeah, you are. You're always a little tangential to do it. We've talked about WordPress a whole bunch on this show over the years. In fact, it was our top FAQ question - unbelievably to me. Although, it was near and dear to my heart. But people would write in, and this is what they would write. They would say, "How the hell do you sync your live database on your production website to your local database so that you can work on it with the data that you have?"

It was just an unbelievably common question on this show, and we'd always be like, "Well, you can always... You can SSH into the server, and you can type SQL dump - or whatever - and get this text file that's SQL and get it to your computer and then type MySQL whatever," I forget the exact commands now, "and suck it back in." That was rough.

Now there are WordPress plugins that will do it. It's still probably not the most comfortable thing in the world, but I think there are enough solutions to that where that's no longer an FAQ on the ShopTalk Show.

But that was a long time ago. Now we've moved on and there's been drama after drama in the WordPress community. But the one that we're probably going to dig in the most -- because we have a special guest that I'm getting to here in just a moment -- is just talking about WordPress blocks. And maybe we'll even use the word Gutenberg. We'll see if that happens.

Then where it's gone from there, because that's been a number of years now. Now what's happening is full site editing and block themes and other words that are admittedly less familiar to me. But we have part of the release team of the last two releases on here, Fabian.

00:02:24

Fabian Kagy: Yeah. Thanks for having me.

Chris: Welcome!

Fabian: I'm very excited to be here.

Dave: Hooray!

Chris: Yeah, great. You reached out because maybe you caught the last show or part of it or something. I don't think it was the last show, but it was one of them recently where I was probably like, "What even is a theme anymore?! Rawr-rawr-rawr-rawr! I don't even know." And you're like, "I know, though. I'll tell you."

Fabian: Yeah.

Chris: And I want you to tell us, so that's cool. Let's do you first, though. You're at 10up, right? I have that. It's an agency that works on a bunch of large-scale WordPress stuff.

Fabian: Yes, I work at 10up as officially kind of director of editorial engineering, meaning I work on WordPress sites most days and kind of do 50% still active client work, 50% kind of internal future direction shaping, helping the team level up, and all of that fun stuff.

Chris: Ah... Okay. Okay. But hacking on WordPress sites on the daily.

Fabian: Yes.

Chris: On the daily.

Dave: I have always appreciated 10up's business model. They're like, "WordPress is probably the tool you need, and you're a large company, and we know it's not your wheelhouse, so we'll do it for you. We'll help you out with it."

It's always struck me as, "Yeah, you do enterprise-grade WordPress, and that's useful for a lot of large companies."

Chris: Yeah. Darn right. I'm sure you charge for it.

Here's probably the most important question. Are you VS Code or you write so much PHP that you're in PHP storm? What do you got?

00:03:57

Fabian: I'm VS Code all day long. I'm a front-end developer and started that way, going that way.

Chris: Yeah.

Fabian: I probably write more React, honestly, than PHP.

Chris: Than PHP? Okay. Fair enough. VS Code.

Dave: When did you start getting into WordPress? What version number would be--?

Fabian: I think it was something like 4.3, 4.5, or something? I started very late in the game. I have to admit, as a WordPress developer, I haven't written a line of jQuery in my life. I kind of started at the time where the Gutenberg plugin, which you already mentioned, was already in beta. It was not ... to core or anything, but I kind of started right at that point of time.

Chris: Okay, sure.

Fabian: Yeah, very much a newbie to that old WordPress.

Chris: That's good. That's why you don't have huge bags under your eyes. Fair enough.

[Laughter]

Dave: Your fingertips aren't bloody and soiled.

Chris: Maybe they are, though. I don't know.

[Laughter]

Chris: I'd love to clear that one up a little bit. People still say it. It's locked into their mind, the word Gutenberg, because it was called that for so long because we were told, "WordPress, the editor itself is going to change. It's not going to be like it was before. It's going to be different. There are these things. We're calling them blocks, and you can make custom ones, but it's going to ship with a bunch of ones. But you can drag them around. They all have state and settings, and it's amazing, and you're going to love it."

Then that came out. Then it wasn't called Gutenberg anymore. Then it's just the block editor, but this plugin stays around, and I think it's basically the beta channel - or something - for the block editor. Is that still correct?

00:05:42

Fabian: Pretty much yes. I very much think of the Gutenberg plugin as the beta channel of all of WordPress.

Chris: Of all of WordPress! Woo! Okay.

Fabian: Over the years, so many different areas of the WordPress codebase have kind of started to be taken over from that Gutenberg plugin that, unlike other features (going back all the way in the history of WordPress), all the new features or bigger new features always got developed as feature plugins. Then at some point, that feature plugin has kind of showed this is useful; we want to merge this in. It gets merged in. That plugin gets closed, and it's now just WordPress core and evolved there.

Chris: Okay.

Fabian: But kind of that Gutenberg project was a little different. Yeah, it started out as one of those features plugin, and actually got merged into WordPress core back in, I think it was, November of 2019. But then that plugin actually stuck around and all of the new feature development for the editor, at first, started to happen in that Gutenberg plugin. Part of the reason why it stuck around is because that plugin gets developed in GitHub, whereas all of WordPress core still uses track, and so it's just so much easier and more approachable for developers to contribute that way.

Chris: Yeah.

Fabian: Also, it's kind of a different codebase. It's much more JavaScript-focused codebase, lots of TypeScript in there, React stuff, and because of that, the developers that contribute to that Gutenberg project are largely different to the ones that traditionally contributed to WordPress core. And so, now it kind of (slowly from the inside out) took over a lot of the WordPress development. Not all, obviously, but a lot of it.

Chris: Yeah! Funny. The React kids hang out in the Gutenberg plugin. Wow. Okay. That makes sense to me, though, in a way.

Yeah, I actually found it to be a little comfortable at one time. I was bullish and still am, I guess, about block-based editing. It just felt right to me. It happened at a time where Notion was getting popular, and it was block-based. It just seemed to be in the water, and I just liked it somehow.

And I was working on CSS-Tricks at the time, which is a big WordPress blog. And I could be like, "Oh, I could make my own code block? Then it has metadata? And I could say, 'This code block is a block of CSS. That's really useful to me.'" I liked that idea of attaching state directly to an individual block. That was so cool.

What if I just want two columns side-by-side, 50%, 50% columns? The Gutenberg made that beautifully easy, and I use that all of the time.

Then that's simple-ish stuff, and it can level up from there, having sliders and photo galleries and Google Maps and stuff. I was like, "This is genius. This is just what we need, little pieces to compose together some content and spit it out."

I was like, "I know it's going to be a little painful," and it was. But again, this was a long time ago. I don't know how many years ago, but this is kind of when you were getting into it. But man was it controversial at the time, people jumping ship on the whole project. Even people that were like, "I've made my whole career on WordPress and I hate this. What do I do now?" It was existential crisis stuff for people when this thing came out.

But you know it happened. To this day, I open up old sites and open up some old site and there's still a button at the top that's like, "Convert to blocks." I'm like, "Yeah, go ahead."

You click the button, and you know what? It does fine. [Laughter] At least on my simple sites.

Okay, blocks now exist for a long time. But then there's this new place that I want to talk about that's like, now that we have blocks, what else can we do with them? It turned into, like, "I guess you can just make everything out of them."

When they first dropped, it was still like you make what I think of as a traditional theme. You still have a special kind of page template that's called conferences.php, and it represents a custom post type called conferences, and then, within that template, you still write your HTML and PHP and stuff in that.

Then at some point it says, "PHP WP Content," and then it goes blah, and that's where it goes blah, and it barfs out all the blocks on that particular page. To me, it's just comfortable, and that's just how I've done it for a long time, so I wanted to stick with that.

Then enter me today in this episode that perhaps you heard where I was just like, "Does WordPress even want me to do that anymore, or are they trying to waggle their finger at me and say, 'No, don't build themes like that anymore. Don't build conferences.php. Build something,' which I don't know what, 'inside the WordPress admin that is that template that is crafted of blocks'?"

I don't even know if I said that right. I'm just so confused by it all.

00:10:47

Fabian: Yeah. It tracks very well with what actually happened. When the block editor was introduced, it started taking over the content area. As a content author, you can write, you can author your actual content. Then you still have a traditional theme that just has your PHP template, that old PHP template hierarchy that we all probably stared at way too often to figure out which template we need to use. But we can just write PHP and drop in our content in some spot.

Then at some point WordPress started to introduce that theme.json file as a way to configure what options are available for all of your blocks. For folks who are not familiar with that, it essentially allows you define your color palette, spacing presets, typography options, all of those things that are then inherited by all those different blocks. You can define the default styling for any of those blocks in that JSON file, and you can also configure the options that are presented to editors. That kind of was that first additional step.

Chris: Okay. That was the first baby step into this. I never shipped a theme.json, but I can understand what you're saying. They're kind of like design tokens that represent defaults to styling that could be changed.

Fabian: Yes.

Chris: Even then, you could go so far as to ship a theme that is just that. It's literally just a theme. I don't know. Maybe it requires a .css file sitting in there, too. But you could do a pretty advanced theme with just that file, right?

Fabian: You can now. There were a couple of intermediate. At the beginning, you still required a lot of the other template stuff for a theme to work. Now, these days, technically, you need three files. You still need that main style CSS. You need a theme.json and you need your index template, essentially.

Chris: Okay.

Fabian: Yeah, that theme.json file got introduced, and that is design tokens, all of the tokens that you'd used in all the places.

Chris: It could be pretty powerful, right? Is it still kind of like runtime? We all know how the Web works. There's a div on the page. If the div has a font family of Lato on it, then the Lato font is going to be used for the text inside that div. Cool. That requires CSS to do that job. If the only place in this entire theme that says Lato in it is a piece of JSON, what is converting that piece of JSON data into a style that gets applied to the page? Does it happen at runtime?

00:13:33

Fabian: It does happen in the PHP runtime. There is some caching that will happen that WordPress will do for you, so it's kind of getting cached.

Chris: Yeah, right.

Fabian: There are some development modes that you can enter to prevent that caching as you're developing. But yeah, it essentially is a runtime thing that converts those styles into... There is a bit of style sheets that get generated and injected. There are some inline styles that get added in the head to define all of those custom properties. Then there are also some inline style attributes for user-selected styles.

In that theme.json, you provide all the defaults. Then if a user actually goes in with a color picker and says, "Hey, actually, I want my group to be this particular shade of green," then that gets applied as an inline style.

Chris: Yeah, right. Yeah, inline style. But I'm not going to call it convoluted or anything, but what actually happened is doesn't it get onto the page in an HTML comment that says whatever color green on it, and then that gets converted into a style?

Fabian: The HTML comment gets saved to the database. Then from the database, that gets run through WordPress as it outputs stuff and actually generates all that styling.

Chris: I like that, too, honestly. Not to paint that picture really strangely, but I thought it was kind of clever the way it uses HTML comments as this way to persist state is kind of cool. It means that... I don't know. It just seems to make sense to me. Even though it's replicated in the DB - or whatever - it's like, yeah, I can now move. I can literally just copy and paste it to another site and it brings that state with it, is kind of an interesting idea.

Fabian: That is a slight change from the theme conversation that I want to get back to for the actual kind of what new themes can be.

Chris: Sure, theming. Go.

00:15:34

Fabian: For those blocks, for how they get stored, there are actually two different ways that these blocks can be built. There are static blocks and there are dynamic blocks.

Chris: Okay.

Fabian: Both of them have that HTML comment. But static blocks store all of the generated markup in the database, and most of the core blocks (if you have a heading block or a group block).

What actually happens is Gutenberg, that block editor, actually just is a React application that is running in client in the browser of the user of WordPress. And as you author your page, that React application, that React code generates the HTML, including that HTML comment of your Dave for your group or of your paragraph tag with some classes and with that stuff added, and then saves that. It's not technically it, but kind of pre-rendered HTML into the database so that WordPress just spits out that pre-rendered HTML when....

Chris: Right, that means React doesn't have to run client-side.

Fabian: Correct.

Chris: Yeah.

Fabian: That is one of the common misconceptions, as folks start to develop. "Hey, I can see I have a safe JavaScript file where I write React," but that React isn't actually executed on the front end of the site. It is just generate or it is used to generate the markup that has persisted to the database.

Chris: Yeah, it's just the language used to build blocks.

Fabian: Yeah.

Chris: Which is very weird to me but, I don't know, kind of smart. Clearly, it's doing some stuff. Just because I write React at the old day job, the custom blocks I've built, I was kind of thankful to have it because you're using use state and use effect hooks and stuff. You're using all the same crap everybody else that writes React uses, which is nice.

Fabian: Yeah.

Chris: It just was surprising to me. I remember, as another tangent, that -- what's the big plugin everybody uses for custom meta fields - or whatever?

Fabian: ACF.

Chris: Yeah, ACF. Then at one point released their take on building blocks, and it was just all PHP. You're like, it's so weird to me that it took a plugin to do it the PHP way, you know, which felt very WordPress-y, like, "You should have done it like that!" You know? That makes sense to me.

Then a plugin would be the one that comes in and do it the React-y way. But no, it kind of happened in reverse. Can't change history. It's just how that works. Yeah, that's cool.

Then there's some kind of reconciliation step, too, because it's all too easy, the few blocks I made, to break a custom block. If you change the HTML that it expects inside of it, you'll get this error thing when you open up a page that uses that block. It'll be like, "There's crap in here that isn't what I expect it to be and I don't know what to do with it." I don't know. Just dangerous territory there.

00:18:42

Fabian: That exactly is kind of what I was getting where there are two different ways of writing those blocks. There are the static blocks that save all of the markup to the database.

Chris: Mm-hmm.

Fabian: That's again how most of the core blocks are authored. Then there are dynamic blocks, which actually only store the HTML comment to the database with all those attributes and all that kind of JSON structure for, "Hey, here are all these settings fields. I'm just storing the actual values. I'm not storing any markup."

Chris: No content. Yeah.

Fabian: Just leaving those and then you actually have a PHP file that essentially is allowing you to write the markup for the front end.

Chris: Oh...

Fabian: You just get those JSON values. You just get those attributes already parsed passed into that quick kind of template, essentially. You can write that front-end markup in PHP, as you're kind of more familiar with.

Chris: It was kind of nice because it can never be wrong. You'll never get invalid block because it's just going to get what it gets and put it in there.

Fabian: Yeah, and that is why--on the day job, essentially--for client sites where the client decides 100 times, "Hey, we want to change this, we want to move this over, we want this to be three columns instead of four columns," if we write custom blocks for stuff, we write them as dynamic blocks where we are only saving the actual settings, the attributes to the database, but the markup can really change at any point.

Chris: Yeah.

Fabian: And we can kind of iterate quickly.

Chris: You like it. That's the way to make blocks for you. That's cool.

Dave: Is there a cost? You said it's parsed at runtime or the actual final HTML is injected later. Is there a cost, a theoretical limit of how many comments, JSON comments, I guess? I don't know. It's not exactly JSON, but comments you can parse into HTML without caching or anything like that.

00:20:33

Fabian: There theoretically are limits. Though, in all the sites, all the very big sites, I have not ran into any cases where it actually did matter at the end where we were anywhere close to approaching those kinds of limits. But yeah, in theory, yes, every single block that even if it is one of those static blocks that just has everything serialized, they do get parsed in the runtime of WordPress because there's additional stuff that gets output. There's parsing to check, "Hey, is this block actually in a page? Do I need to load the CSS file? Do I need to attach this JS file?" All of that stuff is happening runtime, so yeah, theoretically, if you add millions and millions of blocks, at some point your PHP will tell you, "Hey, you need to add a little more memory here," or do something.

Dave: Interesting. Interesting. So, I guess I don't know. I would assume 10up has a pretty standard enterprise caching system. Is it just like, "We're using WP Engine," [laughter] or what does 10up try to do for those sort of varnishy situations?

Fabian: For the most part, it is working with our various hosting partners and kind of using their solutions. There are, of course, systems folks that know their way around that stuff much better than I do as a front-end developer.

Dave: Yeah.

Fabian: But for the most part, it is just working with hosting providers that are set up to deal with those sites that get millions and millions of hits every day.

Dave: You work with the client, but you don't necessarily get a call, the hardware, the service they're hosting on, right?

Fabian: Yeah.

Dave: Yeah. Interesting.

Fabian: We can make recommendations, but oftentimes... Some clients reach out to us directly. Some clients approach us through having reached out to a hosting provider. We've, of course, worked with many of these hosting providers for many years and are in their agency programs and whatnot. If it's a good fit, that sometimes happens as well where, hey, hosting is locked in before even the vendor that builds the site is locked in.

Dave: Yeah. Cool.

Chris: It's like the ultimate caching story, WordPress. If you like caching, you should work on WordPress because it's ten layers deep, man. You know? At the very top, it's like, "This page has already been rendered," so it gets cached at, I don't know, the Cloudflare level or something. It's a complete HTML document, so it doesn't have to call anything.

Then it kind of goes down the nest from there, all the way down to tiny little database query caching, which is a totally different kind of caching. WordPress has transients, too, which developers can take advantage of to tuck little things inside, which is kind of caching in the middle. Whoa! Too much! Too much.

I'm sure it all makes sense. But for my brain it's too much.

00:23:29

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by jam.dev. You've got to check it out. Go to jam.dev. It's a free browser plugin you can install.

As a developer, you need some kind of tool for capturing and annotating screenshots for bugs or, even better, recording little video screencasts of what the bug is. They communicate the bug so much better.

You've got to have a tool like that. That's what Jam does. But it does so much more than that because it automatically captures a whole bunch of interesting, actionable metadata along with that.

Imagine you've recorded this little screenshot now. It automatically becomes this shareable URL that you can put wherever. There are integrations, too: send it to Jira, send it to Notion, use it in your Slack -whatever.

You can comment on them, leave text there explaining what's going on. But it automatically captures the console, everything in the console, what happened. If it's a bug and the bug threw, for example, a JavaScript error, you'll be able to find it.

You integrate it with Sentry. We definitely have that at CodePen. Now I take a screenshot. There is some backend problem or front-end problem even, it can compare the timestamps of what got reported in Sentry and then what was happening on the website and marry the two so you can see more even than in the console with Sentry. I think that's amazing. Not to mention you're looking at the video of the problem is super, super useful.

Then it's got the browser, the platform, the version, when, where it happened, all this stuff. More than just the console to other stuff from the dev tools. Just a tremendous thing.

It doesn't make any more work. You need a screenshot tool, a screen recording tool anyway. You might as well use this one and get all the free metadata information and debug information there, too. I even see there's a little AI tab, so it's like, "Oh, this is representing a bug. Now with all this information, it'll take a crack at how it thinks you could fix it. Why not? Sometimes you're stuck. Let it help you.

Check this all out at jam.dev. A really cool tool.

[Banjo music stops]

00:25:40

Chris: Okay, so there are blocks. I think we got into talking about custom blocks there for a little bit, which is nice. I think probably especially big sites that have been around a while or have a development team or have really special needs probably are making custom blocks. It can be very powerful.

But probably 99% of sites don't use custom blocks. At least of their own creation. Perhaps they use a plugin or something that provides a custom block. But there are an awful lot of blocks that are just built-in, or you install Jetpack and Jetpack gives you another 50 of them - or something. There are those types of blocks, too.

Okay, but we're still just kind of talking about content. You're crafting a landing page. You're crafting a page or a blog post or whatever it is. Great. Then you spit it all out at once. But there's more to this story, right?

You can also create a footer out of blocks, and that's another place where I'm just a little lost as to the approach. What purview is that? Are we talking about full-site editing at that point? How do I make a footer with blocks?

Fabian: Yes. That is the next step in that iteration. We had introduced that theme.json file. Now the next step was that full site editing project, which now, because WordPress apparently loves renaming stuff, is just called Block-Based Themes, but everybody still calls it--

Chris: Block... FS is out! Oh, like me--

Fabian: Theoretically, it's out. But it is very much--

Chris: Okay.

Fabian: It is burnt into the brains as much as Gutenberg is, and I don't think that term is going away anytime soon. But yeah, the concept behind full site editing is essentially there are now block-based themes, which allow you to essentially use blocks for all the parts of your site. It's no longer just the content area, but your sidebar, your header, your footer. All those pieces can be made up of blocks as well.

The way that works is technically the same template hierarchy that existed in traditional PHP-based themes still exists. Just instead of having PHP files, they're now HTML files that are located in a templates folder. And those HTML files have the same naming structure as those traditional themes.

If you have a single PHP or a singular or single custom post type or whatnot, that naming still applies, so that is how you can still attach or know which template gets used for something.

Chris: Wow.

Dave: Hmm...

Fabian: But then those template files, those HTML files actually, at the end of the day, contain the same block markup that is also used in the content area in the database, in the post content, of a single post. It's just using different blocks.

For example, in your template, you would use the post content block, which then outputs the actual content of an individual story, or you would use the post title block to put the title of a story, the post date or the date - all of those things.

Chris: Hmm... Yeah, that's weird.

Fabian: Right.

Chris: I don't think probably a lot of developers even... Not weird but new anyway.

Fabian: Yes.

Chris: Developers maybe don't even know that that exists (right) that there's a block that outputs a post title. Mostly, you think of the post title is just this big input field. When I make a post, I write it at the top and hit save and that's the title. Why do I need a block that's the title?

Well, you need a block that's a title if you're building a template that needs to output that block. I need a block to put there. [Laughter] That's just something.

00:29:18

Fabian: Yeah. Funnily enough, those blocks, most of them already got introduced before we got to that template editing because WordPress also includes this query block. And that query block. And that query block essentially is your analog of the WP Query, which just allows you to pull in content, display other posts somewhere.

In that query block, you can define, "Hey, show the ten most recently published posts." And in that query block, you can use all of those kind of page-level blocks, like the page title, page excerpt, page featured image.

Chris: Right.

Fabian: All of those blocks in that template there as well, so they kind of existed beforehand if you wanted to display your posts somewhere. In content, you were able to use that query loop to pull those in.

Chris: Right.

Fabian: Now those same blocks also get used on those templates to output all that stuff.

Chris: I started this talking about conferences.php - or whatever. I just invented some concept that you might use WordPress for as a custom post type. Sure, it's a blog, but it's a website that lists upcoming conferences - or something.

To me, that was like, "Okay. I am in PHP town now because I know that I need to use WP Query because I'm actually going to query for a different custom post type than posts, so I definitely need to tell it that that's what I'm doing. Then I actually want them to be ordered by the date of the conference, not the date that I published it. So, I'm going to need to write some special PHP that looks at a custom meta field and ascends them in descending order against that meta field because that's what I'm actually trying to show here."

To me, I was like, "I cannot escape it. The only way I can do this is PHP," but that's not true anymore because now there's this WP Query block, and I can express those needs through drop-down menus now, I guess. Is that true? That's wild.

Fabian: Yeah, pretty much it is. You can do all these things through the UI now, in theory. You don't ever have to open your code editor.

You can go into WordPress. In that sidebar, you have an area for themes. Under themes, there now is that site editor. It's now just called editor. If you click that, you get a new sidebar, a new, fancy-looking interface that lists all your different templates, your template parts, all of those things.

Chris: Yeah.

Fabian: In there, you would be able to hit a plus button. It brings you up the selection to say, "Hey, what type of template do you want to add?" You have a post type called conferences. Do you want to create a single conference or a conference archive or those types of things?

Chris: Uh-huh.

Fabian: You just select that. On that template that is now created visually in that editor, you have query block. There's one by default.

Chris: Right.

Fabian: Without you even needing to make any changes, that query inherits that query that is defined by the template. Any archive in WordPress already has... It's already known what that query is for that page.

Chris: Ah... Right.

Fabian: Because it is archive/something, archive/conference.

Chris: Yeah.

Fabian: Or archive-conference.php. By default, it just displays by alphabetical or most recently published.

Chris: Yeah. It's a little bit a part of the magic of WordPress, right? If I make it in an old-school way, if I make a page called archive.php, it's not like I have to handcraft the query at the top of that page that does archiving. When I do the loop on that page, it's just going to be the archive when it gets to that page.

Fabian: Yes.

Chris: It just knows somehow, and you're saying that's the case here, too.

00:33:09

Fabian: Yeah, that's the case there as well. The default behavior of that query loop in a template is just what inherit whatever of that global query of that page is.

Chris: Right.

Fabian: You wouldn't even need to configure anything. You now have pagination and all of that stuff represented as blocks. You can move them around. You can style them. You can do all that stuff. And you can kind of do those things.

Chris: Right. Can you be like, "But don't show posts of the category Dave"? Can I just sprinkle in a little adjustment to the query?

Fabian: Yeah, so there are a bunch of filters to allow you to only pull in those categories by that author, sort by that. Those options do exist. But for that example that you mentioned, "Hey, I have this conference post type where I have a custom meta field for a date," you would then... You can use a PHP filter to modify that underlying WP Query of those arguments that you passed to that. In PHP, you would just do it in a filter instead of directly in that template because some of those things like custom ordering based on meta key--

Chris: Yeah.

Fabian: --those are not things that you can do just through the UI. You would need to do that through a custom kind of PHP filter.

Chris: Oh, so you do have to write PHP. Where do you write the PHP? Can you still do it through the admin somewhere, or do you have to bust out to VS Code?

Fabian: That is, I think, a non-secured down WordPress installation. There theoretically, technically still is that code editor that you can jump into.

Chris: Ah, yeah!

Fabian: Yeah, at that point you would jump into the....

Chris: You have to really warn people.

Fabian: Yeah.

Chris: Yeah. I had to adjust something. A random lady--

Fabian: Yes.

Chris: --I made a WordPress site for like ten years ago, texted me just last week and was like there's some select menu was too long, and it was busting out her responsive design, because she just threw... She just tossed WooCommerce onto this old site to take credit cards - or something. It just didn't go super good.

All I needed to do was shrink the size of that select menu so it stopped messing around with it. She's like, "Where is the button to do it?" I'm like, "I actually can't even think about it," and I think in CSS, so I just opened up that damn theme editor and found a pretty specific selector and said, "Back width 100 pixels," or something on the selects, and it fixed her problem.

She was like, "Where did you do that?" I'm like, "I'm not even going to show you where I did that because you don't want to know. It's not the correct place to do it."

Dave: "Don't use or you will be fired," section of WordPress.

Chris: Yeah! [Laughter]

Dave: Yeah. Yeah.

Chris: Totally. Definitely, don't use that. One of the problems with using that, of course, is because the vast majority of websites these days are version-controlled. So, if you go in there and mess with some crap in there, it's going to live as long as the next person that pushes to that site pushes, and it's going to override your crap. That's why we don't cowboy code.

But that brings me up. Let's say I'm building the sidebar of this thing. You're saying the sidebar now can be this block-based thing, which is pretty cool. Then it makes an HTML file that represents that sidebar. Isn't that changing a file on disk?

00:36:24

Fabian: By you just going into that site editor and making some changes there, creating that new template, creating that sidebar, that only gets saved to the database.

Chris: Okay.

Fabian: That is only on that site where you're editing it. There is a plugin that gets maintained by the WordPress core team that is called the Create Block Theme plugin.

Chris: Oh...

Fabian: That plugin has an option that then allows you to persist any of those things that you edited visually to disk and just save them to your disk so that you can then use to manage all of that stuff.

Chris: Okay. Okay. That must be what's going on with the 2025 theme - or something. I clicked onto that GitHub repo. They were like, "Oh, 2025 is coming," and that's always interesting because you're like, "Okay. What does the default theme do?" It's kind of interesting.

They've never been minimally. It doesn't seem like it's been in a long time. They tend to be doing interesting stuff. But people look at them. They are a prototype of what can be done in modern WordPress.

If you are a little bit old school in your WordPress stuff, like I am, and I poke through those files, I'm like, "What in the fricken' earth is happening in here?" It's full of .html files, which you just explained. I did not understand that they're a 1:1-ish to the PHP site hierarchy. That's useful and makes sense.

But they're full of HTML comments. There's no way that we're expected... Are we expected to author HTML comments? No. Right? No.

Fabian: Yeah.

Chris: It's this plugin that makes it.

00:38:00

Fabian: Correct. That plugin allows you to just use that site editor essentially as a visual ID to then spit out those files. Yeah, there exists some VS Code syntax highlighting plugins that make it a little more bearable to hand-update that HTML markup. But I would never expect anybody to update that markup by hand. And it really is more if you need custom markup, you write that custom markup in a block. Then you use that block in the template.

Chris: Okay.

Fabian: It's not you'd just go into the template and put random markup into that. You use markup of existing blocks, either core blocks, third-party blocks, or custom ones that you've built.

Chris: I'm working on the homepage, and I want a special template for my home page. It's very commonly the weirdest page on a website, right?

I remember at design system conferences and stuff, they'd always say, "Don't think about your design system too much based on your homepage because the homepage tends to be a total one-off of the rest of the site a lot of times."

I'm going to manage mine with blocks. I'm going to make it a block thing. I'm going to do weird crap with blocks. It's going to have two columns here and six columns down there. I'm just going to do whatever the heck I want in there.

That will ultimately be a home.html file. But I don't need that file. I can just craft it and it'll go in the database and I can use it. But if I were going to pick that up and move it to another site or something and be like, "Hey, look what I did. You can use it, too," then it would behoove me to make a home.html file because then that will be the default.

What if it deviates from it then? Let's say I have a home.html file in my theme. Then I open up the home template, and I change it and move stuff around. It's going to honor the one in the database. It kind of doesn't even matter what's in that HTML file anymore, right?

00:39:51

Fabian: Yeah. Very much so, there is an option to always clear that out and go back to the version on disk.

Chris: On disk, as it were? Yeah.

Fabian: But it is something that, especially for me in the enterprise market, we use the site editor as a development tool. Our clients are not expected to go into the site editor. In fact, we don't want them to because we don't want anything to be loaded, any template to be loaded, from the database. We always want that version that is committed to Git that we can push updates to at any point. And we never want to be locked out of those things.

Chris: Oh, you're the exact opposite. You're like, "Don't touch it on the editor."

Fabian: Yeah, that site editor really is a development tool for us that allows us to kind of visually do those things and leverage all of those niceties that come with using blocks for all those things, which we get code splitting for free, essentially, in a WordPress site--

Chris: Right.

Fabian: --because only the code attached to that block actually gets loaded on the page.

Chris: Okay.

Fabian: The CSS, the JavaScript, all of that stuff is only loaded. There's a bit of critical CSS happening. There are just many cool advantages to using a block them.

Chris: Yeah.

Fabian: And it allows us to get a nicer preview in the editor and all of those things. But we're not using that site editor much for what the client is editing.

Chris: No, because you want to be able to get push origin master and have it actually change on the website. If you made one little change on the site editor, it would abort using that one on disk. It'd used the one in the database, and you wouldn't get that anymore. That's fascinating.

Some people probably very much are using the site editor. Obviously, tons of time and effort and work went into making that site editor a nice user experience for people to use. But you don't have to use it. In fact, there are some advantages to not using it.

00:41:45

Fabian: That is one of the most interesting but also most challenging things about working in the WordPress space. Because of just how large the WordPress ecosystem is, there is no one WordPress user that you can kind of build all the things for and that you can optimize for.

There are the top Fortune 500 websites and then there are small, kind of homegrown sites that are DIY that are building it. All of them kind of use that one shared tool. That is what I find interesting about looking at something like a 2025 theme that is in development right now. That is much more geared towards those kind of DIY, "Hey, you have all the options, all the freedom, all the control. You can just build your site and tinker with it." Whereas on those large enterprise sites, yeah, we're using the same tools. We're using those full-set editing, block-based themes. But we're using them in a very different way.

Dave: See, that's what I was going to ask. I'm looking at the 2025 theme, and it's like 1,000 lines of tokens, let's call them. Right? Style tokens and fonts. A lot of it is fonts, so maybe it's 700.

You're saying you don't really supply these theme.json to your clients. Maybe just some to bootstrap or you pick a theme, infinitely customizable. Right? Or you just send... Do you send a theme.json or do you not even opt into that?

00:43:17

Fabian: We heavily use theme.json because, one, it allows us to just... In that theme.json file, you can of course use all of those presets that WordPress already knows about. But there's also just a custom section, so we kind of... There are some adapters that allow you to actually work with token systems to just pull them in and use them in that theme.json file. Or if we don't have an already established design system, we can actually use that theme.json file to define all of our tokens, so color palette, all of that stuff, we would actually define there and then just use those generated variables all over in our custom CSS.

But then the main reason why that theme.json file is so interesting for us is it allows you to actually curate that editorial experience. It allows you to say, "Hey, I actually don't want you, user, to be able to just pick any random hex code. I just want you to be able to pick from these five predefined colors that are in your design guidelines. And I actually only want you to use these three text colors and only these text...."

Dave: Maybe it's not even a color. Maybe it's a CSS variable, so you can do light and dark - or something. Right?

Fabian: Yeah, exactly.

Dave: Yeah.

Chris: Oh, nice.

Fabian: All of that theming, tokenizing for us, we do use theme.json for it. We don't have to. But because we're already using those tokens in the rest of the site and we're using a lot of those, that just is the naming scheme that, for us, we use most times. But you very much don't have to. You can also... Even if you're using Tailwind colors, you can use those Tailwind tokens, those custom properties in that theme.json file and reference them. You'd then just need to make sure that all of those Tailwind tokens are available everywhere kind of in all of the different editors on the front end and all....

Chris: That is so, so weird.

Dave: Yeah. If I were to jump in today, I would have no idea how to operate that piece. That would be... I mean... whatever. I'm smart enough to figure out how JSON works.

[Laughter]

Dave: But how it's matriculating through the whole--

Chris: Yeah, dude.

Dave: --the whole theme is a lot. I don't know. I do that in my day-to-day job, too.

Chris: Well, it would break me because I'd be like, "I need to put..." I just want to put 200 pixels of bottom margin at the bottom of this post before the comments because I just feel like it needs some fricken' white space, and I need to put it there.

This theme is screaming at me to not write CSS. Where do I put it?

Dave: Like how Arc browser only nudges you to use one tab, is WordPress nudging you to not use CSS? #hotdrama

Chris: Well, it's saying, "Find the template."

Fabian: [Laughter]

Chris: Find the template where the content is at the top and the comments are there and use the spacing block and put it in there. Then do that. But I also need to make sure that then I use the plugin to put that spacing block into the .html file template because there's no way... I don't make sites that aren't version-controlled, so that's got to happen.

00:46:35

Fabian: That very much is that "Hey, if you're a DIY'er who just wants to build your site and kind of tinker with it, make those adjustments visually. You know nothing about CSS. You don't know what Git is. You just want to use a WordPress site," that is what kind of... If you are building a multipurpose theme that anybody is supposed to just be able to manipulate, write in your CSS in that JSON file--even though it is super weird to figure out--makes some sense because then that CSS can be parsed and understood by WordPress and get populated.

The UI shows you what the values are. You're not confused, "Hey, where is this weird padding coming from?" In that example that you mentioned earlier, "Why is this that width? Where is that coming from?" If those styles are defined in the JSON file, then WordPress knows where they're coming from and it allows you to display them in the UI. You can see that. You can update it.

But if you're working on a site like when you were working on CSS-Tricks, when you were iterating on that, you have your team that has your known design and just your stuff, and so, for me, yeah, we use that theme.json file to restrict what's available. We can limit the options. We can make those variables that we have available to editors and do that. But then you still write tons of custom CSS, and you have a nice folder structure that makes sense for you.

That CSS isn't all written in one big file that gets loaded on every page. But rather, it gets put into individual files that are then linked to blocks so that CSS knows when that block is actually used on the page.

Chris: Oh, yeah. Cool. Wow. That feels like the future. The future has arrived. We are now writing CSS for individual componentry and not even CSS and JS, right? I don't know. What are these block-based chunks of CSS thought of as?

00:48:38

Fabian: If you write a custom block in that main kind of JSON file that is related to every block, you can reference a style sheet. That style sheet only gets loaded when that block is actually on the page.

But then if you're a developer working on a site and are not just literally building custom blocks for every single thing, there's also a method for you to write your own CSS file. Then call a function to reference, "Hey, this CSS file is connected to that block."

For us, in our kind of standard scaffolding, we have some automagic. We have a folder. If you put it into that and name it a certain way, that gets connected to the block automatically. If you create a folder called Core and a file called paragraph.css, that file only loads if there is a paragraph block on the page. That then makes it so that you can just author your CSS in those individual files. Those files only get loaded when that block is used on the page.

Chris: Intelligently? Are they concatenated? Do they land in a style block in the head? Are they a style block within the--?

Fabian: Yes.

Chris: Yeah?

Fabian: WordPress parses your templates if you are in a block-based theme, and then the actual content area, top to bottom. For every single block that it encounters, it checks, "Hey, are there some CSS files that I need to load?" There is a total buffer that you can configure. But by default, I think it's 50 kilobytes or something.

Up until that buffer is full, it takes that CSS file and just puts it into an inline style tag at the top of the page, so that's kind of critical CSS for the topmost, the few top-most blocks that are on the page up until you get to that 50k kind of threshold. Then the rest of those CSS files, individual CSS files, are just link tags that kind of get referenced as individual files.

You have a couple more HTTP requests for those blocks further down on the page. But the top-most blocks actually get their CSS inline....

Chris: Clever. Yeah, why not? That's cool. I always envisioned that future. I didn't know that we would ever get there. But that's how it's going now. HTTP2.

Dave: Do you feel like the theme authoring experience has changed so much that it's maybe leaving people out of the process? I know we've kind of gotten this question in different ways here, but just like, man, I go to WordPress, I don't even know how to make a theme anymore. Do you feel like that's good, and what would you say to them?

Would you say, "Tough shit"? [Laughter] Would you say, "Figure it out. Get good, kid"? What would you say to somebody who is kind of struggling with the new paradigms that WordPress has introduced, from React blocks to comment blocks on your PHP?

00:51:38

Fabian: Yeah. The entire ecosystem has certainly shifted a whole lot in the last five years, and I don't expect that to really slow down anytime soon. That is a lot and a lot to handle. That is something that, even for us as a large agency that has super-talented folks working for it that have worked with WordPress for literally decades in some cases, it has been a struggle and it is a struggle, and I can totally emphasize with that.

The thing to put some folks at ease, WordPress very much is dedicated to backwards compatibility. And so, if you are starting today and do author your theme in the way that you did almost 20 years ago, that is still going to work and that is not going anywhere because WordPress is not just block-based Gutenberg stuff and site editor. But WordPress also... I just saw the numbers yesterday from WordCamp US that is happening right now. I think Elementor has 17 million active sites now, and they don't use blocks as their architecture. They use what's much more akin to that traditional WordPress, PHP-based templating. And so, even though there is this whole new world on top of WordPress that is using this block-based theme that is the direction that WordPress core is taking, that foundation is not going away, and that foundation is here to stay.

It is just the WordPress core team and kind of leadership did not see, with the demands of other builders like Squarespace and all the others, the actual demand for users who want to just build a quick website for themselves, they don't want to learn CSS. They don't want to learn how to code. They want to be able to visually just build their site, customize it, and kind of do that kind of stuff. In order to meet that, that is the whole rationale of why all of this stuff was built.

Yeah, that old way brought WordPress to that 43% market share of the popular sites on the Web. But that trend is going down. That trend has been going down for a few years now. In order to be ready for that next 20 years, that is why that shift has happened.

Chris: You can do it the old way if you want to.

Fabian: You can do it the old way.

Chris: The argument against doing it the old way is that you know that you're doing it the old way.

Fabian: Yeah.

Chris: You feel like you're doing it the old way. You're not... You go to conferences and nobody is talking about doing it the old way. It will slowly feel like it deteriorates on you, and it's just not a good feeling.

00:54:31

Fabian: One thing to that, though, that I haven't mentioned yet is those two modes are entirely... You can use both at the same time. If you have an existing theme, that PHP template hierarchy continues to work. If you add a new, one of those HTML templates, that template is just going to override that particular other PHP template.

Chris: Hmm...

Fabian: You could start to introduce just, "Hey, on my conference site, I'm going to leave that conference template as a PHP template because I did a lot of custom work on that. But actually, I'm introducing this new area of my site for another unrelated conference or for showing the team that actually builds out the conference."

Chris: That's not a block-based theme or an old - whatever we want to call the old theme. It doesn't matter. There's no switch you flip.

Fabian: You can interchangeably use those templates in either approach. The one thing that you will need to adopt at some point is that theme.json file.

Chris: Right.

Fabian: Theoretically, technically that can be an empty JSON file, but it changes some things about the inner workings of WordPress to read from that and to have that.

Chris: Mm-hmm.

Fabian: But yeah, even in a block, fully block-based theme, if you are using that 2025 theme when it comes out in a couple of months, you can then go in and technically create that single conference.php and go to town and just build some stuff in it. That will work. Those two paradigms exist at the same time and are working with one another.

Chris: It's funny. It seems like you could do a lot with 2025. There's a little bit less incentive to design a really cool theme because - I don't know - you can just use 2025, and it has already unlocked almost anything that you can do with a WordPress site with that theme.

Then maybe if you do a really tremendous, interesting, cool job, all you've really got to do then is install this plugin that craps out the templates as HTML and then sell that. [Laughter]

You're like, "Look. I worked on this. It's 2025 Chris edition."

Fabian: Yeah. That is really the one thing that I think has, with this shift to these block-based themes, the responsibility of a theme has been reduced. A theme, at the end of the day, because everything is blocks, the actual features of WordPress.

Hey. New, cool navigation blocks, or querying stuff, or any of those stuff. Those are the blocks, and so those new features get introduced by blocks. The theme, at the end of the day, is just how do I arrange those blocks and what colors and fonts do I want to use.

Chris: Yeah. Yeah, no wonder you made some enemies there, though. There was theme of the month clubs that made so much money and just stuff like that that's just kind of gone now.

Dave: It's kind of back to that old idea of like the C-frame, right? The header, sidebar, footer. Then the block editor is all the content juice. Then you just give it a little bit of JSON to render the content, right? That's it? We're done?

Chris: [Laughter]

00:57:43

Fabian: Yeah, it kind of is that CSS Zen garden from 100 years ago, it feels like.

Chris: Yeah.

Fabian: Where it's just, "Hey, we have this shared markup of these blocks. We have that common language for how we're building these sites. You can theme them with just CSS or that JSON file and that config." That is how those open themes for everybody are being built.

That is not how those very, very complex, big agencies' sites and that stuff is being built for the most part because they are much more single-purpose sites where, "Hey, we have tons of custom post type. We have tons of custom blocks for various particular features and integrations and that kind of stuff." But the beauty is that, at the end of the day, we can use that same foundation and just build on top of it.

Dave: I mean there is something to be said. I do have a hard stop here, but there is something to be said. Now the job of a theme editor isn't just cut 200 themes from scratch. You can make one good, expressive theme and then tweak the right variables and now you have 100 themes - or whatever - 10 really good ones. Maybe that's kind of a positive spin for that.

Chris: There is some detail here. I really like how the spacing variables in 2025 are clamp-based. They literally are clamp expression in CSS.

Dave: That's cool.

Chris: That's pretty classy. Yeah. Sorry, Dave. We went over your thing.

Dave: I do have to go. But thank you so much, Fabian, for coming on the show. I really appreciate it. I have updated a lot of my knowledge here. I'd almost like to try to make a WordPress theme just to feel what it's like now.

Chris: Feel it, man.

Dave: But for people who aren't following you and giving you money, how can they do that?

Fabian: Following just on my entire name all lowercase put together on all the places. I'm happy to chat about all things WordPress, user experience, anything.

And as far as giving me money goes, nobody needs to do that. But if I can ask of something, it's kind of St. Jude childhood awareness, childhood cancer awareness month. So, if you want to put money somewhere, spend it there.

Dave: St. Jude, good cause. Thank you. Awesome. Well, thank you so much for coming on the show.

Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up.

Follow us on Mastodon and then join us in the D-d-d-d-discord, patreon.com/shoptalkshow.

Chris: [Laughter]

Dave: Chris, do you got anything else you'd like to say?

Chris: Oh... ShopTalkShow.com. And again, thanks. That was super enlightening.