EDITS.WS

Category: wptavern.com

  • #71 – Nathan Ingram on How To Manage Contracts With Your WordPress Clients

    Transcription

    [00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley. Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case how to manage your website client contracts.

    If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

    If you have a topic that you’d like us to feature on the show, I’m very keen to hear from you and hopefully get you or your idea on the podcast as soon as possible. Head over to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

    So on the podcast today, we have Nathan Ingram. Nathan is the host at iThemes Training, where he teaches WordPress and business development topics via live webinar. Based in Birmingham, Alabama, he has been working with clients to build websites since 1995.

    He’s also the creator of MonsterContracts, which helps WordPress professionals create contracts for their client work.

    If you’ve worked directly with clients, then you’ll know that things don’t always go according to plan. Assets might not be delivered on time. The client does not respond to your emails. The expectations of the client begins to creep away from the original proposal.

    Whilst there’s unlikely to be a perfect system to ensure that all projects run according to the plan, you can protect yourself from some of the worst aspects. And for this, you may need a contract.

    Nathan is on the podcast today to talk about why he thinks contracts are an essential part of any client facing WordPress work.

    We begin by talking about how the contract is designed as a tool to bring clarity to both parties. You, the website builder, can set out the constraints within which you work and the client can understand what they can, and cannot, expect from you. Nathan thinks that setting these expectations before the project begins leads to fewer problems later on.

    We talk about the fact that contracts don’t need to contain overly complex legal language, but they do need to be checked by a qualified legal professional before they’re deployed.

    Nathan also explains how he’s refined his contract over the years, tweaking the wording and the structure, depending upon the project at hand.

    We then get into what you can realistically do should your client breach the contract. Are you able to turn off their website, or withhold work that you’ve completed? Nathan’s not really in favour of sending in the lawyers as soon as something goes wrong. Rather trying to resolve any conflict through better communication.

    It’s an interesting conversation, which makes contracts seem less adversarial and more about ensuring that your WordPress website projects run as smoothly as possible.

    If you’re interested in finding out more, you can find all of the links in the show notes by heading over to WPTavern.com forward slash podcast, where you’ll find all the other episodes as well.

    And so without further delay, I bring you Nathan Ingram.

    I am joined on the podcast by Nathan Ingram. Hello, Nathan.

    [00:04:07] Nathan Ingram: Hey Nathan, how are you?

    [00:04:08] Nathan Wrigley: That’s strange. I’ve not had that before. Two Nathan’s on the podcast today. Very different levels of experience in the subject that we’re going to be talking about. Nathan Ingram is here today and he’s going to be talking to us about the legal aspects of hiring clients.

    You might describe it in one word as contracts, I guess. And there’s a whole treasure trove of things that we’re going to unpack there. But before we do that, Nathan, if anybody hasn’t heard of you before and hasn’t seen the things that you are doing online, would you just spend a few minutes introducing yourself? You can go back as far as you like but, give us yourself in the WordPress context.

    [00:04:44] Nathan Ingram: Yeah, sure. So I’ve been working with WordPress exclusively since right around 2010. I run a small agency down in Birmingham, Alabama. I’ve been working with clients since 1995. So I’ve been around the webspace for quite a while. I also am the host at iThemes Training. So we do live training webinars three days a week through iThemes. And then I also do some business coaching, and I have a product called MonsterContracts.

    [00:05:08] Nathan Wrigley: Tell us about the iThemes thing for a minute, because I know you do trainings over there. How did that all come about? Was it like a happy coincidence that you ended up doing that? Were you making content, training content, elsewhere that got you into that position?

    [00:05:22] Nathan Ingram: No goodness. So it’s really an interesting story and we could take a whole , a whole episode on how do people find their way in the WordPress community? So for me, iThemes was actually iThemes training at that time. Early on it was called webdesign.com. They had leased that really awesome domain name.

    And it was where I learned WordPress. At that point I was sort of in a, the Macromedia ecosystem, and I had resisted WordPress for quite a while. Decided this is coming and I’ve got to go with the flow and move into WordPress, because a lot of my clients were looking for WordPress sites. Or sites they could log in and edit themselves. I found iThemes as a theme company, and the training went hand in hand, and that’s where I learned WordPress. And gradually over time, I started presenting one or two webinars and then gradually rolled into the presenter role.

    [00:06:08] Nathan Wrigley: That’s nice. And so you do that regularly, three times a week. You go live and give trainings about a whole range of different subjects, right?

    [00:06:15] Nathan Ingram: Yeah, like just yesterday we did our monthly news roundup on iThemes training. So look at the news in the WordPress world. Particularly from the perspective of people who build and manage websites. That’s really our audience on iThemes training. What news is important for people who do what I do.

    [00:06:29] Nathan Wrigley: Okay, so that’s really excellent. Unfortunately, it’s not the topic that we’re going to be talking about today. We’re talking about one of the areas, I think in web design that really can cause the blue touch paper to be lit, and the firework to go off. This is the whole thing of relationships with clients and the boundaries that you set, and whether you should have contracts, and whether you should be getting involved with lawyers and things like that.

    And there are very few parts of the business that I used to run, which would cause me to become upset, irritable, and in some cases quite angry. But relationships with clients could do that. It’s quite unique, isn’t it?.

    [00:07:15] Nathan Ingram: Oh, it really is, and I’ll tell you, it is certainly one of the common challenges that people who do WordPress things run into. You go to WordCamps, back when we used to have those things, so we actually just had our WordCamp Birmingham two weeks ago, and it was wonderful to see people in person. But when you get a group of people who work with clients around, you know, a table eating lunch at an event like a WordCamp, inevitably the conversation turns to bad clients and everybody has a story.

    [00:07:40] Nathan Wrigley: Yeah, it’s just one of those things. I’ve got a whole litany of stories. On the whole I think I was able to manage this scenario fairly well, but there was a lot of things probably that I shouldn’t have done. So I gave way in many cases because I believed that the things that the client was asking for didn’t really push the boundaries too far, although they certainly stepped over the expectations that I had.

    But your premise really, the reason why you’ve been getting into this and talking about this is because you want to prepare people and educate people to give them a kind of legal framework. And you describe it in terms of boxing in a client if you like. That’s probably too harsh a word.

    You go about it in much more conciliatory language than that. But the point is, you are educating people to get themselves into a position where they’ve got some piece of paperwork, some contract. Something written down somewhere where you can all go back and say, okay, these are the boundaries, these are the constraints. If we step outside of these, one of us is at fault. So tell us a little bit more about your approach there.

    [00:08:47] Nathan Ingram: That’s a great question. So years ago I put talk together about dealing with problem clients. And the title of the talk was “dealing with problem clients, building fences around friendly monsters”. And it’s a book, actually now I turned that into a book on Amazon. But, it’s really positioning the client, every client as what I would call a friendly monster.

    Meaning they’re friendly, but they still have teeth. The idea is we need to build fences around the clients that we work with, because we never know what kind of person we’re dealing with. And the fences that I talk about are the systems and processes in our business.

    Four in particular. We need to establish clarity. We need to have good commitments between us and our clients. We need to have communication and documentation. And those four fences can show up in a lot of different ways depending on your particular business and how you work. And there may be additional fences you’d want to build, but those four at least have to be in place in order to have good ongoing client relationships.

    And a lot of those things show up in a contract. But they start as just part of your regular business system, the way you work, the way you deal with clients. Clarity, commitments, communication, documentation. And that’s where it all has to start. Like you’ve got to get your house in order before you can really bring in a good document, like a contract to, make your rules clear.

    [00:10:10] Nathan Wrigley: I think the clarity piece coming first is really intriguing. Because that was always the misstep that I felt I’d made. In that I was very often in a position where I felt that I had explained myself clearly, and assuming the clients were being honest when they were explaining their frustration with the way things were going.

    I clearly hadn’t done that. I maybe expressed it in a way which I understood, maybe that was too technical. And later down the road it became obvious that there was a complete disconnect between what I was trying to achieve, and what they, in their head, had got designed. And so yeah, the clarity piece, I think is perfect at the beginning, but also quite difficult to achieve. How do you, how do you advise that? What are some of the strategies that you’ve got in place around that?

    [00:10:57] Nathan Ingram: Yeah, it really is difficult, and one of the first things I think you have to realize is that agreement on the surface does not equal clarity. So, if there’s no meeting of the minds, like maybe we use technical jargon, or maybe the client doesn’t tell you everything at the beginning.

    I can’t tell you how many projects I’ve gotten into where the client, we’ll get three quarters of the way through the project, and they’re like, oh, well where do my clients log in? Well, wait, we haven’t talked about this at all. And in those sorts of situations you ask yourself, well, whose fault is that?

    And I would say it’s probably 50 50. And so one of the great skills that we can develop in in way, but specifically in our way of working with people on the web, is learning the skill of asking great questions. If you learn the skill of asking great questions, and continuing to ask until you reach that point of clarity. That skill can really set you apart from other people that are doing client work.

    Asking a question, asking why, and following up with additional questions until you really get down to the root of what the client expects. If you don’t do that, then oftentimes you can be saying one thing, the client can be saying another, and you’re both shaking your head up and down, but nobody is really clear on what we’re saying. Assumptions are made.

    [00:12:08] Nathan Wrigley: In the work that you do, do you typically do all of that client exploration work prior to beginning the build? And then in a sense, that process is closed off, and you go away and you take six weeks, whatever it takes to complete your initial first offering and then go back to the client? Or do you, do you encourage a more agile approach where you iterate with the client? I mean, I know that they’re completely different ways of doing things. Curious as to know what your process is.

    [00:12:36] Nathan Ingram: So it really depends on the complexity of the build. We try to get some understanding of that at the very beginning, when we’re trying to create the scope of work. If it’s a project we’ve done before, if it’s a simple, just a basic identity piece, a brochure site, that’s fairly simple.

    When you get into something that is a lot more complicated, maybe there’s lots of different content types, or you’ve got to do some really interesting thing with data. A lot of times what we’ll end up doing, and I picked this up from my friend Beth Livingston, a change budget. So adding a change budget into the original pricing, that as we go forward and the client gets more ideas where things are uncovered, that we didn’t realize, there’s some pre-approved money sitting there, that the client can say, okay, we’ll allocate some of that change budget to build this thing that we hadn’t talked about yet.

    [00:13:22] Nathan Wrigley: Yeah, we’re in such a curious industry as well, in that there’s not many things that I purchase that morph over time. You know, if I go into a shop and I buy some clothes, I’m just getting what I’m getting. I can see it right off the bat, and there it is, and I can hold it in my hands, and it’s either what I want or it’s not what I want.

    I’m not going to purchase that pair of trousers and then turned around a week later and said, actually, you know what? These pockets. I’ve been wearing these trousers for a couple of weeks now, and the pockets are not deep enough. Can we have an amendment to the pockets please? This curious idea of scope creep that creeps into more or less every project that I was ever involved in.

    Are you getting your clients, after your initial discussions then, are you getting them to a point where you draw up some contract which in effect puts the four fences around the friendly monster that you were describing?

    [00:14:12] Nathan Ingram: In our world we would call that the scope of work, which is part of the proposal. That comes from the original conversation. Or if it’s a complicated project, maybe there’s a discovery phase that happens first to really flesh out, what is the scope of work? What are we trying to accomplish in this project.

    And then depending on the complexity of the project, the longer, or the more complex a project is, the greater chance of scope creep. Or honestly, the longer a project takes, because the client delays on content or something else. The longer a project takes also, you tend to have scope creep.

    When you talk about scope creep, people’s eyes roll. They hate scope creep. But I’ll tell you what, I love scope creep as long as there’s corresponding price creep, right? If you want more things, that’s great. It’s just we can’t do more for the same price. In your analogy about, we don’t use the word trousers.

    [00:15:00] Nathan Wrigley: Oh yeah, you use pants don’t you? I apologize.

    [00:15:02] Nathan Ingram: Yeah. When you’re talking about something like that, it’s a little bit different because, well some people sell websites more as a product rather than a custom service. We’re more on the custom build side. Everything we do is bespoke. But you know, if you’re selling websites as a service, that is a good analogy because you’re in package three and this is what it comes with and this is your pair of pants.

    But for us it would be more like, I’m hiring a contractor to come in and do a remodel on a kitchen .And this is kind of what we talk about at the beginning, but as we go, maybe we had a problem we didn’t anticipate. Or maybe my wife sees something on television that she wants to add. And so we want to add to it and we change it along the way. That’s really a closer analogy, I would think, to a custom website.

    [00:15:44] Nathan Wrigley: It’s pretty clear that the audience for this podcast is pretty broad and deep. In other words, there are all sorts of people listening to this doing all sorts of work around the WordPress space. Some of them very new to WordPress and website building at all. Some of them just doing it for their own hobbies. Other people just getting into building websites for the first time.

    So let’s speak to that crowd first. The crowd who really are just embarking on a career. They’re scoping out whether they wish to build websites for other people and charge for that, and make a business out of that. Let’s speak to the importance of a contract, because it may be that when you’re starting out, you’re just doing this with friends and we know that that can turn south quite quickly.

    So, and also, you know, you may be encouraging businesses in your local area to come on board and they’re going to be expecting something like a contract. Is this an essential component of the makeup of a web designer? Do you truly need a contract? Or is there any realistic situation where it’s okay to begin work on a website, charging a fee without some legal protection?

    [00:16:50] Nathan Ingram: Wow, what a great question. For years I worked without a contract. I just had a proposal with a scope of work and a price, and you pay me, I build the thing and there it goes. Then I started running into problems. Expectations that were never really talked about anywhere. For example, oh wait, this would’ve been like many years ago.

    But at that point it was maybe Internet Explorer 6 was the browser of choice for everyone. And the person would say, wait this is not working on my Internet Explorer 4. Well, we don’t design for older browsers, we design for newer browsers. And there was great difference in rendering between those two.

    These are the sorts of things that you don’t think about until you have a problem with a client. What I like to say is you don’t need a contract for good clients. You need a contract for bad clients. But my goodness, it’s hard to tell them apart at the beginning. So every client gets a contract. And my contract is mostly plain English, and virtually every paragraph in that contract, aside from the necessary legal constructions, everything in that contract is there because I had a problem one time with a client. That now gets added to the contract for the next time.

    [00:17:59] Nathan Wrigley: I was very much like you in that I began way back, and it was long before IE6 in fact. I remember writing that into my contracts at one point. We are not supporting IE6. It was exactly the problem you described. I had happily breezed through multiple websites. No problem at all, everything was fine. I had a client who simply was able to push harder than anybody I’d come across before. In other words everything that I delivered, they would either reject or request it to be entirely different.

    So this whole notion to me of scope creep and the client who refused to accept that anything was finished, came along. And it really was at that point that I started to look around and try to protect myself. So, I would imagine that your advice is really, it doesn’t matter on what level you’re doing this. You need some kind of legal protection, right?

    [00:18:51] Nathan Ingram: So I would even take a step backwards. You need a consistent process that you use for every client, every project, every time. And that process needs to be documented somewhere in something that you and the client agree to. Call it whatever you want. Call it a contract. Call it, as we do, a master services agreement. You could put it in your proposal, but just have some place where everybody’s agreeing to the process. That’s that piece of clarity at the beginning where we are clear on how this is going to proceed.

    Where we get into trouble is where we, we think, well we just sort of do every project differently and there’s not really a consistent process. And so the client is able at that point to dictate how the project goes. Will have at some point, you know, some level of control over your world, as long as you’re building that website. Instead of realizing, okay, this is the best way to build. We’re going to document this process out, and have the client agree to it in a contract.

    [00:19:47] Nathan Wrigley: I guess whenever I’ve read legal contracts before, whether they’re for my car insurance or what have you. I’m always confounded by the language used, within moments of beginning the reading of it. I’m coming across, not only words which I haven’t encountered before, but the sentence construction is entirely bizarre.

    In other words, it can be read by a lawyer. Sometimes I’m confused as to whether or not it’s written deliberately to be hard read or whether or not it’s the most expedient way of hammering something down perfectly. I can never parse that. Either way, I’m left confounded.

    So given that lawyers very often end up with this language, which is impenetrable. And you mentioned that your contracts are in plain English. Is it possible to nail things down, absolutely watertight with plain English? And do you feel yourself equipped to do that? Or is this really the domain of a lawyer? Do we need to get a lawyer to go through your contract and inspect it to make sure that in every scenario it’s having your back?

    [00:20:59] Nathan Ingram: So, just first of all, I’ll answer this from my perspective as a person who’s been working with clients, doing web things for over 25 years. I’m not an attorney. This is not legal advice or anything like that. But my experience has been sort of a blend of both.

    It’s important to have good, practical experience working with clients and knowing what the problems are. But you also do need the legal language. Because if the worst thing happens and you end up in court with a client, there’s a reason that attorneys write things the way they do. You know, this is language that has been proven out and so forth.

    And so if you take a contract that is exclusively plain English, you can get tied up with defining what the meanings of this word and that word and so forth are, and it turns into a mess. So, if you went out today and you did a search for a web design contract on the web, you would find two types of contracts in general.

    You would find some that are just absolutely plain English with no legal constructions whatsoever. And those are okay. They do establish clarity, or give you kind of a template to establish some clarity. But they don’t have the legal protections. On the other side, it’s like the total opposite end of the spectrum. Contracts that are a hundred percent legalese, and I don’t understand what some of these things mean. And this is what you were talking about a bit earlier. And I’m not sure if that really gives clarity to the client, because nobody really knows what any of this means unless you’re an attorney.

    And so what I found to be the best approach, and this is what I’ve done, is I began years ago explaining our process. Explaining what we do, what we don’t do. Explaining some of the issues like browser compatibility, and what happens if you hire a digital marketing person that comes in and they break your website. Are we responsible for that because we’re managing your website.

    All of the bad experiences I’ve had with clients, I started putting those things down in a document and then I gave that to an attorney and said, okay, make this legal. And so they added all the necessary legal constructions, and patched the holes. Over time this has become my agency contract, and that’s what I ultimately turned into MonsterContracts.

    [00:23:02] Nathan Wrigley: With your contracts, did you find that the nature of the project at hand, in other words, the one that you’re working on right now. Given that each client website is slightly different and it may have different constraints. It may need, I don’t know, let’s imagine, a WooCommerce store or something like that. We really are getting into a completely different variety of website. Or it may be a simple brochure site. Or it may be that there’s a bespoke plugin, for example, has to be written for that website.

    Do you advise taking those contracts that you’ve had written, or rather inspected by lawyers, do you take them back and get them to look, more of a scan through each time and append to it, the bits and pieces that are needed? Or have you settled on a contract which you think is broadly good enough to fit any situation?

    [00:23:50] Nathan Ingram: It’s a great question. So this exact situation is why I recommend a two document approach. So we have a proposal of services that deals with the scope of work and the price for every individual project. And those are going to be different every time. But then we have a master services agreement, or a contract, that has the rules of the road for every project. These don’t change. And so we present those documents together.

    So the contract that the master services agreement covers the process. All these things that we do and timeframes, and what happens if you don’t pay and, here’s how the website management works, and we don’t guarantee results for SEO.

    All these things that need to be in a contract that don’t change from project to project, are there in the contract. But then the scope of work of we’re going to build this plugin, or we’re going to add a store, we’re going to do whatever. Those are in the proposal, which is the scope of work and the price for that individual project.

    [00:24:43] Nathan Wrigley: Right, okay, that’s an intriguing separation. Yeah, so two different documents. One which is more bespoke and one which is more generic and you can reuse over and over again.

    [00:24:53] Nathan Ingram: Exactly.

    [00:24:54] Nathan Wrigley: So, given that we’ve got a contract. Given that it’s been written by a lawyer, and there may be aspects in there that are impenetrable to us. I guess there’s always going to be a need to go back to the lawyers. I can imagine the fees of this starting to tick up quite quickly actually. Because if a client comes back to you and you believe they’re in breach of the contract in some way, but the contract is difficult to read, it’s in that legal language. That’s an important thing to do, isn’t it? You really do have to understand the ins and outs of your contract.

    So given any scenario of inverted commas, wrongdoing by the client, you are able to say to them with confidence, look, this is what you signed. This is what this clause in the contract meant. In other words, you have to know what it says in plain English in your head. Otherwise you can’t really enforce it, because you wouldn’t be sure what you were able to enforce.

    [00:25:47] Nathan Ingram: Right, and this is why if you were to open my agency contract, or if you were to look at MonsterContracts. You would see things like payment terms, and they’re all in plain English. Again, this is why I said earlier, I want to have my system documented ahead of time.

    Like I want to know, internally, this is how we deal with late payments. This is what happens if the client disappears during a project, all these things. We have our policies internally for this. Those are then put into the contract in very plain wording that can be easily pointed to. There have to be legal constructions, but these are, they’re really at the end of the document and they don’t pertain, nearly as much to these practical issues that come up with the client.

    [00:26:28] Nathan Wrigley: Do you ever, so this is a question more directed at you personally, given that you’ve got all these contracts and you’ve thought all of this through. Do you ever let things slip, in other words, you’re having a conflict internally. Part of you saying, I know that this client is now in breach of what the, not only the spirit, but the letter of the contract said. But I’ve got a bit of a spidey sense that I can let this one go. It feels like it’s going to be all right. Because there be monsters down there.

    And it’s so easy. I did that and probably continue to do that quite a bit, because sometimes I feel that if I push the legal button, I really have transformed everything. I’ve suddenly gone from it being a fairly friendly relationship, albeit fraught at times. To a really adversarial relationship where the lawyers are getting involved and so on. So I’m just wondering whether or you permit yourself to ignore your contracts in some scenarios.

    [00:27:24] Nathan Ingram: Oh, what a great question. So the answer to that question, it revolves around emotional intelligence, right? you have to make a judgment call on, is this a situation that is worth really enforcing the contract or not. And honestly, many times, let’s just say, here’s the situation. The client, we’ve been waiting for three months for the client to supply assets that are needed to build the website, and that happens all the time, right? Clients delay, delay, delay for content, and photography and everything.

    So, in the contract, it says if we haven’t heard from you in 30 days, then your project is suspended. And there’s some things that happen as a result of that. Now, can we choose to change that? Sure, but oftentimes what will solve that problem is a simple email to the client. Hey, we haven’t heard from you in the last 30 days. At this point your project is about to go into suspended status. And this is what that means.

    We explain in the contract. And just having a clarifying email like that can oftentimes shake up the client and get them refocused on the project. If it doesn’t, then you have to make a judgment call on, is this a salvageable project or not?

    [00:28:34] Nathan Wrigley: Yeah, I feel like I’ve encountered many different interpretations of this. On the one hand, there’s a lot of people out there in the wild who really are proponents of, look, the minute it goes wrong, start lawyering. Just protect yourself. Get the lawyers involved. You cease communication with the client and start to go through the lawyers.

    It’s this idea of, it’s not working out. I need you to do what you’ve agreed right now, otherwise it doesn’t work. We also hear constantly about firing clients and the joy that that can bring.

    But on the other hand, I feel that, like you said, you have to judge off your own instincts sometimes whether there is a legitimate reason behind there. And that has happened to me. You know, I’ve had clients that have not delivered things, and then it turns out there’s not only a plausible reason, but a reason, which if it were me in their shoes, I would desperately want the web designer to understand my crisis.

    Something personal has happened, some event in their life has meant that they literally have been away from the computer for weeks on end. And so it’s not really their fault. I guess the answer is use your judgment. Invoke the spidey sense, and figure out which is the best way to proceed.

    [00:29:42] Nathan Ingram: For sure. I mean, we’re dealing with people here, right? And so my default dealing with people is generally grace. I’m very gracious with people. Understanding about issues that come up. On the other hand, it’s important to have a document that protects you. If you get to the point where you have to fire the client.

    That’s a great conversation. And, and you hear a lot, especially on social media and Facebook groups and places like that. Oh, we got to fire the client. This whole discussion, right? But that’s complicated. If you want to fire the client, can you even do that? Do you have a contract that specifies what happens if you want to terminate the relationship?

    That’s where having a good document that protects you is critical, because you know at some point, oh, the client didn’t pay me, so I’m going to turn their website off. Well, guess what? If you just turn their website off for non payment, and they haven’t agreed to that stipulation, then you can get sued for that.

    Well you didn’t give me due process and whatever. And you can find yourself in a lot of trouble if you don’t have a good document that protects you. So my advice is always have a great contract that is weighted towards you as the service provider, and then you can choose to be gracious when you want.

    [00:30:44] Nathan Wrigley: So let’s get into that bit. You were mentioning about switching the website off. So it’s almost like the sanctions piece. What do you have in your arsenal as a web designer, which you can bring to bear should you need to apply a little bit of pressure to make sure that things are moving? So I’m describing a scenario now where things have clearly gone south.

    We’re definitely in the territory of miscommunication has been heaped upon miscommunication. We’re at the point of almost falling out. Communication is breaking down, and so we now need to bring out the big guns, if you like. What have we got? You mentioned turning off the website, that’s obviously one thing that we could do, given that that was in a contract.

    I’m thinking we could refuse to do any additional work. There’s obviously the refusal to communicate unless you go through lawyers at this point. What are the kind of things that you would put in your contracts that you would allow yourself to have as an option?

    [00:31:40] Nathan Ingram: So it would obviously depend on where we are in the process of the project. But if you’re in the middle of building the site, the client is texting you at 2:00 AM, or whatever. This is clearly not going to work, and we’ve tried to communicate and tried to request the client to change their behaviour, and they just simply won’t do it for whatever reason, and you need to pull the plug on the project. Then, you know at that point, at least my contract says, we as an agency get to evaluate the work that’s been done and say, okay, 78% has been completed and so you owe this much more.

    Or if we’ve already received full payment, we’ll refund that much or whatever. You need some process by which you can mitigate or decide who gets what at the end of this. So if you’re in the middle of the project, and you want to pull the plug, somebody has to figure that out.

    If it’s a client that’s maybe in a management phase and they’re just not paying their bill or they’re asking for too much or whatever, it’s always a conversation. What’s going on here? And is there something we don’t understand about this? But, at some point you have to have an agreement that if you don’t pay your bill within certain time, then we do suspend the website from view.

    [00:32:46] Nathan Wrigley: I guess there is also a point where you have to cease communication through anything other than the lawyers. Because at some point any stream of email going left, right, and center has to be mediated by a professional who’s removed from all of this.

    [00:33:03] Nathan Ingram: Yeah, you really do. And you know, we first tried to do arbitration, just to try to keep things out of court. That’s just a personal preference. But at some point you have to do that. Now, thankfully I’ve never even gotten close to anything like that, and I’ve heard horror stories of where it’s gotten to that point.

    You know, a lot of this is, as you work with clients and you have good client experiences and bad client experiences. You start to develop, like you said earlier, this spidey sense. This radar of early on, like before you even sign a proposal with a client, getting better at filtering out the bad clients at the beginning.

    Hopefully over time that becomes part of this, where you don’t have nearly the issues. Early on I had bad clients. They would take advantage of me. they didn’t want to pay. They wanted to pay a just a little bit, not really what the work was worth.

    They would constantly second guess and question my professional decisions. It was just terrible. I began to realize there are better clients out there and, not let those difficult clients in our world to begin with.

    [00:34:02] Nathan Wrigley: It’s interesting as this podcast has gone on, we’ve concentrated on the negative aspect of contracts, in the, you know, we’re protecting ourselves. This horrible thing could happen, so make sure you’ve got some protection. Oh, and this horrible thing could happen. But really, it’s the opposite, isn’t it? The contract is there to give you peace of mind. It’s to create a sort of positive scenario.

    And so hopefully you won’t find yourself in these positions. If the contract is robust enough, everybody signed it, read it, understood it, then those boundaries are in place so that these disasters don’t occur. So there’s a bit of silver lining on this cloud.

    [00:34:38] Nathan Ingram: Oh, it absolutely is. There’s this old story about this mother who’d warned her children about playing next to the road because they lived next to this busy highway. And oh, don’t get close to the road because, you know, you could get hit by a car or whatever. And so the kids would not go just a few feet from the house because they were terrified of this road.

    And then they realized, well, our kids aren’t even playing in our yard. So they put up a fence between the yard and the road. And the kids then could play within the boundaries of the fence and weren’t afraid of the road anymore. And that’s just a little example of put up a fence, a contract, and it really frees you to work better with clients.

    And in my experience, it’s if a client out of the gate, if the client pushes back against some of the things in our contract, it’s a huge red flag that we probably don’t want to work with this client, just right away. Because everything that is in our contract is there for a reason.

    I tell the clients that. It’s a rather long document, but everything is there for a purpose. And if you have questions about it, I’m happy to answer those, you know, happy to talk through why we do this. But it’s there for a reason and it really establishes the boundaries of our relationship.

    And the remarkable thing about all of this is, people look at a contract, well, I’m afraid to get my clients to sign this, it’s really long or whatever. The good clients have no problem signing contracts like this. They welcome it. It’s a mark of your professionalism that you’ve thought through your business well enough to have a well crafted document that governs this whole process of us working together.

    [00:36:03] Nathan Wrigley: You’ve obviously given this a great deal of thought in the past. You live in the United States and you mentioned Alabama. Obviously America’s a tapestry of different states with laws and, honestly I don’t understand that a little bit. But in the UK we have UK law and then there’s EU law, and then obviously there’s law in other jurisdictions.

    This, I suppose is something which we might mention right now, towards the end of our recording. You’ve got to have that in mind as well. It really does matter where you are and where the clients are because I guess you’ve got to think about the law. Should it go wrong, are you protected correctly given where the client is and where you are?

    [00:36:40] Nathan Ingram: Yeah, for sure. There’s a lot of local laws that govern things that you wouldn’t think about. And that’s why it’s critical to have a local attorney that understands technology and things like intellectual property and these sorts of things, to take a look at whatever document you have.

    One of the biggest challenges with MonsterContracts was, okay, I’ve got this document that I have a hundred percent faith in for my work here, and really even state to state. There are very few things that would have to change from state to state, using in the United States.

    But then we started getting some people buying the product internationally. And I began to wonder, wow, how is this going to work? I did have some experience. I had a coaching client, somebody that I was working with in business development who lived there in the UK. I provided her a copy of the contract and she had it vetted through a local attorney there.

    There were just very few changes. So, the way that at least my contract works is most of it, and I would just, pulling a number out of the air, say 80% of the document is just plain language about processes and things like that. And the legal language is at the end. So the attorney in the area, whether it’s internationally or locally in a different state or whatever, they could just substitute the little bits of standard legal language at the end and make it work wherever you are. And we now have people who’ve bought MonsterContracts all over the world and they’re having that experience where the attorney can review it with maybe one or two hours of time. It works great for their location.

    [00:38:05] Nathan Wrigley: So just give us the quick elevator pitch of MonsterContracts. It sounds like that it’s a service that you can essentially log in, pay your subs, and then you can extract from it contracts, which hopefully you can then use.

    [00:38:19] Nathan Ingram: That’s basically it. And so again, this is, it’s based on my contract that over 25 years of working with clients, I’ve gradually made better until it’s virtually bulletproof, I think, in my opinion. The MonsterContracts is simply a Word document. You log in, you purchase the document. You take this. You tweak anything that’s there to match your processes or the, you know, if you don’t do things in the same order that the contract specifies, change that around. Plain simple wording. And then the recommendation is always take that to your local attorney to allow them to, you know, run through it and make any changes.

    And universally the response has been, one or two hours of time and it’s done. So, for most people they’re going to have one of the two types. So if they’re using a contract, they have the type that’s just plain English and full of holes, or it’s just a bunch of legalese that no one understands.

    MonsterContracts it addresses the specific situations that we encounter as web professionals, and it provides the cover that you need to grow your business. It addresses all the things that we deal with in client work.

    [00:39:16] Nathan Wrigley: I think you’ve got a system whereby you can submit amendments that you’ve had made. So let’s say for example, in my case, the UK. I could make amendments and then submit them back to MonsterContracts so that other people can benefit from that as well.

    [00:39:32] Nathan Ingram: Yeah, exactly. So we have the ability to do that. That’s an area of MonsterContracts that I’m really working on growing this year. We haven’t had as many members do that as I had hoped originally. And so that’s one of our goals this year is to expand those revisions. MonsterContracts is a subscription, just to keep access because we do have the contract vetted by an attorney annually.

    And, there are usually at least a few changes to the contract every year to just keep up to date with things that are happening in client work. The subscription gives you access to those changes as well as any revisions that people upload. And if you upload a revision that’s accepted we credit you for that year’s cost.

    [00:40:06] Nathan Wrigley: So a scary subject hopefully somewhat tamed by having contracts. Nathan, thanks for chatting to us today and putting our minds at rest and giving us some advice. If the listeners to this would like to get in touch or figure out where you are or begin a chat with you, what are the best, some of the best places to find you online?

    [00:40:26] Nathan Ingram: Yeah, sure. So, monstercontracts.com is, the place to find the MonsterContracts product. There’s a great contact form there if you want to reach out to me about any contract related questions. My coaching website is nathaningram.com. That is available out there for coaching work or questions around that subject. And I’m online three days a week with iThemes training, at training.ithemes.com.

    [00:40:48] Nathan Wrigley: Nathan Ingram, thank you so much for chatting to us on the podcast today. I really appreciate it.

    [00:40:52] Nathan Ingram: Thanks, Nathan. I enjoyed it.

    On the podcast today, we have Nathan Ingram.

    Nathan is the host at iThemes Training where he teaches WordPress and business development topics via live webinar. Based in Birmingham, Alabama, he has been working with clients to build websites since 1995.

    He’s also the creator of MonsterContracts, which helps WordPress professionals create contracts for their client work.

    If you’ve worked directly with clients, then you’ll know that things don’t always go according to plan. Assets might not be delivered on time. The client does not respond to your emails. The expectations of the client begins to creep away from the original proposal.

    Whilst there’s unlikely to be a perfect system to ensure that all projects run according to the plan, you can protect yourself from some of the worst aspects, and for this, you may need a contract.

    Nathan is on the podcast today to talk about why he thinks contracts are an essential part of any client facing WordPress work.

    We begin by talking about how the contract is designed as a tool to bring clarity to both parties. You, the website builder, can set out the constraints within which you work, and the client can understand what they can, and cannot, expect from you. Nathan thinks that setting these expectations before the project begins leads to fewer problems later on.

    We talk about the fact that contracts don’t need to contain overly complex legal language, but they do need to be checked by a qualified legal professional before they’re deployed.

    Nathan also explains how he’s refined his contracts over the years, tweaking the wording and the structure, depending upon the project at hand.

    We then get into what you can realistically do should your client breach the contract. Are you able to turn off their website or withhold work that you’ve completed? Nathan’s not really in favour of sending in the lawyers as soon as something goes wrong, rather trying to resolve any conflict through better communication.

    It’s an interesting conversation which makes contracts seem less adversarial and more about ensuring that your WordPress website projects run as smoothly as possible.

    Useful links.

    iThemes Training

    MonsterContracts

    WordCamp Birmingham

    Nathan’s “Dealing with problem clients, building fences around friendly monsters” webinar.

    Nathan’s website

  • Limit Login Attempts Plugin Patches Severe Unauthenticated Stored XSS Vulnerability

    Wordfence has published a security advisory about a severe unauthenticated stored Cross-Site Scripting vulnerability in the Limit Login Attempts plugin, which is active on more than 600,000 WordPress sites.

    The security issue was discovered by Wordfence security researcher Marco Wotschka in January 2023. It was submitted to the WordPress Plugin Security Team, which acknowledged receipt of the report nearly two months later on March 24, 2023.

    “This can be leveraged by unauthenticated attackers to facilitate a site takeover by injecting malicious JavaScript into the database of an affected site that may execute when a site administrator accesses the logging page,” Wotschka said.

    Version 1.7.2 of the plugin patches the vulnerability. It was released on April 4 with a note in the changelog that simply says “Security fixes.” Version 1.7.1 and previous versions remain vulnerable.

    In August 2021, the plugin had more than 900,000 active users, and more than 2 million in 2018, but seems to be dying a slow death and is no longer maintained, as it hasn’t been updated in years.

    Wordfence has more details in the advisory on how the plugin might be exploited and advises users update immediately.

  • TeamWP Launches Team Experience Index To Measure Employee Engagement and Satisfaction in the WordPress Ecosystem

    In February 2023, James Giroux founded TeamWP, a project that aims to advocate for open, people-first workplaces in the WordPress ecosystem. His first initiative was to launch the Team Experience Index, a benchmark employee engagement survey designed specifically for people working in the world of WordPress.

    “The distributed nature of WordPress companies means they often lack the resources and knowledge to create truly open, people-first workplaces,” Giroux said. “The Team Experience Index fills this gap by providing insights and benchmarks that help companies identify strengths and areas for improvement, fostering a more open, collaborative, and innovative work culture.”

    The comprehensive survey will be aggregated and anonymized. It takes approximately 4-7 minutes to complete and includes questions about employee experience, company culture, leadership, management and teamwork, career progression opportunities, professional development, compensation and recognition, and employees’ individual experiences.

    While responses are recorded anonymously, it’s important to note that the company name is required, along with the employee’s role and the number of employees. Respondents should be aware that they are collectively giving away a lot of private information and should only share if they believe the insights will have a positive impact on the wider ecosystem.

    Giroux plans to share the initial results of the Team Experience Index at WordCamp Europe in Athens in June 2023. Anyone working at a WordPress product or service company, agency, or hosting company is invited to complete the survey.

  • WordPress Developers Are Experimenting With Gutenberg-Native AI Block and Content Assistants

    As more WordPress plugins for AI-generated content and images, chatbots, and assistants, are landing in the official directory, developers are beginning to explore even deeper integration with the block editor. Moving beyond the prototypical content generators that are cobbled together into a plugin, the tools developers are experimenting with today will provide a more deeply integrated experience that works seamlessly with the block editor as a natural extension of its capabilities.

    Last week Human Made CTO Joe Hoyle published an early preview of generative AI natively integrated into the block editor with a video demonstrating prompts working across various blocks.

    “Taking a native-first approach to integrating generative AI into WordPress, we’ve been experimenting with approaches to a ‘WordPress Copilot’ that can ‘speak’ Gutenberg / block-editor,” Hoyle said.

    “Copy-pasting paragraphs between ChatGPT and WordPress only goes so far, while having the tools directly embedded in the editor for block layout generation, auto-linking, formatting, translation summarization and more open up a world of possibilities and productivity wins for content creators.”

    Munir Kamal, WordPress developer and founder of Gutenberg Hub, has created a native AI writer with a similar UI to the tool Hoyle previewed, as they both were inspired by the Notion app. His preview video demonstrates far more capabilities than the earlier AI content generators for WordPress have implemented.

    Kamal has tapped into the GPT API to add more options to the AI writer, including the ability to rewrite, improve the generated text, fix grammar, simplify language, make it shorter, make it longer, and translate. He plans to release it as a commercial plugin in his Gutenberg Hub shop when it’s ready.

    “With the increasing advancements in AI technology, thanks to OpenAI for taking the leap, I believe it will become an even more integral part of blogging,” Kamal said when asked about AI and the future of blogging. “It can assist in generating ideas, improving grammar and structure, and even help with SEO optimization.

    Hoyle is equally optimistic on the future of AI integrated into WordPress tools. It will be exciting to see if his Gutenberg-native AI copilot can be extended to blocks inside the Site Editor, to offer a text prompt-guided design experience without having to click through the tools.

    “Going through this project has convinced me that LLMs [Large Language Model] have much more potential than I was giving them credit for,” Hoyle said. “It feels like there’s still a lot to discover what the models are capable of.

    “As the availability to GPT-4 (and with it larger token limits) increases, we see a clear path of improvement to what we’ve shown today. The data and information that is stored and available to the Content Management System is ideal for model-training and building a corpus of data specific to the user. Generating, improving and suggesting content of all types that is specific to the data set will be another lead forward in the utility of these tools. We see a future where AI will support and enhance the work we all do, and see the necessity to integrate the technology deeply into the tools and solutions we create.”

  • Gutenberg 15.5 Introduces Experimental Grid Layout Support

    Gutenberg 15.5 was released this week with more new features and refinements to WordPress’ full-site editing capabilities. The project will soon be moving on to Phase 3 with real-time collaboration on the roadmap, but there are still many improvements on the way for the Site Editor and core blocks.

    This release introduces experimental support for grid layouts in the Group block. Gutenberg contributors are testing a Grid layout type as a new variation for the Group block. They decided on this implementation instead of a new block in order to get more real-world use on the first iteration.

    After testing, I found the Grid layout type fits as a natural addition to other Group variations. This first iteration ships with one setting for configuring the minimum column width, but more options can be added in the future. I found it to be far easier to manipulate than the Columns block for basic grids. It may be easier for users to discover and understand if it were implemented as a new block, with the grouping implicit instead of having to add a Group block first and then select a layout.

    Grid layouts are a common feature of page builder plugins and this new capability is necessary to make Gutenberg’s page building capabilities more robust. With more testing, contributors can settle on an implementation and build it out from there. If you want to give it a try, the Grid variation for the Group block can be enabled under Gutenberg > Experiments.

    Gutenberg 5.5 also introduces the ability for theme authors to identify a custom pattern to be displayed when users load a specific template, such as a 404 page, author page, or single post, instead of relying on a fallback template or starting from a blank slate. This makes it possible to have custom patterns as template starters, a friendlier jumping off point for users who are editing their sites.

    The update brings the ability for users to style their Captions in the Styles interface. Captions’ color, typography, and size can now be easily edited with changes applied globally.

    image credit: Gutenberg 5.5 release post

    A few other important updates in this release include the following:

    • New Post Modified Date variation for the Post Date block lets users display the post’s most recent date updated
    • Sticky Position: New “Make sticky” action added to the Template Part block
    • Buttons: Disabled support for “edit as HTML” in block options
    •  Time to Read block adds spacing and typography support
    • Columns block adds support for template locking
    • “Image size” replaced with “Resolution” in image size controls

    Check out the changelog in the release post for a full list of all the bug fixes, enhancements, and performance, documentation, and code quality improvements.

  • WordPress Mobile Apps Get a New Support Forum

    Support for the WordPress mobile apps is moving to the WordPress.org forums. Previously, users were routed to WordPress.com, even those who were self-hosted, and Automattic employees handled support tickets related to the mobile apps.

    This move to WordPress.org is part of an effort to disentangle the official WordPress mobile apps from Automattic’s services. In July 2022, the Mobile Team announced it will be pulling all the Jetpack and WordPress.com features from the official WordPress mobile apps and moving them into the Jetpack app.

    Although the mobile apps previously had forums on an older bbPress installation, they were rarely used as those in need of helped were piped through the WordPress.com support queue. The new mobile support forum is listed on the Support page and is already active with requests regarding app crashes, XML-RPC errors, and issues with core blocks.

    Bringing mobile support to a public place has the advantage of allowing users to help each other, search through old threads, and look for answers in the same way they do for problems with themes or plugins. It standardizes the support experience so users know what to expect. The Meta trac ticket for the forum creation has been closed now that the initiative is complete and the forum is operational.

  • Preferred Languages Feature Plugin Needs Testing

    The Preferred Languages project is gaining some momentum with this week’s 2.0 release of the feature plugin. In 2017, WordPress Core Committer Pascal Birchler released a prototype that lets users select multiple preferred languages in their settings so that WordPress will load the first translation available, falling back to the next language in the list.

    More than half of all WordPress sites in the world use a language other than US English,” Birchler said in a previous update. “For these sites and users, the options to change the site and user language are great. But when there’s no translation for a given plugin or theme, WordPress falls back to US English. That’s a poor user experience for many non-English speakers.”

    Version 2.0 introduces some major changes with a full refactoring of the UI to use React. (Previously it was using jQuery and jQuery UI.) Birchler removed the drag and drop sorting functionality to improve accessibility but users should find that almost everything the plugin still looks the same as before.

    This update also brings compaibility with with WP_Textdomain_Registry and switch_to_user_locale() for users on WordPress 6.1+ and brings unit test coverage to nearly 100%.

    The Preferred Languages plugin has more than 2,000 active installs but Birchler is calling for people to test the update, as he believes the plugin is close to a core merge proposal.

    “One big remaining question mark is the concept of translation merging,” he said. “By default, if there are only some missing strings in a selected locale, these would be displayed in English. But with translation merging, the missing strings will be taken from the locale next in line instead. While this works great, it could be a tad slow due to the way translations are loaded in WordPress. Any help addressing this potential performance concern would be greatly appreciated.”

    Testers can contribute to the code on GitHub, leave feedback on the support forum, and open new issues to submit bug reports. Getting this project into core will make using WordPress and its plugin and theme ecosystems more accessible for non-English speakers.

  • ACF 6.1 Adds Support for Registering Custom Post Types and Taxonomies

    ACF (Advanced Custom Fields) version 6.1 was released this week with support for creating Custom Post Types and Taxonomies. This is a long-awaited feature that users have been asking for since the earliest days of the plugin when it was still developed by its original author, Elliot Condon.

    When Delicious Brains acquired the plugin, the ACF community reiterated this feature request. WP Engine kept it on the roadmap when they acquired ACF in June 2022 and has finally been able to deliver. Registering post types and taxonomies is now available through a simple interface that works in a similar way to creating field groups and fields.

    After registering the CPT, users can then add an existing or new field group for it or create a taxonomy, and move on from there. The advantage is that users don’t have to break their workflows and use a different plugin for this functionality. For those managing client websites, it is one fewer plugin required.

    “We know there are a large number of ACF users registering custom post types (CPTs) and creating custom fields for them,” WP Engine Senior Product Manager Iain Poulson said. “But they have to register the CPTs either manually with code or using another plugin. The overarching workflow of modeling the data needed for a site build is fragmented between different plugins, UIs, and user experiences. We wanted to fix that!”

    The ACF development team has also created a dedicated import tool for users who want to migrate post types and taxonomies from the Custom Post Type UI (CPTUI) plugin to ACF in order to manage them all from one plugin. ACF has also built in the ability to disable post types and taxonomies from the plugin admin in case users do not require this feature in the update.

    ACF reports more than 4.5 million users, so it will be interesting to see how having this built in will impact the CPTUI user base, which is active on more than a million websites. Some users simply need custom post types but won’t require all of ACF’s capabilities, but there is certainly a large overlap between the two plugins.

    After expanding well beyond the creation of custom fields with this and previous updates, Poulson said they will be referring to the plugin as “ACF” more going forward. The plugin’s admin sidebar menu has been updated from “Custom Fields” to ACF.

    Version 6.1 also includes the following highlights and important changes:

    • New ‘browse fields’ button opens a modal to search and showcase all field types
    • Post Object, Page Link and Relationship fields now support filtering by post status
    •  Full compatibility with PHP versions 8.1 and 8.2
    • New option to filter field settings tabs so other plugins can add custom tabs and arrange their fields
    • Security fix backported to ACF 5.12.5 for a security issue where ACF might unserialize maliciously manipulated data which instantiates a class

    All of these new features are available in both the free version and ACF Pro. Check out the changelog for the full rundown of everything included in version 6.1.

  • #70 – Steve Persch and Brian Perry on How Hosting Is Changing

    Transcription

    [00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

    Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, the past and future of website hosting.

    If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice. Or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

    If you have a topic that you’d like us to feature on the show, I’m keen to hear from you and hopefully get you all your idea on the podcast as soon as possible. Head over to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

    So on the podcast today, we have Steve Persch and Brian Perry. They’re both employed at Pantheon, an enterprise website operations platform. And they’re here to talk about the evolution of website hosting.

    Back when the internet started, hosting was a fairly straightforward enterprise. You created HTML files and uploaded them to a server. That was it. An HTML file was a page.

    Server-side technology such as PHP came along, and the picture became a little more complex. Web pages needed to be constructed on the fly. Databases were thrown into the mix, and the complexity increased. Add in the different languages that you could write your code in, and the server configurations. The CMS that you choose also plays into this mix. Now we’ve got CDNs, headless, React, Gatsby, Node.js and much more. Is it even possible for the non-technical to have any understanding of where their website is?

    Steve and Brian talk about how they got into the hosting space, and what’s changed over the years. We address what Pantheon is doing with WordPress and Drupal.

    We discuss how headless can be difficult for content teams, given that there’s a disconnect with hitting the publish button and that content going live on the site.

    What’s certain is that there’s no end in sight in terms of the rate of innovation in the website hosting space. What’s popular today might not be several years from now. And so it’s a timely discussion of what Steve and Brian see as the best bets for the future.

    If you’re interested in finding out more, you can find all of the links in the show notes by heading over to WPTavern.com forward slash podcast, where you’ll find all the other episodes as well.

    And so, without further delay I bring you Steve Persch and Brian Perry.

    I am joined on the podcast today by Steve Persch and Brian Perry. Hello.

    [00:03:37] Steve Persch: Hello, Steve Persh here. Happy to be here.

    [00:03:39] Brian Perry: Yeah, Brian Perry also really excited to chat.

    [00:03:42] Nathan Wrigley: Well, thank you for joining me on the podcast today. We’re going to talk about something, and I seem to have said this sentence much more often recently, about something that that really is a mystery to me. You are going to school me in all sorts of ways about something that I’m really not that familiar with, and that is all about how files get served up. Where are our website files being kept? Where are the computers? Where’s the infrastructure, and how much more complicated it has become over the last 10 or 15 years.

    Before we begin that, I think we’ll take you in order. I’ll go Steve first, if that’s all right? I’m wondering if both of you can give us a little bit of orientation about who you are, who you work for. Your history with technology and possibly WordPress in particular. So yeah, we’ll launch that with Steve.

    [00:04:28] Steve Persch: Sure, so Steve Persch here in Minneapolis, Minnesota. I’m the director of technical marketing at Pantheon. We’re a website operations platform for Drupal, WordPress and now front end frameworks, which is, much of what, thinking about that question of what computer makes the website.

    I’ve been in the web space for a while now. I first started making websites, first semi-professionally, and then professionally in the early days of WordPress. I built some of my first professional websites in WordPress 2, back in 2006. Then for some of the sites that I wanted to make, that took me into the Drupal world. And now in Pantheon, we play in both of those worlds, in the lamp stack, and as Pantheon is aiming itself at running extraordinary websites, as we like to say, the best possible websites. We see that that requires us to step more fully into the JavaScript centric front end framework ecosystem.

    [00:05:23] Nathan Wrigley: Well thank you Steve. That was great. We’ll hand it over to Brian to do a similar job.

    [00:05:28] Brian Perry: I’m Brian Perry. I’m a staff software engineer at Pantheon. What I’m focusing on at Pantheon is leading a project we’re calling Decoupled Kit, which is a set of open source utilities and projects that aim to make this decoupled architecture or running headless WordPress and Drupal sites easier.

    What brought me to that is, prior to Pantheon, a lot of my background was in the agency space. Specifically focusing on front end and front end develop. More and more I found myself interested in what was going on in the JavaScript ecosystem, and working on projects where using a CMS like WordPress or Drupal to feed data into the front end. But also found that there were a lot of solutions that were being invented over and over to solve those problems. So being able to focus on trying to make that easier for folks has been really exciting.

    [00:06:24] Nathan Wrigley: Thank you very much indeed. So you’re both coming from Pantheon and you mentioned there that you have a very keen focus on, well you mentioned two CMSs, which is curious actually. Obviously this is a WordPress podcast, but we’re not here to destroy the opposition if you like. But Drupal and WordPress, I think I’m right in saying that you don’t find too many hosting companies that lay claim to both of those. Is that a relic of the past of Pantheon, how it all began back in the day?

    [00:06:51] Steve Persch: It’s an intentional choice. We think that supporting both of those systems gives us more flexibility. It ends up fitting us better to our core audience. Pantheon started with digital agencies. Our four founders came from running web development agencies, that’s the background.

    And for a lot of the agencies and in the ecosystems we came from, we knew that it was normal for those sorts of agencies to have a preference between Drupal, WordPress or, you know, Ruby and Rails or any other of system. But often, the given client you’re working for might have both, for any number of historical reasons.

    So yes, the initiation of that was, uh, somewhat happenstance. Our customers figuring out like, this platform was first built for Drupal, I bet we could make it run WordPress. And then Pantheon as a company realizing like, yes, we should support WordPress. That’s something that I think was a bit inevitable.

    It’s good for us technologically and business wise to support more than one. And at the same time it’s good for us to not open it up as wide as, well, anything PHP. Some of our competitors take the other extreme of, hey, if you can make it run then you’re good. We think of ourselves as, we prefer the term, a website operations platform.

    And hosting is a feature of that. But don’t want to have a relationship with our customers that’s as simple as like, well, yeah, if you can make it run, that’s good. We’re only here to provide the server. We see ourselves as facilitating more growth of value of the websites, not just the question of can this run at all?

    [00:08:21] Brian Perry: Yeah, I think that, that same sort of concept also extends to the front end and JavaScript frameworks in that, there’s definitely a lot of excitement around Next.js. But we are looking to build a platform where other future frameworks can run on it. But also, yeah, we’re not necessarily trying to be like, run whatever crazy JavaScript project you want. We want to have some guardrails there.

    [00:08:44] Nathan Wrigley: I remember back in the day prior to stumbling across WordPress, which I did quite a long time ago now, I used to use Drupal exclusively actually, and I have a, have a memory of Pantheon cropping up, and at the time, really hadn’t heard of a hosting company that was binding itself to a CMS in that way.

    It was curious to me that Pantheon had laid claim to, okay, if you’re using a CMS, we’re somebody that you should look at. Prior to that, it was always, we’re just a hosting company. You know, we’ll host anything.

    [00:09:16] Steve Persch: I often go back to the first blog post that was done by, one of our co-founders, our four co-founders, when Pantheon started. I think the title of the blog post was Putting the Humans at the Top of the Stack. And it laid out, or at the time, but a decade plus ago, two common ways of running websites.

    One was just that hosting mode of a host providing some baseline technological capabilities, but the team buying the hosting is responsible for assembling the parts and making it all work. And yes, that’s an appropriate choice for some teams, but it’s not a great recipe for success for what we see as the broad plurality of professional web teams.

    The other extreme at the time, and it’s still present there, is the Squarespace, Wix, very templatized, cookie cutter way of building a site. Which again, is totally appropriate for certain people who need websites. But Pantheon, a decade ago and still now, wants to find a middle path that empowers the majority, or a plurality of professional web teams to make the best possible websites.

    And we see that, fulfilling that mission does require us to build CMS specific capabilities, and now front end framework specific capabilities, while not putting ourselves as narrow as only WordPress, or only Next.js.

    [00:10:35] Nathan Wrigley: Okay. That’s really interesting. Thank you for that. The subject at hand is really about how hosting has changed over the last decade, two decades, what have you. And it might be of interest to the listeners to the podcast if they pause for a moment and go and watch one of the videos. It was created by Steve, I believe, created the video.

    It’s called Decoupled Architectures, What Computer Assembles the website, and it’s a great watch. It’s. 10 minutes long, and it’ll give you a real insight into the things that we’re going to talk about. What Steve brings to bear is lots of papers and drawing, which we can’t do on this podcast, but they really do help solidify the problem. He’s got lots of nice diagrams of how things are working.

    But just to rewind the clock, let’s go back 20 years or so ago. It seems like an age almost at the birth of the internet almost. But if you had a website, whatever CMS it was. You would have to host it somewhere, and you would probably select a host and upload the files.

    They were probably at that point, just static HTML. I imagine CSS probably hadn’t even emerged at that point. And you just uploaded them. And you had a great idea of where that computer was. You had a slice, a share of that computer. It was yours. You could point to where it was on the map and so on and so forth.

    And that’s not how it’s done now. Or at least that’s not how everybody’s doing it. So I want us to run through a history of how that’s changed over time. Going right back from the beginnings when the internet began and you could build your own websites. Right up to how it’s done now. We can really be ponderous about this, we’ve got a whole episode ahead of us. So, whoever wants to begin that journey, you can flip flop and change, do tag team if you like, but that’s what I want to do. The history of how hosting has changed.

    [00:12:19] Steve Persch: Brian, if you don’t mind, I’ll start from flat HTML files, and enter us into the era of PHP. And then you can talk about CMSs. So one of my first experiences getting paid to maintain a website, a thing, I wasn’t even pondering as a career path. I was a theater major, and then I found myself working in the marketing department of a theater company. And they had a flat HTML website that did the job, was good enough for the early two thousands. A few hundred pages of flat HTML files, mostly it’s like if you want to buy tickets, call this phone number. Here’s the production that we’re producing, here’s the calendar.

    And one of the most annoying tasks, once I became the person getting paid to update the website was, add this menu link in the sidebar. And that sidebar appears on like a dozen pages. Okay, so I open up a dozen flat HTML files and then I notice, oh, this sub sidebar menu for the education department of the theater company. This menu isn’t even consistent on these 12 HTML files, because over however many years, copy paste errors happened. And that’s annoying, and creates a bad, confusing experience.

    But, I know enough to realize that I could put in some PHP tags, and save myself some time. That’s how I first started transitioning that question of, what computer assembles the website? How does this website really come together? The first answer of, it’s all flat HTML that I’ve got to hand code on my own machine to, what if I put a little bit more, just a little bit more intelligence in the server and told it to like PHP include education sub sidebar dot PHP.

    Then I don’t have to worry about copy pasting menu updates across 12 HTML files. That started to transition the question of what computer assembles the website, but the content management systems that were cropping up at the same time, WordPress, Drupal, others, provided a much more robust answer. But I can let Brian talk about that.

    [00:14:25] Nathan Wrigley: I’ll just interject at that point because the pain that you’ve just described was my pain. I remember exactly that. I mean, it wasn’t the 200 page website, but I remember the exact same thing. And then stumbling across the, oh, you can include something with PHP can you? That will take that whole burden, maybe the header or the footer or wherever it may be on the website.

    And I do remember finding that really quite startling, and thinking good grief. I’ve just saved myself literally hours of time, and it was fabulous. It was really, really an excellent moment. So, okay, so.

    [00:15:00] Brian Perry: It’s also a, it’s a gateway to the danger of creating your own CMS, I don’t know if anybody on this has done that?

    [00:15:07] Nathan Wrigley: Yes, that’s exactly what I did. We’ve laid the pathway then to, we’ve got PHP in there somehow now, and so now we’re moving towards CMSs. So I guess we’ll hand it to Brian to tell us what came next.

    [00:15:19] Brian Perry: Yeah, and Steve, feel free to jump in as the overall tour guide with any color commentary. But yeah so, many of us have rolled our own CMSs. But then projects like WordPress and Drupal come along and provide a consistent user experience to being able to manage your data. Have an associated front end.

    It’s the great situation where there’s a community of folks making that project better, rather than the CMS we built on our own. That is a situation where you have your CMS, that handles that data. But it is essentially a single lamp stack. And your CMS is responsible for assembling your website. So you can edit things in the admin. But at the end of the day, WordPress, for example, is what puts everything together, using its templates and providing the end page that the user interacts with.

    [00:16:15] Steve Persch: Another way I think about this progression is through the lens of the three really broad groups of people who make a website like this possible. Especially in those early PHP days, to make something like this work there’s someone probably with an IT sort of job title who’s setting up the server. There’s someone with like a web developer type of job title who’s making the Drupal or WordPress part work, and they may be working with designers as well. And then there are people managing the content.

    So in addition to what computer assembles the website, a more specific framing is where is the work of these three broad groups of people coming together? It’s coming together over and over and over and over again, to make a functioning website. And in the lamp stack era, it’s that PHP server, you know, be it shared hosting or a server in the closet. That is where the work of those three groups has to fit together.

    And for the decade or so that the lamp stack was dominant, there became pretty solidified best practices on how those three groups need to work together in order to do their jobs most effectively.

    [00:17:26] Nathan Wrigley: I feel that’s a really nice segregation of the different things that were going on. But also it makes the two bits that you are not involved with suddenly quite mysterious. If you’re the content editor, suddenly the IT bit, the hosting if you like, you’re no longer involved in that in any way. And, so that over time becomes a little bit more murky and what have you.

    But the advent of the CMS suddenly opened up a whole range of possibilities for people who really don’t have any technical, they don’t desire to be technical. They want to be consumed with the content. They want to log into something, type away, upload images, what have you, and press publish, and for it to be done.

    So I think that’s a really useful definition. Prior to that, you had to be fairly technical, at least technically enough to create the HTML and what have you, to then upload it to the server. And now we’ve got a kind of career path coming out of it, haven’t we? We’ve got the IT people, we’ve got the editor people, and various other different pieces of the puzzle.

    It feels like maybe that is where quite a few people will still be with WordPress. That is to say they’ve got a WordPress website, they’re paying a monthly fee to a hosting company. That hosting company is literally holding the files of the CMS, in our case, WordPress. Holding them on a particular box somewhere. The DNS is pointed correctly. It all works. That set up is still doable, but I guess the journey doesn’t end there. I suppose we’ve got quite a long way to go in this journey.

    [00:18:59] Steve Persch: Yeah, the journey does not end there. Actually it might, because it comes back around. There are other steps along the way. So, I see the next big event in this history as the release of the iPhone. Which for a while I wondered like, am I drawn to that as the key moment? Because that’s when I was coming into professional web development, around 2007. In the decade plus remove, I can see, no, that really was a big deal when we had to figure out how to make websites squish, and fit on different size devices. Phones, tablets, Android devices of every single size and resolution.

    That was a huge change. And it came about at the same time these native application ecosystems sprung up, and really, really raised the bar for how good of an experience you could have on these devices. So not only is this just a new form factor to make work at all. The quality bar jumps up very, very high. In retrospect, I can see like, oh, that set off a bit of a panic in the web development community. And different people reacted in different ways and, you look at the 2010s and think, oh yeah, people ran in a bunch of different directions trying to handle or deal with the existential question of, how does the web stay relevant when literally billions of dollars are pushing technology towards native applications.

    [00:20:33] Nathan Wrigley: I feel there’s some other pieces I might add into that as well, and that is, the invention of the iPhone, which then spawned so many other similar devices, some slightly larger, some competing operating systems. But the thing there was suddenly the internet went from something which was probably peripheral in your life.

    You would interact with it, maybe with email or something at work. You’d have to turn on a computer and sit in a chair. And the internet would be on that screen and then you’d walk away from it and you’ve forgotten about the internet. Suddenly you’re at a point where the internet is with you 24 7, should you wish. It’s there all the time. So it marks a moment where not only is it technically possible to do it, but it increases the importance in everybody’s lives. So, almost everything now, what are we now about 15 years later or something?

    Almost everything can have a web presence. You know, you were talking about buying tickets earlier. Well, what’s the best way to do that now? It’s the internet. How do you consume your radio? It’s the internet. Where does your entertainment come from? It’s the internet. There’s almost nothing, which the internet hasn’t touched, and I feel that that was the inflection point when it went in your back pocket and suddenly every company on earth had a window into everybody’s lives.

    [00:21:50] Brian Perry: It’s a blessing and a curse.

    [00:21:52] Nathan Wrigley: But also a convergence of the technology, you know. So cellular data was suddenly getting rolled out. Prior to that it was just mobile phones was as, as much as you could do. You could do voice chat and so on. But then mobile data came along and it all coincided at the same time. So I, yeah, Steve, I think that’s a really insight thing. The iPhone being this moment.

    [00:22:09] Steve Persch: So the iPhone, when it comes out, it suddenly becomes the most powerful computer in the whole stack. If you’re thinking about what can we make a website or a native application? What can I do with this device? A lot of people consciously or unconsciously realized if we push more responsibility to this last computer in the chain. From the developer’s computers. There are still servers involved.

    There are increasing number of computers in the cloud that are involved in getting the website to that iPhone. But the iPhone in many respects, the most powerful computer in the whole stack, and that leads to an architecture of, oh, let’s make that end device, be it a laptop, a high powered iPhone or a low powered budget Android phone. Let’s put all the responsibility there. Brian, I bet you could talk in greater detail about the upsides and the downsides of the single page application architecture that came about when a lot of the web development ecosystems said, oh, let’s put all the responsibility in the client, in the end device.

    [00:23:16] Brian Perry: Yeah, there’s definitely like a huge trade off to that in that the end result that we’re doing there, especially thinking about modern JavaScript frameworks, were essentially pushing more responsibility, more code, more JavaScript to that end device. So there’s more places where things could potentially go wrong.

    There’s more cases where rather than having just a HTML document that is passed from a device to device, it actually has responsible, responsibility for rendering the page and executing all of that code. And it’s even a situation where things as simple as being able to click the back button in your browser to go to the previous HTML document, that’s things that need to be handled within that client device.

    So it really does increase the complexity there. And then also related to what we’ve been talking about and thinking about, the three audiences that we talked about before. One thing that jumped out to me is that as we’re finding all of these, you know, the internet everywhere, and all of these, different devices that can be used for these different purposes. I think some of also what brings us to the headless architectures that we’re going to get to down the line, is in some ways, I think driven by the content editor. In that they still want to have one place where they can go and manage content that is going to show up in all of these different places.

    Whether it’s a client side page, a traditional website, things managed by PHP, and I think that also does start to lead us in the direction of how can we manage this content in one place and make that data available to all kinds of different consumers.

    [00:25:01] Nathan Wrigley: So we have the, we have the iPhone, and prior to that we have just regular servers. I guess we’ve now got to take a bit of a leap and stray into an area where maybe many of us really don’t know what we’re talking about, and I’ve very much include myself in this. What are the evolution of things that have happened subsequently since the iPhone?

    And what was the purpose of all of that? Were there things which were tried and failed? And I suppose we are slowly getting towards the present day, but if there’s been some interesting evolutions during that time which need to be mentioned to give context, please do.

    [00:25:35] Steve Persch: Absolutely, I think one dynamic that played out in the 2010s was the splintering of all these different disciplines. I said in that lamp stack era, there are these three broad groups, of IT and content editors and developers. And I was even lumping in designers with the developers there.

    There might be some designers who take offense to that, but you know, it’s a blurry line. I lump them together because at a very, a very zoom out level that that’s the group that’s responsible for controlling how the website looks. And the handoffs that happened between designer and developer have changed over the years.

    But in the 2010s, there’s just an incredible splintering of the amount of detailed knowledge necessary to make websites look good across all these different devices was so large it was just unreasonable to think that you can hire one human being to know how to even implement a good design across all of these devices.

    Who also knows how to, like, configure Advanced Custom Fields and WordPress. That’s not a terribly reasonable expectation, to think you can find one person who is excellent at both of those things. Some of those people do exist in the world, but for many team leaders putting together teams, they’re realizing, we’re going to be better off if we say like, Steve, you’re going to be the backend expert, and Brian, you’re going to be the front end expert. And, even though Brian has a whole lot of that backend expertise, for many teams, they just decided to make a hard divide in the people.

    And then subsequently, or the order was sometimes flipped, a hard divide in the technology. So for, you know, a lot of websites built in this era, there is a very hard divide between the content management system is over here, be it WordPress or Drupal or a natively headless system like Contentful or Sanity. That’s going to be managed by one group, and then this group of front end specialists will handle the front end presentation.

    That’s a hard cut to make. A question I’ve been asking for the last decade or so is, if we’re going to cut off WordPress’s head or Drupal’s head, where is the neck? That is an answer that is constantly moving. The next era, after single page applications, is static site generation. As people saw the, you know, that downside of single page applications, then it’s, oh, well what if we, what if we get some of the benefits of that old way of doing it where it was just flat files? Can we have flat files again, Brian.

    [00:28:06] Nathan Wrigley: Full circle.

    [00:28:07] Brian Perry: Exactly. That introduces a whole new set of challenges and trade offs. You know, it certainly does, things being completely static does provide a build asset that is immutable, and it’s easy to roll back. It’s something that can be cached on a CDN. But also it really changes, kind of going back to again, the editing experience. It really drastically changes that experience where someone who was used to editing a page in WordPress and clicking publish and then being able to see the page.

    Now you have a workflow where you make a change in your CMS or whatever the source of the data is, and then a build has to run to be able to have the end website updated. And how do you preview what that looks like before the build runs? Do you need a separate environment? That trade off definitely brings a lot of additional complexity potentially to the content editing experience now.

    [00:29:07] Nathan Wrigley: Yeah, I think it’s potentially very frustrating as well because although the technological benefits and probably things like SEO and all of those things. There probably are great benefits there. If you’re the content editor, there’s probably only annoyance that when you click publish nothing happens.

    We’ve got to wait for some, like you say, some build process to carry on. You’re adding in a great deal of incredible technological innovation, which speed things up and pushes things to different parts of the world, and I’m sure it’s something we can get into. But also from the content editing point of view, we’ve had this evolution toward being able to edit everything right away, and click publish and seeing it, to then suddenly yanking that carpet out from underneath them, which is yeah, kind of frustrating I guess.

    [00:29:55] Steve Persch: I called this the cliff of complexity. If you search on YouTube for that phrase, you can probably find a presentation that I did at Gatsby Conf. So Gatsby, as a front end framework, really became popular as that static site generator pattern was on the ascendance, because there are so many technological benefits to be had, but when you add in a handful of possibly extra requirements. Requirements like, well, the content editors really like to be able to press publish and see it immediately. That shoots you up this cliff where making that work in an architecture that is fundamentally static, is really cutting against the grain.

    Like it can be made to work, but is massively complex. And we think for a lot of teams like that complexity is just now worth it. The fundamental mode that WordPress has done for 20 years of like, you press publish and then you see it immediately. That is something that should not be compromised on for most teams.

    [00:30:56] Nathan Wrigley: We’re used to a trajectory where technology just gets better in every respect. So, not only does it get quicker, but the, you know, the UI is easier to use and there’s a complete expectation that if I could publish it yesterday, and click publish and it was published right away and I could examine and look for errors that I’d made.

    Well, we’re a year on from that. Why have you taken that capability away from me? We’re going backwards? Well, we’re kind of going sideways. We’re not going back because we’re just changing things. I think that would be a bitter pill to swallow. Hard to understand if you’re not technical.

    [00:31:30] Steve Persch: Yeah, absolutely. And I think that’s, that backwards moving or that sideways moving does happen in other places. That’s not something I think that’s unique to web development. I remember the first time I got a car that relied heavily on a touchscreen. I was like, no, I want a knob to turn up the volume on the radio. This is so much worse. But somebody thought, no touchscreens, that’s the future. No. A lot of cars are now backswinging. There’s some parts that we do need physical buttons and dials for. That is better.

    [00:32:01] Brian Perry: I was going to say, it’s funny that you bring up the car example because, my car actually has both, which is somewhat infuriating. There is a touchscreen that could do everything. And then on the console, all the knobs and buttons, they can do the exact same things. I feel like the JavaScript frameworks in trying to address the shift aggressively in the direction of static sites has had a period of time where it was the equivalent of my car that had both.

    So things started shifting back over to server side rendering. But a lot of the frameworks had, and still have, concepts of both at one time. So there are ways that you can say, I want to either build things statically by default, and after some period of time they’re invalidated and re rendered on the server. Or say that it’s this subset of pages that are pre-rendered statically. Maybe it’s my homepage, and my 100 most popular pages.

    And then other things are handled server side. That also does increase the complexity now. You have to know what things are static, what things are not. It’s kind of two different approaches. But yeah, it does feel a lot like my car that has essentially two completely redundant ways to interface with it.

    [00:33:19] Nathan Wrigley: I’m waiting for somebody to invent the car which has levers in it. So that you’ve got screens, dials, and levers. Then we’ll, we’ll truly have the car from across the entire century. So is that where we’re at now then? If we chart our history we spoke about HTML files, and then PHP coming along and then flattening things. Is that this history lesson ends, or is there more to say?

    [00:33:42] Steve Persch: The way I think about it, a phrase I often like to repeat to myself that came from a customer of ours, is that Pantheon needs to aim for state of the art, not bleeding edge. We see the state of the art for many web teams right now is one where you use a totally stable content management system like WordPress or Dupal for the content management systems.

    And because so many front end developers simply expect to be working in JavaScript centric tools for teams in that, in that pool. Yes, you should have the front end then controlled through JavaScript centric tools. But do so with server side rendering because the content editors expect to press publish and then immediately see the change. And that works well with server side rendering.

    So that’s, that’s a mode that we support in our front end sites product, the front end sites product does also support that static mode. Which is beneficial for a subset of teams out there. Like Pantheon’s own documentation site has been a totally static site for nearly a decade. I think as long as we’ve had a standalone docs site, it’s been static. And that works for that team where everything is all just in a Git repo. An edit to code can happen at the same time as an edit to the content markdown files. That works for that mode.

    But we see that, you know, the state of the art for some web teams, as that mix of a contact management system, and a server side rendered Node.js framework. I should also say, because we’re on a WordPress centric podcast here, if you are totally comfortable with WordPress, as is, you don’t need to jump on a new React framework or a new JavaScript framework, just because there are a lot of people on Twitter saying it’s great. If you can do your job without taking on the extra complexity, stick with what works.

    [00:35:28] Nathan Wrigley: Yeah, it’s a really good point. You mentioned there, now, I can’t remember the exact phrasing that you used, but you made a differentiation between bleeding edge and something else. Is that an approach that you take? Do you keep a watchful eye on what is happening at the extremes of technology.

    [00:35:44] Steve Persch: Oh absolutely, yes.

    [00:35:46] Nathan Wrigley: PhD thesis which are describing what the future might look like. But holding back just a little bit until it’s embedded and we figured out what all of this stuff is. That’s the approach?

    [00:35:56] Steve Persch: Absolutely. So it is not a coincidence that Pantheon as a company started a decade after Drupal came into being. It was starting as a Drupal centric company, and then adding WordPress a few years later. That’s not a coincidence. There needed to be a decade or so of figuring out, how do we make websites like this before Pantheon or any company like Pantheon could do what we did. Which is put guardrails around what our founders considered to be a best practice mode of developing and maintaining and improving a lamp stack site.

    Trying to impose those guardrails the same year that a system like WordPress or Drupal comes out, that wouldn’t make sense. Similarly, we didn’t really enter this front end framework ecosystem until about a decade in. I think almost exactly a decade after React, was released publicly is when we entered this space fully.

    We’ve been keeping an eye on it for a very long time. I’ve been at Pantheon for seven years and that was one of my very first questions, my first week, like, when are we going to get into the Node.js space? And the answer then was not yet. And then for a while, it was soon. And then the answer was like, okay, now.

    And now we can see, okay, the edge and one of the reasons I like to use that term bleeding edge is because that’s also the term for where the bleeding edge is now. The edge, as a synonym for the content delivery network. So companies like Cloudflare or Fastly that cache your website all over the world, have been adding more and more advanced capabilities beyond the simple caching that makes the website faster. That is very clearly where the bleeding edge or the cutting edge is now. We have a CDN baked in. We have ways of exploring that. However, put it all on the edge is not an acceptable answer yet for the broad plurality of professional web teams.

    [00:37:50] Nathan Wrigley: Why is that? What’s the thing which makes that untenable?

    [00:37:53] Steve Persch: The very short answer is because your database is still in one place. Even though the cloud abstracts so much like. There is a MySQL database or an abstraction thereof that lives physically in one place. Because we run on Google Cloud, that place for most sites on Pantheon is in Council Bluffs, Iowa.

    For a WordPress site that you know, may be making in some cases hundreds of MySQL queries to generate an HTML page, hopefully fewer than, than a few hundred, but in many cases, hundreds of queries. It’s best if the PHP process that’s making those queries is right next to, physically right next to that database.

    There are new companies popping up spreading your database all over the world at the edge. Okay, that sounds cool, but before, before we take some of the biggest websites in the world and say, oh yeah, your database will be everywhere. We need to see how that plays out with those who, who want to jump on the edge earlier. Because for the sites we serve and cater to they need to be planning in very long terms.

    We’re highly adopted in the edu space, and I, I’ve put together timelines on yardsticks to represent like the multi hundred year history of these universities that we’re working with. And asking like, on a multi a hundred year scale or a scale of decades, it doesn’t matter that much if you switch to the new thing, whatever the new thing is, this semester or next semester, or this year or next year? Let’s wait till we know that that next thing is solid before we jump on it.

    [00:39:23] Brian Perry: As the JavaScript guy, I got to say I want it now. But, aside from that, one thing that’s interesting from the front end perspective as well, thinking about running things on the edge. One of the challenges there is that right now, all of the different solutions for edge functions tend to use different variations of JavaScript runtime. So there’s really no consistency there. And I think that’s another thing that’s going to have to change before that gets real wide adoption, when there can be one consistent JavaScript runtime that is typically used for that solution.

    [00:39:54] Nathan Wrigley: You mentioned Steve, but Brian maybe can answer this as well, I don’t know. You mentioned that there are people who are endeavoring to break up the database and put it in all sorts of different parts of the world and what have you. So that’s one innovation which people are trying to achieve. I’m just curious about what the next 10 years will look like. What kind of fun, interesting projects have you guys been keeping your eye on, which the listeners may be interested in? Just to give some insight into what hosting a WordPress website might look like Well, in 2025, 2026, whatever it may be.

    [00:40:29] Brian Perry: My kind of, it’s partially my hope, but also where I’d like to think that things are going. With all of the constant changes in the JavaScript framework landscape, I think that more and more of the things that people like about that sort of developer experience is going to find its way just more generally into the platform and into browser standards.

    Again, like looking back in the rear view, jQuery is a good example of that, in that jQuery brought so many wonderful niceties for how you can interact with the DOM. And then over time, most of the things that jQuery can do are just in JavaScript now. So they’re part of the platform.

    So my hope is that the things that people like about React and Vue and et cetera, start to find their way into the general platform. Web components are one potential technology that might help there. A component based approach that can be used regardless of the framework.

    My hope is that in the next 10 years, a lot of the things that people turn to React or Vue or different frameworks for, are just a part of the platform, rather than having to find your cool JavaScript framework that was released three months ago,

    [00:41:47] Nathan Wrigley: Yeah. Nice. Thank you, Brian. Steve, anything to add to that?

    [00:41:51] Steve Persch: I’ll give a quick tech answer, then a longer, uh, philosophical sort of answer. So the quick tech answer is web assembly. I’ll be quick because I can’t speak to many of the details of web assembly, maybe Brian can? I see it as a layer that can abstract away many of the differences between the different computer languages that we’re all writing in. PHP, JavaScript, TypeScript, Rust. If web assembly is a common target that can be used to leverage software. You write in these different modes. Run it in the same place, be it at the edge, or I saw a demo recently that I think involved web assembly getting WordPress to fully run in your browser, like the WordPress running in web assembly in your browser. Okay, that, that looks cool.

    The thing I’m, I’m probably most excited about right now for where the overall web zeitgeist is going is, is that the web development ecosystem seems to be coming back to what WordPress has been saying for a long time, of decisions, not options as that philosophical pillar for the WordPress community.

    I find it very reassuring that these front end framework projects that for a decade or so, provided so many options and put so many decisions on the plate of individual web teams and said like, you figure out whether or not you want Redux or this other thing to pair with your React project, and good luck sorting out the hundreds or thousands of NPM dependencies that get installed.

    The frameworks that seem to be, that just are ascendant, right now, are the ones that are consolidating a lot of those options. Turning them into decisions that are made at the framework level, be it Next.js or Astro or Remix. The leaders of those projects seem to understand that there’s a desire in the community for, for those framework maintainers as experts to make a good quality decision that works for the broad majority of users of those frameworks. Be it Next or Astro or anything else. The users of Next.js are comfortable with an increasing number of decisions being first made in a centralized framework. WordPress has been doing that again for 20 years. Again, it’s fashionable.

    [00:44:11] Nathan Wrigley: Yeah, history I think in many respects is fairly cyclical. What goes around does seem to come around. Yeah, good observation. I’m curious at this point, we’ve reached the 50 minute mark, and I want to wrap it up. I know you’ve got things to do with your day. But is there anything that you had wished that we had talked about that we failed to?

    [00:44:31] Steve Persch: Brian, do you want to touch on Decoupled Kit?

    [00:44:34] Brian Perry: Yeah, I’d love to talk about that a little bit. The Decoupled Kit project is essentially what we’re thinking of as a kit, is essentially a backend starter project and a front end starter kit that are intended to work together as close to out of the box with as little configuration as possible. To try to simplify the process of setting up the headless or decoupled architecture sites.

    And also provide some common examples of types of integrations and common problems that need to be solved there. And the thing that I think is most interesting about some of what we’re doing there. Again, thinking about this being an open source project sponsored by Pantheon, is we’re trying to solve some of these problems in cases where it makes sense in a framework agnostic way.

    So, obviously starter projects for both Drupal and WordPress. And then within that we have a starter kit, we have multiple starter kits that are based on React. So we have a starter kit for Gatsby and WordPress, and a starter kit for Next.js and WordPress. So we’re trying to find cases where there are things that we can abstract out, which are just essentially like general utilities for sourcing data from WordPress. And not things that are really strictly tied to any one framework.

    So that if there is, you know, another framework in the future that we need to support, or gains popularity, it’s easy to make adjustments there and adapt to that. And I think in the headless CMS community, both in the Drupal world and the WordPress world. I think there’s a lot of opportunity for tools that are a little bit more framework agnostic, that can still serve popular projects like Next.js. But hopefully are things that the community can use as the JavaScript world evolves.

    I’ll just also throw out there that, would love to, as we continue to build things, any feedback on the project. The main repo is decoupled dash kit dash js, under the Pantheon Systems GitHub. Would love to hear what people run into, any features that they’d love to see us support in the future. Any feedback is welcome.

    [00:46:45] Nathan Wrigley: I will make sure to link to all of the bits and pieces that we’ve talked about in the show notes. So if you are listening to this and you want to follow up on what the guys have been mentioning, then head over to wptavern.com, search for the episode, and all of the links will be in the show notes. Just before I let you go and get on with your busy days. If somebody wants to reach out to you personally and connect, what are the best ways, what are the methods that you are willing to share publicly? Let’s go with Brian first.

    [00:47:16] Brian Perry: Sure. Yeah, I’m in a number of CMS and Pantheon community Slacks, usually as Brian Perry. That, that’s one decent way to get at me. And then also I am still on Twitter. That is my main connection to the web development social media world, currently. Bri Comedy, b r i comedy on Twitter.

    [00:47:38] Nathan Wrigley: Brian, thank you very much. And Steve.

    [00:47:40] Steve Persch: I am spending less time on Twitter these days, although I’m still there as at stevector. And LinkedIn is the social network that I’m opening most often these days, and I’m easy to find just by searching for Steve Persch.

    [00:47:55] Nathan Wrigley: Thank you very much. Brian Perry and Steve Persch really appreciate you coming onto the podcast today. Thank you very much indeed.

    [00:48:02] Steve Persch: Thank you, Nathan.

    [00:48:03] Brian Perry: Thank you.

    On the podcast today we have Steve Persch and Brian Perry. They’re both employed at Pantheon, an enterprise website operations platform, and they’re here to talk about the evolution of website hosting.

    Back when the internet started, hosting was a fairly straightforward enterprise. You created HTML files and uploaded them to a server. That was it. An HTML file was a page.

    Server-side technologies such as PHP came along and the picture became a little more complex. Web pages needed to be constructed on-the-fly. Databases were thrown into the mix and the complexity increased.

    Add in the different languages that you could write your code in, and the server configurations. The CMS that you choose also plays into this mix.

    Now we’ve got CDNs, headless, React, Gatsby, Node.js and much more. Is it even possible for the non-technical to have any understanding of where their website is?

    Steve and Brian talk about how they got into the hosting space and what’s changed over the years. We address what Pantheon is doing with WordPress and Drupal.

    We discuss how headless can be difficult for content teams, given that there’s a disconnect with hitting the publish button, and that content going live on the site.

    What’s certain is that there’s no end in sight in terms of the rate of innovation in the website hosting space. What’s popular today might not be several years from now, and so it’s a timely discussion of what Steve and Brain see as the best bets for the future.

    Useful links.

    Brian’s blog post about Decoupled Kit

    Steve’s video “Decoupled Architectures: What Computer Assembles the website”

    Contentful

    Sanity

    GatsbyConf

    Pantheon’s documentation site

    Cloudflare

    Fastly

    WebAssembly

    Next.js

    Astro

    Gatsby

    Brian’s Twitter

    Steve’s Twitter

  • iThemes Rebrands to SolidWP

    iThemes, one of the oldest brands in WordPress that originally launched around theme products nearly 15 years ago, is rebranding to SolidWP. Over the years, the company’s products became increasingly centered on plugins, yet the old brand had so much name recognition that its leadership was not quick to change it.

    “iThemes is known today for security, backups, and site maintenance – none of which are well-represented in the name ‘iThemes,’” StellarWP Senior Director of Ops and Marketing Matt Cromwell said. “Additionally, the brand evokes the early 2000’s Apple era of technology, and we want to look toward the future.”

    This week the company kicked off a “rebrand in public” approach to updating its identity to be more aligned with promoting iThemes’ key offerings – its security, backup, syncing, and educational products. They will all be rebranded to the following:

    • Solid Security
    • Solid Backups
    • Solid Central
    • Solid Academy

    “This shift in branding signifies our renewed focus on providing a solid foundation for every WordPress website,” Cromwell said. “Our whole team, as well as our products, will pivot to focus on security, backups, site maintenance, and training as we enhance and improve our solutions for all of our users.”

    The rebranding is a massive undertaking, as the company’s products have millions of users and years worth of articles, webinars, eBooks, and tutorials. SolidWP will present reworked pricing and retire some legacy products in the process.

    “Currently on ithemes.com you’ll find a lot of products that are either part of a bundle, or sold on other websites in a variety of ways,” Cromwell said in the FAQ section of the announcement. “Some products will continue to thrive on their own, and others will be retired. We plan on reviewing publicly the complete inventory of our current products and bundles and working with the community to shape what the future plan is for each.”

    The company is not planning to increase prices on its products at this time but Cromwell said they reserve the right to adjust pricing as needed. iThemes will also be consulting its community regarding products that are slated to be retired.

    “We will continue to support any and all who land in our support queue with our best efforts and service,” Cromwell said. “The official end-of-life for the products being sunset will be discussed with the community and decided on before the full launch of our new brand.”