Author: Ipstenu (Mika Epstein)

WordPress Reviews: The Good, The Bad, and the Stalker

The following is the original notes on my WCEU talk about WordPress reviews. It’s more or less what I said, though the video will no doubt be up soon.

30 Months In Jail Over a One Star Review

This is a true story. In late 2014, a man violently assaulted a woman who left a bad review on his self published ebook. He stalked her, sorting out her pseudonym, finding her real name, address, and work location. He traveled 500 miles, found her at work in Scotland and hit her over the head with a full bottle of wine. He received 30 months in jail for the assault and stalking.

An Extreme? Not So Much

Every day people leave hundreds of reviews on WordPress themes and plugins. They talk about how much they love or hate a plugin, there is rarely any middle ground here, and they are as passionate as the developers themselves. This passion leads to a large amount of confrontation on the WordPress Review Systems.

Your Code Is Bad< And You Should Feel Bad<

We are all going to get the bad reviews, and while you might want to dismiss the idea of being a stalker or a violent offender, because YOU would never do it, I promise you this. You will react badly to a poor review. It’s human nature. You’ve worked for hours on something and someone just said your code sucks. It hurts. And while I say this simply, it’s incredibly hard to do what I’m about to tell you…

Learn: Reviews Are Lessons

You have to learn from the reviews. Even the worst review has something you can take from it. If you can put aside your own ego to try and see the world from their side, you can many times take the lessons, apply them to your code, and make everything better. Maybe it’s a fix to code, but more often it’s a documentation issue. There is no 100% perfectly intuitive system out there. Not even life itself. We all had to learn how to use a toilet after all. So what can we learn from reviews?

The Points Don’t Matter; Everything Is Made Up

People concentrate on getting good reviews, on getting five stars. That’s the wrong approach. A five star review is useless for your ongoing improvement of your product and tells you nothing. All you can do is begin a humanization of your code, leaving a reply of ‘thank you’ perhaps, but you can learn little from these.

Context Is Everything: Room For Improvement

The review you want is the one that tells you they mostly like your work, but can see room for improvement, and they leave you suggestions. The review where someone has trouble finding information is another good one. That tells you what your FAQ is lacking, for example. These are people who are probably willing to have a conversation and just need you to begin it. Don’t be afraid to ask “What was it about the cowbell feature that bothered you?” or “I do explain this in the FAQ. Would it have helped you if I put an in-line note?” Engage them and learn from them.

There Will be Anger: To The Pain

The review you don’t want is the one where people are livid. Where they all you names and abuse you. No one wants that, and sometimes you can talk to them and get details, but you’re starting in a disadvantageous position and you have to fight to get answers. If you talk to this person, which I do recommend, be prepared for snarky replies and snide remarks. When you get to the troublemakers who complain they wanted to leave a ZERO star review, you have to be strong and not reply in kind. Sometimes there’s no salvaging the relationship.

A Review Is An Experience, And It’s Not Yours

The trick of all this is to remember that a review is not always a review on how a product worked. It’s also about how someone FEELS when looking at and using your product. A review is THEIR experience with your product, and the users experience with your code doesn’t necessarily start with them using your code. You need to understand who they are, why they feel this way, in order to properly handle their review. The experience begins with how people are introduced to your product, so if that’s an email marketing campaign or a website with a lower-case P, this will impact their experience and thus their review.

Handling A Review… It’s Not Easy

You’re going to get angry. If you’re like me and sometimes, when you’re mad, you feel your face heat up and you literally see red? Walk. Away. Don’t reply. If you cannot reply, in public, politely, DO NOT REPLY. Okay? Shut up, don’t do it. What you do in response to a review will be PUBLIC and you WILL be weighed by it. So don’t shoot yourself in the foot. Once you’re calm, you can process the reviews.

The “Support” Review: “I don’t know how to use it.”

This one drives people nuts. A review that should have been a support ticket, or maybe it could have been solved by looking at the FAQ. While you can’t make them do the right thing, you can offer help in the review. Explain how they should report this next time and try to find a solution. These suck. A lot. I hate them. But they happen everywhere, even Amazon. Try to fix the issue, but don’t give it any more attention than you would a normal support post. Be careful not to let these become the next kind of review…

The “Blackmail” Review: “You don’t have a feature I want.”

