Tag: support

C’mon Get Trac’in!
After every major WordPress release I trawl the forums and look for new superstars. I usually find one or two people who, like I did five years ago, catapult themselves into the stratosphere by taking notice of issues of communication and correcting them. That’s how that OMGWTFBBQ post was born! WordPress 3.0 dropped with a lot of changes and people lost their minds. That’s the best part of a complex release.

The worst part is people losing their minds in the wrong places.

Oh there’s nothing wrong with going batty over a change or reporting something is broken. What’s wrong is when you go into a half-dozen similar posts and repeat the exact same rant. Much like the superstars who get noticed because they’re being helpful, when you spam-rant, you become noticed in a bad way.

No release is perfect, and WordPress’ ideology of ‘Release and iterate!’ means that we know we’ll have missed something, or not totally finished another, and it’s not everything we want yet, but also that the fastest way to get ready is to get more people poking at it and breaking it. This means we know things aren’t perfect, but it doesn’t mean we ship broken code. Still, change breaks things, and some of those things are outside our control (like TinyMCE 4 changed how it implements a lot of things).

Naturally though, big changes cause loud complaints. For people who shout and demand to know why we had to change, the problem is where they do it, not so much how and with what language. The where problem is that someone will post a rant in a bunch of similar posts, or create a trac ticket when they haven’t done any debugging.

It’s pretty easy to remember that the support forums are not your personal soapbox to stand on and shout about how much everyone sucks (or is awesome, I know). The forums are a place to describe your problem and get help.

So … How DO you know when it’s time to get trac-a-lacking and make a ticket, and when it’s not?

Is it just you?

A quick search of the forums will tell you if you’re the only one with an issue. If you see one or two other people with similar issues, read deeper. Similar is not the same, so just because you both have a white-screen-of-death on the post editor does not mean it’s the same bug.

Did you do the needful testing?

Have you tried:
- flushing any caching plugins you might be running, as well as server and/or browser caches.
- deactivating all plugins (yes, all) to see if this resolves the problem. If this works, re-activate the plugins one by one until you find the problematic plugin(s). If you can’t get into your admin dashboard, try resetting the plugins folder by FTP or PhpMyAdmin (read “How to deactivate all plugins when you can’t log in to wp-admin” if you need help). Sometimes, an apparently inactive plugin can still cause problems. Also remember to deactivate any plugins in the mu-plugins folder. The easiest way is to rename that folder to mu-plugins-old
- switching to the Twenty Fourteen theme to rule out any theme-specific problems. If you can’t log in to change themes, you can remove the theme folders via FTP so the only one is `twenty fourteen`. That will force your site to use it.
- manually upgrading. When all else fails, download a fresh copy of the latest.zip file of WordPress to your computer, and use that to copy up. You may need to delete the wp-admin and wp-includes folders on your server. Read the Manual Update directions first.
(Can you tell I use that a lot?)

Does it happen on a clean install?

The best testers test on a test site. Even on my personal, I don’t code on it, laptop, I keep a copy of MAMP handy, as well as a pure test site on a live server. But I’m weird. Still, if you’re even considering making a trac ticket, have a test site and test it there before you click that ‘new ticket’ button. It may feel like an extra hurdle, but having that clean test will make sure you’re not losing your mind sometimes.

Have you asked anyone else about it?

I admit, this works better if you know people, but if you do know someone, just ask. I bug my coworkers sometimes “Hey, do you see this? No? Okay…” It helps me sort out if I’m being crazy or not, and sometimes just asking “Anyone know why I might get this error…?” gets amazing results. Again, this works best if you have a network already, so don’t worry about this too much.

Hope you’re right…

Even I don’t know if it’s right to make a ticket all the time. I hesitate over those buttons a lot, and often delete the whole thing. It’s not super simple to know, so you have to make your best guess.
30 May, 2014
The Person of WordPress

