Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How It Is

Making philosophy about the why behind technical things.

  • Support Politeness

    Support Politeness

    I had a great time at WordCamp Miami, talking about becoming a WordPress hero and inspiring people to do more in WordPress even when they can’t code. I helped people figure out how to approach their favorite theme shops and plugins and suggest that perhaps they could fix documentation. I networked and met a lot of people who opened their eyes to opportunities. I told them the truth: companies ask me if there are more people like me to help answer questions.

    One of the off the cuff comments I made in my talk was that people think that support is the ‘low end’ of WordPress because that’s how they treat it. What I meant was that I see a lot of people look at support, dismissively, and say “Well that’s a low end job for dumb people who can’t code.” and honestly I want to grab them by their shirt and shout “You’re the dumb person!” I don’t, mostly because that would get me arrested, but also because it won’t help.

    Let me explain by telling you about my flights to and from Miami.

    I live by a tiny airport, and I always have to transfer at either DFW or ORD. I went through DFW on the way to Miami, but I almost didn’t. As we got on the plane, they announced there was a horrible storm and we were all de-planing. No flights were going to DFW. So we all started calling American (my airline of choice) about options, and the crew removed luggage. Then I overheard the gate agent say that if people did not have any checked luggage, including gate-check, they could get them on the next flight to DFW. I rushed over, asked if I could get on the flight, and had a ticket in my hand. I said thank you very much. So did the people behind me.

    When I got to DFW, I found the second half of my flight was canceled, so I went to the gate and asked about it. The gate agent was harried and I told her “You know what, take your time. Do you need me to step back?” She looked at me and asked if I’d mind ‘blocking’ for her, just standing there and acting as if I was being helped, so she could sort out other things. I agreed, and proceeded to say things like “I can’t believe how helpful you are, how dare you be so accommodating!” until she laughed too hard and made me stop. Then she pulled my information up and bumped me to a better seat. As she did so, they told her the plane had been diverted and she asked me not to tell anyone. I thanked her, agreed (though I told my family my flight was delayed), and we watched a tornado pass by.

    Cat on the floor, screaming

    If you can’t tell, I was nice to the people giving me support. I was polite, I treated them with respect, and I made sure to take a moment to tell them I appreciated their work.

    You see, the problem with support is that it’s low end because that’s how you treat it. Certainly, when I call Time Warner and tell them “My DNS tables aren’t refreshing, I can’t get to this domain, how do I refresh them on my modem?” and they ask me “Did you reboot?” I get annoyed. I make sure to tell them, exactly, what I did, I ask them how to do things I’m less familiar with, and I say thank you when they explain things. But when they ignore what I ask to follow their scripts, yes, I get frustrated. I appreciate what they do, but they created a situation where my service is problematic and my experience was sub par because the way they’re told to handle people is to follow a script.

    Let’s go back to airports. Sometimes things happen outside the control of anyone, like weather. When I was at ORD, my flight got grounded due to lightning on the tarmac. And when I say that, I mean we watched lightning hit the tarmac in front of us. It was a microburst storm, so we waited it out, boarded the plane, and then got hit by another storm. This storm was so bad, the whole airport was grounded for 6 hours. I spent four hours getting my flight sorted because all the flights were canceled. Did I get mad? Nope! It was not American’s fault all the flights got canceled, and it wasn’t their fault everyone’s calling to get help. When I finally got a hold of someone, I told her what happened and asked if she could get me home. She said she could get me on the first flight out and I said “Oh my god, I love you!” You see, I’d heard all these other people from my flight get multiple leg trips to our small airport, or not even to ours. And here I got an exit row aisle seat. I thanked her, and went to a gate to get my pass printed. When the gate agent did that, I said thank you for the extra work.

    That’s when something amazing happened. The woman beside me did a double take and said “That’s right! Thank you very much, we do appreciate this!” And people around us suddenly looked sheepish and started muttering thanks. A small angry group became calm and polite. The gate agents told us where we could get pillows and blankets, and when I went there, I also said thank you. The same thing happened. People around me stopped snatching pillows and complaining, and they started being humans again.

    I changed the feeling of support. I made the people helping me feel respected and needed, which they were. I made the people around me remember that these people were providing a service above and beyond the norm. I changed support from being a low-end situation to a valued service.

    When you deal with support, when you have a problem and ask for help, remember that. We know you’re having a terrible day. Take a moment to breath deeply, calm yourself, and thank the people helping you. When you treat support like crap, you get crap support. It’s as simple as that. I’ve been out with WordPress folks and seen them lose their shit on coffee barristas, and I’ve told them “If you treated me like that in the forums, I’d ban you.” It slaps them in the face, because they forget somewhere down the line that humanity is what makes us human.

    If you want more people like me in the support world, and I know you do, you need to start with yourself. Check yourself, treat people how you want to be treated, and when you read what they say, assume the best intentions.

    And say thank you. It will change everything.

  • How to Market Your Blog

    How to Market Your Blog

    I recently had a poll on my ebook store, asking people to vote for what I should write about. Someone suggested this: how to market your blog-best strategies and “no no’s”

    Friends Forever - PeaceFor a while, I looked at the suggestion with Reddit face. I’m not in marketing. I’ve never been in it, I don’t have the foggiest idea how one goes about marketing anything, and I don’t really care to. Why would anyone ask me to write about that? But then again, maybe they’re asking specifically because I don’t normally write about that.

    With that in mind, here’s how I market a blog, and it’s one really simple step:

    Know my audience

    You’ve got to know who you’re writing for if you want to sell it. If I’m going to be blogging about dog food, then I should take the time to learn about how dog enthusiasts act online. What kind of ‘fan’ blogs are there, what kind of official/professional sites are there, what sort of forums. I need to understand who they are, how they act, and what they expect. A blog for tech people will accept different design styles than ones for pre-teen books.

    A side-note to knowing who I’m talking to is knowing what they consider normal. Even if you think the current ‘trends’ on their sites are ugly as sin, you have to aim at them in order to be accepted. Similar but different. People don’t like big changes, and you may find yourself ignored. At the same time, being different is good, you stand out. Find that balance.

    But when I tell people “I know my audience and I write for that” it sounds at once insanely overly simplistic and bloody genius. The fact is that I’m not a marketer, so I don’t ‘market’ my site, I write good content, put it on a theme with good SEO (thank you Carrie Dils for your Utility Theme and StudioPress for Genesis), and the rest magically takes care of itself because what I put into the world isn’t my blog, but myself.

    I said once that Chris Lema doesn’t sell himself, he sells you on yourself. He liked that so much, it’s on his header for his blog redesign. Chris, I suspect, gets what I mean when I say I don’t actually market anything. See, I go out there, I find people who need help, and I help. I spent time without really meaning to building up a rep of being helpful and knowledgable and understanding because I have some skills that were perfect for my audience. Not only do I know them, I am them!

    What’s on this site is essays, how tos, and ebooks. I sell the books based on the attraction from what I do in the world. See, Open Source is weird. We put stuff out there for free, and then people pay us for other things they can’t do themselves. It’s like how I tell my coworkers to ‘sell’ people on our managed hosting. It’s a question of where people want to spend their time. I like playing on the server, my wife doesn’t. If she didn’t have me for hosting, I’d actually tell her to get managed hosting from the start, because it lets her do what she wants to do!

    And that’s what you’re selling. That’s what you market.

    Dog walking another dog on a leashSteve Jobs was right when he said your customers don’t know what features they want. But don’t sell them or market them just because they’re features. Sell them what you are what you use. Tell them the truth. Market by representing what they could be, help them get there, and don’t sell ‘As Seen On WordPress.’

    We build in WordPress things we need. We should market them as that. “I needed this. Here’s how I did it so you don’t have to reinvent the wheel.”

    I’m Mika Epstein, aka Ipstenu. I know things you don’t because I do things you don’t, and I write about them for you to be able to do them even easier and faster. I know what it takes to learn because I learned. I know how to explain it because it’s how I explained to myself. I know who to talk to, because you’re my people.

  • So Your WordPress Upgrade Broke

    So Your WordPress Upgrade Broke

    I’m delving into angry-land here, so hold on to your hat.

    So. You upgraded to WordPress to a major release without testing it first, and broke your site? It’s probably your own fault. Bring on the stones and when you’re done, let’s talk.

    Ready to talk? Okay, you didn’t test. That’s why it’s at least partly your fault. This triples if the next words out of your mouth are “And my WordPress site is my life!” It quadruples if you say “My client sites broke!” It’s infinite if you broke your company site and you happen to be a WordPress based company.

    Picard and Riker (from Star Trek: TNG) facepalm

    But notice how I said probably? I can honestly say that 50% of the time my site breaks, it’s WordPress, not me, but I happen to run trunk without testing, which makes it my fault, not theirs. Seriously. I’m running trunk on a live site, which updates twice a day. I’m a little reckless. My life is WordPress, which makes me in violation of one of my own cardinal rules, but at the same time, the part of WordPress that is my life is supporting it, or breaking it and reporting it. For me, a broken WordPress install is one that needs my love to fix it, and I embrace that role.

    You’re not me. And in fact, neither is my dad or my friends’ sites that I host. For them, I have a couple options: Let them upgrade themselves, upgrade them automatically, upgrade them myself. I use all of those methods, in different situations and with each of those, what happens when they break? I will say this, for everyone but me, if I have a contract to manage their updates, I test the update first. To the fellow who complained he had 200+ sites to test, I say “Well, that’s your job.” You agreed to manage them, you better do it right.

    Telling people “Your site broke because you didn’t test.” isn’t an answer, though. It doesn’t explain why the site broke. The answer to that is a little more simple. “You have code that doesn’t work with the upgrade.”

    And yes, it’s really that simple. You have a plugin, or a theme, or an add-on to your server, that doesn’t like the newest version of WordPress. Now, it’s a struggle to fix one’s site at the same time as placating one’s customers/clients/visitors, because you’re in a race against time. This is why you have to do that usual testing with plugins off and so on. Complain all you want, there’s no way around it. Point out you’re not a coder all you want, that’s actually why this happened to you and not me.

    Tai Chi HeroWhat do I mean? Well I am a coder, so when I install a new plugin I review it first by looking at all the code. You’re not a coder, I hear, but you can still review the plugin by looking at the updates, the author, their contributions to WordPress, the support forums, and the size of the plugin. The larger a plugin, after all, the more chances to go wrong. I also like to check /wp-admin/credits.php and look for the author. If they’re there, the odds of them not knowing that there was a change in WordPress that impacts their code is pretty negligable.

    And this is how it works. It’s the addition of all things, combined to make a good, educated, guess as to the relative safety of your site. Good plugins that you’ve checked on, good themes ditto. Sure everyone can make a mistake, but good code makes fewer, good coders adapt well, and responsive coders react well. That’s the biggest thing. People will make a mistake and break your site, but if you use a theme were the developer is on the spot with patches and generally responds quickly (say, within 5 days), then you can be pretty sure that this developer knows when WordPress is releasing a new build, and that they should test Betas and RCs. That’s what you’re looking for.

    This is especially important if your site breaks on a MINOR upgrade. If your site broke going from 3.8.2 to 3.8.3, and you find out it’s a theme, stop using that theme. That’s really hard, I know. But it’s really serious. A theme or plugin that breaks on the minor updates is doing something really wrong, or is taking advantage of a vulnerability which makes it dangerous to use. That’s it. That’s the reality. Either code is really bad or it’s really unsafe.

    Neither of those things means the developer is a bad person. It just means they did bad code. We have all done bad code. We have all been the cause for bad and dangerous code, and we will all be so again. But again, it’s how we respond that makes us heroes or not.

    Look for the heroes. They stand out. Use their code.

  • Mailbag: I want to make WordPress.com

    Mailbag: I want to make WordPress.com

    Justin is not the only person who’s asked me this one, and it boils down to “How do I run my own wp.com?”

    I wouldn’t. It’s insane, and if you want just an inkling as to how frustrating it is, spend 8 hours a day, for 2 days, doing free support in the WordPress.com forums. That’s going to be your life. If you hate it, don’t do it. And more to the point … I don’t feel we need more generic ‘Anyone can host here.’ sites. The most successful modern one is Medium, which doesn’t give you a site like ‘ipstenu.medium.com’ but instead just share-posts everything. I’m personally not sold on the efficacy of it, but my point is I feel these gateway blogs are less and less necessary, the better we make WordPress software. We’re lowering the bar for people to own their own sites.

    If IF I was going to consider it, I’d be looking at it from the aspect of a small group of people. For example “A network for small town newspapers.” I take care of the servers and code, they just write. That’s a smaller, niche, market, but also one that probably can’t afford VIP WordPress.com. You can always expand, after all.

    But Justin actually has a security concern. Let me share in his own words:

    I want to build a service like wp.com, blogger.com but with free and commercial themes and plugins. Drag and Drop themes (Headway, Ultimatum), plugins (Visual Composer). If my site is feature-loaded, people will come, is’t that right? But I wonder why people don’t use all those nice software to build better than those companies. I want to ask, is it because people can insert malicious codes in css and javascript code editors?

    Yes and no.

    Its not the malicious codes in CSS and JS, though that is a concern. WordPress.com has a CSS editor that you can pay extra for, and the question many people ask is “Why isn’t that free?” The issue isn’t with security, it’s support. Frankly, people who need (note the word ‘need’) a managed site like that generally haven’t a clue what they’re doing in CSS for design. They need those baked and locked themes because they’re not ready for the rest without a conscious choice and a monetary investment. You’re paying more for something, ergo it’s worth more.

    But JavaScript? Well that would be security but also support. I certainly don’t want people messing with JS because it’s easier than CSS to break your site with it. Don’t believe me? Go look at everyone’s whose visual editors broke after upgrading to WordPress 3.9 because of plugins that don’t work well with the new JS settings in TinyMCE. Those are plugins, written presumably by people who know what they’re doing. And they broke.

    Is there a security risk to letting people edit CSS? No.

    Is there a security risk to letting people edit JS? Yes. And worse on Multisite (which is what WordPress.com is running) as that could break the entire network, not just one site. A bad CSS call will only break your own site on the network, after all.

    A lock on a locker

    But I think the question may be “What’s so dangerous about JS anyway?” and the answer there is “Cross Site Scripting” (aka XSS). XSS is a vulnerability that will allow hackers to inject scripts from their computer into your site, which is normally (in WP land) used to bypass the requirement to be logged in, dump garbage into the database, and then log in and create merry havoc on your site. I’ve been told up to 84% of all vulnerabilities in the web are XSS related. This may or may not include CSRF (Cross Site Request Forgery). The XSS article on Wikipedia is pretty good.

    Based on that alone, I would not allow users to make their own javascript edits. I would perhaps provide plugins to allow them to make certain adjustments, but not anything they wanted, any time they wanted. If they need that, then they need to get their own hosting on their own server, so they only blow up themselves.

    Oh and whatever you do, don’t try to become ‘the next…’ anything on your own. That way lies madness. Get some help.

  • Mapping Domains Without a Plugin

    Mapping Domains Without a Plugin

    Recently I wrote WordPress Murder Mystery. The day I released it, I got on a plane to fly to Miami, and proceeded to have a pretty awful travel day, thanks to a storm that pretty much knocked travel to the SouthEast out of commission. While I waited for my flight to DFW, I got pinged. “Hey, I can’t add anything from your store to my cart!”

    I pulled up my laptop and thought about what I’d changed. Oh. I’d turned off domain mapping. But not really.

    Ghost Cookies

    You see, I love the WordPress Domain Mapping plugin. But I’m not using it here. No, I’m actually doing something I expressly and patently tell people not to do … because time has changed with 3.9 and it’s almost okay to do things this way. The change here is that WordPress is smarter now, and it’s safer, and you actually can just edit the home and site URLs in the Network Dashboard. But you know how I said ‘almost’ back there? Your ability to shoot yourself in the foot is directly proportional to how smart you think you are.

    What I did? It’s basic but assumes you already know how to add a domain onto another.

    1. Go to Network Admin -> Sites
    2. Edit the site in question
    3. Change the URL to the mapped domain, check the ‘change home and site URL’ box, and click update

    That was it! Three steps and everything still worked! This also let me force change a site to https all the way, and since I didn’t have content, I didn’t bother with a search/replace. If I had, I’d use that Interconnectit Script or WP-CLI for it. Still, like a wise person, I always get the domain ‘right’ before I add content.

    And at this point, everything seemed to work just fine! And so I left it as is and published my book. And as you know, it all failed, spectacularly. I rolled everything back (because I knew what I’d changed last, see? always remember that!) and it worked again, so I knew I had to have missed something big here. Since I was stuck in an airport with choppy wifi, I disconnected everything and fired up my localhost version of my site. Banging on that for a while, I saw I missed a small, but hugely important factor in the plugin.

    See most of what it does is that pretty interface to say “Pull domain.foo content from site (aka foo.example.com)” and force redirects. It also lets you do cool things like “Allow users to log in from foo.example.com instead of domain.foo” but really I didn’t need any of that. The meat of the code is in the sunrise.php file, which when I studied, I realized was just doing the redirects “Send Site to domain.foo” and for me, by renaming the home and siteURLs, I was already doing that.

    So what had I missed?

    define( 'COOKIE_DOMAIN', $_SERVER[ 'HTTP_HOST' ] );

    That was it. I forgot to tell it “Cookies belong to the domain you’re on.” What this means is that if you log in at example.com, the cookie you get is for example.com and not domain.foo! For the most part, this isn’t a problem since no one logs in but me … until you try to make a purchase and it validates a cookie which doesn’t match the domain. I added that to my wp-config.php (down at the end of my Multisite section, where the SUNRISE define had been earlier) and everything magically worked.

    Two lessons! First, test everything. Second, you can map domains without a plugin, safely.

    I will note that, over time, it’s possible those settings for home and site URL may vanish from display. They’re powerful and dangerous settings, and you should not mess with them without a good backup.

  • Defaults Matter

    Defaults Matter

    We tout decicions and not options. We laud people who make it work, simply and efficiently. So how do we decide what the default decisions should be?

    I was looking at a new plugin for an affiliate program, and it set up the links based on region. The way this plugin worked, if you don’t have an account specifically for that country, the plugin author had it set to use his ID if the user didn’t enter one. This is a small issue, in that the user may, unwittingly, be letting the dev earn money of their site. It’s also just not permitted. You don’t put up links or ads on someone else’s site without them checking a box to allow it, it’s gauche and against the .ORG guidelines.

    Timer settingsWithout knowing the issues of the affiliate app, I pushed back, and was surprised that the plugin dev was doing this because if he didn’t, the code would break. The affiliate program didn’t have a fallback to show a default location if you didn’t have an ID for that area, it just errored out. Thankfully, this developer and I worked out a solution. If there was no ID for the region, the plugin wouldn’t display the affiliate links. There was also a checkbox “Use the developer’s affiliate code in regions where you don’t have one!” that explained this would help feed and clothe the dev.

    Another example. A plugin made a shortcode to play MP3s, and by default if you don’t have an MP3, it played one of him from his domain. Besides the fact that you’ll crash your server if you get popular enough, the fallback for that should be for the shortcode to output “Oh noes! No MP3 picked!”

    This got me thinking about how we determine the defaults for anything. We pick what we want to support most, we guess at what people will use most, and we test what we can think of. But that isn’t easy at all. Start factoring in upgrades. You add a new feature and you want people to use it, so you turn it on to aid discovery (Jetpack does this). Not everyone likes that and gets mad that the first thing they have to do is disable it! So you think about alert boxes “Hey, you upgraded and there’s a new thing!” but then people hate dismissing those alerts.

    Picking the right defaults for your intended audience matters. The affiliate code guy knew about an error if he didn’t do that, and compensated in a way that would be seamless for the users, but a little unethical (I felt) because it took advantage of their ignorance to make money for him. I’m kind of hip on educating the masses. The shortcode guy just didn’t think about the long-term ramifications. Neither actually meant to be harmful, but both were thinking about their users and their familiarity with things. Both were cognizant of the fact that a product not working because of incomplete settings should not break.

    Firetruck SettingsDetermining your default settings is a race between education and simplification. It should be as simple and straightforward as possible to make things easier for the new users. At the same time, it should be made totally obvious in straightforward ways what the defaults can be changed to. This can be done with help screens in your plugins, but also in the welcome pages and the in-line explanations of setup. You can hide aspects of the code from users until they’ve finished pre-requisites.

    Defaults are the one place where you have to actually try to know what the users will be thinking, so don’t worry if you get it wrong. You can always iterate.