Special Episode: WordPress Publisher Sessions

Welcome to another special episode of WordPress publisher sessions. Hosted by Steve Burge of Publish Press, Leslie Sim of Newsletter Glue, and myself, Pete Erickson of Leaky Paywall. We invite smart people in publishing to share what is working in WordPress. So let's get into it. Welcome to episode three of WordPress publisher sessions. We're here with Frank Klein of Human Made and we're going to talk about how to scale WordPress for high volume readership. And Frank has experience with TechCrunch and other large publications and we're gonna, we're gonna dive right into it. So welcome Frank, appreciate you being here.

Yes, hello and thank you for having me.

Excellent, excellent. So you're. Can you. How about if we start off a little bit by your journey into these large enterprise systems and how, you know, how you ended up working with TechCrunch, which I think everyone knows by now who that is and how you got to Human Made. And I know that you also have some other projects cooking as well. So can you give us a little background?

Yeah, sure. So WordPress is not my first career choice actually. So I went to school to be a print designer and came out in 2008 and there wasn't any work available, but I had done an internship at a web agency and the boss said, look, if I don't need any more graphic designers, especially not print designers, let's be honest, but I could need a project manager. So he said, if you go back to school, I'm going to hire you. So that's what I did. And then I worked in that for two years, but I was just horrible. Like wasn't a career for me because I'm still a creative type. And so at that point I thought to myself, okay, I need to plan my career. So what's growing while it's the web, obviously, like web design was the big thing. So look at who makes the most money in the web and that's programmers. Then looked at what's the most popular CMS, that's WordPress. And then there was that, you know, that's how I land in WordPress, you know, bought a book on PHP that was in 2011. And so yeah, when you know WordPress, who do you want to work for? Well, the big one. So I applied to Automatic and I was hired as part of the WordPress.com theme team. And so that's already kind of large traffic, but very different in the sense that you're always dealing with individual people's blogs. There was, you know, working on, on the theme Part and I said to myself, look, if you have all of these big websites, like what's, what's the secret sauce, right? What's what makes these websites so special and different from rest of WordPress. And so Automattic back then had a department called WordPress.com VIP. So yeah, I applied to that and then was part of the VIP team. And that's, that's when I got kind of the insight into, you know, what is a WordPress site that handles all the traffic, how that is done. And so that's landed at how I landed Human Made because they were working one of the projects that I did. Never heard of them before, to be honest. And they seemed like a really good company. So I applied to them Land that Human Made. And from that point on, since I came back from that publishing angle, because back then Vip did a lot of large news sites. That was like their core business. So that's what I worked on at Unimate too. So the first project I did was so the sun. That's like a British, British newspaper, the most popular one, I guess in Britain. So that was the first product. Yeah.

Sorry, you're kind of shaking your head like it's the most popular one. I don't understand how it has a reputation.

I mean, the thing is that, yeah, I'm so, I'm from Luxembourg and they say, well, it's the sun, it's the biggest newspaper. I'm like, never heard of it.

So.

But I, I, I heard from other colleagues in that live in UK that it's controversial. But yeah, but that's for me, I, I didn't really care, you know, because the thing is that what is funny about the sun is that we were having this meeting in London and I said, how do I find the offices of the Sun? They're like, oh, you'll find it. I'm like, that's really stupid instruction. But yeah, they own, if you've ever been to their offices, they own like a huge office building, right. And even know what it belonged to the son. I haven't even looked up like, what's the mother company, anything. So. And I was quite impressed. Just, I think it was a great project because I taught an internship when I was in, in high school here in Luxburg in the newspaper and they had a newsroom of maybe and people like print stuff. And I walk into this newsroom and it's just, it's huge, right? It's just the sheer amount of people that work in that company. I was just, I was blown away. To be honest. And when I looked at just the content that they produced, the mass of content that this newsroom outputs, I was just, I couldn't fathom it, to be honest. I get beginning that this is just a scale that we are operating at, but was very good because it was a great project for me, because they treated me very well, way better than other clients treated me when I was in the agency world. They were all very professional and I learned a lot from them, to be honest. You know, how to run not only like the technical part, which is where I come in, but really how newsroom, like a newsroom works. What are different roles, how do they work together? What are the tools that you use? And from that point on, I think once you have that on your resume, then I guess, you know, it's easy, it's easy to stay in that kind of lane and so work with TechCrunch, other big blogs. Skyscanner was a block that I did, which is not, it's not publishing, it's just more content. So they have like a network of content blogs which they use to do content marketing essentially. And so yeah, like big publishing is really my, my, the thing that I'm most experienced in. But I think right now I'm coming more down the niche publishing aisle because I think that what I say, big publishing for me means you have tons of content, tons of readership, but it's ad financed. That's how it works. That's why it's very different from, well, niche is maybe not super good, but you have a lot of smaller publications which are maybe not ad finds. And here, you know, it's very different how we approach that because the thing is really when you have something like the sun, you know, so many people are visiting their website, they don't care, they just want traffic, traffic, traffic. When you have some specific blog about a specific, let's say, hobby that you have, you know, on your vegan cooking block, you're not looking for insane amount of traffic, you're looking for the right amount of traffic, right? People that want that kind of information and especially, you know, people that, that fit with whatever angle you have. Because even vegan cooking is, you know, it's a niche, but it's a huge niche, right? Is it like more Asians, like more comfort food? And so it's very interesting to see how we are kind of moving away from that and also how we have a different model for financing these things when we are more in a niche publishing space. So yeah, that was like a Big introduction.

So it's a radically different experience to work with a company like the sun, which has an old fashioned print newspaper compared to something like TechCrunch is a good example, which is an entirely modern kind of newspaper. No, maybe no offices or maybe just a very small office.

