In this conversation, Ian Svoboda, a developer at GeneratePress, discusses his background in WordPress development and the collaborative approach at GeneratePress. He explains the functionality of GeneratePress and GenerateBlocks, emphasizing their focus on user experience for both low-code and power users. Ian shares insights into the challenges of implementing new features, the extensibility of the block editor, and the integration with ACF for dynamic data. He also touches on the future of cloud features and the importance of community feedback in product development.
- https://iansvoboda.com/
- https://generateblocks.com/
Brian (00:01)
Welcome, today I’ve got Ian, developer over at the GeneratePress team. Ian, maybe you could give everybody kind of like your background and what actually you do over at GeneratePress.
Ian Svoboda (00:10)
Yeah, sure. So I’ve been doing WordPress development and all around web development things for over 10 years and almost 14 years now, totally. And I started working mainly on WordPress things, did a few other e-commerce platform things in between there, but it’s largely been an emphasis on WordPress and then later React and then custom PHP applications and things. And I’ve worked in a bunch of agencies, large and small. The one that probably anyone’s heard of though, would be Tenup where I worked for a while as a senior software engineer.
Brian (00:37)
Mm-hmm.
Ian Svoboda (00:39)
senior front-end engineer there. And now I work at on GeneratePress working on all the products there. So GeneratePress, GenerateBlocks, GenerateCloud, all that stuff. And yeah, so I’m heavily involved with creating new features as well as working on existing ones, all those different things. We take a really cool collaborative approach there. Tom, the owner of the company and lead developer and stuff, he’s one of those guys that really just loves to work on cool things.
And he wants to, you know, come to a good idea and the best possible idea, you know, best reasonable idea we can do rather than just what’s the what’s something we can sell or something we can market and in the process of making stuff that’s cool and useful. He found something that people wanted to buy and it’s really nice to be a part of that. I get to do a little bit with the support forms here and there just, which I actually kind of like because I have a support background. I used to do that a lot before I got like multi-channel support before I ever got into web dev.
Brian (01:09)
Mm-hmm.
huh.
Ian Svoboda (01:38)
So it’s nice. I kind of get to do all kinds of things, but it’s all really fun stuff. Really cool stuff.
Brian (01:44)
And how do you describe
GeneratePress and GenerateBlock specifically? Do you guys use the term page builder or do you have a specific term for how you describe what kind of the core offering is?
Ian Svoboda (01:58)
I mean, I think that maybe some people might answer that question a little bit differently than others. like for me, it’s like the page on the page builder part. I mean, we don’t, we don’t have our own page builder. We are using, we’re like a blocks plugin. So we add blocks to the editor or, you know, we add controls to the, native WordPress options, but it’s, it’s an all in one solution for building WordPress sites as close to core as you probably reasonably want to is a good way that I would
We try to leverage a lot of the core mechanisms in what we build and then where we need to color outside the lines or kind of add a little bit more to bridge a gap, to make things easier for people or what have you, then that’s where we…
Brian (02:28)
Okay.
What do you think was the decision to go all in on blocks versus, say, make your own page builder?
Ian Svoboda (02:48)
that’s a good question. I think Tom would probably be a little bit better suited to answer than me. But I think that the thing that attracted me the most to that idea myself was we’re making something that has a lot better interop with other things. So you can have other blocks, things that play nicely with our things instead of having to say, well, you have to go really all in on this one ecosystem to be able to leverage the stuff that we have.
Brian (02:53)
Mm-hmm.
Ian Svoboda (03:15)
I think that’s probably the biggest overall benefit of that decision. As far as why though, I mean, that’s more of a Tom question.
Brian (03:22)
Yeah. Yeah. Yeah. I mean, I think that’s like kind of the value of the block editor where you look at every plugin and then they’re like, okay, now we have Elementor compatibility, Beaver Builder, like they have to build their like compatibility for every single thing, or they have to use like legacy short codes. And then once you’re in like the blocks world, you’re like, oh, this plugin has block, this plugin has block. can use, you know, you guys have a lot of like structural blocks, right? Like things that are more for layouts like that, but you could bring in some forms plugins. It’s just feels like it’s a better place where things kind of
commingle a little bit.
Ian Svoboda (03:54)
Yeah, right. And you know, one of the things that is key about all of our offerings right now, like the Generate Press stuff, you have all these cool pro features. Those are all modules you can turn on and off. So it’s kind of designed to be like use as much or as little of it as you want. And I think that’s really nice when you’re talking about playing with other things. So then you can say, well, I want to use these Generate Blocks to lay out this section and I want to use these for styling. But then this one thing over here, you know, I want to do this way with it you can…
There’s a lot of flexibility of approach there, but not so much where it’s like, which thing do I do? It’s more like there are easy options, reasonable escape patches, ways to color outside the line safely as far as it goes.
Brian (04:26)
Hmm.
When you’re thinking about who’s gonna use it, do you feel like you have developers who are maybe more WordPress code knowledgeable, maybe they understand WP query, things like that, or do you have people who are more focused on just the visual aspect of building out a page or something like that? Do you guys have a specific niche?
Ian Svoboda (04:59)
think that in general, the vast majority of people, and this is kind of like inescapable for a product that has this many users anyway, but like, yeah, the vast majority would be like more like low or no code types of folks, I would say, or at least that’s the way that it usually ends up being used. Like there’s sites that I build with this stuff where I don’t need to do a bunch of heavy developer things. Like I maybe use a little bit of extra CSS here and there.
a couple filters here or there, but it’s all really basic stuff compared to the type of custom theme development things that I’ve had to do most of my career. I think that in general, those folks like many things, know, like when you read GitHub issues and support forums, there are more technical topics. You usually get those technical people or people who aren’t scared of those things coming out. It feels like these are the only people I hear from.
That’s because those other people just don’t reach out that way or they don’t reach out at all, or they say, no, I’m going to try this other tool. But yeah, I think, I think first and foremost, we, when we make these things, we try to optimize for. What is the most reasonable, what’s going to take care of the most people’s needs here? What are most people really wanting? Most people don’t necessarily, and this even goes for developers. Not every developer understands how grid template columns works or how, you know, these various, which font.
Brian (05:49)
Mm-hmm.
Yeah.
Mm-hmm.
Ian Svoboda (06:18)
thing do I choose or whatever, you know, some of this is unavoidable where you got to kind of learn it to really understand, but some of this is like, just make it easy for me. And even for people like us, man, like you can just click a button and it does what you know what to do, then great, right? That’s easier for everybody. But yeah, we try to optimize, I think for the non power user first, while in the process though, we still make some pretty sweet power user features too, right? So think it’s a good framing.
Brian (06:26)
Yeah
And
it’s an interesting thing because you come from an agency background where I’m sure you built a lot of really complicated custom stuff. Even just to build something like generate blocks, you have to have some pretty deep React knowledge. You have to really understand all of that sort of stuff. And I feel like there’s always this gap between the skills you have to have to really do these power user things. And then who I think WordPress is always trying to appeal to, which like you said, is the no code.
or low code user. like, you have to like context shift at all when you’re thinking like, man, I know I can, I know I gotta dig deep into this crazy React stuff to like build out what I’m trying to make happen. And at the same time, like you said, like translate it to just feel intuitive to somebody who doesn’t really know or care what’s under the hood.
Ian Svoboda (07:34)
Yeah, and it’s tough sometimes when you have to do this really complex technical implementation for something and then it turns out that, you actually just over complicated this whole thing in the process. And maybe there, it still is complicated, but it’s not that complicated in that sort of way. And that’s sort of, that becomes a little tricky at times with the, with the editor itself, because sometimes the, like there’s an update.
and something changes. And so now you have this non-experimental API that was experimental before. And now you have to kind of make these other changes and adjustments. yeah, sometimes it can be, but we try to heavily test these things just like ourselves. And we have a lot of non-developer folks that we work with on the team in various roles who we have. we’re like, hey, man, come take a look at this. Or, hey, can you give us your feedback on this thing and whatever? then
Brian (08:05)
Mm-hmm.
Hmm
Ian Svoboda (08:29)
combine that with like beta and alpha testing. And we usually seem to do, I think, okay on that. Like we, don’t think there’s been an enormous miss that I can think of where it was like, wow, we really massively overcomplicated that whole thing. But there, was definitely some fun technical challenges that have been solved, like some, some crazy stuff that we, that we’ve had to write that just to make really simple yet powerful features.
Brian (08:57)
Yeah, like one of the big changes, it feels like recently, is a lot of people really want like class-based styling. They really want like more robust, know, obviously responsive controls, all these sorts of things. These are like things that you are working on implementing, things that people say like, I wish the block editor did this, but I have to imagine you’ve maybe learned like just how hard it is to, like, it’s easy to say this is what I want, but to actually make it happen. Has it been hard to get those sort of like advanced tools?
Ian Svoboda (09:25)
I mean, I think that the the crud like the it’s interesting, probably 80 % of most of the really good ideas that we have, like the 80 % of the ideas a whole that part happens pretty quick, right? Like, sometimes Tom will come back to me and say, wow, like, check out this thing I just I just did over the weekend. I don’t know about
I don’t know if it seems like it was almost too straightforward. I’m like, no, I think it’s exactly straightforward enough, right? Like this is amazing. And sometimes those things can fall into place pretty quickly, but a lot of it comes down to you really have to commit to making decisions. You have to make a decision about things like say with the block attributes. When we were coming up with this concept for the styles.
All those styles live inside a single styles attribute. So we don’t have to add like an attribute for every single CSS property or something, right? Just nightmare from a maintenance perspective. But it’s like, if that’s what you’re gonna do, now you have to lean into that and you really have to start doing things a certain way. you know, with the block editor, there’s not always an easy way to say, everybody needs to do it exactly one way the other, like static or dynamic blocks or do
use like these kind of more object driven attributes or you have them enumerated more specifically, whatever. So yeah, I mean, there’s definitely a challenge there. I think there’s a bigger challenge when you’re building a product like Gutenberg, because you have to sort of appeal to all the possible options. And I think that’s kind of part of the reason why a lot of the. I hesitate to say the word like narrative, but like the things that I’ve been hearing the people in the dev team say tend to skew more towards like we need to get more opinionated about some of this stuff so we can.
make more of these decisions, right? Like, yeah, so I appreciate the complexity that comes with that, for sure.
Brian (11:13)
Yeah, I mean, there’s also like, I would say like a narrative in the community that it’s really hard to extend the block editor, but obviously you guys are doing it. So, I mean, do you think it’s gotten easier? Do you feel like there’s like a path towards it or is it just because you’ve staked out like a larger domain where you can say like, well, no, this is a custom block. So now we can do whatever we want or we have our own styling engine so we can do whatever we want. Like how has that extensibility happened?
Ian Svoboda (11:39)
Yeah, mean like the core, it’s interesting because when we first came up with this whole idea, know, Tom had this notion of wanting to do the blocks a certain way, which we tried to do and I won’t get into It would be too much to details wise to get into, but it’s, we had to sort of go back to the drawing board one or two times, but we ended up landing on this concept of having a couple core blocks that we then make variations of, right? And the variation.
Brian (12:04)
Mm-hmm.
Ian Svoboda (12:06)
for the benefit of anybody watching, a block variation is essentially just a combination of attributes associated with a given block, right? So you say if this block has all of these things set, or this thing set, that makes it a whatever block or something, like say a text block versus a button block. Those were both the same core block under their hood. They’re just variations and things like that. And I think that having more of a sort of flexible approach where we have
Brian (12:19)
Yeah, yeah, yeah.
Ian Svoboda (12:33)
something like that or like a styles object that then just all the styles are in there. It makes it way easier because then we can create a new block and we can apply our styling engine to it and boom, it just works. Global styles, just, they just work. You know, we get a few H O C’s, we line them all up and everything just kind of jams. And if you really build things in a way that’s designed to be fundamentally pluggable, I think you’re going to have a better time of it anyway. It doesn’t mean that everything’s simple though, cause like
Brian (12:46)
Mm-hmm.
Ian Svoboda (13:01)
Variations aren’t actually blocks. So you can’t do certain things that are like say you can’t limit them in the insert or the same way as just a regular box could or there’s that’s why we had to make certain blocks like the loop item or other things like that, which is kind of, which seems kind of weird if you say, well, you have these like the element and the text block and you use those to make all these. Sometimes you have to do something different, but that’s the, that’s, I think that’s probably the biggest thing I’ve seen go wrong with most people’s implementations.
Brian (13:10)
Yeah, yeah.
Ian Svoboda (13:31)
things. It’s like if they’re doing an extending project to extend the editor, they’ll get it in their head that they have to do it in this one very specific manner. And so then they’ll do it that way, even if it is kind of like rough in these other areas, or they just kind of abandon the project and like the notion of doing it all a certain way at all. And then everything’s just kind of spaghetti. And then in both of those types of cases, you’re in for a bad time, right? Like you got to kind of look at this and say, I don’t think that this is exactly right here, but we can do this thing differently over here.
Brian (13:38)
Mm-hmm.
Ian Svoboda (14:00)
because it’s for a really good reason. It actually makes a lot of sense. And I think that’s made some of these things a little bit easier. Lean into the core features. Do it this way as much as you can. Color outside the lines just where you need to.
Brian (14:02)
Uh-huh.
Yeah, I was over the holiday break. was experimenting with building a plugin for something in the block header where I was like, I really want this feature doesn’t exist. I’ll see if I can build it for fun. And I was really struggling with a few things. And one of them, like you said, was that idea of like, like there’s three different ways to build it. And I keep trying each different one and you’re like losing sort of the overall picture. And then, so I have like all these branches of like, try this, try that.
re-delete everything and redo it. But the one thing that really tripped me up the most was that I hit a point where what I was trying to build was not going to really be valuable if you couldn’t have some sort of a responsive control to it. Like you couldn’t have different styles on desktop and mobile. That was like one of the key things that this feature I’m trying to build needs. then I sat there and I thought, well, that’s not in core.
If they’re just using a simple core theme like 2024, then I have to build this all from scratch. If they’re using another plugin that has responsive controls, now I have duplicate responsive controls. There’s not like an abstract library I can pull in that comes from core and stuff like that. And I kind of, I don’t know, I might even abandon it. I hit a point where I was like, it seems like a problem that is insurmountable. Did you ever hit like problems like that where you’re just like, this is just such a thing that like, if we do it our own weird way.
it’s just going to cause problems for any other integrations or is it kind of fine because you you are the sort of base level integration for them.
Ian Svoboda (15:45)
Yeah, I don’t know. mean, we don’t, we don’t really go out of our way to make sure our plugin plays nice with every other plugin there is, of course, or things like that. But we also go out of our way to make sure that it’s not unnecessarily like hard coded or static in certain ways. Like trying to like it as an example, if we’re going to get the WordPress excerpt or something, you know, we’ll apply the filters that would normally be used there.
Brian (16:05)
Mm-hmm.
Ian Svoboda (16:14)
things like that to try to make things as smooth as possible with the notion being like it should try to be as unhacky as it can be. So that way it does play nicer with other stuff. Like I think in a way doing that is almost more valuable than like trying to do a bunch of really meticulous research unless you’re building like an integration of some sort. Right? Like a good example of that in that last part would be like this thing we did with the dynamic tags. We’re in pro we have an ACF in
Brian (16:15)
Yeah.
Mm-hmm.
Ian Svoboda (16:43)
Now, in the free version, it’ll still list the ACF fields because they’re all post meta, but it just won’t put them in a certain order and make them all nice in the editor so it’s more clear which ones you probably want to choose and things like that. So we wrote that specifically with ACF compatibility in mind. It uses these ACF methods to tell if it’s actually an ACF field or not and things like that. There’s a way to even modify.
Brian (16:44)
Mm-hmm.
Yeah.
Ian Svoboda (17:12)
that process if you’re using like an ACF custom table plugin or something actual thing that we were asked about, you know, where it’s like not stored in post-meta at all. You know, it’s flexible enough to support all of those types of use cases just because we’re again trying to keep it simple, use as many like reasonable kind of core things first and then where we can appropriately add filters and things like that. Trying to document a lot of those as we go too.
Brian (17:19)
Mm-hmm.
Yeah, yeah, yeah, I’ve seen that.
Yeah, ACF is actually a really good example of that because I’ve been really interested in the block bindings API in core, which is this idea that they’re going to start bringing custom fields and meta and stuff into like a more dynamic experience and stuff. But ACF isn’t going to work with it, you know, out of the box because ACF has to do things a little differently when they register meta, for example. like, you know, ACF like custom fields registered in ACF aren’t quite quite like the same as like regular custom fields because
they needed to make it more powerful and they needed to go a different route and stuff. And now as it comes back around, it’s like, okay, well then that’s, I guess, gonna just be on ACF’s team to build that sort of integration. And I guess that’s your sort of responsibility too. guess if ACF’s that big of a player, you guys kinda have to, at some level, work with it, because otherwise, why would people wanna use your plugin?
Ian Svoboda (18:32)
Yeah, absolutely. And in this case, I think our integration for doing dynamic post meta things and ACF things like that, where you’re not just like, you know, where you’re actually using them in the editor and stuff. It’s pretty top tier. I’m not, I don’t know every other plugin out there. There’s probably going to be someone that goes, Hey man, this other thing. I’m sure, sure. There’s other things out there that might do something similar, but ours is pretty sick. Like when you say I want a post meta key, it doesn’t matter where that thing comes from.
Brian (19:00)
Hmm.
Ian Svoboda (19:00)
It could be
any post meta key that you could possibly think of. If it’s a real post meta key that is available for that thing, you can do stuff to it. Additionally, even if that key is an object or an array of key data, you can still access all of it too using a dot notation syntax. So if you have like an ACF image field that returns as an array, you can say image dot alt, image dot URL, image sizes large URL or something, and you can just get all of that.
And it doesn’t matter where that stuff comes from. all works. Our integration allows you to also like if you’re say like a pods or something or some other, you make your own custom meta box plugin and you want to do something, you know, to get into there in that process. have a filter that people can use for that. And it short circuits our entire original lookup. So it doesn’t look up the value twice. It takes all the advantage of the WordPress caching things.
but it’s super flexible for being able to just pluck data out of any structure. You take a repeater that’s in a group and then you want to get, the, you put a post object in there and you want to get the status off the post object. You can do all that, all that stuff, all possible out of the box. It just works. And then when you like, when you go in there to set the keys, it’s all, it’s very user friendly though. It’ll enumerate the keys where it can. So it makes a list for you. So you don’t have to remember what they all are, but
Brian (20:08)
Cheers.
Ian Svoboda (20:22)
It doesn’t just throw every single key there ever was into a big list, which I don’t find very, uh, there’s a couple of plugins I’ve seen that do that when you’re doing these meta integrations, it just gives you every key that’s registered. And it’s like, that’s kind of confusing. What if that key doesn’t exist in this post? What if that, uh, isn’t an ACF thing that I want? I don’t know. You know what I mean? But it’s, it’s a really nice system. And that kind of was, uh, that whole thing, that whole meta lookup system is actually available to people. Like if you’re a developer nerd, who’s here in this and you’re like,
PHP templates. You can. Because we made a handler for doing all of this stuff. There’s REST endpoints for doing it too. So if you want to do those types of lookups in JS, it all works. So there’s a lot of really nifty. And see, that’s an example of we wanted to make it really easy for people to just use ACF, just use their post meta. It doesn’t matter where it comes from. I know it’s this post object that we set as post meta. I just want to get this thing that I know is on the post object. Great. You just do that, and it just works.
And in the process of doing that, we actually made something really powerful that we then were able to expose for other people to be able to use if they wanted to.
Brian (21:30)
And so you don’t give, like for example, do you offer the functionality of like registering post types, registering custom fields and stuff, or do you say, hey, there’s a solution for that, it’s ACF, everybody loves it, we’ll just integrate with that. Or do you guys, like when do you draw the line and say like, well, we should have our own form, we should have our own custom field UI, we should have our own, so on and so
Ian Svoboda (21:51)
I don’t know. mean, again, that’s kind of a little bit more of a bigger picture question. I think Tom is probably the person who’d give you the best answer there. But I think that we want to try to focus on like making tools, the output, clean things that people can use well. And so it all starts with having this framework, this bedrock of like the styles engine and these other blocks. Now that we have those, I mean, that enables us to more easily do things like say like
carousels or more interactive components or things like that. But I would be, I’m not sure that we would be like looking to get into the forms or the custom UI, the custom field space or any of that kind of stuff soon. Cause it’s like you said, there’s a lot of good established solutions for that, but it’s kind of like for us, like we have a lane that we occupy really well. Like if you want to make markup, that’s as close to hand coding it yourself as possible.
and have something that’s friendly but works and you can do things fast, that’s us. But playing nice with others is another big part of what we do too. So I think we just try to look at it as like, can we properly serve people in the solving the problem that we’re trying to solve for them by doing things in this way that doesn’t involve making our own version of something? It’s kind of like an NPM package, right? Like if you find one.
Brian (23:06)
Mm-hmm.
Ian Svoboda (23:14)
that’s really good, it’s well maintained, it does everything. You don’t have to spend 10, 15 hours building it for a client and they’re paying you by the hour or something. Well then sure, you’d be remiss not to use it, right? But if using that thing comes with a, you have to rewrite your whole API to work with it and then, well, they update and it’s all this stuff and it’s like, well, is it worth it anymore? Maybe not. So maybe then we look at kind of doing our own thing, right? But I think that Tom has a really good radar for that sort of stuff. And over the years, people have
I think people have really developed a strong trust in his intuition for that sort of thing. Like this whole styles object was just an idea he had at one point that he just put together and I was like, bro, this is fantastic, right? He’s got a really good radar for that stuff. So I’m thankful to work with a guy like him to be able to help with these kind of guiding product decisions and that sort of thing. That’s really nice.
Brian (23:56)
Mm-hmm.
He’s like page builders sort of become are like fashionable or trend, you know, and it sort of becomes like this month’s page builder suddenly falls out of fashion or everybody’s mad because this one is not as clean of the markup because now we need cleaner markup. And it’s always good criticisms of each page builder. Like this one is, know, whatever the problem is, it’s not performing enough. The code output is not accessible and it’s good. It’s like, it’s nice to see that we demand more from our builders and stuff, but obviously like you have.
to have like you said, like a clear product vision and somebody who understands product and that’s, you know, very important, especially in WordPress. But then also I’m guessing you guys have some sort of like feedback loop with community or like you guys do, like how do you stay in touch with the people that are using it to make sure, you know, they’re happy with it, that they’re enjoying what you’re building.
Ian Svoboda (24:57)
sure,
tons of different ways for that. There’s obviously things like the support forms and support tickets that people send in, but then there’s also things like the Facebook community, there’s just the discussion and discourse that you find on Twitter. And I gotta say that I was really happy to join this team originally because one thing I found when I was looking is like almost all the feedback on this thing is relentlessly positive. You look at the January Press and January Blocks feedback, people just go.
Yeah, this is really great. And it’s something that, you know, they work really hard to make sure the updates are good and all that. And like that’s something that I wanted to be a part of when I saw that, because that’s the type of thing that I want with products that I would make. Like if I was making my own product, I would want people to say that sort of thing. And so you don’t base maybe everything you do based on just what people ask for, right? But there’s certain things that you can see, like when we get these GitHub issues or
Support threads or whatever and people I just want to throw it out there to any of the people who do that stuff that watches stuff You guys are great by and large almost everything I read is helpful and useful Everybody’s really cool and it’s it’s really an honor to be able to work on this product for all these people And be able to make something that lets people make other stuff or generating tools Sorry unavoidable But yeah, I mean like that’s that’s something though that we really care about because we don’t We don’t make this for
Brian (26:00)
Yeah.
Ian Svoboda (26:20)
us. It’s not just for people like me or people like Tom or whatever. It’s bigger than that.
Brian (26:26)
Yeah.
And then the last thing you guys did was is the cloud stuff. That’s like newer, right? The cloud library. How’s that going?
Ian Svoboda (26:35)
Uh, that’s pretty sweet. We’re going to be, think, working on some additional new features. Like I think there’s still a discussion on how we’re going to do it, but we want to do things to like integrate like the font library and maybe like the global style system a little more with that. So you can just have this like ultimate home base, if you will, for all of your things that you’ll be able to just send out everywhere. It’s a really neat concept. There’s a lot of, um, there’s a lot of potential to it that is still yet to come. Right.
But it’s a lot of power, especially if you’re a freelancer type person or somebody like an agency who likes to kind of build from, you have a couple of set site patterns that you like to start people off on, you know, as your boilerplate. This is a great sort of product for that.
Brian (27:21)
Yeah, I’m like super bullish on cloud libraries for WordPress. feels like the next sort of big thing that needs to be solved and it’s nice to see people are starting to solve it. I feel like there’s been ones in the past, but I think it’s taken until we’ve had like the Gutenberg era to like really solidify just the fact that WordPress now has a consistent approach to markup and styling and
people who use your plugin are gonna have a consistent approach to markup and styling. It now makes it so much easier to say like, yeah, we can start like having structural patterns, design libraries, things like that floating around that you can just like set just pulling to any site. I think that’s gonna be probably the big frontier of WordPress, hopefully.
Ian Svoboda (28:05)
Yeah, yeah, definitely. And like with the new font stuff that we were just doing too, I think there’s a lot of cloud potential for that as well. That feature, by the way, is freaking so cool. It’s not an… That is a GP premium feature where we have a brand new font library and it’s kind of sort of similar. Like if you look at it, it’ll probably look a little bit like the core one in WordPress. It is in many ways based on it. Like the…
Brian (28:17)
So what’s the new font thing? Cause I don’t know if I’ve seen it.
Ian Svoboda (28:34)
heavily inspired by based on a true story, if you will, right? But we did a lot of extra things that the core one doesn’t do. Like talking about the whole, is where we have to color outside the lines kind of situation, right? Like when you’re installing Google fonts from there, it doesn’t actually install any variable fonts, even if the font is a variable font, it forces it to have the like big chunky, non-optimized, unsubsetted version of those fonts.
Brian (28:35)
huh. Yeah, yeah, yeah.
Hmm.
Yeah.
Ian Svoboda (29:02)
All the font files that that thing pulls are ginormous. Like in our tests, they’re all just way larger than like if you went to Google Fonts and just got them. And so we were like, why is that? And we figured out that was just because of the way that the Google Fonts API works. If you haven’t seen it, by the way, the way that WordPress actually, like Gutenberg actually generates those font choices is they have a whole repo package for this, where they generate these like inline SVG fallbacks and stuff. It’s actually kind of an interesting little mechanism.
Brian (29:24)
Okay.
Ian Svoboda (29:30)
you know, in general, but it’s really neat. Like we, we basically took a lot of that stuff and then we found ways to optimize it further. added subsetting mechanisms and these other things so that it’s downloading like the, fastest and best version of the file. If there’s a variable version, it gets it for you automatically. It handles all of that stuff. It generates a CSS variable for you to use. You can choose the fallbacks on the font, all that. It’s very, it’s really customizable. It’s really sweet.
Brian (29:30)
Okay.
yeah.
Nice. And I feel like we just like scratched the surface because I feel like you and I could probably go deep on like one specific thing and talk about how you accomplish and stuff like that, which I think we should do in the future. overall, where can people go to kind of get more information from you? I mean, you’re always sharing kind of like cool stuff. I feel like I’m always learning from you online. So where do you recommend people go to follow you?
Ian Svoboda (30:21)
Well, probably the best place would be like blue sky or Twitter. So that’s at Ian’s foe in both places It’s like at Ian’s flow dot B sky social or whatever it is over there and then I have my personal site which I’m working on revamping so that I can Follow your footsteps a little bit more and start writing a bit more on right because I have been woefully Neglecting that so I’m gonna be trying to really revamp my my personal blog efforts And then I have the learn WP theme dev site
Brian (30:32)
Nah.
Ian Svoboda (30:49)
which we’re also gonna be making some updates to. And I think I have some exciting changes on that coming up. So all good things to stay in touch about.
Brian (30:57)
Awesome, man. Thanks for coming and talking. Hope we’ll chat again soon.
Ian Svoboda (31:00)
Yeah, definitely.
Welcome, today I’ve got Ian, developer over at the GeneratePress team. Ian, maybe you could give everybody kind of like your background and what actually you do over at GeneratePress.
Ian Svoboda (00:10)
Yeah, sure. So I’ve been doing WordPress development and all around web development things for over 10 years and almost 14 years now, totally. And I started working mainly on WordPress things, did a few other e-commerce platform things in between there, but it’s largely been an emphasis on WordPress and then later React and then custom PHP applications and things. And I’ve worked in a bunch of agencies, large and small. The one that probably anyone’s heard of though, would be Tenup where I worked for a while as a senior software engineer.
Brian (00:37)
Mm-hmm.
Ian Svoboda (00:39)
senior front-end engineer there. And now I work at on GeneratePress working on all the products there. So GeneratePress, GenerateBlocks, GenerateCloud, all that stuff. And yeah, so I’m heavily involved with creating new features as well as working on existing ones, all those different things. We take a really cool collaborative approach there. Tom, the owner of the company and lead developer and stuff, he’s one of those guys that really just loves to work on cool things.
And he wants to, you know, come to a good idea and the best possible idea, you know, best reasonable idea we can do rather than just what’s the what’s something we can sell or something we can market and in the process of making stuff that’s cool and useful. He found something that people wanted to buy and it’s really nice to be a part of that. I get to do a little bit with the support forms here and there just, which I actually kind of like because I have a support background. I used to do that a lot before I got like multi-channel support before I ever got into web dev.
Brian (01:09)
Mm-hmm.
huh.
Ian Svoboda (01:38)
So it’s nice. I kind of get to do all kinds of things, but it’s all really fun stuff. Really cool stuff.
Brian (01:44)
And how do you describe
GeneratePress and GenerateBlock specifically? Do you guys use the term page builder or do you have a specific term for how you describe what kind of the core offering is?
Ian Svoboda (01:58)
I mean, I think that maybe some people might answer that question a little bit differently than others. like for me, it’s like the page on the page builder part. I mean, we don’t, we don’t have our own page builder. We are using, we’re like a blocks plugin. So we add blocks to the editor or, you know, we add controls to the, native WordPress options, but it’s, it’s an all in one solution for building WordPress sites as close to core as you probably reasonably want to is a good way that I would
We try to leverage a lot of the core mechanisms in what we build and then where we need to color outside the lines or kind of add a little bit more to bridge a gap, to make things easier for people or what have you, then that’s where we…
Brian (02:28)
Okay.
What do you think was the decision to go all in on blocks versus, say, make your own page builder?
Ian Svoboda (02:48)
that’s a good question. I think Tom would probably be a little bit better suited to answer than me. But I think that the thing that attracted me the most to that idea myself was we’re making something that has a lot better interop with other things. So you can have other blocks, things that play nicely with our things instead of having to say, well, you have to go really all in on this one ecosystem to be able to leverage the stuff that we have.
Brian (02:53)
Mm-hmm.
Ian Svoboda (03:15)
I think that’s probably the biggest overall benefit of that decision. As far as why though, I mean, that’s more of a Tom question.
Brian (03:22)
Yeah. Yeah. Yeah. I mean, I think that’s like kind of the value of the block editor where you look at every plugin and then they’re like, okay, now we have Elementor compatibility, Beaver Builder, like they have to build their like compatibility for every single thing, or they have to use like legacy short codes. And then once you’re in like the blocks world, you’re like, oh, this plugin has block, this plugin has block. can use, you know, you guys have a lot of like structural blocks, right? Like things that are more for layouts like that, but you could bring in some forms plugins. It’s just feels like it’s a better place where things kind of
commingle a little bit.
Ian Svoboda (03:54)
Yeah, right. And you know, one of the things that is key about all of our offerings right now, like the Generate Press stuff, you have all these cool pro features. Those are all modules you can turn on and off. So it’s kind of designed to be like use as much or as little of it as you want. And I think that’s really nice when you’re talking about playing with other things. So then you can say, well, I want to use these Generate Blocks to lay out this section and I want to use these for styling. But then this one thing over here, you know, I want to do this way with it you can…
There’s a lot of flexibility of approach there, but not so much where it’s like, which thing do I do? It’s more like there are easy options, reasonable escape patches, ways to color outside the line safely as far as it goes.
Brian (04:26)
Hmm.
When you’re thinking about who’s gonna use it, do you feel like you have developers who are maybe more WordPress code knowledgeable, maybe they understand WP query, things like that, or do you have people who are more focused on just the visual aspect of building out a page or something like that? Do you guys have a specific niche?
Ian Svoboda (04:59)
think that in general, the vast majority of people, and this is kind of like inescapable for a product that has this many users anyway, but like, yeah, the vast majority would be like more like low or no code types of folks, I would say, or at least that’s the way that it usually ends up being used. Like there’s sites that I build with this stuff where I don’t need to do a bunch of heavy developer things. Like I maybe use a little bit of extra CSS here and there.
a couple filters here or there, but it’s all really basic stuff compared to the type of custom theme development things that I’ve had to do most of my career. I think that in general, those folks like many things, know, like when you read GitHub issues and support forums, there are more technical topics. You usually get those technical people or people who aren’t scared of those things coming out. It feels like these are the only people I hear from.
That’s because those other people just don’t reach out that way or they don’t reach out at all, or they say, no, I’m going to try this other tool. But yeah, I think, I think first and foremost, we, when we make these things, we try to optimize for. What is the most reasonable, what’s going to take care of the most people’s needs here? What are most people really wanting? Most people don’t necessarily, and this even goes for developers. Not every developer understands how grid template columns works or how, you know, these various, which font.
Brian (05:49)
Mm-hmm.
Yeah.
Mm-hmm.
Ian Svoboda (06:18)
thing do I choose or whatever, you know, some of this is unavoidable where you got to kind of learn it to really understand, but some of this is like, just make it easy for me. And even for people like us, man, like you can just click a button and it does what you know what to do, then great, right? That’s easier for everybody. But yeah, we try to optimize, I think for the non power user first, while in the process though, we still make some pretty sweet power user features too, right? So think it’s a good framing.
Brian (06:26)
Yeah
And
it’s an interesting thing because you come from an agency background where I’m sure you built a lot of really complicated custom stuff. Even just to build something like generate blocks, you have to have some pretty deep React knowledge. You have to really understand all of that sort of stuff. And I feel like there’s always this gap between the skills you have to have to really do these power user things. And then who I think WordPress is always trying to appeal to, which like you said, is the no code.
or low code user. like, you have to like context shift at all when you’re thinking like, man, I know I can, I know I gotta dig deep into this crazy React stuff to like build out what I’m trying to make happen. And at the same time, like you said, like translate it to just feel intuitive to somebody who doesn’t really know or care what’s under the hood.
Ian Svoboda (07:34)
Yeah, and it’s tough sometimes when you have to do this really complex technical implementation for something and then it turns out that, you actually just over complicated this whole thing in the process. And maybe there, it still is complicated, but it’s not that complicated in that sort of way. And that’s sort of, that becomes a little tricky at times with the, with the editor itself, because sometimes the, like there’s an update.
and something changes. And so now you have this non-experimental API that was experimental before. And now you have to kind of make these other changes and adjustments. yeah, sometimes it can be, but we try to heavily test these things just like ourselves. And we have a lot of non-developer folks that we work with on the team in various roles who we have. we’re like, hey, man, come take a look at this. Or, hey, can you give us your feedback on this thing and whatever? then
Brian (08:05)
Mm-hmm.
Hmm
Ian Svoboda (08:29)
combine that with like beta and alpha testing. And we usually seem to do, I think, okay on that. Like we, don’t think there’s been an enormous miss that I can think of where it was like, wow, we really massively overcomplicated that whole thing. But there, was definitely some fun technical challenges that have been solved, like some, some crazy stuff that we, that we’ve had to write that just to make really simple yet powerful features.
Brian (08:57)
Yeah, like one of the big changes, it feels like recently, is a lot of people really want like class-based styling. They really want like more robust, know, obviously responsive controls, all these sorts of things. These are like things that you are working on implementing, things that people say like, I wish the block editor did this, but I have to imagine you’ve maybe learned like just how hard it is to, like, it’s easy to say this is what I want, but to actually make it happen. Has it been hard to get those sort of like advanced tools?
Ian Svoboda (09:25)
I mean, I think that the the crud like the it’s interesting, probably 80 % of most of the really good ideas that we have, like the 80 % of the ideas a whole that part happens pretty quick, right? Like, sometimes Tom will come back to me and say, wow, like, check out this thing I just I just did over the weekend. I don’t know about
I don’t know if it seems like it was almost too straightforward. I’m like, no, I think it’s exactly straightforward enough, right? Like this is amazing. And sometimes those things can fall into place pretty quickly, but a lot of it comes down to you really have to commit to making decisions. You have to make a decision about things like say with the block attributes. When we were coming up with this concept for the styles.
All those styles live inside a single styles attribute. So we don’t have to add like an attribute for every single CSS property or something, right? Just nightmare from a maintenance perspective. But it’s like, if that’s what you’re gonna do, now you have to lean into that and you really have to start doing things a certain way. you know, with the block editor, there’s not always an easy way to say, everybody needs to do it exactly one way the other, like static or dynamic blocks or do
use like these kind of more object driven attributes or you have them enumerated more specifically, whatever. So yeah, I mean, there’s definitely a challenge there. I think there’s a bigger challenge when you’re building a product like Gutenberg, because you have to sort of appeal to all the possible options. And I think that’s kind of part of the reason why a lot of the. I hesitate to say the word like narrative, but like the things that I’ve been hearing the people in the dev team say tend to skew more towards like we need to get more opinionated about some of this stuff so we can.
make more of these decisions, right? Like, yeah, so I appreciate the complexity that comes with that, for sure.
Brian (11:13)
Yeah, I mean, there’s also like, I would say like a narrative in the community that it’s really hard to extend the block editor, but obviously you guys are doing it. So, I mean, do you think it’s gotten easier? Do you feel like there’s like a path towards it or is it just because you’ve staked out like a larger domain where you can say like, well, no, this is a custom block. So now we can do whatever we want or we have our own styling engine so we can do whatever we want. Like how has that extensibility happened?
Ian Svoboda (11:39)
Yeah, mean like the core, it’s interesting because when we first came up with this whole idea, know, Tom had this notion of wanting to do the blocks a certain way, which we tried to do and I won’t get into It would be too much to details wise to get into, but it’s, we had to sort of go back to the drawing board one or two times, but we ended up landing on this concept of having a couple core blocks that we then make variations of, right? And the variation.
Brian (12:04)
Mm-hmm.
Ian Svoboda (12:06)
for the benefit of anybody watching, a block variation is essentially just a combination of attributes associated with a given block, right? So you say if this block has all of these things set, or this thing set, that makes it a whatever block or something, like say a text block versus a button block. Those were both the same core block under their hood. They’re just variations and things like that. And I think that having more of a sort of flexible approach where we have
Brian (12:19)
Yeah, yeah, yeah.
Ian Svoboda (12:33)
something like that or like a styles object that then just all the styles are in there. It makes it way easier because then we can create a new block and we can apply our styling engine to it and boom, it just works. Global styles, just, they just work. You know, we get a few H O C’s, we line them all up and everything just kind of jams. And if you really build things in a way that’s designed to be fundamentally pluggable, I think you’re going to have a better time of it anyway. It doesn’t mean that everything’s simple though, cause like
Brian (12:46)
Mm-hmm.
Ian Svoboda (13:01)
Variations aren’t actually blocks. So you can’t do certain things that are like say you can’t limit them in the insert or the same way as just a regular box could or there’s that’s why we had to make certain blocks like the loop item or other things like that, which is kind of, which seems kind of weird if you say, well, you have these like the element and the text block and you use those to make all these. Sometimes you have to do something different, but that’s the, that’s, I think that’s probably the biggest thing I’ve seen go wrong with most people’s implementations.
Brian (13:10)
Yeah, yeah.
Ian Svoboda (13:31)
things. It’s like if they’re doing an extending project to extend the editor, they’ll get it in their head that they have to do it in this one very specific manner. And so then they’ll do it that way, even if it is kind of like rough in these other areas, or they just kind of abandon the project and like the notion of doing it all a certain way at all. And then everything’s just kind of spaghetti. And then in both of those types of cases, you’re in for a bad time, right? Like you got to kind of look at this and say, I don’t think that this is exactly right here, but we can do this thing differently over here.
Brian (13:38)
Mm-hmm.
Ian Svoboda (14:00)
because it’s for a really good reason. It actually makes a lot of sense. And I think that’s made some of these things a little bit easier. Lean into the core features. Do it this way as much as you can. Color outside the lines just where you need to.
Brian (14:02)
Uh-huh.
Yeah, I was over the holiday break. was experimenting with building a plugin for something in the block header where I was like, I really want this feature doesn’t exist. I’ll see if I can build it for fun. And I was really struggling with a few things. And one of them, like you said, was that idea of like, like there’s three different ways to build it. And I keep trying each different one and you’re like losing sort of the overall picture. And then, so I have like all these branches of like, try this, try that.
re-delete everything and redo it. But the one thing that really tripped me up the most was that I hit a point where what I was trying to build was not going to really be valuable if you couldn’t have some sort of a responsive control to it. Like you couldn’t have different styles on desktop and mobile. That was like one of the key things that this feature I’m trying to build needs. then I sat there and I thought, well, that’s not in core.
If they’re just using a simple core theme like 2024, then I have to build this all from scratch. If they’re using another plugin that has responsive controls, now I have duplicate responsive controls. There’s not like an abstract library I can pull in that comes from core and stuff like that. And I kind of, I don’t know, I might even abandon it. I hit a point where I was like, it seems like a problem that is insurmountable. Did you ever hit like problems like that where you’re just like, this is just such a thing that like, if we do it our own weird way.
it’s just going to cause problems for any other integrations or is it kind of fine because you you are the sort of base level integration for them.
Ian Svoboda (15:45)
Yeah, I don’t know. mean, we don’t, we don’t really go out of our way to make sure our plugin plays nice with every other plugin there is, of course, or things like that. But we also go out of our way to make sure that it’s not unnecessarily like hard coded or static in certain ways. Like trying to like it as an example, if we’re going to get the WordPress excerpt or something, you know, we’ll apply the filters that would normally be used there.
Brian (16:05)
Mm-hmm.
Ian Svoboda (16:14)
things like that to try to make things as smooth as possible with the notion being like it should try to be as unhacky as it can be. So that way it does play nicer with other stuff. Like I think in a way doing that is almost more valuable than like trying to do a bunch of really meticulous research unless you’re building like an integration of some sort. Right? Like a good example of that in that last part would be like this thing we did with the dynamic tags. We’re in pro we have an ACF in
Brian (16:15)
Yeah.
Mm-hmm.
Ian Svoboda (16:43)
Now, in the free version, it’ll still list the ACF fields because they’re all post meta, but it just won’t put them in a certain order and make them all nice in the editor so it’s more clear which ones you probably want to choose and things like that. So we wrote that specifically with ACF compatibility in mind. It uses these ACF methods to tell if it’s actually an ACF field or not and things like that. There’s a way to even modify.
Brian (16:44)
Mm-hmm.
Yeah.
Ian Svoboda (17:12)
that process if you’re using like an ACF custom table plugin or something actual thing that we were asked about, you know, where it’s like not stored in post-meta at all. You know, it’s flexible enough to support all of those types of use cases just because we’re again trying to keep it simple, use as many like reasonable kind of core things first and then where we can appropriately add filters and things like that. Trying to document a lot of those as we go too.
Brian (17:19)
Mm-hmm.
Yeah, yeah, yeah, I’ve seen that.
Yeah, ACF is actually a really good example of that because I’ve been really interested in the block bindings API in core, which is this idea that they’re going to start bringing custom fields and meta and stuff into like a more dynamic experience and stuff. But ACF isn’t going to work with it, you know, out of the box because ACF has to do things a little differently when they register meta, for example. like, you know, ACF like custom fields registered in ACF aren’t quite quite like the same as like regular custom fields because
they needed to make it more powerful and they needed to go a different route and stuff. And now as it comes back around, it’s like, okay, well then that’s, I guess, gonna just be on ACF’s team to build that sort of integration. And I guess that’s your sort of responsibility too. guess if ACF’s that big of a player, you guys kinda have to, at some level, work with it, because otherwise, why would people wanna use your plugin?
Ian Svoboda (18:32)
Yeah, absolutely. And in this case, I think our integration for doing dynamic post meta things and ACF things like that, where you’re not just like, you know, where you’re actually using them in the editor and stuff. It’s pretty top tier. I’m not, I don’t know every other plugin out there. There’s probably going to be someone that goes, Hey man, this other thing. I’m sure, sure. There’s other things out there that might do something similar, but ours is pretty sick. Like when you say I want a post meta key, it doesn’t matter where that thing comes from.
Brian (19:00)
Hmm.
Ian Svoboda (19:00)
It could be
any post meta key that you could possibly think of. If it’s a real post meta key that is available for that thing, you can do stuff to it. Additionally, even if that key is an object or an array of key data, you can still access all of it too using a dot notation syntax. So if you have like an ACF image field that returns as an array, you can say image dot alt, image dot URL, image sizes large URL or something, and you can just get all of that.
And it doesn’t matter where that stuff comes from. all works. Our integration allows you to also like if you’re say like a pods or something or some other, you make your own custom meta box plugin and you want to do something, you know, to get into there in that process. have a filter that people can use for that. And it short circuits our entire original lookup. So it doesn’t look up the value twice. It takes all the advantage of the WordPress caching things.
but it’s super flexible for being able to just pluck data out of any structure. You take a repeater that’s in a group and then you want to get, the, you put a post object in there and you want to get the status off the post object. You can do all that, all that stuff, all possible out of the box. It just works. And then when you like, when you go in there to set the keys, it’s all, it’s very user friendly though. It’ll enumerate the keys where it can. So it makes a list for you. So you don’t have to remember what they all are, but
Brian (20:08)
Cheers.
Ian Svoboda (20:22)
It doesn’t just throw every single key there ever was into a big list, which I don’t find very, uh, there’s a couple of plugins I’ve seen that do that when you’re doing these meta integrations, it just gives you every key that’s registered. And it’s like, that’s kind of confusing. What if that key doesn’t exist in this post? What if that, uh, isn’t an ACF thing that I want? I don’t know. You know what I mean? But it’s, it’s a really nice system. And that kind of was, uh, that whole thing, that whole meta lookup system is actually available to people. Like if you’re a developer nerd, who’s here in this and you’re like,
PHP templates. You can. Because we made a handler for doing all of this stuff. There’s REST endpoints for doing it too. So if you want to do those types of lookups in JS, it all works. So there’s a lot of really nifty. And see, that’s an example of we wanted to make it really easy for people to just use ACF, just use their post meta. It doesn’t matter where it comes from. I know it’s this post object that we set as post meta. I just want to get this thing that I know is on the post object. Great. You just do that, and it just works.
And in the process of doing that, we actually made something really powerful that we then were able to expose for other people to be able to use if they wanted to.
Brian (21:30)
And so you don’t give, like for example, do you offer the functionality of like registering post types, registering custom fields and stuff, or do you say, hey, there’s a solution for that, it’s ACF, everybody loves it, we’ll just integrate with that. Or do you guys, like when do you draw the line and say like, well, we should have our own form, we should have our own custom field UI, we should have our own, so on and so
Ian Svoboda (21:51)
I don’t know. mean, again, that’s kind of a little bit more of a bigger picture question. I think Tom is probably the person who’d give you the best answer there. But I think that we want to try to focus on like making tools, the output, clean things that people can use well. And so it all starts with having this framework, this bedrock of like the styles engine and these other blocks. Now that we have those, I mean, that enables us to more easily do things like say like
carousels or more interactive components or things like that. But I would be, I’m not sure that we would be like looking to get into the forms or the custom UI, the custom field space or any of that kind of stuff soon. Cause it’s like you said, there’s a lot of good established solutions for that, but it’s kind of like for us, like we have a lane that we occupy really well. Like if you want to make markup, that’s as close to hand coding it yourself as possible.
and have something that’s friendly but works and you can do things fast, that’s us. But playing nice with others is another big part of what we do too. So I think we just try to look at it as like, can we properly serve people in the solving the problem that we’re trying to solve for them by doing things in this way that doesn’t involve making our own version of something? It’s kind of like an NPM package, right? Like if you find one.
Brian (23:06)
Mm-hmm.
Ian Svoboda (23:14)
that’s really good, it’s well maintained, it does everything. You don’t have to spend 10, 15 hours building it for a client and they’re paying you by the hour or something. Well then sure, you’d be remiss not to use it, right? But if using that thing comes with a, you have to rewrite your whole API to work with it and then, well, they update and it’s all this stuff and it’s like, well, is it worth it anymore? Maybe not. So maybe then we look at kind of doing our own thing, right? But I think that Tom has a really good radar for that sort of stuff. And over the years, people have
I think people have really developed a strong trust in his intuition for that sort of thing. Like this whole styles object was just an idea he had at one point that he just put together and I was like, bro, this is fantastic, right? He’s got a really good radar for that stuff. So I’m thankful to work with a guy like him to be able to help with these kind of guiding product decisions and that sort of thing. That’s really nice.
Brian (23:56)
Mm-hmm.
He’s like page builders sort of become are like fashionable or trend, you know, and it sort of becomes like this month’s page builder suddenly falls out of fashion or everybody’s mad because this one is not as clean of the markup because now we need cleaner markup. And it’s always good criticisms of each page builder. Like this one is, know, whatever the problem is, it’s not performing enough. The code output is not accessible and it’s good. It’s like, it’s nice to see that we demand more from our builders and stuff, but obviously like you have.
to have like you said, like a clear product vision and somebody who understands product and that’s, you know, very important, especially in WordPress. But then also I’m guessing you guys have some sort of like feedback loop with community or like you guys do, like how do you stay in touch with the people that are using it to make sure, you know, they’re happy with it, that they’re enjoying what you’re building.
Ian Svoboda (24:57)
sure,
tons of different ways for that. There’s obviously things like the support forms and support tickets that people send in, but then there’s also things like the Facebook community, there’s just the discussion and discourse that you find on Twitter. And I gotta say that I was really happy to join this team originally because one thing I found when I was looking is like almost all the feedback on this thing is relentlessly positive. You look at the January Press and January Blocks feedback, people just go.
Yeah, this is really great. And it’s something that, you know, they work really hard to make sure the updates are good and all that. And like that’s something that I wanted to be a part of when I saw that, because that’s the type of thing that I want with products that I would make. Like if I was making my own product, I would want people to say that sort of thing. And so you don’t base maybe everything you do based on just what people ask for, right? But there’s certain things that you can see, like when we get these GitHub issues or
Support threads or whatever and people I just want to throw it out there to any of the people who do that stuff that watches stuff You guys are great by and large almost everything I read is helpful and useful Everybody’s really cool and it’s it’s really an honor to be able to work on this product for all these people And be able to make something that lets people make other stuff or generating tools Sorry unavoidable But yeah, I mean like that’s that’s something though that we really care about because we don’t We don’t make this for
Brian (26:00)
Yeah.
Ian Svoboda (26:20)
us. It’s not just for people like me or people like Tom or whatever. It’s bigger than that.
Brian (26:26)
Yeah.
And then the last thing you guys did was is the cloud stuff. That’s like newer, right? The cloud library. How’s that going?
Ian Svoboda (26:35)
Uh, that’s pretty sweet. We’re going to be, think, working on some additional new features. Like I think there’s still a discussion on how we’re going to do it, but we want to do things to like integrate like the font library and maybe like the global style system a little more with that. So you can just have this like ultimate home base, if you will, for all of your things that you’ll be able to just send out everywhere. It’s a really neat concept. There’s a lot of, um, there’s a lot of potential to it that is still yet to come. Right.
But it’s a lot of power, especially if you’re a freelancer type person or somebody like an agency who likes to kind of build from, you have a couple of set site patterns that you like to start people off on, you know, as your boilerplate. This is a great sort of product for that.
Brian (27:21)
Yeah, I’m like super bullish on cloud libraries for WordPress. feels like the next sort of big thing that needs to be solved and it’s nice to see people are starting to solve it. I feel like there’s been ones in the past, but I think it’s taken until we’ve had like the Gutenberg era to like really solidify just the fact that WordPress now has a consistent approach to markup and styling and
people who use your plugin are gonna have a consistent approach to markup and styling. It now makes it so much easier to say like, yeah, we can start like having structural patterns, design libraries, things like that floating around that you can just like set just pulling to any site. I think that’s gonna be probably the big frontier of WordPress, hopefully.
Ian Svoboda (28:05)
Yeah, yeah, definitely. And like with the new font stuff that we were just doing too, I think there’s a lot of cloud potential for that as well. That feature, by the way, is freaking so cool. It’s not an… That is a GP premium feature where we have a brand new font library and it’s kind of sort of similar. Like if you look at it, it’ll probably look a little bit like the core one in WordPress. It is in many ways based on it. Like the…
Brian (28:17)
So what’s the new font thing? Cause I don’t know if I’ve seen it.
Ian Svoboda (28:34)
heavily inspired by based on a true story, if you will, right? But we did a lot of extra things that the core one doesn’t do. Like talking about the whole, is where we have to color outside the lines kind of situation, right? Like when you’re installing Google fonts from there, it doesn’t actually install any variable fonts, even if the font is a variable font, it forces it to have the like big chunky, non-optimized, unsubsetted version of those fonts.
Brian (28:35)
huh. Yeah, yeah, yeah.
Hmm.
Yeah.
Ian Svoboda (29:02)
All the font files that that thing pulls are ginormous. Like in our tests, they’re all just way larger than like if you went to Google Fonts and just got them. And so we were like, why is that? And we figured out that was just because of the way that the Google Fonts API works. If you haven’t seen it, by the way, the way that WordPress actually, like Gutenberg actually generates those font choices is they have a whole repo package for this, where they generate these like inline SVG fallbacks and stuff. It’s actually kind of an interesting little mechanism.
Brian (29:24)
Okay.
Ian Svoboda (29:30)
you know, in general, but it’s really neat. Like we, we basically took a lot of that stuff and then we found ways to optimize it further. added subsetting mechanisms and these other things so that it’s downloading like the, fastest and best version of the file. If there’s a variable version, it gets it for you automatically. It handles all of that stuff. It generates a CSS variable for you to use. You can choose the fallbacks on the font, all that. It’s very, it’s really customizable. It’s really sweet.
Brian (29:30)
Okay.
yeah.
Nice. And I feel like we just like scratched the surface because I feel like you and I could probably go deep on like one specific thing and talk about how you accomplish and stuff like that, which I think we should do in the future. overall, where can people go to kind of get more information from you? I mean, you’re always sharing kind of like cool stuff. I feel like I’m always learning from you online. So where do you recommend people go to follow you?
Ian Svoboda (30:21)
Well, probably the best place would be like blue sky or Twitter. So that’s at Ian’s foe in both places It’s like at Ian’s flow dot B sky social or whatever it is over there and then I have my personal site which I’m working on revamping so that I can Follow your footsteps a little bit more and start writing a bit more on right because I have been woefully Neglecting that so I’m gonna be trying to really revamp my my personal blog efforts And then I have the learn WP theme dev site
Brian (30:32)
Nah.
Ian Svoboda (30:49)
which we’re also gonna be making some updates to. And I think I have some exciting changes on that coming up. So all good things to stay in touch about.
Brian (30:57)
Awesome, man. Thanks for coming and talking. Hope we’ll chat again soon.
Ian Svoboda (31:00)
Yeah, definitely.