I read Manga, pretty much like every comic book nerd from the 1980s. I got hooked on some fairly grown up stuff as a tween, and today I read the stuff with entertaining and semi realistic stories. One of them I read is called “Space Brothers” about, get this, two brothers who decide to become astronauts. When the story starts, the younger brother, Nanba Hibito, is poised to make his first trip to the moon, while the older brother, Nanba Mutta, is fired for head-butting his boss. As the story goes on, Mutta overcomes obstacles and is accepted into JAXA, Japan’s version of NASA.

It’s during his first lecture as a newbie wanna-be astronaut that the lead of the support staff draws the Japanese character of Person on the white board:

And he tells them a famous person said this:

The character of person shows that people are living by supporting each other.

I was unable to verify the quote, but it sounds somewhat reasonable to me. Still, in looking at it, I thought that the stroke on the right seemed to be supporting a bit more than the one on the left. So did the character in the manga, who went on to explain that some people support more than others, but they do so with the intent of boosting the others higher. That’s why the leftmost stroke is taller.

Now, Japanese has three written languages: hiragana, katakana, and kanji. For those unfamiliar, you can read a brief explanation from Ancient Scripts, but the person character I used above is from kanji. There’s a historical basis in kanji that look like their meanings, so this interpretation isn’t outside the realm of possibility.

When I look at WordPress, I see that leftmost character as being the path taken by the people who manage to write amazing code. And I see myself as the rightmost character, who tests and debugs and supports them. I feed information into them as I find it, I help others to do the same and solve their problems. I am, indeed, a support guru.

There’s nothing wrong with this. If it wasn’t for me, and people like me, WordPress would fall over. I said this at WordCamp SF in 2012: If there weren’t users, there would be no WordPress. All of us, the users and the support people and the random one-plugin developer and that person who edited a theme once, we’re all the reason WordPress is still being used as well as it is. The app was made useful and deemed useful.

But consider the modern version of the character.

This may seem strange if you’ve never read about kanji before (I was once deeply into a manga about caligraphy), but it has it’s own version of print and cursive. Here are all the various ways one might write ‘person’ in kanji:

Now you may notice that’s a Chines Kanji exemplar. It’s the same thing for around 70% of the characters. And in this case, it happens to be the same.

If I was to extend my previous thought, that the support arm of WordPress helps it reach new heights, I would look at the modern character and say that the two arms keep each other from falling over and, only when combined, can they reach the future of marvelousness.

That’s a bit cheesy, I know, but the point is that we’re not alone. We don’t work on open source in a vacuum, we work together, relying on each other, to make everything better for everyone. We’re equal partners in the work of creation, even if we don’t see it as such all the time.

I don’t know what the kanji is for Open Source, or if there even is one, but I hope it represents people for being the crux of it all, always helping people.

23 April, 2014
General Behavioral Guidelines
The following are cribbed from TWoP’s Dos and Don’ts. They should not be considered the be all and end all of how to behave on a site, but I find that abiding by these gets you going on pretty much every forum and comment site in the history of ever. Since a lot of people never saw TWoP (or the similar post I made on make/support in WordPress land), it’s useful here.

Good Manners and Respect Dos and Don’ts
- DON’T use “um,” be snotty to another user, or make the argument personal
- DO know the difference between differences of opinion and personal attacks
- DON’T present your opinions as facts
- DON’T post the same opinion over and over in the hopes of wearing other people down or “winning” a discussion; just move on
Starting New Threads Dos and Don’ts
- DO search for existing topics before starting new threads
- DON’T use all-caps or excessive punctuation in thread titles
Posting Messages Dos and Don’ts
- DON’T post in a thread until you’ve read the whole thread
- DON’T post “Me Too!” messages; add something of substance to the conversation
- DON’T sign your posts
- DO use proper spelling, capitalization, punctuation, et cetera
- DON’T pimp your site or product, et cetera;
- DON’T post copyrighted articles; link to them
- DON’T post the same thing in multiple areas; pick a spot and go with it
Warnings, Bans and Trolls Dos and Don’ts
- DO take any mod warnings you get seriously
- DON’T bug the mods to remove moderation on your posts
One thing I left out is something that drives me up the wall. Don’t reply to things in the wrong place. If you’re reading someone’s blog post about how to tie shoes and you post a comment of “Will Prince Harry get married?” because the blogger remarked about that in a separate post, you’re being really annoying. I personally delete off topic posts, and serial-off topic posters get blocked.