Yeah. So I think it's just, I think it's different sense that when you look at the sun for them, it's more. We're gonna say that what can we write about, right? What, what is the stuff that we can write about? And just, they just pump out the content. And so for them it's really much more ease of use, rapidity, and also everything that we can automate. That's really great for them. They like that. Right. So reduce the step down from. Takes you one minute to ten seconds. They're interested in that. When you talk about something like TechCrunch, they're not pumping out content because they need to write certain pieces which are very interesting for their audience. Right. So somebody reads TechCrunch, they want to have specific information. And for them it was a lot more. How can we have an experience on the website that allows us to showcase the work that we do? So one of the features that was specific to TechCrunch is developing stories where they said we have information about something and we post the first article. And that's just a small bit. This company got acquired by this company, whatever. Right. And that's all they know at that point. And then they can add additional posts to that original article. And in the ui, it's all going to be one thing when it expands. So for them it was much more. How can we present this information that we have? And what they were interested in is more of an app feel. You go to TechCrunch website, obviously huge mobile traffic and it's not meant to be consumed as it would like a traditional website where you go and read the article, it's much more like you scroll through, it opens in the feed, you read it, you continue. So for them, that was really the thing that they wanted because previously the TechCrunch blog, I don't even remember, was very bloggy, as we would do with Kubrick even, Right. You have a feed, you click on article, you're on a single page and they want just people to stay and scroll through and then consume the content that way. So those were kind of two different things that they were looking for.

How is.

Oh, sorry.

Well, I was just going to ask how TechCrunch is set up. Might be a Good segue to talk about, you know, like how they handle the amount of traffic that, that they handle. Are they, are they running like WordPress and a native theme? Are they running headless? And I, you know, we could talk about login as well, because that's something that you have to do at TechCrunch. But what, what, what's, what's the trick to dealing with this kind of volume with WordPress?

Well, so techno is specific in the sense that when we saw the mock ups and we know what they wanted the field, we got that. So this is headless, but it runs all in users browser. So the server is still classic WordPress as you would know it. And if you were to disable JavaScript, it already serves up content. Because one of the things that we were looking at is when we have a headless site that runs all of the UI is handled by the browser. You don't want the experience where somebody loads the page and then there was a spinner while the app is bootstrapped and it gets the data, everything like that here, the way that we do it is just when you load the page, the PHP provides already a lot of the data and then the react kicks in and then that handles any subsequent requests. So those are now once you have done the first page load, it gets it from the REST API and so the REST API can be cached the same as anything else. And that's really the big secret to if you get a lot of traffic, you cache things very heavily. So that's I guess the trick. So when we talk about just. Yeah, when I say caching, that can mean different things. But one of the things that kind of distinguishes the small, well the low traffic websites from the higher traffic websites is that when you have a low traffic website, all the requests go to the server itself. So the server that handles WordPress, that produces the page, usually even on, let's say the accessible hosting, you have something like bad cache which takes the page output, generates it once, stores it, and then produces the page as is when you come onto it. So you don't have to do all of the work to get the data from database, have the page and things like that. That's great because it's faster than regenerating the page every time. But the thing is you're still hitting the web server every time that the request comes in because the caching is handled by the web server itself and also inside of WordPress. So WordPress needs to boot and everything like that. So when we're talking about the layer above what you have is that there is actually something in front which hands the request. So could be cloudfrog, could be Akama, it could be anything. So that's an edge cache. So the idea of the edge cache is both that it's not the same infrastructure that handles the website because it's an entirely different part of the hosting infrastructure. And also since usually this is combined with the cdn, it gets served off of a location that is closer to you. So when I'm in Europe, I'm getting served this from different location. If I were to be in the US for example, and that's really the big. It's not a secret, but that's like the thing that makes all of this stay up on the traffic because if there is a traffic spike, well, the edge cache is going to handle it for you. Just going to serve cache pages. And also if you want on a specific setup, you can always increase the cache duration. That's a thing. If you're really in bad shape, you can always do that. But that's the basic setup. And where this kind of falls apart a bit is that when you're dealing with such a caching approach, when you have a URL of a specific article, the article always needs to be the same. So anything that varies the output of the page, for example, the users logged in, the user's coming from a specific country, whatever it is doesn't really work. So the geolocation you still can do, but then it's done on the level of the edge CDN actually. But that's really where for example, a plugin like block visibility, right? But you can say, well, if the user is locked in, show them this. If the user is not logged in, depending on these things, it's not going to work if you have an edge caching solution because it will only ever deal with locked out users.

I was going to ask that partly selfishly, because we have plugins that deal with user accounts and authors and we see all sorts of very strange things happen. Once you get into hundreds of thousands or millions of users on a WordPress site, things start to break pretty fast. At that scale, how does a site like TechCrunch handle user sessions? Because I think TechCrunch has a membership system. How does it deal with user sessions? That once a WordPress site gets that busy, gets that big.

But the difference is since when TechCrunch, the way that they solve it is all solved through the browser. So since it's headless, the browser can do a lot of the work that, you know, you don't really have to do the thing where you need to go back to WordPress for everything, because if you have something like Bad cache, right, which is the most common caching plugin, it's going to skip for logged in users, right? And so the database gets asked every time that a page is generated to get all of the information. But if you have a headless setup, you can keep things on the screen and then only go back to the REST API for the things that need to be different for that specific page. So you're already benefiting of the fact, for example, when we look at TechCrunch, so the interface rendering is react and then the data storage uses Redux, which means that once we have gotten the post from the database, it's going to be stored in the browser itself and we don't get it a second time. And so when we're talking about Redux, there are many different ways to optimize this. Just in Redux itself, right? Because you would actually store all of the posts, all of the terms, everything like that, everything you have already. You don't go back to the server when we're Talking about traditional PHP driven WordPress, if you're dealing with locked in users, you beef up the server. But the thing is that would be the traditional approach and that's. How can I say that that's low tech and depending on how much, how many users you have, it works very well. But the thing is that when we look at just how much of the page is different for the user, because commonly the content is the same, it's just the surrounding UI is different. And so an approach that we are taking on other projects is that we mix the two so we keep just the caching as is and then we do other work to get stuff in which relies on user being locked in, for example, the comments of things like that. And when we look at kind of the interactivity API that the Gutenberg team has presented, it kind of goes into that same way that they're saying, hey, we want to benefit from existing HTML that is server rendered and then we're going to Superset it with JavaScript to do things so that we don't have to go back and rerender and everything. So that's somewhat of a mixture that they are taking now for the future. So it's too early to say where the interactivity API is going to go, but certainly there are ideas to go back, I think from the very monolithic approach to serving pages that we have now.

So you find that the bigger the site almost the more essential a headless setup is that for a large website there are just some massive advantages to running them headless as opposed to running traditional WordPress?

