Half-Elf on Tech

Thoughts From a Professional Lesbian

Year: 2012

  • Yourls

    Yourls

    For a long time I’ve wanted short URLs for one of my sites. Finally I figured out a short URL, picked up the domain, and said “It would be great if I could redirect posts with this! But how?”

    As it turned out, I was making a mental mountain out of a miniature molehill. I do that sometimes, get all caught up in a non-meaningful detail. This was easy, it wasn’t super complicated, and it was fast. On the scale of things where WordPress is the easiest (1) and MediaWiki is the hardest (8), this landed next to Zenphoto (4) and was about the same (3 or 4, depending on your skills). It requires more RTFM than WordPress, and I had to do some things manually.

    Setting Up Your Domain

    First buy the domain. This part is obvious, I hope. Since I’m on cPanel, I added my new domain as an addon domain to the master. This let me have the short domain (do4.us let’s say) hosted off the main domain.com site, without making a separate account. If I’d wanted to map a domain, I would have parked instead of addon-ing.

    To add an addon domain in cPanel:

    1. Enter the domain for the new addon domain into the New Domain Name field.
    2. Enter the main FTP username for the addon domain in the Subdomain/Ftp Username field. You can use the one you use for the mani account if you want.
    3. In the Document Root field, enter the directory that will contain the addon domain’s files.
    4. Enter the password for the addon domain into the Password field.
      • Make sure you use a secure password.
      • You can have cPanel generate a secure pasword for you using the Generate Password feature.
    5. Confirm the password in the Password (Again) field.
    6. Click Add Domain
    7. To add files to the addon domain’s home directory, click the File Manager link, or use FTP/SSH like normal people.

    Once I did that, and DNS propagated, I was ready to go.

    Installing the App

    I decided to use Yourls for this, since my friends use it, and I know (in that internet way) the guys behind it. Hi, Ozh.

    That said, their install doc was screwed up. For 1.5, it says to edit a file that apparently isn’t included in the build. That’s okay, since I just used SVN anyway. The directions are very much geeky. This is not a simple WordPress install.

    What I did was first make a database domain_yourls and added my DB user account to it (I never use my domain FTP account). Then I ran an SVN checkout from googlecode to grab the files into the root of my add-on domain: svn checkout http://yourls.googlecode.com/svn/trunk/ .

    After that, it’s the manual editing of the config file (the sample of which is not included in the 1.5 zip) and then I went to myurls.com/admin/ to finish setup. I had to grab the .htaccess file sample, since mine didn’t copy down (my own fault there).

    Configuring the App

    Install the YOURLS: WordPress to Twitter plugin. Even if you don’t plan on using the auto-tweet function, this is the easiest way to get your URLs made. The “hard part” here is setting up a Twitter ‘app’ for the first time. If you’ve done it before, it’s not terribly hard, but with all new things, it’s scary. Ozh’s directions are painless, thankfully, and then … you’re done. And you have your own Short URLS!

    What’s Missing?

    Two things, and neither are YOURLS fault!

    1) Twitter doesn’t know that three different URLs (domain.com/postname, domain.com/?p=2 and do4.us/2 for example) are all the same URL. That means if you use those Twitter Rewteet buttons on posts, it doesn’t show up the same way, and the ‘count’ is off.

    2) There isn’t an easy way to tell Jetpack to use my short URLs instead of my site’s full one. Edited to add: By this I mean only in the ShareDaddy links. Like the ‘tweet/email/facebook’ ones. Actual shortlinks work perfectly.

    I suppose a third is ‘Damn it, Twitter, stop shortening a short URL!’ but that’s a different rant.

    Should you do this?

    I think so, but then again, I’m weird.

    Read Also…

    Otto – Using YOURLS with WordPress

    Rev. Voodoo – How I Set up Vudu.me URL Shortener With Yourls

  • Why You Shouldn’t Use Plugins

    Why You Shouldn’t Use Plugins

    These are words I never like hearing: “I want to change WordPress functionality, without a plugin.”

    At first, when I started using WordPress, I would say that myself sometimes. WordPress should have everything! Why do I have to use a plugin to use footnotes? Why do I need a plugin for fighting spam!? Why can’t I have everything I want and need all in one!

    Flash forward many years and my answer is “Because the world’s largest Swiss Army Knife is unusable.”

    85 options and when I look at it, I can’t fathom how I’d use it to do the things I need a Swiss Army Knife for. I do own one (two actually) and they’re both the perfect, simple, classic models. Heck, the one I pulled a picture of here has more gizmos! Mine has two knife blades, two screwdrivers, a toothpick and tweezers. That’s it. No extra bells and whistles, and I don’t need them. That little tool is 100% what I need for the moments I need a Swiss Army Knife, and has gotten me into locked buildings, fixed a car, pulled a thorn from my dog’s paw, and a hundred other little things.

    So when I hear people say “I want to do XYZ without a plugin…” I can’t help but think they’re looking at the whole process wrong, and I ask them “Why?” People have some pretty amazing excuses for why they can’t use a plugin, but I stick with my beliefs that no tool is all-in-one, and the more I hard code customizations, the harder it will be for me to upgrade them later.

    A plugin isn’t ‘core’ so it’s less reliable.

    People have this odd idea that ‘core’ makes something better. It’s actually not true. A good part of the design in WordPress was done so people could hook and action into it, making changes and tweaking things. So if you trust that core is ‘reliable’ then you trust those hooks are as well. And if you’re trusting the hook, you’re trusting the plugin. I think what the real fear is, is this:

    A plugin author might vanish.

    There are a lot of WordPress devs who vanish. Some even work on core. But yes, a plugin author could take a walk and you’d never see them again. This is ‘dangerous’ if you think of WordPress plugins like you think of, say, software vendors. You shouldn’t. Let’s look at HP’s tablets. No one has any idea what’s going to happen with them, if there will be more software, hardware or any support at all in the future. But HP is a proven, reliable company! And what about the Zune? Every vendor makes mistakes with products, and a freelance plugin dev is no better or worse than a major company at the end of the day. A real company might close it’s doors without warning, too! Maybe what people are saying is this:

    There’s no one to sue.

    Why this is a sticking point… The non corporate version of this is actually “For my protection!” But much like the point above, having someone to sue isn’t a magic solution. It’s not a promise that your vendor won’t wander off into Chapter 11, and leave you hanging. Go ask around, everyone’s had that problem with a pay-for program, and worse, one that left you with no one to sue. People are too sue-happy in my opinion, but I can’t fight that one. I do ask why they think they’d need to sue, and I get told this:

    A plugin is less secure.

    I’d like to know when the last time was you did a security audit on WordPress. Look, I’m not saying plugins don’t have the potential to be insecure, but if you’re performing your own due-diligence, and security is your bugaboo, then you should be testing WordPress core, your theme and all plugins with equal scrutiny! We perform audits on all vended software. Every year we have ‘hack it day!’ where we actively try to break into our products (in a non-live environment) to verify it’s as secure as we can make it.

    So if you have a plugin you really want, you should be reviewing the source code. And that’s where open-source code takes the prize. I can open up a plugin, and if I see base64(), or get() calls to things I don’t recognize, I know the plugin’s possibly insecure. I may even email plugins@wordpress.org and let them know about the bad behavior (base64() isn’t allowed at all). But none of that gives me a feeling, like so many other people, of this:

    A plugin is less reliable.

    Than… what? Seriously, I’ve heard this a hundred times. You’re saying “Someone else’s code isn’t as reliable!” but I’ve never had anyone explain how the code total strangers wrote in core is more or less reliable than the code in a plugin. And what about the plugins written by core devs? Are they incapable of problems? Tell that to the bugs that slipped into Jetpack. Nothing is perfect.

    Now, there are checks and balances on core that don’t exist on a plugin. Core changes are tested by hundreds of people (you’re testing it right now, visiting this site, which runs on the latest bleeding edge).  With all those testers, it’s still possible for major bugs to slip through (like json conflicts, sorry, Nacin). Which is probably why people say things like this:

    If I edit my site myself, the code will be there forever.

    Don't Edit CoreThat one amuses me a lot, actually. A friend of mine blogged about this recently and pointed out that life ‘without a plugin’ is dangerous. If you edit your site yourself, you have two places to do this.

    1. You edit core
    2. You edit your functions.php

    If you edit core, after you’ve killed a kitten, you’ve locked yourself into manually updating WordPress forever and ever. You can’t use the auto-upgrade, you have to read and re-read every code change to make sure it’s not on your file, and you have to pray nothing else was changed to make your hack invalid. How is that different from a plugin? Even a deprecated function used in a plugin will still work.

    As for your functions.php … maybe you don’t know this, but the difference between a functions.php change and a plugin is where you put it. Put it in functions.php and now you’re locked into that theme. Which is actually a problem I have with Custom Post-Types right now. If I want to switch themes, there are things I have to remember to bring with me. Hassle. There are plugins, thankfully, that can cover that for me, and I’m glad for them.

    Just use the damn plugin!

    Well okay, then. Are there reasons when a plugin’s a bad idea? Sure! Brian nailed it in one:

    If the plugin is making it snow on your site, I’d consider it unneeded. But I don’t advocate the use of fewer plugins just to use fewer. I do it because I think everything should have a purpose. If there’s no good reason to use a plugin, don’t use it. If it’s redundant, don’t use it.

    What else? Oh, Joey says:

    And that’s another excellent reason. If you want to learn to code, you don’t use a plugin. Or if you’re like me, you ‘fix’ it.

    Excuses, excuses

    What are the best ‘worst’ reasons you’ve heard for why a plugin shouldn’t be used? Here’s what my tweeple said (and my slightly sarcastic replies):

    Clearly they’re unclear on the concept. Functions are great for small, quick changes, but they’re tied to your theme! A plugin is forever.

    https://twitter.com/#!/TJList/status/153654497380540416

    So will adding the code manually.

    https://twitter.com/#!/sabreuse/status/153664752810336256

    I couldn’t even dignify that with an answer.

    http://twitter.com/sabreuse/status/153664914278453248

    If everything was ‘in core’ it would be 600megs and no one would use it.

    Let’s hear your best ones!