This is my least favorite. One star review because a plugin didn’t do something they wanted. It feels unfair, too, because you’re being judged on something you didn’t do and weren’t even planning on doing. It makes me seethe. And there isn’t a fix here. You have to be able to say “no” and not feel guilty, which is hard. Your trick here is remembering it’s okay to not have your code do everything. If your theme changes colors based on photos, it’s okay not to want to support changing for animated gifs. Speaking of reviews of the wrong things…

The “Commercial” Review: “I bought the pro version and it sucks.”

The reviews on WordPress.org should be for your free product on WordPress.org. Sometimes they’re not. If you’re upselling your products from the free version, if you have ads on your plugin and tell people “for more features, use the pro version!” then you’ve opened yourself to the painful review of how that upgrade process goes. The best you can do is offer to help them via official channels, but if someone’s upgrade to your pro version goes poorly, you’re going to get a bad review. You cannot ask people to upgrade and give you money and not expect them to have an opinion.

The “Way Too Angry” Review: [CENSORED]

Oh boy. This one. The review that you read that is insane. You know this one, right? It’s filled with language so foul and so appalling you can hardly process. Don’t reply. Don’t. This person is a lost cause. If you say anything, keep it to “I’m sorry you feel this way” but frankly I wouldn’t.<

The “Mistake” Review: Spam, sockpuppets, wrong plugins, and more!

I actually like these reviews. They’re easy to deal with because all I do is have them deleted. Tag the post ‘modlook’ and then spam or sockpuppet or wrongplugin and walk away. I wish they could all be this way…

Learn: Mistakes Will Happen

The biggest takeaway from this, if you want to distill this entire talk into a tweet, it would be this: Don’t post angry. Don’t attack anyone. Remember we are, all of us, humans. And really, this should be simple for everyone and every thing. This is humanity at work, we can be nice and respectful in the face of adversity, thinks would be be better all around. But maybe that’s the wrong take away. The wrong drive. So let me say this a different way.

Your Business Is Not Code, It’s You

Read that. Your business is not your code, your product, your output. Your business, every business, is people. If you’re replying to the reviews, you are the face of your product, and if you’re here, I’m assuming your company. One or five people, ten or ten hundred, your company is the face and if you’re the face then how you act, in public, will impact your business more than any one-star review ever will.

A Final Thought… Don’t Be The Bad Guy

Let me conclude with another true story. There was a plugin that had a troubling user. The user bought the premium upgrade and was disappointed. Nothing worked right. The plugin developers tried to fix it, but were unable. It was an incompatibility between their plugin and another. The user wanted his money back. The developer argued they’d gone above and beyond the call of duty and were not going to refund as per their policy. The user threatened to leave bad reviews if there was no refund and carried through this threat. The developer capitulated BUT held onto the money and said they would only refund if the reviews were altered. The user said no and things went even more downhill from there.

You Can Say No; Defeat Does Not Mean Loss

This is the hardest lesson of all. It’s okay to say no. It’s okay to walk away. It’s okay to tell someone “I’m sorry, but I can’t help you.” or “I’m sorry, but this is against our policy.” This hurts. It makes you feel inadequate and like you’re a faker. You’re not. It’s mathematically impossible to be perfect, so while you should try to be the best you can, it’s okay to concede to defeat. The trick is understanding that defeat, accepting you cannot help everyone, does NOT mean you lose. It doesn’t kill your plugin or theme or business. It teaches you what you can do better next time.

4 July, 2016
Mailbag: Life Without Contact

It’s not a secret I deleted my contact form back in February. It’s been a few months since, and for the most part it’s been the greatest feeling when it comes to writing for this site.

I do miss the random cool questions people had that would lead to new posts. But that is really it.

The hate mail is a lovely thing to not get. Oh sure people still leave comments in whatever open post they can to tell me off, but those never see the light of day.

Let me just share with you the common sort of hate mail I get. Please note, this is word-for-word what was said. The only part I redacted was exactly what I’d done (and to whom) to deserve this.

You are a real piece of shit. Someone came to you with respect and in good faith to ask you but a simple request […] and you chose to fucking lecture them?

Congrats at showing what an insipid androgynous cunt you are.
You’ve now lost another user

Yeah. Someone thought that was okay to talk like that. Wanna know what brought it on? I was explaining to someone that we do not have the technical capability of deleting forum accounts on WordPress.org, and we’re probably not bound by any UN statutes seeing as everything you post on .org is of your own volition. The tl;dr is “If you don’t want things to be in public, don’t post them in public.”