No, absolutely not. So we need to distinguish between headless. So the headless that TechCrunch did is very exceptional because the JavaScript is there to give it this app feel right. The site should feel like an app. So in that case, you cannot get around JavaScript. There are other headless setups where also in publishing where it is headless. But the thing is that the headless is still driven by back end technology. So they use Node for example, and Node generates the front end and then delivers HTML to the browser and then node goes to WordPress to pull out the data. So which is perfectly fine if you're in a scenario where your publication is headless anyway and it is driven by several different CMs, which is is the case out there. And what if it's just one part of it? Well, that's the way you're going to do it. So wifi is one more data source. You inject it into your existing front end, which also powers the other cms and that's a perfectly fine setup. However, the thing is that whether you render backend code through Node or backend code through PHP doesn't really matter. It's just, you know, it's always the same issue. And especially when you look at the setup that, you know, with an edge cache you don't care like what, what does the, the back end because the edge cache is going to handle it like for you. And the thing, the problem with Headless is that you're always having to maintain two different applications. So a very simple feature has always a UI component and it has a backend component. Right. So data, just the data. Or it also may have something of a component where, you know, you Change the admin UI so you have two different GitHub repositories, you have two places where I need to do changes. You deploy the changes at once, you test them and then you deploy the changes onto two different infrastructures at the same time. So that's just the problem. The other problem is that WordPress is very much like traditional WordPress is that anything goes, which is both very good and both very bad. For example, I remember like not, not too dark on Jetpack, but Jetpack sharing buttons appear on the website. Like, wow, magic. How does this get there? Well, it injects them into the content itself.

Yeah.

So I'm like, you know, I mean, it's great because essentially you can just plug in sharing buttons into the content. You're like, well, that's awesome that you can do this just with a small snippet of code. On the other hand, it creates a lot of problems. And so when you're dealing with Headless, the thing is that you're not dealing with just random HTML, which essentially most WordPress sites, you throw HTML at the screen and maybe it works, maybe it doesn't. You're like, yeah, whatever, you know, because it's WordPress, we don't care. The thing is, with Headless, always like a data structure and the headless JavaScript, expect this data structure to be a specific way and you can't just throw random stuff at it and be like, hey, you know, why don't you work? Because usually WordPress just we do whatever and we let the browser figure it out. And with Headless, no like the front end needs to know what you're giving it. It needs to be a certain structure, it needs to be this, it needs to be that. And then it becomes difficult. Like, if you're dealing with mobile apps, for example, which have been around for ages traditionally, something that a publisher will ask you is that, hey, we have a website, we have a mobile app, let's create a few endpoints to prepare the content for the mobile app. What you're going to do is you're going to strip out certain things, you need to adapt certain things, you need to remap data. And so all of that work, which is not really difficult work, it just takes time to do, it's very painful because the app developer is going to be like, I need you to do this. Then you do it, you show it to them, you're like, oh, it's not really what I want, maybe this. So this whole back and forth, it just takes a ton of time, Nobody likes to do it. And so that's kind of the downside of Headless, right? So you always have this thing where it's a lot slower, it's a lot more interaction between the teams and in the case of a mobile app, you cannot really get around it, right, because it is distinct and it's good as it is distinct. But if we're just talking about a website and you want to publish content, like, my opinion again, is keep it as low tech as possible. Because the thing is that if you were to look at actual performance numbers, once you hit an edge cache, what does it matter? It's going to Be as fast for something that is no generator or PHP generator. So that's just the thing. And especially where when we talk about publishing can mean a lot of things. But if you are a newsroom, an article is always very similar, right? Some text, some interest, some videos, whatever. It's a stuff we all know that's cool. Then you have the marketing department and they're like, like they're off the rails. I want to inject this into the page, wanna have that one of this and that's great. Right. But if you combine and they can do that with WordPress, right. A lot of marketing people know WordPress, they know what it can do, they wanna use it and they want to build up this page. So like, well if you want to have that module, we need to do an adaptation in the rest of your endpoint and blah blah blah, you lose them completely. Right. That's actually advantage of having WordPress is that when you keep it to the stack that it is by default it's very flexible, it's very fast. So like why would you change it? So that's kind of my opinion on it. That said, there are definitely use cases for Headless but I think there has been this push of saying well this is the new frontier and it's so much better in this way and that way in I, I can only speak like anecdotally but I haven't really seen that you know, Atlas is dominating the WordPress world and you know, we all have been converted so why so different tech, different headaches.

Yeah. So sort of my big question is when do you consider Headless like a, as a publisher, what. When do you say okay, headless makes sense. Now just let me a little backstory is this week I talked to a good sized publisher who's running Headless and WordPress and they have a Laravel server that's running a login system for. They have a very, very basic subscription system running on their site and they don't, it's not doing what they need it to do. And so I, I basically, you know, we've had a conversation, we've had a bunch of emails and it's like why did you do headless in the first place? Was sort of my fundamental question like do you need headless? Which is now my question to you is, you know, for, especially for a login system, where's the line? Where do you draw the line on? Okay, let's, let's stay native WordPress and keep it flexible which is what I'm hearing from you or when do we actually really need to invest in this second layer and make it more complicated? You know what I mean?

