Categories
How To

Don’t Say WordPress

Sometimes it’s WordPress, sometimes it’s not. And sometimes saying “WordPress” blinds everyone to the real problems.

This time I’m absolutely 100% serious. Yes, I can be sarcastic and humorous when I talk about WP, but in this case, I’m being honest, and I promise you serious. I work for DreamHost as a WordPress Guru. I’ve been training people, and teaching them one at a time, and in doing so, confirmed a bias I’ve had for years: Tech Support goes blind sometimes.

Man with tape over his mouthI don’t think this is really their fault. They have to handle 60 to 100 tickets a day about everything from “How do I reset passwords?” to “My Database is speaking in R’lyehian. HALP!” In order to get through that volume, they look for the key words, the important ones that tell them that this is the problem. And one of those keywords is “WordPress.”

This is not great, because sometimes the problem isn’t WordPress. Like a PHP isn’t running, or the DB is missing, or a hundred other ‘It’s not WP’ problems. Naturally, that means a handful of tickets escalated to me aren’t WordPress at all, and I have to dig into it, and explain why.

Before my coworkers think I’m pointing figures or blaming them, I really don’t. It’s a volume thing, and it’s got to do with how the customer presents the error. If they tell you “My WordPress site is down, I’m getting an error 500 on all pages!” you think “Oh, it’s probably .htaccess or they’re using too many resources.” Those are the most common causes after all. After that, you start getting messy and into weird things like “PHP memory is set too high, causing WP to crash” (which I didn’t even know you could do to be honest until November). And sometimes it really takes someone who knows how WordPress works to put the pieces together and determine “Oh! This is it!”

However, hands down, when I’m working with Multisite and I see someone say “My wildcard subdomain isn’t working!” and the ‘error’ page they get is not a WordPress styled 404, I will tell them “DO NOT mention ‘WordPress’ or ‘Multisite’ to your host. Tell them this:” and here’s my copy/pasta:

I’m trying to set up a wildcard subdomain, so anything.mydomain.com will pull the files from mydomain.com, however I’m having problems. I’m getting a server error instead of seeing the content on my site. Is there a trick to setting this up on this server?

Now some hosts will look and say “Oh well you’re using WordPress, that’s why.” and I want to kick them a little. No, that’s not why. When you go to a subdomain and get the server error (like subdomain not found) or worse a DNS error (like Google saying the domain doesn’t exist), then the problem is not, and cannot be WordPress.

That’s why it’s really important to present your error in the best way possible. The most accurate to the actual problem. Of course, if you have no idea, then you should just be honest and say what you did. If you really, truly, didn’t do anything, though, be prepared for someone to ask “Are you sure? You didn’t change a setting on the dashboard?” And sadly this is because a lot of people lie, a lot of people misrepresent the facts, and a lot of people play dumb. There is a very small percentage of people who will come back and say “You know, I may have done something, but I cannot remember what I did.” I like those people a lot. They’re my people. They admit they may have, but they can’t recall.

WordPress FauxGo
WordPress FauxGo (yes, this is the FAKE logo)
Sadly all those people who aren’t quite as truthful screw it up for the rest of you, which is why there’s a time and a place to point at WordPress, and there’s a time and place to not do so.

How do you know the difference? Well you have to think. Is what you’re trying to do something you do with a plugin or theme? Did it happen after you made a change to your site’s settings? It’s probably WordPress. However if you’re trying to do something outside of WordPress, like domain mapping or wildcard subdomains or creating a database? Then don’t mention WordPress.

It’s counter-intuitive, I know. I’m telling you to be honest and say what you did or what you’re doing, but at the same time I’m telling you to leave out what might be important information. And that’s why you have to think. Is the error a WordPress error? Learning that takes a long time, so for a lot of rookies, the easier question is “Does the error happen without WordPress involved?”

Let’s go back to that subdomain thing. Turn off Multisite. Does the same problem happen? Probably not WordPress. So don’t bring it up just yet. Now if they ask “What are you trying to do?” or why, tell them. “I’m trying to setup wildcard subdomains so I can use it with WordPress, but at this point, I’m not even getting a WordPress error.”

Of course, it’s not always that simple. Like what if I told you that, on Multisite, not getting the CSS to display on subsites could be a server error? That’s when you get to say:

My complex .htaccess rules don’t seem to be honored by my server. Is AllowOverride set to either All or Options All in the httpd.conf (or equivalent) file?

Notice how I didn’t mention WordPress? This is because I know that if my .htaccess rules are right, the problem’s not me. Unless of course my host blocks that on purpose because they don’t want to let me run Multisite on a shared box.

It’s not cut and dried, it’s not ‘If this, then that!’ But what it is, is education and thinking. As long as you can learn what is and is not WP, you’re on your way to knowing when you ask about WordPress problems, and when you ask about server problems.

3 replies on “Don’t Say WordPress”

I ran into that issue with a host once. Took a few rounds to get them to realize the issue was theirs and not mine. (And yes, it involved wildcard subdomains.) This was a host that explicitly supported Multisite, too. They were quite apologetic once they discovered that the problem was in fact at their end.

This article made me remember a similar incident that happened a year ago.

A person came to me with a problem that their Linux Apache Tomcat server was displaying error pages.

The person was so sure that this problem was caused by some random service that I wasn’t even allowed to look elsewhere other that the system logs.

After 15 minutes of fruitless troubleshooting and arguments this person admitted to have added some code to a file. So this error was due to incorrect JSP syntax 😯 😥

Moral: Some people are very sure that what they did isn’t causing the problem even if the problem came up after that.

Comments are closed.

%d bloggers like this: