Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: essay

  • Permalink Elephants

    Permalink Elephants

    Broken Link The best permalink format for your site is so simple, you’re going to wonder why you never thought of it before. It’s obvious, intuitive, and perfect. In fact, I dare say it’s genius. Want to know what it is?

    The best permalink is the one your visitors can remember.

    I told you it was obvious.

    Look, you can waste immesurable hours and days trying to determine if /postname/ is better than /2012/postname, or you can sit down and remember you’re not making a site for search engines, but for your visitors.

    SEO does have a point, don’t get me wrong. If it’s easy for people to find your site, you get more traffic. One of my sites, following the recent Panda and Penguin updates on Google, jumped from 5th place to 3rd on a search for the major keyword. Another went from 12th to 9th (we’re working on that). None of that has to do with me changing anything, or even picking the best SEO plugin. It was done the traditional way.

    1. I wrote good copy
    2. I networked with related sites for links
    3. I advertised
    4. I was memorable

    Those three things, when done correctly, are how you get your site to rank high. And it’s that last item, being memorable, that should drive your URL choices.

    A URL like http://example.com/12897342134/jkahsdu.aspx isn’t memorable. It tells me nothing of what your site’s about, what the topics are, what the subject is.

    Elephants being adorableOn the other hand, a URL like http://example.com/2011/how-to-save-elephants tells me quite a bit. I know when the post was written, so if there was a big to-do about elephants in 2011, it probably is related. But it’s not always easy to tell someone that URL, nor is it a given I’ll remember it tomorrow. I may remember that example.com had a cool posts about saving elephants,  however. It’s certainly more likely I’ll remember it than the other link!

    This is where WordPress does something cool, though. See, I can tell someone to go to http://example.com/how-to-save-elephants/ and that will redirect them to the right URL! You can do this on Drupal as well with a module called Global Redirect (Drupal folks, correct me if I’m wrong/there’s a better one).

    To me, that says the issue isn’t what permalink pattern you pick, but what permalink slug you use! On that train of thought, what if I made my URL http://example.com/2011/save-elephants instead? Naturally then http://example.com/save-elephants  would also work.

    Now we can clearly see that ultimate issue is not the permalink structure. The only thing I don’t like about how WordPress defaults URLs is that I have to tell people ‘it’s example dot com slash save dash elephants’ and that’s not as easy as ‘example dot com slash elephants.’ Or even ‘saveelephants, all one word’ (I don’t know why that’s easier, but people tell me it is).

    The whole reason people like short URLs is that they’re short and easier to remember. If I told you to get to a site you used http://bit.ly/elephant, you’d have a much higher likelihood of remembering. Invariably, however, we look at branding and think “I don’t want bit.ly to have my name.” That’s a case for Yourls, and now, as long as you customize all your Yourls, you’re in it to win it. I know most people use short URLs for Twitter and such, but I find that making a handy short URL to tell someone ‘go to foo dot in slash facebook’ works astonishingly well. Of course Facebook knows that too, and lets you use http://fb.com/username to find people.(I don’t have a yourls setup here because I’m incapable of finding a short URL I like.)

    Sadly, there is one problem with this, and it’s that you can only use each ‘slug’ once, so once you’ve use ‘elephant’ you’re never able to use it again.

    Name your slugs wisely and plan, as best you can, for the future.

  • WordPress 3.4 – No Problem

    WordPress 3.4 – No Problem

    It’s in beta, don’t nobody panic.

    The last 3 releases of WP, I’ve made troubleshooting posts about what to do, what plugins are going to barf, and so on. This time, there really doesn’t seem as much to worry about. Of course, having said that, everything will die in a fire. Actually, though, I haven’t made a list of things yet, because there’s nothing to list. I’ve not run into any stand out ‘Oh shits!’ and the forums are remarkably quiet. So. If you’ve got stupid problems, or found you have to edit themes/plugins, please reply and let me know! I’ll get on it.

    So here’s some of the cool new stuff:

    Akismet 2.5.6

    Custom Headers and Backgrounds — See also Flexible Headers in 3.4 Themes and Backwards Compatibility for WP 3.4 Headers and Backgrounds

    Twitter was added to oEmbeds — This should just work out of the box, but if you have a plugin (like Blackbird Pie), you may want to disable it before upgrading.

    RPC-XML support for Custom Post-Types.

    Admin Toolbar To The Top! Click on any blank space in the admin bar and you go to the top of the page. (It’s the toolbar, damn it, I know this!)

    Sexier Theme Options. Have you ever wanted to see what the changes did to your theme on the fly? Go to WP Admin > Themes and click on Customize Theme to get a quick way to see what you’re tweaking. Not every option is there, nor will every option be added, but this is pretty nice!
    Theme Options

    You also get that view when you preview a theme.

    Of note, Twenty Twelve and Favicons got punted to 3.5.

    Edited to add…

    Jane Wells has a nice write up of some of the new stuff. It’s on .com, but a lot of this (all) is on 3.4 too. What? You didn’t know .com used the same (mostly) WordPress we do?

  • How To Submit a WordPress Plugin

    How To Submit a WordPress Plugin

    Submit to WordPressI’m not a super-psycho coder. But between being a busybody and being a volunteer plugin referee, I do spend a disproportionate amount of time looking at the code people put in for plugins, which means I actually see a lot more code, and a lot more submissions, than you might expect. This puts me in a place where I actually can offer some of the world’s most basic advice ever, that a surprising number of people seem to miss, about how to submit your plugins, what will get them downcheked, and what you really just shouldn’t do.

    This list is not all encompassing, but touches on the issues I see the most often.

    What You Must Do

    Failing to do the following will likely end up in your plugin being yanked (or not approved at all).

    Read The Guidelines

    We are not pirates. These are not wishy-washy rules, though they are intentionally kept as light as possible. You see, the more you make a rule “You can’t do this!” then the more you get “Well, you said I couldn’t dig to China, not Australia!”(That’s a true story on my part. I once got my kindergarten school class to dig to China. After being told not to, I got them to dig to Australia. At this point, they said ‘No digging tunnels at school.’ My parents explained in more detail why this was dangerous, and we watched The Great Escape to understand tunnel collapse. I forget how Dad explained the distance, but I remember a long explanation about the earth’s core being molten, and no, you can’t dig under the ocean. I was bummed. I was also 4.) The basic guidelines are on the front page of the Developer Center, but it’s the expanded guidelines you really need to read. I helped write those guidelines (over beery emails with Otto) and he and I both hate that we have to spell certain things out, but apparently they’re unclear. Just read them. If you think you’re doing something that might be on the far side of okay, ask around. Tweet, post in the forums, or find a plugin dev you respect and ask them directly.

    Check Licences

    All plugins must be GPL2 (or later) compatible. This is pretty basic, but a lot of people don’t realize what that means. First, there’s the issue of GPL2 versus GPL3. While the WordPress repository accepts GPL3 plugins, it’s still not compatible with everything, so make sure the code you fold into the plugin will work with which ever license you chose. If you don’t want to use GPL, you don’t have to! Remember, there are a lot of GPL Compatible Licences. At the same time, there are a lot of incompatible licences as well. And there are the Non-free Software licenses. When you’re only releasing your own code, this is pretty easy. You pick a compatible license and move on. When you’re incorporating other people’s code, however you have to study their license carefully.

    Generally I’ve seen people get dinged for using the Creative Commons license, and in most cases this is because they’re not using the CC0 license. That is the only CC license that really works with GPL (except for CC BY ND). Your code really shouldn’t be CC licensed, anyway, though. Just don’t use it.

    Provide the code

    World Wide DownloadsWhen you submit your plugin, put in a link to the code so it can be downloaded and checked. (See Expanded Guidelines, Rule #16) If, for some reason, you can’t because the code is behind a paywall, or you don’t want it in the wild, don’t worry! The only people who see that link are the plugin review team, and they’re trustworthy. They don’t need an API key, either, they just want to make sure you’re not breaking the repo guidelines. If you don’t provide a link to the code, you don’t get in. It’s really that simple.

    Don’t break the other WP rules

    Did you know you can’t use ‘wordpress’ in your domain name without permission? If your author or plugin URL is http://mycoolwordpressplugins.com then your plugin will be rejected. (See Expanded Guidelines, Rule #17) In addition, you’re still going to be held subject to the forum rules with your account. I mention this because if you get blocked on the forums for rampant asshattery, you won’t be able to check new code in. Basically remember that it’s the internet, and we can see your behavior on Twitter, Forums, Faceybooky, etc. Don’t be an idiot.

    What You Should Do

    Not doing the following won’t get you punted from the repo, but they’re still good to do, in order to provide the best support possible.

    Write a good readme

    A good readme file is going to tell the person everything they need to know before they download the plugin. This means:

    1. Describe what the plugin does
    2. Explicitly state any and all requirements
    3. Be upfront about any external accounts required (for APIs or what have you)
    4. Inform users if their information is being sent to another site, where, and why (not necessarily technical explanations, just ‘Your IP, browser specs, etc will be sent to Google for Analytics purposes. This is required if you want to use Google Analytics.’)
    5. Include screenshots of the options
    6. Include a screenshot of what the plugin looks like on the unmodified default theme
    7. Document if no support is provided (or if support is handled somewhere other than the WordPress forums)

    Credit Appropriately

    Thank YouA subset of that is that if your plugin is a fork of someone else’s, be the good person and credit them! It’s not required all the time, but take a look at the copyright information on a plugin. Sometimes they say they require credit in the code. If so, you’ve got to do it. Even just a line that says “Copyright 2009-2011 Some Other Dude” and then “Copyright 2011 Me” below it. That’s a nice CYA. If you want to be really nice, put their userID under ‘contributors’ in the readme file, and they’ll have their pretty face on your plugin.

    Write Good Code

    Using good code is complicated. I don’t pretend to be the best at it myself (seriously, the level of shenanigans I went through over nonces cannot be measured on a human scale). But I know that good code is secure code. I know I should use nonces in certain situations, I know to protect against SQL injections, and I know to not let total strangers upload executable files (so they can’t upload a PHP file that wipes my DB, for example). And I know when to go find Otto, WePay him a beer, and say “So what the hell did I do wrong, here?”

    Writing good code is exceptionally complicated, which is why, if you’re going to write a large plugin, you need to know what you’re getting into. The problem a lot of people get into is the classic ‘Your eyes are bigger than your stomach.’ When you write a plugin, keep it simple. Start with the code you know, slowly fold in the new stuff. Try to test as many different ways as you can think of, but know that you’re going to miss something.

    What To Do If Your Plugin Is Yanked?

    Every plugin developer’s worst nightmare is waking up to find that their plugin was yanked from the WordPress repository.

    Don’t panic!

    Don't Panic This happens when your plugin has been reported as possibly being in conflict with the developer guidelines, or it has a security hole. Many times you will not be notified when this happens. Sometimes you’re not notified because the report is found to be incorrect, and sometimes it’s because you’ve been warned before. And, once in a while, it’s because the person who closed your plugin doesn’t have the ability to email you. Surprise! There are some people on the plugin repository team who don’t have the access to the plugins email system, so when they close your plugin, they’ll ask someone else to email you. If that person is busy, it might take a while.

    When a plugin is closed, the rest of your plugins are usually checked over to make sure they’re not also having an issue. For example, if you have one plugin with a front facing link that’s turned on by default, all your plugins will be checked for that and, if they all have the same problem, they will all be yanked. This is why you need to keep up to date on the plugin guidelines, and follow the WordPress Development Blog.

    As soon as you find out your plugin is closed, email plugins@wordpress.org and ask what you can do to restore it. Posting in the forums won’t help much.

  • Lesson #1373 – Learning

    Lesson #1373 – Learning

    All the help I give on all the forums and various places works using this maze. I can tell you, but then you won’t learn anything.

    Lesson #1373 - Learning (Surviving The World)

    There’s more than one path to knowledge; it’s not always the same knowledge once you get there, either. But if you think it was easy to get there, you’re not at the destination you think you’re at.

    Credit: Surviving the World

  • Making a Stand Alone SQL Account

    Making a Stand Alone SQL Account

    One of the ways to secure your web apps is to limit the damage they can cause. When you create a database for a webapp, you have to provide a user ID and password to connect to the database, logically enough. Illogically, most people just use the same username and password they use to SSH into their server. After all, it works.

    The obvious problem with this is that if someone gets access to your files (via a security hole in your webapp or your webhost), they now know your server password and ID, and can get in and cause serious damage.

    But what if instead of using that normal ID and password, you made a special one that only was used for SQL. You couldn’t log in with it, you couldn’t FTP or anything except play with SQL. Then, even if they got in, they couldn’t delete your files! That’s really simple.

    cPanel

    If you’re using cPanel, just go in to the MySQL Databases screen and add a new user. I like to use something totally obvious, so I can remember it, like ipstenu_sql.

    MySQL - Add New User

    For those passwords, I tend to use the generator to make something like m}+akwQN=&)!, not because I feel they’re more secure (I prefer pass-phrases, like ‘donkeyvanillatapdance’), but as a reminder for me not to use it for anything but SQL. Hang on to the password right now, though, you’ll want it in a minute.

    Then you add the user to the databases. Back on the main MySQL page, there’s a little selection to Add User to Database which is really obvious to use. Pick your user and your database.

    Clicking Add will take you to the privileges screen:

    Manage User Privileges

    Give the user ALL privileges, as you may need this later on.

    Plesk

    It’s just as easy in Plesk. Once your new database was created you, were automatically brought to the area to create the New Database User. If you didn’t do that, it’s okay, just go back the main database page and find the datase you want to add the user to (in this case, it’s LovePlesk_NewDatabase).  Click on the Add New Database User icon, fill in the information (remember to save your password!), and click okay.

    Plesk should automatically grant the user ALL privileges.

    Updating Your WebApp

    Once you have the new user made, all you have to do is edit your config file (i.e. wp-config.php for WordPress) to use the user and password, and hit save.

    Now you’ve made your install a little more secure.

  • WHOIS Tells All

    WHOIS Tells All

    WHOIS?This most often comes up when someone is suffering content theft. Invariably, someone will see their hard written prose on some scammy person’s site, and want it taken down. This is, sadly, harder to do than we’d like. Basically you have to find the site owner, contact them, ask them to take the stuff down, hope they do it, and when they don’t, go up to their webhost. I’m not going to get into the copyright issue, and just assume you know not to attack someone over links to your site (not illegal), rss feeds pulling excerpts from your site (ditto), or quotes (really?). If you don’t know what is and isn’t copyright/content theft, then you’re not ready for this yet.

    Assuming you are, how do we do find out who owns a site?

    First, remember that when you see “Powered by WordPress” in a footer of a site, it is not, in fact, hosted by WordPress. This site says “Powered by WordPress” but it’s hosted by Liquidweb. Now if you see “Blog at WordPress.com”, then yes, it’s hosted by WordPress, and you can easily report the site. The same is true of Blogger, who also has a way to report copyright theft. Many of these ‘hive’ hosts do that.

    LiquidWeb doesn’t, though. So, pretending for a moment that I’m a dirty thief, how do you find out who I am, my email, and get your content removed? And when I don’t answer, where do you go next?

    Start With WHOIS

    Your first tool is called ‘WHOIS’ and does exactly what it sounds like. It tells you ‘who is that.’ Network Solutions has a free whois lookup tool and if you were to search for Halfelf.org you’d get the following:

    Registrant ID:bf39ab1b08df1394
    Registrant Name:WhoisGuard Protected
    Registrant Organization:WhoisGuard
    Registrant Street1:11400 W. Olympic Blvd. Suite 200
    Registrant City:Los Angeles
    Registrant State/Province:CA
    Registrant Postal Code:90064
    Registrant Country:US
    Registrant Phone:+1.6613102107
    Registrant FAX:+1.6613102107
    Registrant Email:28a9f8aa493149b1a58ff9b4c51e0bcd.protect@whoisguard.com
    

    It goes on and on, but you may notice none of that is actually … me. That’s because I pay a wee bit extra a year for my host to hide my personal information via whoisguard. I do it becuase I had some idiot track me down to call me about how I wasn’t updating my website enough (a different site), and I now have a restraining order against him.(This is a true story, and yes, he called my house. I no longer have that number for a reason, and frankly if you even think about doing that to someone, get a grip! It’s harassment. For the full story, buy me a drink.) Now that said, the last line I listed is Registrant Email and that email actually works! It’s a real email that will forward messages to me.

    So step one with these things is email that address and hope the person answers. But when a week goes by with no reply, what next? Sadly, some people never check those emails, or they think you are spam, and ignore it. Thankfully, WHOIS will still save you! Scroll down to the name server entries!

    Your nameservers are what translate your domain to the server IP address, and, as a rule, they have to point to where your server really lives. Generally speaking, a nameserver will give away either the registrar (i.e. who you registered your domain with) or the webhost (who you host with).

    Mine are:

    Name Server:NS1.IPSTENU.ORG
    Name Server:NS2.IPSTENU.ORG
    

    Doesn’t really help, does it? I mean, that just says ‘ipstenu hosts ipstenu!’ Here’s what I used to have:

    Name Server:NS1.LIQUIDWEB.COM
    Name Server:NS2.LIQUIDWEB.COM

    That would have been much more explanatory. Thankfully you can use Who Is Hosting This? and run a search for any domain (like http://www.whoishostingthis.com/halfelf.org), even if they have their own name server, and you get this:

    Well thank goodness we have some information! Look up LiquidWeb, and you can contact them. “Hey, this evil Half Elf is stealing my stuff!”

    I prefer Who Is Hosting This to ‘Who Hosts’ becuase if you look me up on the latter, you get this:

    Not useful (though accurate). If you keep getting nested domains, you have to keep digging until you find the end of the rabbit hole.

    Really the best thing is always going to be whois, and once you get used to looking at it, it’s really not that scary. At the same time, I strongly suggest people invest in Whois Guard, or some other ‘protection’ to stop annoying people from getting their personal information. You don’t need the hassle of being listed in a phonebook.