Yeah. So I think that when we talk about logged in users, that's a different use case. But let's say you're starting out with a very basic content restriction plugin. Whichever one you use in WordPress. Right. And everything is just in WordPress. So you have the content in WordPress, the access restriction is handled through WordPress through the roles and everything and you sell the stuff through WordPress through some way. Then that's great, right? Everything is in one place. You don't need to ask this place or that place for information. Where it falls apart is if you have while WordPress is the content repository, but actually our subscriptions live over here and then our users are actually not. We cannot store them WordPress because of GDPR or whatever privacy. So they are in another service. Well, if you use PHP just to aggregate all of those sources, it's not going to be a great experience. So if you have a headless setup, it's much easier to take these different data sources and combine them into one piece. And that's actually a scenario which, which I had on the project where essentially before it was all in WordPress and that was great, but then, you know, the website got acquired by a different company and they have already established systems. So I said look, still point in duplicating all of the stuff that you have in WordPress because they were already headless. Let's just keep WordPress as a data storage and let's keep it as an editorial tool, which is very good at. But the front end is going to be headless and essentially all of the business logic. So which is. Is the user logged in? Can they log in? What content can they access is all handled by the headless setup. And then the header setup reaches out to WordPress and just pulls the content when. When it should be able to. So in that sense, it makes a lot of sense. So headless. Not really. When I say that it sometimes gets seen as something which it just like. I don't know, it seems to me that it's. It gets sold as. It's just like installing a plugin or buying a hosting. Oh, you buy headless. Boom, boom. Now it's all working. It was really more. Well, if you have very complex needs, you can have something like that. That makes it a lot easier to handle. But again, you know, that's also of course the. When we just take away all of the technical aspects. If you Have a node code base, you need to have a node developer. If you have a PHP code base, you have a PHP developer. I don't know, I don't know any developers that really do both at the same time. Because as a developer you choose one stack or another and that's like your main stuff and then you add stuff on top like React. But Node is really very different to php so you need to have two developers ready. You know, if you're talking just people now, the developer is sick on holiday, so you need to have two like four developers in total. And that's I think what a lot of people forget is just no sourcing these things because you need a lot of talent to run the front end, a lot of talent to run the background. The back end might be two different agencies, might be one agency. So I think it's if the decision for to go headless or not, it's a technical one on one end. But there's a lot of other considerations that you need to make inside of your organization when it comes to staffing. How you run the projects, how you plan the projects. So it's not something which is purely decided on technical merit. That's my view on it.

A couple of years ago we used to do a bit more Drupal work and I sat in on a bunch of sales pitches from Acquia and for Headless that was very much their pitch, was that if you're a large company with a CRM, a website for the content, a marketing stack, if you had 10, 15 different pieces, then Headless was a good option to combine them all together. That was their approach to it. But in reality they needed a lot of staff. It was just a, a big company problem. A big, big company solution to a big company problem.

Yeah, that's pretty much exactly my thoughts about it. I mean if you have tons of money, you can throw tons of money at, you know the problem and you don't care. Like I need three developers, need four. Like if you're a big company you don't care, you could have eight. Doesn't matter because the budget is going to be so small compared to what, what you have. But I think that what most people, I think maybe forget is just if you look at just very normal WordPress hosting, like nothing VIP, just the stuff that you can buy off of website by one click, it already can handle a lot. And I think that as a publisher getting a lot of traffic is a good problem to have to deal with that. But solve that problem once, once you have it. And if you do, I don't know if, you know, Basecamp, you know, the, the project management tool, they have a cto and so they were running Basecamp. And if you're dealing with big data sets, at one moment, you have to split up the database, right? Which you didn't want to do because it's a pain to do. And they actually, I don't know if they're still able to do it, but they, Every year or whenever they needed to upgrade, they could just buy a bigger server because technology has evolved so much that they could just buy a bigger server and that was it. And it cost them money, but really cost them way less than the pain of dividing up the database. So always go back to that. It's kind of like, how far can you take just normal hosting with WordPress to handle the traffic you have? And especially. And that's, I think, the dark secret of it, or maybe the thing that we shouldn't really mention is that there's a way to write efficient code and a way to write inefficient code. And one of the things, because when people ask, oh, like, what's the difference about enterprise WordPress, what is really the margin for error is very, very, very slim. So you need to know exactly what you're doing. And a lot of developers, you know, they somewhat know what they're doing, but not really. I mean, it's. I have spoken to WordPress developers which, you know, build sites, they are successful, everything. They didn't write a single line of SQL in their life. They have like a basic idea of what it is, what it does, but they're like, I've never written any SQL statement in my entire life, which is great for them. But when you get to, you know, the enterprise level, need to understand you can't just request random data and just, you know, through the magic of software, it's going to be fast and everything. So that's, I think, just the idea of understanding, okay, what are we dealing with? How can I make this efficient? So that's really, I think, the part that makes WordPress possible to run on, like, normal hosting.

Can we talk?

Sorry, Steve.

Oh, go for nothing.

Can we talk about milestones? Like, you were talking about publishers growing bigger and bigger and dealing with the problem when it happens. So, like, let's say we're starting, let's start from like, zero. So at what point do we have to start to care about, you know, oh, crap, I'm getting, I'm getting a certain number of visitors and at this point, what should I start caring about? And then what's the next milestone? And then what's the next milestone?

Right. So it's hard to give hard and fast recommendations. But I think that if you're looking at two, if you look at the two models, one model would be your ad driven. I would look at the core web vitals that Google gives you. Because if you are driven by just traffic, but it's going to be social and it's going to be a search that's going to provide your traffic. So the web vitals is a good, it's not a perfect metric, but it gives you a good idea of what's wrong. So commonly the server isn't even an issue. I mean it's often an issue. But often if you look at the vitals, the server is doing its work well because even on basic hosting it's good enough. Then the front is just ridiculous. So in terms of performance, you first fix that and that's already a lot of work. And then once you just probably a lot of hosts have like traffic layers so they will tell you once you need to go up. So in that sense you're safe. And pretty much at a certain point, just from the pricing, you're going to start to introduce like a cdn, like Cloudflare for example, is very popular. But then again, it's like Cloudflare makes your site faster. Yes, it does, from a certain level of traffic on. So that's something to look at. And pretty much if you have exhausted that, you're going to go to something like Altis Cloud or what is Pantheon.

At what point would you exhaust it?