When you get off topic, you make it harder for a conversation to be followed. When you make it hard to follow, you get bad help (at least in support forums). Hate it.

Of course, when I suggested these to WordPress’s Support folks, I got some interesting replies which tell me that folks aren’t quite as receptive to things being spelled out, fairly friendly, that should be common sense. Allow me to quote Voltaire:

On dit quelquefois: “Le sens commun est fort rare.”

For those of you who do not speak French: People sometimes say: “Common sense is quite rare.”
16 April, 2014
So You Just Have One Small Question….

Every single developer, tech supporter, manager, project planner, tester, parent, teacher, and quality checker knows that question. And we all know that absolute feeling of dread that comes with it.

No, you don’t have one ‘small’ question, we think to ourselves, wishing we had a drink in hand, or maybe pondering how much money we’d have if we got a penny (yes, one cent) for every single time someone asked a ‘small’ question that worked out to be larger than the initial topic. It’s right next to one more small change, which is always inconvenient.

The questions are nearly never ‘small’ and they’re nearly never ‘quick.’ They’re born of a lack of understanding (hence question), which in and of itself is alright, but they seem to always come at the end, when we think we’re done. As a developer, I often feel these last minute ‘one more’ questions are because I didn’t ask all the right questions in the beginning of a project (which is why I’m not answering ‘Should I use multisite?’ anymore, too many questions). If I had a simple checklist to go down for my projects, it would be a lot easier.

But…

Therein lies the bane of most development setups. We don’t know what questions to ask much of the time, because we can’t know. We ask everything we can think up, and suffer from the failures of imagination later on. Or we end up in design hell (this is an Oatmeal link!).

And what if we’re not developing? Tech support is a nightmare when people have ‘one more question’ because it means they’ve asked for help before they’ve actually thought through everything. Hey, I’m guilty of this too, there’s a reason me and my friends will sometimes tweet a question with a tag of #lazyweb – Sometimes it is faster to ask a question of the masses (or one person) than it is to think hard about the context.

Here’s my challenge to everyone. Stop asking one small question, and try to ask one smart, simple, question.

Boy that probably sounds weird to a lot of people. A smart, simple, question, is a page shy of being asked by Captain Obvious. It may net you a reply of “Ask that again, would you?” so you slow down and think about what you just asked, clearly. Other times, the smart and simple is a clarification of something confusing in documentation (or missing from documentation entirely). Maybe it’s a link you can’t find. Maybe it’s that thing you know your wife will remember, like an actor’s name (“Honey, who was the guy who wasn’t a guy in the movie with the weird clothes? Tilda Swinton! Thank you!”)

They sound like they’re stupid questions, don’t they? The ones you ask and think “I was dumb.” They’re not. They’re really smart because you know the one thing, and the one person, who can help you pull an answer out of your own head.

The other great smart and simple questions are the one-offs. They’re short. “How do I start this car?” That’s generally smart and simple. But moreover, they’re specific! That’s the trick to a simple question, it’s to the point and direct. It means you’re not sending a novel to the CEO of the company, but a carefully thought out explanation of what you expected to happen and what actually happened. A good bug report is always simple, even when it’s complicated.

What it’s not is needlessly complex.

