His WordPress site was hacked.
He’d reported it as a ‘slow site’ and the techs had done an amazing job helping him clean it up, but when it landed in my lap, I took one look at saw backdoors, permissions issues, and vulnerabilities galore. So I did the reasonable, responsible, fair thing. I reinstalled the files, I cleaned up the plugins, and then I saw his theme was behind a paywall, old, and, worse, no longer supported. So I removed the theme from his website (putting it where he could get it back) and switched him to Twenty Fourteen. Then I explained in a rather long email about how his site was hacked, how I determined it, and what he needed to do to get the theme back (basically download it again from the vendor).
He was mad.
He argued that I had broken his site and it no longer looked right. This was true. He complained that my service was deplorable because his site looked wrong. This is debatable. He groused that I had to put the theme back. This was not going to happen.
It’s the service conundrum. If you know something’s wrong, do you leave it alone or do you fix it? When I see people post their passwords in public places, I delete them and use bold and italics to chastise them. When I see people doing dangerous things like editing core, I do the same. I try really hard to educate and warn people, so they can be protected from shooting their own foot off. So when I have a rabid customer telling me I need to let them do it … I don’t.
My job is really to help people fix their sites, and that tends to mean my job is to debug and educate and provide options. But when someone has an abjectly wrong bit of code, like the bevy of people who had their old themes and plugins break when we upgraded them from PHP 5.2 to 5.4, I will regularly go that extra mile and fix the code. That doesn’t mean I don’t educate them, they usually get a quick lecture about why we upgrade promptly, but when someone’s that far off normal that their code won’t work on PHP 5.3, I assume they just don’t know anything.
The worst part about it, though, is when they argue. They’ve asked you for help and advice, you provide it, they demand you fix it, and at a certain point… they’re just asking the wrong person. Your webhost is not your consultant. While many times we can and will fix the site, when it gets down to code that isn’t working, we can’t be expected to re-write all the code.
Sometimes we’re going to be the bearers of bad news. Your theme is hacked. Your plugin is vulnerable. Your code won’t work on this server because of reasons. We’re never making an excuse, but we are trying to explain to you why things happen.
Now I know I’m a little weird, because I think that everyone should be educated in how their site works. Not that I think they need to learn to code, but to understand what’s going on, in broad terms, means you’ll be able to help us help you fix your site. And with that, I expect people to actually listen to what the support techs say. We won’t always be right, especially not with WordPress which has infinite combinations of plugins and themes (it’s a mathematical impossibility to be able to be familiar with everything) but for the most part, we are all trying to learn to be better and faster at debugging.
But. What do you do when the person you’re trying to help insists on hurting themselves? Like the person with the hacked theme, maybe you’re lucky and your company has a policy that once you know something is malware, you’re legally not permitted to reinstall it. But what if they decide to use a plugin that has a maybe backdoor, like an older version of TimThumb? How big a deal is that? Is it better or worse than helping someone do something that will absolutely kill their SEO?
For me, it’s pretty simple. My company does have a no-malware policy, and I can fall back on that. When I volunteer, I often tell people “I will not assist you in doing something I don’t feel is right.” and I walk away. Because I feel strongly that I should educate you, but also that I should never enable you to hurt your site.