Well, usually the thing is that when we talk about hosting, if you get to the point where you need Cloudflare and you have tons of traffic coming in, it's no longer just a problem of dealing with the traffic. At that point you are dealing with a website that gets actively maintained and developed and worked on. And that's where I think when I look at especially Altis Cloud, which is made by you and me, there's a ton of developer tooling in there. Because, because it's quite surprising to me, or it was when I came, you know, when I started building out websites on, on my own, is that you go to non WordPress hosting, like here's the server and then good luck, like how do I get stuff on the server? Oh yeah, however you want. So I'm like, okay, so if you have something like vip, Altus Cloud, they have a way to get code on the server, they have instant rollbacks, you have database tags, database backups, like all these features which are not really related to I guess the just handling the traffic but just working on the website. So there is also the part of what that depends on what hosting package you buy. But you can actually have the host scan your code for you know, basic quality insurance measures. So for example, when you, when you look at Altus Cloud, that's something, you know, if we have a plugin that we recommend, we make sure that it's, you know, safe perform and everything like that. So that's I guess more the angle when people start to switch because certain companies also do self host, you know, on AWS. Like doesn't matter what WordPress hosting you have, it's all the same stuff everybody else uses. Just a combination of things that makes it so special. And so since like the hardware and everything is very commoditized. For me the point at which you look at a higher priced hosting is when you need to really have those other features and also especially support, you know, if you're just on normal WordPress hosting, you have support but it's, you know, it is what it is. The thing is when you buy higher priced hosting, the support level is kind of also what you pay for and especially if you have a more specific needs. That's where I get into the second model. If you have a lot of logged in users then pretty much that's when you need to talk to a hosting company. And this is where I think in my view when people say for example, well Headless is performing this and that it's often because these are very bespoke setups, right? It's very specific to this one project or company or whatever. And you can have the same thing on WordPress hosting. It's just then at a higher price because I was on a project which is it's a site that publishes real estate news and they send out a newsletter every day at like 2 o' clock in the afternoon UK time. And that's how people, you know, know what, what, what there is. And I thought, you know, I've seen everything, nothing can surprise me anymore. But the traffic spike when a newsletter goes out, it's just crazy. Like nobody visits the site because it's all behind a paywall. So of course there's not a lot of, you know, SEO traffic. But once that newsletter goes out, just the traffic goes through the roof because essentially they have the best scoop about real estate. For some reason I didn't understand anything what they do but like really impressed. I'm like, wow, I've never seen this before. And so of course the problem that they have is that, okay, we have to, we have two like possible solutions. One is we pay a server, like a server setup, which is very cheap and then it's going to be crap when everybody logs on at 2 or we're going to have something which is very expensive, but then the servers just sit around doing nothing most of the time. Here is where, when you work together with a hosting company, actually the way it's handled right now is that before the new setup goes out, the servers scale up because we're adding more resources. And then once the traffic spike is over, it's like five o', clock, whatever, I don't remember the exact time, we just scale back down. And that's just something which you can only get when you pay a specific price to actually talk to people that know what they're doing, they know what they're talking about. So that's, I think more the switch that you do. But I think it's also, for me, it's also more when you look at a publisher, let's say you start out as a single person. Let's say I start a blog, right, and I write it, I do everything. And then at a certain point I going to need an assistance, I'm going to need someone to review the content. And then as it goes on, at certain points you're going to need somebody to look after the website. And so essentially once you go from a single developer to an agency, you know, there's going to be maybe cto. I think those are more the evolutions that you have inside of the company. And when you have somebody that looks after the website and they are specialists, they're going to tell you when to switch hosting, essentially. So I think that's just the part where as a publisher you need to recognize in the beginning you need to do everything and that's great. But at a certain point you need to say, okay, what is the value that I bring to this company if I'm, you know, a journalist? Essentially the content that I write, it's not my ability to click buttons in WordPress. And then you need to find a trusted partner which knows what they're doing and they're going to handle that for you. I think that's, that's the way to do it.

When we were. Sorry, Hugo, you go, no, no. Did you have a follow up question? I was just gonna kind of ask a different question.

Oh, I was Gonna, I was gonna kind of sum up the advice you've given that kind of. It sounds like your Basecamp advice is your, your core advice that if you have traffic problems, maybe throw money at, at the hosting company. It might be better to spend $10,000 a month on the best hosting you can buy. Because $10,000 is the salary for one developer probably each month and they may not get nearly as much leverage on solving your problems as a really good hosting company with really good support, with really good caching system, with really good tools that the debate about which technology to use, headless or core WordPress is not, not quite so important as finding the very best hosting you can afford.

Yeah, especially because once you get to a certain point or even at like the low end, there are certain hosts which don't allow certain plugins and the higher the price of the hosting, the less plugins you can use. So that kind of tells you where the problem is. Right.

Do you do that with your human made Altus hosting? Do you approve plugins or ban plugins? I know WordPress VIP used to do.

That a lot more.

Maybe not so much now, but very much used to vet everything that went on.

Okay, they do. Yeah. So we still do. I mean every host has even WP engine. Does it. They have like a blacklist. I was told, I don't know but I know that you certain plugins are kind of known for. Yeah. Not being very efficient. So the problem is essentially two, two fold. Well, I can only speak when I was at vip. So when I was at vip, the guarantee was very much the website stays up.

Right.

That's our guarantee. And so the responsibility for the website staying up was on vip. And so of course when somebody comes with, hey, I bought this for $70 on ThemeForest, you know, you're gonna have a look at what's in there. And so the difference really is that when you bring. Well, when we work on the client project at Human Made, which is the agency doesn't matter where we hosted VIP or you know, Altus Cloud, we look at the plugins that you bring because you need to make sure that it's secure, it's performance. And a lot of plugins don't make that cut. Very, very few do, like out of the WordPress.org scenario. So I think, and I think that that's just, you know, you need somebody to tell you. No, I would say that at any stage of, of your journey, like when, when you want to start a blog and you say, hey, I'm gonna get this $70 theme. I'm gonna be like, nah, maybe, you know, choose something very simple. Even start on WordPress.com in the beginning if you just have a blog, right? Because you know, it's gonna be stuff that is. That is good. So that's actually, you know, I don't envy. I don't envy a lot of people that are out there because you said, for example, yes, throw money at hosting. It's a very good, very mature combination up to a point. At a certain point, you need to fix the code. So who you're gonna find to fix it, you know, because I think that there's a problem. It's just, you know, there's a certain type of developer who will look at code and say, I can make this a lot better if I just would have written this code would have been this much and that much. And if you believe those, a lot of those actually, you know, gonna write something which is maybe a bit better, but not really. And they introduce a lot of new bugs and everything. So you need really somebody to look at it and say, okay, we're just gonna keep 80% of this as is, because it's gonna be too painful. And then we're gonna optimize 20%. Because even big sites, it's not like when you have like a big site with a lot of traffic, you look at it, it's like the most pristine code base ever. But it's just, you know, having that ability to distinguish what we can live with and what we can't live with. I think that's very important because one of the things, for example, which I always say is don't query by meta value, like, don't do it. It's just slow and unreliable. Now, that doesn't mean that there are no big sites out there that don't do that, but it's always done in a very, we know that this is bad kind of fashion, and we do it in this specific scenario to avoid this and that, right? So there's just a ton of knowledge that goes into being able to write good WordPress websites. And that's, I think, just due to the how low level everything is and how open everything is. And so, curiously enough, if you look at plugins that are being used is always the same ones. And for example, well, it's again, we had, when we look at Yoast, right, Yoast SEO, the plugin, it does sitemaps, and those are good, and we use those. But we had a project on which it was too slow and we had to revert back to the core sitemaps because they were faster in that scenario. So do you have any examples?