This guy hid his email … or so he thought. I’m aware of who it is. So are the other forum mods, so if he comes back and acts up on .org, we’re prepared. Following people home and treating them like that is not welcome in any community I’d want to be a part of.

So deleting the comment form? Smartest thing I’ve done in years.

1 July, 2016
Whose Fault Is The Hack?

Your site was hacked.

Welcome to the worst day of your webmastering career. This is worse than the time you accidentally rebooted the server in the middle of processing the largest orders ever. This is worse than the time you cowboy coded something stupid at 1am on your phone from the bar. This is worse than the time you typed rm -rf ./* in the wrong window. This is worse than the time your credit card expired and you put off fixing it in the billing system until your site was down.

Why? It’s worse because you have no idea what the hell just happened, why, or who to blame.

Let me tell you who to blame.

Your Web Software

Oh yes. They are to blame. They left you vulnerable. They made it all sound so super easy and simple that you installed a site and walked away, assuming all was well. They didn’t push those security updates like they promised and they left you ready to be hacked!

Except… Did you update everything promptly? Did you use the code only in the ways it was intended? Did you add on extensions that weren’t vetted by security experts. Did you limit the administrative access to your site to only people who knew how to do things and what was, and was not, safe?

Your Web Host

Can’t forget these idiots, right? They’re supposed to be locking your server down for your own protection and making sure no one can see anything. They take care of everything, like server updates and network upgrades and those zero-day SSL alerts. Clearly they dropped the ball.

Except … Did the OS they’re using actually push the update needed for security? Did they not and now your host had to decide if they fork and support more or they wait and only support the legit things? One is getting you fixed faster, but it’s also making it harder to make sure all security patches are applied. Oh and hey, there are 40 other people on your slice of the network, and one of them has a down-time requirement. And did you remember to only use the secure access to your server? Did you maybe, the one time, turn on FTP (even though they told you not to) and use a clear-texted password?

Yours

Hey you. If you can’t tell… The answer is it’s everyone’s fault.

Of course everyone can do better to make the world more secure, but we have to accept the fact that it’s not ever any one person’s fault. Very few bits of code are written by one person and never looked at. Very few situations are clearcut. We forget to lock the door, we leave a window cracked, we assume and don’t check.

But at the end of the day, the fault for our hacks lies on the person who cares the most when the hacks happen. If your website is your life, if it’s the way you make business and survive, you cannot just take it all on a hope and prayer that you got it right. And if the effort of upkeep and maintenance is too much, you’ll have to compensate with paying for experts who do that.

The fault is ours.

29 June, 2016
Multisite Emails and Redirects
I wrote a plugin that allows people to Join A Multisite on a Per-Site Basis.

There are some things it doesn’t do that I have no intention of adding into the plugin, but people often ask me how to do them. Personally, I think people should always know they’re on a network, and hiding this will only lead to complaints later one, but my way is not the only way.

That said. I am aware of things people try to do that my plugin won’t. All of these snippets should go in a file in mu-plugins. I’d name it multisite-registration.php personally. That way I know what it is right away.

Emails By Site

When you register for a network site, you always get emailed from the network. This means even if I go to halfelf.org to reset my password, the email always comes from ipstenu.org. To change the password reset emails to be from the one where you’ve actually pressed the reset link is pretty easy:
```
add_filter( 'retrieve_password_message', function ($message, $key) {
  	return str_replace(get_site_url(1), get_site_url(), $message);
}, 10, 2);

add_filter( 'retrieve_password_title', function($title) {
	return "[" . wp_specialchars_decode(get_option('blogname'), ENT_QUOTES) . "] Password Reset";
});
```
But when we talk about the activation it’s a little messier. If you’re using my plugin, you can have users sign up on a specific site. You probably want to have new user activations come from that site and if you do, you need to do this:
```
add_filter( 'wpmu_signup_blog_notification_subject', function($subject) {
	return "[" . wp_specialchars_decode(get_option('blogname'), ENT_QUOTES) . "] Activate Your Account";
});

add_filter( 'wpmu_signup_blog_notification_subject', function($subject) {
	return "[" . wp_specialchars_decode(get_option('blogname'), ENT_QUOTES) . "] Activate Your Account";
});
```
That subject can, obviously, be changed.

Redirect Lost Password Pages

So you may have noticed that the lost password page on a network always points to the network and never the site you’re on.

That can actually be fixed by doing this:
```
add_filter( 'lostpassword_url', function ($url, $redirect) {	
	
	$args = array( 'action' => 'lostpassword' );
	
	if ( !empty($redirect) )
		$args['redirect_to'] = $redirect;
	return add_query_arg( $args, site_url('wp-login.php') );
}, 10, 2);

add_filter( 'network_site_url', function($url, $path, $scheme) {
  
  	if (stripos($url, "action=lostpassword") !== false)
		return site_url('wp-login.php?action=lostpassword', $scheme);
  
   	if (stripos($url, "action=resetpass") !== false)
		return site_url('wp-login.php?action=resetpass', $scheme);
  
	return $url;
}, 10, 3 );
```
This simply filters the URL and if you’re on a site’s login page, use that site for the URL.

Redirect Logins to Their Site

This one is messier. If you always want a user to be redirected to ‘their’ site, you have to know what their primary blog is on the network. You can do this, and for the most part, this works:
```
add_filter('login_redirect', function ( $redirect_to, $request_redirect_to, $user ) {
    if ($user->ID != 0) {
        $user_info = get_userdata($user->ID);
        if ($user_info->primary_blog) {
            $primary_url = get_blogaddress_by_id($user_info->primary_blog) . 'wp-admin/';
            if ($primary_url) {
                wp_redirect($primary_url);
                die();
            }
        }
    }
    return $redirect_to;
}, 100, 3);
```
If they don’t have a primary_blog, they’ll be punted to the main for the network, as it should be.
27 June, 2016
Apple Watch UX: Too Small

The biggest issue I have with my watch is the UX to perform an action.

I use the WebMD app to remind me to take my pills every morning. At 7:15 it pings my watch and says to take them. I have to scroll down and tap ‘take’ but it gives me three options: Skip, Take, Dismiss.

This is not the same as the alert they show on their Apple page:

That shows up when you miss the alert and go check what you need to take.

This strikes me as a bit off. The information is too small and the buttons are not as clear as they should be, and I have to scroll down.

So let’s think what does someone want when they get that alert? They either take the pill or not. Or they dismiss the alert. We want them to take the pills, so we should make that button bigger and green. We don’t want them to not, so make that normal and red. As for dismissing, we can swipe the alert down, so you can leave that button off completely and use the built in UX.

When we consider the Human Interface Guidelines of the Watch, I think they’ve aimed too small. While they say to have buttons be “large enough to be tapped easily” and “Create buttons that are easy for the user to tap.” the minimum sizes they provide are shockingly small.

A 42mm Watch has 390px of usable vertical height. 52px (which is the minimum size for the 42mm) is 13.3% of the height. That’s 13mm. Hold on to that number.

There was a study by the MIT Touch Lab which investigated Human Fingertips in the Mechanics of Tactile Sense and they determined the average width of an adult human index finger is 1.6 to 2 cm (16 – 20 mm).

Now Apple’s saying the minimum height is 13mm when the smaller end of average is 16mm. That means if your button is the minimum, most of us will have trouble tapping your button.

I’m not a graphic designer. I call myself a monkey with a crayon. I’m not a UX expert. But I am is a very experienced user and I’m someone who understands how users think. That’s distressingly more rare than you’d think. I understand how a user goes from A to B and gets lost on C.

When I first got my Apple Watch, I struggled. I had a lot of confusion over force touch (something I still find a little difficult to get correct). But I’ve learned the one thing. Those buttons need to be bigger.

These are the buttons for alarms. The one I don’t have is the nightstand mode button but I use my Watch for an alarm and I don’t have a snooze. Sometimes I have trouble tapping the button in the morning, but I don’t think that’s a function of button size. That said… Those buttons could be larger.

The Watch tries to separate functions on the Watch, alerts, by ones you look at and ones you interact with. I think the interactions need to have bigger buttons in order for more meaningful, easier, usability.

Some of this will be addressed in WatchOS 3, which will have us swiping less. But the majority of apps are still trying too hard to cram more information onto small screens. WebMD included. We need to get better about separating information from alerts on our notifications and devices. We need to have everything be easily dismissible with one gesture.

Thankfully we’ll keep iterating and getting better.

24 June, 2016
Multisite And Theme Activation Checks
Earlier this week I talked about how you can’t actually network activate all plugins. As it happens, I have a plugin for a specific theme, and it doesn’t like being Network Activated.

The plugin is Genesis Simple Hooks and, logically, it only works if you have a Genesis theme installed and active.

How It Works

When the plugin is activated it properly runs the following activation hook:
```
register_activation_hook( __FILE__, 'simplehooks_activation' );
/**
 * This function runs on plugin activation. It checks to make sure Genesis
 * or a Genesis child theme is active. If not, it deactivates itself.
 *
 * @since 0.1.0
 */