There are a lot of smart, complex, questions. You know the ones where it’s “How do I thread my new sewing machine?” Sounds relatively simple and easy, but it’s deceptive. I say this having had to read poor documentation, from 1920, on how you thread a sewing machine. I realized I was smart, but I was inexperienced, so I googled how to thread that specific machine. It was a smart question, but it wasn’t simple. In fact, it was insanely complex, and at a certain point someone in the house wailed “I just want to sew!”

A smart, complex, question is a great question, but it’s not one you should ask frivolously. What you really just asked is not ‘How do you…’ but ‘Teach me how to…’ And if you think teaching is quick and simple, you have a lot to learn. The complex questions are made worse when they’re asked with that novel. Oh, the novel. This is a novel, and if I saw a forum post or a ticket at work with all this in it from someone, I’d wince.

Smart and simple. Smart and short. My wife can teach someone to make cheese in five tweets. But I can’t debug (most) WordPress problems in that many. This is in part because tweeting code sucks, but it’s also because this isn’t a math question. I can probably explain Common Core in five tweets, but I can’t teach it in the same number. When you ask me a complex question, you don’t want me to explain, you want me to teach.

I know that easy is hard. The easy answers are hard, and they take a long time, which is why sometimes I tell people “Maybe” or “You can, but it will be complex.” I’m not brushing you off, I’m giving you the biggest hint in the world.

Your question is complex and complicated. But it sure ain’t simple.

14 April, 2014
Easier Control

In a WordCamp I heard a developer say something along these lines:

“I include my own jQuery because it’s easier and I can control things.”

The moment he said this, I clamped my mouth shut and bit my tongue. It was not the subject of this presentation, and multiple other people in the room had already pointed out that WordPress has it’s own version. Afterwards, someone remarked she saw steam coming out my ears. All I said in the room was “We reject themes and plugins from the .org repositories for including their own copies of jQuery.” and then shut up. After all, I was in the room because I wanted to learn about something I didn’t know, and that wasn’t jQuery.

It’s sad that my major takeaway from that talk is too many people sacrifice sustainability for ‘ease’ and ‘control.’

You may think that if you force install your own jQuery, you can be sure a random upgrade of WordPress won’t break your theme. You have full control over the theme, after all. And you may think that you can make your theme or plugin faster if you compress all the JS together yourself, rather than having WordPress load a dozen separate files. Those thoughts are both true, but you’re wrong. You’re never ‘master of everything’ unless you only use WordPress core and the themes and plugins that you built. And even then, you’re still not.

While it’s perceived as easier and faster to write code if you assume you know the truths of your website and will always be it’s master, the fact is the assumption is plain ignorant. These days, it’s rare you’re ever the sole developer of a site. You may be hired to make a theme, I’m hired to make a plugin, and someone else is titularly in charge of both of us, but probably doesn’t know a lick of code while still being the driving force behind the website. Not to mention we’re not the webmasters of the site. That may be some intern nephew of the boss, who will take over once we’re done.

And that is exactly where using our own versions of scripts will get us into trouble.

You’re master of your plugin, or your theme, but you’re not master of the rest of the world. Even if you’re making it on spec for someone for a specific purpose to be used on a specific site, there’s no guarantee that it’s the only time and place your code will ever be used. There’s no assurance that then 10 other plugins you tested with today will never upgrade, or that they won’t add more. If you get hit by a bus tomorrow, there’s no promise your code will remain untouched. Basically we’re running on pure arrogance that not only are we crystal clear about the present, but we’re totally perfect about knowing the future. And that just ain’t possible.

So. How do I explain why including your own jQuery in a theme or plugin, instead of enqueuing the one with WP, is bad?

“Picture this. Your theme has jQuery 2.0. So it de-enqueues WPs and re-enqueues yours. My plugin is using version 1.7. I do the same thing. Bob’s plugin uses 1.11, HE does the same thing. Joanne over there properly uses WP’s. Which one of our jQuery files wins?”