Why do you have any examples of plugins you've seen that are really well written plugins that when, when a client chooses it, it's like an automatic yes, that's sorted code that a plugin that someone could learn from in terms of optimizing for performance.

Well, it's a different things. One is it passes the bar in terms of security and performance and the other is being well written, which are two different things. So any of the plugins that you see from VIP turn up Human Made xwp, like all of the big names, you can be pretty much sure that that's code that is designed for large publishing scenarios. When it comes to well written, that's kind of where the opinion goes away. For example co authors plus which you probably know it works well. I mean it did work well until it got a little bit old, but when it was released it was a, was a great plugin. But in terms of just coding style I would have a lot of disagreements with it. But that's because, you know, coding style is again a thing why I'm a big stickler for it. But it, it's all because I've seen things that are anti patterns and when they come to bite you back in your rear end, for example, don't do a thing where you have your include in file which includes another file. You know, there's just ways to structure the code base to make it a lot more readable. But I think that if you were to look for a recommendation on specifically security and performance, look at the VIP documentation and ALTIS cloud because they are going to give you an idea of what to look for in terms of the big picture. The other part is that Human Made has the coding standards for PHPCs, automatic does to automatic VIP and those are going to flag things like data that's not escape data that's not sanitized, slow queries, all of that. So that covers kind of the basics. If you were to look at one book, which I always recommend, just going to do it in terms of just the approach to designing code bases, it would be code simplicity. I'm going to paste into the chat it's code simplicity.com so it's a very small. Yeah, sorry.

We've had a lot of luck building in the WordPress VIP scans into our daily coding workflow. Every time someone does a PR now on our repositories, it kicks off the VIP scans and Just on a day to day basis. That's been super helpful.

Nice.

Yeah, for sure. Yeah. But it doesn't catch things like singletons, for example. Singleton class is just an epidemic in WordPress. I'm like, guys, stop using singletons. But then they're like, why? And then they go into, why don't add hooks into the constructor. It's just, it's seen so much out in the WordPress space, you know, for example, adding hooks in the constructor. I can tell it without, like, without a doubt that a constructor function in PHP is always side effect free. Adding a hook is a side effect. Don't put it into constructor. Boom. Like that's discussion over. Like, I don't care who you ask the PHP word, that's just how it is. And in WordPress people will just argue for days with you that you should be able to do it. I'm like, fine, fine, you know, like, then do it however you want. And still a lot of plugins are like that. But the thing is that we all didn't know at a certain point. So at a certain point I also use singletons until I discovered that there are better ways to doing it. Now once I know that I can say, is it so bad using a singleton? I'm going to go and refactor all of my code that uses singletons to make it not use them. Or I'm just going to be like, hey, I'm just going to keep this as is and maybe refactor it later down the line. I would always say just refactor it down the line because singletons are bad, but they are not horrible. So that's why a lot of, you know, especially when you look at like big plugins that have been around a lot, this is deprecated. That is deprecated. That is deprecated, right? And that's because, yeah, the plugins evolve. You have to keep the code around and people learn. And so it's very hard to say, well, look at this plugin. And it's really, you know, the best way to structure it. But for sure, Code Simplicity is actually a book that would recommend us in the mindset of what you should change and what you shouldn't change. There's not a book which I'm going to find, which was actually, I need to look up the name, but it was, it's a book about programming principles and a lot of the code is like Java C, so stuff that I actually didn't know, but the principles behind it were, for example, have One. So in terms of, I think WASP C have one main function that bootstraps all of the program. Oh, that's interesting. That's interesting. And so all of the plugins that we write at Human Made, we have one main plugin file that loads all of the dependencies and you know, handles all of the setup is all in one file. So that when you look at that single file, already know I know what's getting loaded, I know what hooks are getting added in everything like that. And so that comes essentially from other parts of the programming world which have figured out that, you know, there is the more clearer you make the code, the better it is. But then to have hard and fast rules in terms of how to structure a code base. Yeah, I mean any of the engineering standards again from Tennant Human Made have going to have a lot of information about that.

Circling back, you mentioned the interactivity API. There's a new proposal came out a couple weeks ago. Is it moving in the right direction? Is Gutenberg moving in the right direction for your publishing, for your high traffic customers? Are you putting a lot of.

These.

Human Made customers onto Gutenberg?

Yes. So we haven't built a single site without the block editor since it got added. And we even built two sites when it was still a plugin. And the, the story is kind of. So Gutenberg is very much. Yeah, some people love it, some people hate it. But the thing is more that we were building these sites with a classic editor, right. The sun started on the classic editor because, you know, it was just that time. And then they are like, well, we want to add related article rows to our articles. So that's a short code because like, what else are we going to use? But are you really going to give this journalist a short code? Like, nah. And so Daniel Beckhuber, who also wrote co op, he created this thing called Shortcake. And Shortcake allowed you to have a visual interface for shortcodes, which nobody ever heard of. And you know, for course again it was great, but you're like, hey, Shortcake. So they could have a visual interface to select these articles. But it was so hard to do. Like ridiculously hard to do. And so then the other part is, well, we want to arrange the content on the homepage, but we don't want a page build it, we want a content builder. So in the beginning we had a thing called Zoninator which essentially gives us rows of widget areas and you would, we would create widgets for all of the different parts of the homepage and you would Drag them in. Which is called horrible. That horrible.

It was like Gutenberg before Gutenberg almost was bad.