function simplehooks_activation() {

	if ( ! defined( 'PARENT_THEME_VERSION' ) || ! version_compare( PARENT_THEME_VERSION, '2.1.0', '>=' ) )
		simplehooks_deactivate( '2.1.0', '3.9.2' );

}
```
First this looks to see if there’s no parent theme or if the parent theme version is less than 2.1.0, and if either of those are the case (that is if there’s no parent theme, and the version is less than…) it calls simplehooks_deactivate.
```
/**
 * Deactivate Simple Hooks.
 *
 * This function deactivates Simple Hooks.
 *
 * @since 1.8.0.2
 */
function simplehooks_deactivate( $genesis_version = '2.1.0', $wp_version = '3.9.2' ) {

	deactivate_plugins( plugin_basename( __FILE__ ) );
	wp_die( sprintf( __( 'Sorry, you cannot run Simple Hooks without WordPress %s and <a href="%s">Genesis %s</a>, or greater.', 'genesis-simple-hooks' ), $wp_version, 'http://my.studiopress.com/?download_id=91046d629e74d525b3f2978e404e7ffa', $genesis_version ) );

}
```
And you know what? That sucks. It never checks for Genesis as the parent theme name, based on the assumption that only Genesis themes use the define of PARENT_THEME_VERSION which probably made sense a few years ago, but doesn’t anymore. And more importantly for this explanation, you can’t network activate it because unless you’re lucky enough to be running a Genesis child theme on the main site of your network, it won’t activate.

Worse, it will throw errors on sites that aren’t.

How I’d Fix It

First I made a list of the action/function calls that require a Genesis Child Theme to be active in order to run properly: simplehooks_load_textdomain, simplehooks_init, simplehooks_execute_hooks

Then I moved them all to their own section and wrapped them in a check:
```
if ( simplehooks_can_run() ) {
	add_action( 'plugins_loaded', 'simplehooks_load_textdomain' );
	add_action( 'genesis_init', 'simplehooks_init', 20 );
	add_action( 'genesis_init', 'simplehooks_execute_hooks', 20 );
}
```
What’s simplehooks_can_run? That’s a new function I’ve created to check for the requirements:
```
/**
 * Can Simple Hooks Run
 *
 * This function checks if the requirements for Simple Hooks are met.
 *
 * @since 2.3.0
 */
