Welcome to Press This, the WordPress community podcast from WMR. Here host David Vogelpohl sits down with guests from around the community to talk about the biggest issues facing WordPress developers. The following is a transcription of the original recording.
David Vogelpohl: Hello everyone and welcome to Press This the WordPress community podcasts on WMR. This is your host, David Vogelpohl, I support the WordPress community through my role at WP Engine, and I love to bring the best of the community to you hear every week on press this as a reminder, you can find me on Twitter @wpdavidv, or you can subscribe to press this on iTunes, iHeartRadio, Spotify, or download the latest episodes at wmr.fm. This week’s episode, we’re gonna be talking about is why talking to your host before a large WordPress build might be the right idea and joining us for that conversation is Mr. Aaron Onken. Aaron, welcome to Press This.
Aaron Onken: Thanks, David. Happy to be here.
DV: Awesome. So glad to have you here and for those listening. you might be wondering like well why might I need to talk to my WordPress hosts before I build out a site. And really what Aaron’s going to be covering today is, is really considerations around maybe the way your hosting environments work and what those environment variables are, but also some pointers around how to approach it from a scalability perspective and I think there’s some really interesting insights and has to share around that. Aaron, I’ll kick us off with our first question that I asked the same as every guest. But I was wondering if you could tell me about briefly tell me about your WordPress origin story.
AO: Yeah, happy to. So I came to WordPress, by way of flywheel. Actually, I started out africology that insurance job, oddly enough, a lot of people are kind of surprised to find that out. And after a few years of doing that. I was getting a little burned out was looking for like an entire career change. So, I enrolled in a coding boot camp I was actually trained as a Rails developer, and after doing that. I got back in touch with some of my old friends from some other projects that I’ve been working on around the Omaha area. And they were working on their startup at the time. So I did my career change that way. Shortly after starting a flywheel I, in order to sort of get my feet wet with WordPress I had a passing familiarity with it. I picked up a couple of freelance clients and built a couple of WordPress sites for a couple of clients. So I know a lot of people learn WordPress by like taking courses, instead of like paying someone to teach the WordPress, I had someone pay me to learn WordPress, which adds an odd spin to it. You learn a lot of things pretty quickly. That way I don’t necessarily recommend it forever. But that’s how I sort of got my start with WordPress
DV: trial by fire I like it. I’ll need Trevino the golfer has a line where somebody asked him like. Were you nervous making that putt to win the tournament win a million dollars he’s like no, I was much more nervous when I was betting $1,000 that I didn’t have to. Yeah, that was a real forcing function for you there.
AO: Yes, I realized that I probably added a bit more pressure to the scenario that I needed to, but it worked for me because since I was working at flywheel at the time and doing like freelance work on the side. I had, you know, a lot of people that deep WordPress college like fall back on it I have questions about anything.
DV: All right. Good deal. Now, I guess for those that followed along they might have realized that WP Engine, purchase funnel I guess it was like two years ago or a year and a half ago now or whatever. And so now you’re kind of within the WP engine or in, you’ve been in a kind of unique position I think for this topic of like, what should I be considering when I do my bill, relative to things like environment variables, but could you tell people, like why you’ve seen this so many times like what do you do in your day job.
AO: Yeah, so I’m a solutions engineer for WP Engine. I was a solutions engineer at flywheel when it was acquired. And I noticed when I was sort of folded into the greater solutions engineering team and WP Engine. There are a great deal of similarities between our two programs, not the least of which being. Many of us had a very similar trajectory to become a solutions engineer. We often started out in support. I started out doing support. I had time to do work within sort of our fledgling onboarding program which became a more robust program later on. And also had roles sort of similar to a Technical Support Manager in many like many WordPress organizations where you started the primary point of contact from a technical perspective for some bigger accounts.
DV: So you’ve got like the support side, then you’ve got currently the solutions engineering side and really that’s around like helping people figure out what like the best infrastructure answer is for them I guess to kind of put it in terms the rest of the audience might be familiar with. So, in that I guess you’ve probably experienced both people that are like planning for the future. And then people that didn’t plan for the future and are like reacting right now is that a good way to classify
AO: 100%, okay. During during various points in the lifecycle of a site. Both like before it’s built during its build, as it’s going live. And then, as it’s being supported, like long term.
DV: All right, good deal well. We appreciate all the, the, I guess trials you went through on behalf of others. Up to now, but we’re gonna leverage that experience and we want to get some insights for listeners here. So thinking about it then like through like tactics and like kind of what what you’re really trying to plan for but I was wondering if you could tell me what kinds of things can go wrong. If you don’t fully consider your environments in their variables. When building a site like, what, what, what are the pain points people feel when they don’t do this.
AO: It’s a good question because the most obvious is your site’s go down during a critical time like that’s the thing most people are most aware of and you’re trying to avoid and that’s definitely a possibility. But there are other things as well. Some things I’ve seen, are people don’t fully understand the environment, maybe they’re migrating to, or how certain workflows work, long term, so they’ll encounter a pain point that they did not anticipate and it makes the project like maybe even not feasible down the road. For example, sometimes this comes up with movies where people, maybe have a basic understanding of multisite and how it works and how it works with given the environment you’re building on and launching on supporting your site on, but sometimes there’s an oversight I’ve seen this happen a few times lately where people don’t fully understand how, especially when domain mapping comes into play. How SSL certificates have to be regenerated every time a new domain is added to the number of domains you’re supporting on the site. And that is a big factor when it comes to supporting your site, long term. I’ve also seen this happen with LMS sites, pretty frequently, where. Oftentimes people are building, like a learning management system in WordPress, with a goal of attracting like a certain number of students to pay for a course. And they have in their mind well what they’ll do is on a regular basis, they’ll release a new course send out an email blast. A lot of people will visit the site to consume the course. But what they don’t take into account is that they’re oftentimes driving a lot of traffic to their site, all at once, and they’re on a relatively small plan, and the plan that they’ve selected for that site isn’t rated to support that amount of concurrent on cashable traffic. So that’s another consideration I’ve seen people not take it. Also with LMS sites. People are often surprised to find out how much it costs to support an LMS site. So I’ve seen people get all the way down the. They’re sort of workflow, about to release a new site they’re ready to take it live and perhaps even the next day, when they realize that the amount they’re going to have to spend for hosting their LMS site invalidates their business model because they’re not charging enough of their students.
DV: It’s really interesting that you point out those LMS sites or, you know, core sites I’ve seen that, you know, kind of in that same vein, I guess they can’t seem kind of just but this notion of like, you know, promoting your course via these mass email lists, and then all of a sudden like all your traffic for the month comes out almost in one day. I’ve seen that and I’ve seen that planning around that is also interesting to hear you talk about the workflows and you know not feasible I’m going to use this tech or integrate with this thing, and something about that and your environment doesn’t allow that at all which can be a blocker that you might not even discover it so you get into it. And then I guess you kind of pointed out also you know sites can go down presumably from, you know too much resource utilization or potentially failures within the tech stack of the build. And I think those are some great war story example as it helps people understand like why this is important. I want to kind of get into the strategy part though where we start to engage with our hosts and understand like, what kind of questions to ask and how to work on that strategy, but we’re gonna take a quick break and we’ll be right back.
DV: Welcome back to Press This the WordPress community podcast on WMR. This is your host David Vogelpohl. I’m interviewing Aaron Onken about why you should be talking to your host before a big WordPress build right before the break Aaron you were explaining a little bit about, you know, some of the things that could go wrong if people don’t take into account their environment variables. Everything from resource planning to like, I love how you also pointed out how like how you drive traffic to your site, not only influences your resource planning but also your cost structure which could affect your business model. I think those are really good points to make wondering that like, what is the worst example and please don’t use a name of a company or like the worst example or something, how to totally rebuild their site because if something they didn’t plan for relative to their environment.
AO: Yeah, it actually came up fairly, fairly recently where I think it’s maybe not the worst but it’s the worst one in recent memory for me. And it was a site where they built it to make. There was a lot of dynamic content on all pages. And that made it so that you know that the caching layer that we had applied to it was of minimal utility, because, like, a lot of the content could be served up via the cache, but every page load had at least a little bit of cached content on it, which meant that a lot of the numbers that you we saw, we have around our visit accounts for a lot of our plans are available kind of went out the window. Because every cache page load had a certain amount of uncashed content that came with it as well. And that meant that right before taking the site live, this is like days before they were faced with the reality that the plan that we would have to put the site on in order for it to be successful, was way out of budget, and they only had like three days to basically rebuild a site from scratch because it was core functionality that we pointed out problems. And that was a scenario that I I don’t want anyone to be in because the developer especially was in a pretty tight spot.
DV: You know I feel like this particular observation with this company it’s, it’s like it is specific to your hosts in your environment, right, you’re kind of pointing out like. If the content is not cashable, then that’s basically taxing the server’s resources more perhaps than it should. And because of that, you can of course throw hardware at anything but your point was, because it wasn’t as cacheable. They therefore needed more kind of infrastructure requirements for their hosting environment, more so than they should. But I feel like this is like a general tip though because like having cacheable content also makes your site fast, just even independent of the financial implications of needing more infrastructure, I mean, would you agree right like yeah caching is generally preferred if you can versus dynamic content on almost every page, it is your best
AO: like yeah caching is generally preferred if you can versus dynamic content on almost every page, it is your best friend and okay across almost all categories.
DV: So, even without even with an unlimited budget for infrastructure, it’s still a good thing to try to make as much of your content cashable as possible. Yes, okay, but you’re saying like if people don’t plan for that. Then the intercourse people don’t have an unlimited budget for hosting and infrastructure, then it can start to have a negative impact on the cost of that and this cause you issues in your business strategy relative to your site.
AO: Yes, the scenarios that I see most frequently occur between the end client. The agency who built the site, and then the hosting provider in this case like us, where we’re trying to find common ground when it comes to like budget, and performance and also hardware. Those all have to work together. But if you ignore one component of it. Then the other two are very tough to make sure that you can reconcile as well.
DV: about like functionality of its site you know I know you know one of the favorite go twos of people trying to save server resources is things like offloading, so like through that lens of like more functionality versus like dynamic and static content, and those two are connected but just for a minute thinking about more of like the functionality of the site. Do you have a good, a good worst example of, again the names of someone that had to rebuild because of the functionality of the site, and I’m sorry, because of the scale of traffic The site was receiving maybe connected to that functionality like, did they build the site the wrong way. After they got to scale with traffic.
AO: Yes. So, one of the best examples I can think of, of a rebuild or at least one that the developer wanted to rebuild after they’d gone down a path came up with multi site, which is unfortunate because I think multisite gets a bad rap sometimes. But that only happens, because there are precious few use cases they’re a really good fit for WordPress multi site. There are a lot of others that are a bad fit, and sometimes it’s misapplied and shortly after became an esky I was doing an on site consultation with a university. And they asked questions about how single sites work on our platform, and they asked questions about how multi sites work our platform, at which point I said, Okay, you’ve asked about both which, which is your presence, do you have a multi site presence, do you have a single site presence. And they said that they had adopted multi site. Early on, and higher education is actually one of the better use cases for multi site is one of the ones that we talked about as being a pretty good fit. And this was one university that had done that, where they started building a multi site network with every department having its own sub site on a sub domain. And that makes perfect sense because all of the sub sites have the same look and feel and basic functionality that should be a good use case, but even they said that they got so far down the path that they started to realize that multi site had sold about as many problems as it caused for them so that like they had all they did was swap pain points for different pain points. But once they had adopted that as their their presence. It was really difficult for them to back out of it, so they couldn’t rebuild even though they wanted to. And so I think that’s one of the better situations that we could probably help avoid a lot of
DV: times, is that more like the fact that you’ve seen a lot of sites and deployments and heads to insights into how people might consider their architecture or is it actually related to like a host or server environment variable.
AO: Actually it’s such a mention it’s, it’s kind of both like we’ve got pretty deep experience on how certain types of sites work on our platform, but we also have pretty deep knowledge about how certain types of sites work, especially at scale. So we see people encounter certain pain points just by virtue of being demanded shows. Like I mentioned earlier with how SSL is generated for like multi sites that can be hosting environments specific, but there are certain commonalities that are going to apply to basically all hosting environments as well.
DV: Right, well I think anyone listening, that that’s building multi site Aaron would would definitely consider reaching out to their their hosts to talk about it. I think it is such an interesting construct, I, you know, thinking back to my agency days which I ran an agency for five years. I don’t think I hardly ever talk to this about the, the, the build itself. It’s kind of like once you got through the build and you were ready to launch and you’re like, okay well let’s go buy something now versus like thinking about that earlier on, and you know having sat on both sides of the table that had his side and the builder side I definitely see the value. And so, I think, as folks listening think like okay well maybe I’ll go do that. I think they might also be thinking like what kind of things should I ask about. And that’s really what I want to kind of get into Next, we’ll return to that after this break.
DV: Hello everyone welcome back to press this WordPress community podcast on w EMR, we’re in the middle of our episode talking about questions you should ask your host before a large WordPress build right before the break our guest Aaron on Ken was sharing some some kind of war stories, if you will, about builds and what can go wrong and what might be required in terms of a rebuild. Aaron I thought you shared some really interesting thoughts around multi site. Now I want to get a little more tactical. You know someone’s thinking about like reaching out to their house to talk about a big build before they start or, you know, in the planning phases. What sorts of things should developers share with hosts about their large builds before they start. It’s a good question.
AO: We often start like as solutions engineers by doing a type of discovery where we’re just asking general questions about like the site, the audience, the core functionality and stuff like that, and it’s, it’s very similar to how we would ask you questions for a site that currently exists maybe another hosting environment that was considering moving to like our environment. They’re basically different. I mean, basically the not that different. The only difference is like, oftentimes, early on in a project, you’re really just guessing at a lot of the answers, like when you start to kick off a new project for a new website builder you don’t always know how much traffic The site is going to get. And so sometimes we’ll adapt those questions a little bit. So the question is not how much traffic will the site get in the first month. The question is more like how much traffic with the site need to get in order for you to consider it a success, a successful launch. And we would adapt that like for the the type of site, it is for example if it’s a learning management system site where you’re trying to get a certain number of students, we’re going to ask, how many students would you need to get, and also pay for your courses in order for you to consider the launch success. Do you have goals to grow it in the first six months, like, once the threshold you’re open again to six months down the road or one year down the road. And we’re going to tailor those questions based on the type of site, it is so we’re gonna ask some different questions if it’s a LMS site as if it were an e commerce site or a multi site.
DV: So when I say that what if the people listening I don’t have like WP Engine, what, what, what should they be asking of sales engineers or other people representing like account management are making this kind of decisions with their host.
AO: I think it’s going to be sharing as much information as possible about all the goals you have for the project. And when I say project I mean, the site is about to be a limited time like site. So it’s a pretty candid conversation we end up having about what things are going to look like at launch, what things are going to look like a couple weeks down the road, one standard road a year down the road. So we can help create realistic expectations around all those stages. And oftentimes we have to ask a lot of questions about what are you doing that’s like, maybe not a WordPress best practice, like, we’re not gonna stop you from doing it, but if we know that you’re doing something that’s like non standard. We want to be able to take that into account so we can figure out if we can accommodate it
DV: like advise people get down to like what PHP functions do you support and like like that kind of granular level list.
AO: It can happen, we’ve we’ve seen it happen, it was more important to have those conversations around the time everyone was upgrading to PHP seven, because there are a lot of functions that are being deprecated like between like versions of that time but it’s somewhat less common. Now, if there are certain functions that you’re say like writing a custom plugin that plugin is dependent upon that function that absolutely that’s absolutely something you want to share with your host.
DV: Gotcha. So it sounds like you know if I’m thinking about this from someone building a site’s perspective and I love how you put it you should be prepared to talk about your goals. You know, because they think so much time spent on the architecture side but not necessarily like what am i building and what are the specs and did I build it. But thinking about how that site will perform over time, and I love how you also kind of frame that you know for a site that doesn’t exist, trying to come up with some measure and measuring that against the success of the digital business, I think is is critical. That’s a really sound points. So what should people do if they run into a barrier like what I mean like are barriers that are hosted like there for a good reason in terms of like environment variables might be different in one host to another.
AO: Yeah, absolutely, like, one thing I know about the flywheel platform as a, like, as it compares to WP Engine platform. There are like various variables are different. One of the most common ones we get people asking about whether or not we can extend or change is the max PHP execution time. And we’ve got it set at a certain level on the flywheel platform for various reasons, not the least of which being that it helps us keep control over like rogue processes that might be running like sucking up resources on your on your site, while other requests are waiting in line behind it. Oftentimes people find out what it said and they want us to extend it as far out as possible days or even weeks out, and that is not advisable. We can do it but in most cases we’re going to tell you that we wouldn’t advise that because it’s there to help keep your site running
DV: well there’s like a lot of examples of this like disallowed plugins which can have compatibility issues or security or performance issues and so I think like, you know, I’ve been in that situation where it’s like I want to do this thing but it doesn’t work in this environment. And I found that historically it was better to ask like well why doesn’t it work so I can understand like maybe it’s there for a good reason. Yeah, maybe I’ve made a choice that wasn’t the best choice. Aaron this has been super insightful thank you so much for joining us today.
AO: Certainly, anytime.
DV: Awesome. If you’d like to learn more about what Aaron is up to you can visit wpengine.com Thanks everyone for listening to press this the WordPress community podcast on WMR. Again, this has been your host, David Vogelpohl. I support the WordPress community through my role at WP Engine, and I love to bring the best of the community to you here every week on Press This.
Start the conversation