It was really bad. It was like widgets, like classic widgets, right? I was so bad, I was just. But then again, back then, for us, it wasn't like we were saying, well, this is NASA level engineering. But that was essentially the best you could do. And so what actually was done for the sun, it's that we developed a custom homepage management tool for them to like build that homepage. And they were super happy with it because they were using it all the time. It is a content builder, not a page builder. So great. So when Gutenberg came around and I looked at it was like, wow, like, this is exactly what we need, right? Because people got so hung up on, oh, I can write the paragraph in the classic editor. Like, you don't understand anything about what is is. Like, nobody cares about the content anytime, right? In the beginning, what you care about is the stuff that powers the content editor, right? Essentially all the APIs, the block building APIs, the data handling, all of that stuff, right? Coming into WordPress and people were just like missing the folders for the trees. They're like, I don't like this editor. Forget the editor. Look at the APIs that gives you. Look at the possibilities that this gives you and look at how you can leverage this. And it's a great. You know, I am on Twitter and I always like when I read these opinions, like, nobody of my clients like bulk editor. I'm like, sure, right? I work with people that write all day, somehow they like it, but your clients don't. I'm like, okay, then, you know, like, I'm not calling you a liar, but maybe you do a bad job explaining it. You're probably doing a very bad job at using it. So why would they like it? You take a tool, use it badly, like, why is somebody going to like it? So that's just the thing with the editor. But I think the bigger picture that people are missing is again, forest for the trees. We have the block editor, everybody calms down, then comes full set editing. Drama over. And I'm like, look, it's not again, it's not about full set editing, it's about all the stuff that comes underneath. And now that we have the phase three with the integration activity, where they're saying, what are we going to change the admin screens? We're going to change this, we're going to change that. Essentially, if you're not on board with the Gutenberg Project, like The whole deal just quit WordPress, like not saying that in a bad way, but you cannot. WordPress is not going to stay the way it is. The classic ad is going away, which is going away. Classic themes are going away, like over time. Over time it's going to be that the admin is no longer going to be just PHP scripts. Let's remember that like admin pages are PHP scripts that get read from top to bottom. That's all going to go away. And all these technologies like JavaScript, that's going to be the default. There's going to be a future where you cannot be a WordPress developer if you don't know, react. Right. So that's why I think that the just the freedom that it has given us because once you make the switch to understanding how this is built, I mean the stuff that you can build with it. I know that Joe Hoyle. So our CTO has built some AI thing which I haven't looked at, but I just saw the video. I'm like, well, it's pretty cool, right? He took some AI thing. Now it's in the editor, obviously our newsletter glue, which is also quite awesome.

Right.

We can now make related post process in half an hour. We can. We have already collaborative editing running on one of our client websites. So I'm like, we can do all of this stuff, like, show me where classic workers can do this. And we have journalists that are like, again, content building, not page building, but content building. Certain key sections of the website, they control their homepage obviously what goes where. So yeah, we just use it as our default tool. And for sure it's not the easiest ones to work with. I mean, let's be honest about it. But it's just you need to take the pain to get to good in that sense. That's how I look at it.

So did you drop a little bit of news there that you're already running Gutenberg Phase? Your Human made is so committed to Gutenberg that you're already running Gutenberg Phase three. We on. On a customer website you have collaborative editing up and running.

No, that is something that we develop from scratch. One of our clients that was. It was a couple of years ago by now they said, hey, we want to have collaborative editing. And we were like, yeah, you know, why not? So, oh, like it's hard to do, but it's not ridiculously hard to do.

So there was a demo at WordCamp. Asia was there.

Yeah. Yeah, that could be that.

Yeah, I think that was multi dots maybe.

I think they did it and also Human Made. I think I saw something from Human Made about collaborative editing.

There's like a multi dots, maybe RT camp, like put it to life. So like the VIP demos of it, like when they were doing the tech partner stuff a while back, it's pretty cool. Um, it's a weird one cause it's going to be more like significant change in the WordPress. It's all web sockets, so it's kind of like you're on an extra layer into your like PHP stuff, opening reports and things like that. So it's a real change. But it's cool, it's really interesting to see it work.

Okay, so there's a few, a few people approaching this problem from different angles, kind of proving that collaborative editing is feasible and is going to be a workable addition to WordPress.

Yes. I think again when we talk about phase three, I think the people get so, people get so hung up on collaboration, everything like, well, I don't ever collaborate with anybody. I'm like, yeah, okay, yeah, but forget collaborative editing. Just look at all the other stuff that you're going to do. And one of the things that you said, oh, workflows. So that's actually something which again we've built for clients. So we have a client, they are a bank. And so if you are a bank, you can just have people typing stuff into the CMS and hit publish. Then it's public. Right. Because it's bank. They have all kinds of regulations. So there's an entire workflow where you know, you have a page, you change it, you submit the change, somebody reviews it, if it gets approved, it's published. Different sections of the websites are different owners. Like this whole workflow deal we have already built out so it's possible to do now it's just really, really, really hard to do.

Let's be honest, this sounds like publish press territory.

Right?

But the thing, I mean it's just, I mean it's not, how can I say that? It's just complexity of it all. It's just mind bombing because they have again, you know, it's not just. How can I say that certain sections are run by this team. They have one level of approval. Other sections of the website need to be approved by the boss and then by legal. So you know, there's entire workflow again around who can approve it and how. And then there's again pages which are different because one page is owned by one team. So yeah, it's quite complex. But actually now, right now, since it didn't pay 3. I wouldn't want to develop a workflow plugin for WordPress because, you know, it seems like it's going away. But again, but the thing is that if you haven't ever built something like that and you haven't run up against the limitations of WordPress, which are, to be honest, quite severe, then you don't get why this is so exciting for people. So I think that's like the best, the big disconnect is that if you're not using it, you know, it's kind of like for them it seems, for certain people, I think it seems like they are just changing WordPress for their needs and they are kind of getting left behind. But I think more that if you are kind of building simpler websites, just wait until the plugin ecosystem catches up and then you get all that stuff for free.

Right.

So. Or for very low cost. Because if an agency develops this, you know, collaborative editing, although it's a publishing workflow, it's gonna cost a pretty penny. So that's kind of the, the problem with it. And so since it's now only WordPress, it's the same thing with like full site editing, you know, you can buy a page builder which has limitations because it's Never native to WordPress or you take just full set editing. It's free, it's built in, it's compatible with everything. That's kind of how I look at it. Right. So the benefits for me like way outweigh any of the downsides.

Oh, sorry, I was trying to mute myself.

We have a workflow plugin coming in like a month or so. Probably, probably the worst timing for a plugin release ever with that like Morty Dots, probably they're dropping their collaborative plugin just before phase three. We're dropping our workflow plugin just before phase three. I probably regret this in like a year or so.