function simplehooks_can_run() {
	
	global $wp_version;
	$my_theme = wp_get_theme();
	$genesis_theme = wp_get_theme( 'genesis' );

	if ( ( version_compare( $genesis_theme->get( 'Version' ), '2.1.0', '>=' ) && !is_null( $genesis_theme->get( 'Version' ) ) && !empty( $genesis_theme->get( 'Version' ) ) ) && ( $my_theme->get( 'Name' ) == 'Genesis' ||  $my_theme->get( 'Template' ) == 'genesis' ) ) {
		return true;
	}
		
	return false;
	
}
```
What this checks is if the parent theme is 2.1.0 or higher and, if it is, if the theme or it’s parent is named Genesis. By having it use return I don’t have to check if it’s true or false, the if-check is smart enough for me not to do it explicitly.

Finally I changed the if check in simplehooks_activation to look like this:
```
	if ( !is_multisite() && !simplehooks_can_run() )
```
What this isn’t doing is checking for WordPress 3.9.x anymore, as it’s 2016 and that was 2014 and I’m not worried about it. If I was, I’d toss && version_compare( $wp_version, '3.9.2', '>=' ) to the if-check in simplehooks_can_use to CYA.

This also isn’t giving you an error on Multisite. That means if you network activate the plugin and, on Multisite, go to a site that does not have Genesis running, you don’t get an error. This is by design. There’s no point in telling a site-admin “Hey there’s this Genesis thing you can’t have because you’re not using it! NEENER!”

I’m actually using this here on this site. If you’re interested at testing it out, grab it from my Github repo.

Pull requests welcome.
22 June, 2016