Working with a host isn’t just sending in tickets into the abyss and hoping they answer them. Whether you’re communicating on behalf of a client or for your own benefit, it’s not the same as working with fellow developers. You need to approach a host with different expectations and explain situations in different ways in order to get the best results.
What Is A WebHost? Why Are They Different?
You’ve had this problem where what works on Host A doesn’t work on Host B, right? All webhosts are different for a really obvious reasons. There’s more than one way to solve the problem of webhosting. Every host has decided, on their own, what works well for THEM. Which means no two of them are the same, nor will they really ever be. This is okay, if it’s a little annoying, because not only are YOU a special snowflake with your customized website, but so is your webhost with their customized server and environments.
Setting Expectations
Hosts Are Not Developers
Your host is not going to generally debug themes and plugins. They’re just not. They don’t have the manpower for it. The host cares first about your servers, THEN about your code. And if they find your code is the problem, that discovery is often the limit. They’re not always going to help you debug exactly why plugin X is causing a specific feature on their servers to grumble. This doesn’t mean they can’t do it. Many hosts, especially ones with WordPress hosting plans, can and do debug code all the time. To be more precise, you shouldn’t expect the host to reverse engineer your code to understand why it does what it does. They are problem identifiers.
Hosts Will Fix What’s Theirs
This doesn’t mean that a host will leave you high and dry. A host will fix whatever they can. If their code broke your stuff, you bet they should fix that. Did they run a WordPress upgrade that left your site with bad permissions? Yes. But… If they ran an upgrade and you have a theme incompatible with WordPress 4.2, who’s problem is that? Should they be on the hook for fixing it or should the person who owns the site? This is why I say hosts will fix what’s theirs. It’s a lot of grey areas sometimes. It feels like people are always making exceptions or telling you that you’re an edge case. But at the end of the day, a host is NOT on the hook for upgrading your custom theme to work with the new version of WP.
All Hosts Are Different
Telling a host “But it works locally” or on another host doesn’t do them ANY good, nor do they really care. Everyone sets up servers differently, and sometimes the issue will be with PHP or the Linux OS or maybe, help me, Windows. It’s apples and oranges, like trying to compare two similar themes. Now this puts developers in a bad spot. WordPress is incredibly flexible and works, out of the box, in the majority of situations. The same cannot be said of all code. Most people don’t have the resources core does to test in so many iterations. And even WordPress misses things. Not all code will work in all configurations in all circumstances on all hosts. Sometimes you are a special snowflake. You are the edge case.
Don’t Assume
So what can we do to make things better? Telling the host the important things, especially if you’re a dev, will help everyone. If you’re not a dev, then start with the basics. The important thing here is, even though you having a bad day, not to freak out. You need to be calm, you need to be clear, but you need to provide a GOOD bug report. Don’t assume the host magically knows everything, since the error MIGHT be their servers, certainly, but it may also be a combination of what the user is doing, how they’re doing it, and the server that causes the problem. Hosts are not psychic. They only know what you’ve told them.
Give the Right Information
Who Are We Talking About?
The most obvious question? “What’s the domain?” Many people will have multiple domains with a host, and if the issue only happens on one, you can speed up their searches just by being up front! Many, many, many times I see people complain that their ‘site’ is down. One user had 107 domains. I stared at it for a moment, tested a couple, and finally emailed back. “I looked at these five domains and they seem alright. Your email didn’t specify which domain was broken or how. Can you please be a little more precise? It’ll help us find out what’s wrong faster.” Start out with exactly what’s wrong and where.
Are You The Owner?
The next important thing to tell a host is “Who are YOU?” This is secretly “Who owns the site” because if it’s not you, you may not be able to get all the answers due to security. The host will know who you are, based on the email, so this also means “What kind of person are you?” Are you a user who can’t code? A high end dev? A middle-of-the-road guy caught in the problem? Let the host know what you can do and they can help tailor answers better. It’s okay to say that you’re the new dev taking over and you don’t know everything yet. Just let the host know where you stand. This lets them know what to expect and what they are permitted to tell you.
Where Does It Hurt?
With WordPress, sometimes a host has to ask “Can WE log in?” I hate this. I hate asking someone for access to log into their site. It makes me nervous. But sometimes if the error only happens when you do specific things, a host has to log in to reproduce it with debug on in order to track it down faster. If it requires logging in to reproduce the problem, remember to provide them access. I strongly suggest making a second account for the host and deleting it when they’re done.
Explaining The Problem
Even If It’s Tricky
All the information before should have gotten you here already, but it needs repeated. Explain the problem! “This site is broken” is a terrible email and yet I see it daily. A better one is “This site is broken after we upgraded to WordPress 4.2. This is the error, this is what I’ve already tried. I THINK the issue is this other thing. Can you help?” Give the right information. Tell the host what’s wrong. Give them an error. Don’t assume they’re familiar with every single possible error. You’re not, after all, unless you’re Nacin.
Details Are Important
I know I said to tell them what you think the problem is. It’s okay not to know, but it’s not okay not to give the details on what you DO know. You know some things. Is the problem happening for logged in or logged out users? How do you reproduce it? Start by assuming the host knows NOTHING about your site and how it works. Even if you’re sure they know how a blog works, take the time to step back. This is really hard. You have to give them enough information without spewing your whole history.
Walk Them Through It
Walk them through exactly how to reproduce it. Use screenshots when possible. Videos? Not really as helpful as you might think. If you get an error message, make sure that you give them the WHOLE message as well as the context. I mentioned not assuming before, this goes double here. Don’t assume a host knows how you upload an image. There are multiple ways to do that, so tell them how YOU did it.
You’re Not The Customer? They May Have To Talk Tech
When you’re not the one who pays the bills, you may need to play intermediary and have the owner contact the host. Some hosts let you add specific email addresses as secondary contacts. You should always make sure of that early on. If you hate the social engineering that comes with people cracking into other people’s accounts, that’s WHY many hosts won’t just tell you everything. Playing the middle sucks, and when this happens, try to be patient. Everything will take longer. That said, have the customer ask the host if there’s a way to add you on as someone the host is allowed to talk to. Most have a way around it.
Pick The Host You Like … And It’s Subjective
Speaking of that … You should find a host you like. Figure out what you can work with, and here’s a big secret. Hosts won’t mind if you tell them that they can’t meet your needs. Okay that’s a lie, they do mind. But if the reason is “You don’t have 24/7 phone support!” well they understand. If the reason is “I need a type of server you don’t provide” that’s also okay. And sometimes, sometimes, no matter how much you love a specific person (or people) at a host, they just don’t meet all your support needs. And that too is okay. Hosts understand that. One brilliant person doesn’t make up for the masses, after all. Hosts aren’t the same. It’s okay.
Everyone Wants Everyone To Be Happy
In the end, the host wants the same things a customer does. A good, fast, website that does what they want and makes them happy. If you’re clear about what’s wrong, what you need, and you’re willing to work with a host to experiment a little, you may be surprised at how well you can work with them to succeed.
Comments
2 responses to “Working with Webhosts”
Great article, and some fantastic points.
One place I’ve found a sticking point on a few hosts is between the “are you the owner” and “they may have to talk tech”. On a few hosts, I am set to be an “authorized user” (whatever that means in their particular world – usually the permissions mean I have the power to do everything except handle billing for the customer), and, yet, the process still falls down.
For instance, on one host, I have a specific file where the permissions got messed up. I submitted a ticket, as myself, asking the host to fix the permissions. I made it clear who I was, that I was an authorized user, and that I was not the “owner”. The host then asked their security questions before they’d do anything about the file, but they really wanted the owner’s answers to those security questions (which, for good reason, I don’t have). They refused to do anything to fix the issue without me having the owner answer those security questions. That left a bad taste in my mouth.
That said, in every other aspect, that particular host has been fantastic for 5 or 6 years, now, so we’ve stuck with them. It’s just an annoying little hurdle that I know I have to clear in order to get support.
@Curtiss: Actually you know the answer already 🙂
The key in there is this: “whatever that means in their particular world”
Being an “authorized user” is not the same as being an owner. As you said, usually that means everything but billing, but sometimes it’s “everything but destructive changes.”
We sometimes make fun of the crap like what happened when GoDaddy was socially engineered on Twitter, but most hosts now are being adamant that we are absolutely 100% sure we’re supposed to be answering those questions to you.
Sure it’s just file permissions, but what if they were setting them to 777 and had a vulnerable plugin? Now it’s the hosts’ fault :/ Balancing the responsibility and caution needed for such an infrastructure SHOULD always err on the side of caution.