Yeah. But I think phase three, it's, I mean look at how long the phases have taken. I mean the blog editor got introduced in 2018. Right. Full set editing was what, 20, 21. So there were three years between, you know, when got introduced and when he went for the next phase. So the phase three, I think it's going to be a couple of years and even then, you know, because I think that's one of the problems with editing. Some, you know, when it was announced some companies jumped on it and then it changed so much. And what's this one? Page builder, I can't remember the name. There was a company that they started to build a Page builder based on blocks. And then they certainly just said, hey, we're going to stop until this thing settles down because we just have to do too much. So yeah, and probably it's going to be a migration path, so I wouldn't worry too much, to be honest.

Pete, I got one last question. Oh, sorry, do you have a question for me?

Okay, no, go for it.

Okay, so I just want to circle back to this question of when of headless and scale and sizing you talked about if you had an ad driven model and. And then you end up the. The answer that I took away was hit the hosting. Let that serve you for as long as you possibly can before you complicate your life with headless. Now if I go back to TechCrunch, they have a login system, right? And for those of us that have login systems or publishers that need a subscription system or whatever, could, could TechCrunch be okay without headless? Like at what point with a login system, a subscription system, do you really need to invest in that complexity of going headless knowing that there are limitations with like you can't just drop in functionality like you mentioned earlier, and it gets really complicated. So where, where do you say, you know what we have, we just have special needs, we have so much traffic where we need to go. Headless is really the way to go. And then again, could, would like if, if you, if you could snap your fingers, would you go back to native WordPress, TechCrunch or is that not. Is that completely out of the question?

No, for TechCrunch is out of the question because one of the challenge which adds to just the whole discussion is that very few big companies let people store user data in WordPress. So yeah, that's just the thing. So usually that's when you know pretty much every. So pretty much. So if you look at the wider WordPress space, I don't know how many people have ever implemented a single sign on solution, but if implemented a bunch because at a certain size that's just what you have to like we have single sign up for Microsoft, whatever. I'm like, okay, cool. So that's kind of more of the problem because I know at least three clients, let's say user accounts never going to be stored in WordPress, we saw in our own infrastructure with our own whatever tools which is already there. And so you're just going to use that. And if you're dealing with that then you. Yeah, then it makes a lot more sense. The other part is if you have to integrate the CRM again. Yeah, it's just the downside of WordPress is that you have two, you only have two choices when you're dealing with an external platform. The first choice is you duplicate all of the data in WordPress, which is going to be very painful and also impossible to a certain point. The other part is you let the PHP get the data, which is very slow and you know, due to the synchronous nature of php, it's going to be a very bad experience. So what you can do as a in between is that if you know that only certain sections of the website are impacted by the logged in status, you do a hybrid model where the page delivery is actually php. So all of the stuff you should be able to see is all in php. And then the parts that are used are dependent are just done in React, for example, because React is very good at creating very small applications and you can hook them into certain sections of the website and they all talk to a central store. So yeah, that would be the possibility. And even if you were to have like a paywall, you make the paywall JavaScript driven, which you know, people can get around if they disable JavaScript. But like, honestly who does that? You know, like in the wider world most people don't even know what JavaScript is. So like why are you worrying about that? So I think that the mix model is very good, but I think that when it comes down to choosing a solution is how much of it is pre done. If you have a pre done monolithic solution, WordPress and a pre done headless solution, that's a better choice than either custom WordPress or custom headless just because of the price point. Right. If somebody would give you just the thing, however you want it to be made and it's just perfect, you don't have to do anything. That's the solution that you're going to take. So that's I think the big challenge because I think what a lot of people underestimate is not just the building cost, but the maintenance cost of it. Even with php you could have written some php code 5 years ago and right now it's like, oh, we're going to PHP 8.1, you know, PHP 8.2, 7.4, all these things. Yeah, so there is anything custom that you has as a cost associated with it. So it's a tough decision, to be honest. And I know that people have, you know, some people have gone headless, they regretted it. So some people, it's just, yeah, I don't know. It's a tough choice to be honest, but I think that when we specifically talk about logged in users, my hope is that we're going to see more of these hybrid solutions because really if you have a whole page, you don't need to get it fresh from the server every time because there's a bunch of stuff which is always going to be the same. So I think that the approaches there are not really great. And that's the same for everything. When we're talking about learning management system, when we're talking about any other of these content storage mechanisms, just the thing where when you log in, everything is taken fresh from the database, it's probably not the best solution going forward.

Cool, Good stuff.

Just to say we have done that hybrid model many times as well. Wherever the whole page just returns from the server every time. And we have a react app that reaches out to access control this identity stuff through like JWT or something to be like, yeah, this user has. So like allow them through, don't do anything or render out the paywall blocking stuff. It works really well to do that kind of thing. Then there's another one I've just kind of recently become aware of a company called Zephyr, if you ever heard of it, maybe more so than any of the others. So it effectively operates as like a cdn. Like you put it in front of your site and it like passes through. There's comments in your HTML or classes in your CSS that it uses against its own user database to parse your responses, to make changes kind of in real time. So your user database lives inside of Zephyr. They kind of handle all that payment stuff. But you then mark your content as use this feature or not and then it caches all the responses that it needs and it works really well.

Cool. Yeah.

What's the name? Zephyr. As in like a breeze? As in a wind?

I think so.

Z E P H R PH E.

R. Yeah.

Go ahead, take a look.

Cool. All right, thanks so much. Thanks Frank, for this over an hour long education into what enterprise sites are doing and caching and headless and all of that stuff. Where can folks go to find you if they want to hit you up DM you to learn more or have questions.

Yeah, so you can connect with me on the post status or the WordPress.org slack. I'm @fklox on Twitter. Then my website is wpdevelopment courses. So that's where I teach block development and block theme development courses. So yeah, and then of course, you know, if you will have. If you have something to build, which is enterprise, reach out to human made and yeah, it will set you up.

Awesome. Thank you so much.

Yeah, thanks so much, Frank.

Yeah, thanks, Frank. Much appreciated.

And thanks to it for joining us as well.

Yep.

I think that wraps it up halfway through. Catch you later.

Right. Cheers.