The problem is that you’re emphasizing short term gains (speed of development, speed of site) over long term sustainability (regression conflicts, duplicate files). You’re making your life a little easier, and actually harming the website you’re trying to make because tomorrow, you will be gone and they’ll be trying to figure out why the site is so slow. Or why it’s breaking when they upgrade Jetpack. After all, you tested with Jetpack, right? You were selfish, short sighted, and just … wrong.

But it’s okay. You can learn to do things better. You can do it right with your code and fix those mistakes. You can let the wookie win, and let WP control what it’s supposed to control, while only augmenting what you must control. And you can do it all in a friendly, sustainable, updatable, extendable way. Which is how WP wants it.

Oh and how to I handle minification? I have a proxy service do it for me. In my case, Google’s mod_Pagespeed compresses and combines all my JS and CSS to make it one file that loads faster.

2 April, 2014
Forget 100%

Can I tell you a secret?

I hate the five nines. The Six Sigma Stigma has me wishing that everyone who tells me they’re a ‘black belt’ please die in a fire. It’s not that I don’t think that the process can work for some people, or that it’s useless as a whole, but that I think too many people treat it like an MBA. “I did this thing for a few months, I am now an expert.” I had a bunch of coworkers who did that. I hated them. I got to the point that if you said “We need five-nine reliability” I had a Pavlovian reaction that involved me rolling me eyes and tuning out.

Now this doesn’t mean than I don’t think 100% ‘uptime’ in anything is a nice goal, but I see it as a lofty goal. Look, you know this stuff already. I will not walk down the stairs successfully 100% of the time. I will not have the next key I strike on my keyboard function as I expect 100% of the time.

So moving this off and saying “I don’t need 100% uptime, I need 99.999% uptime.” doesn’t actually change anything. In fact, I’m willing to bet that a lot of people look at the five 9s and think that it’s so close to 100% that they should never see or notice an outage. Thanks, Six-Sigma people, you just made 99.999% synonymous with 100%.

That wasn’t the secret, though.

My secret is that I don’t care about 100% uptime in anything.

I worked for too long in deployment to understand that there is no such thing as 100% uptime for anything. There are ways to minimize and mitigate downtime, and there are ways to make sure it causes as little impact as humanly possible, but there’s no way to avoid it. Ever reboot your computer? Of course! Ever upgrade WordPress? You have then experienced downtime. It’s a nature of life. I expect it, I don’t sweat it.

So if I don’t care about 100% uptime, what do I care about?

Reliability, accountability, responsibility, and timeliness.

I was reaching for the words that end in “ibl”, but really the root ofable is my concern above all else. Are they able to handle it when things go pear shaped? Are they able to fix problems quickly, correctly, and efficiently? Are they able to prevent the exact same error from happening again? Are they able to own up to their mistakes?

I don’t expect anyone to do all that 100% of the time, but I expect them to care about the things that are important to them as an entity. My webhost should care about the severs not being on fire and serving up webpages. My bank should care that my money is safe and available. My government should care that it’s … Too soon? Anyway, the point is that you should care about what you do, and provide the best service you can. Now, if 50% uptime is your best, maybe I’ll look for someone else. I am reasonable about these things. If email goes down, how fast did you get it back up? But to me 50% isn’t reliable unless I’m looking for something that, intentionally, only works half the time.

All this said, I don’t actually look at the uptime numbers all that much, unless I feel that the reliability is sub-par. The actual numbers, the metrics, the absolute “This service is up 100% of the time or your money back” is not really what I count on. My friend Pippin said it wisely the other day:

I have far more faith in a company that encounters occasional problems but responds incredibly promptly than one that has fewer issues but doesn’t respond half as well

He happened to be talking about a brief (like 10 minute) outage on his site when all databases were inaccessible.

Don’t bank on the percentage, bank on the ability to react and come back.

10 February, 2014

Tag: support

C’mon Get Trac’in!

The Person of WordPress

General Behavioral Guidelines

So You Just Have One Small Question….

Easier Control

Forget 100%