Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How To

  • Is It My Server or My Theme?

    This could go on any of my sites, but since the conversation started on the DreamHost forums, I thought I’d tackle it here.

    When your site is running slow, it’s easy to pick on the webhost or the server you’re on, saying that’s the problem, and demanding someone else fix it. The truth is that speed involves a lot more variables than just the webhost. Sure, if your host is slow (or down), you’re stuck waiting on us, but there are a couple really easy ways to determine where the slowness is, and you might be surprised.

    If you’re using a CMS like WordPress or Drupal, take a look at how long a page takes to load the first time, and then again on a refresh. When you look at these pages, they’re in PHP and take a little time to process. The more complex your code, the longer it can take to display. This won’t really impact a refresh, but it’s a good idea to see if your browser is caching anything. If the site is really slow, go look at a static HTML or TXT page. On WordPress, look at http://yourdomain.com/readme.html and see how fast that loads. If that’s slow, hey! It is your server! Open up a ticket with us and tell us that the site is slow to load static pages. It’s really important that you tell us what you’ve done, so we don’t have to waste time re-doing it all for you.

    But most of the time you’ll see the html loads really fast. Why is that? It’s that pesky PHP taking a while to render. Now I know this brings up the obvious question of why would we use PHP if it takes longer to load, and the answer is complicated. There are a lot of benefits to using PHP (like being able to use those cool CMS’s to make publishing your site easier), and I’m not going to go into them. Just know that if you choose to use a modern CMS, then you’re likely going to be using PHP to render your site.

    That means we have to consider how to make our PHP run faster. If you’re on shared hosting, the server side work should have been done for you, and if things are still slow then you have to consider the painful option that you did this to yourself. Don’t worry! That’s not a terrible thing, you probably just picked a theme, or a plugin, that is totally perfect for you, but a little slow. This is why people say ‘too many plugins/extensions slow your site.’ It’s not true, but the idea is that the wrong one will slow you down. And that is certainly true.

    Go to Google PageSpeed Insights and check your site out. It should give you a hint as to what’s lacking. Don’t take this as the holy grail, though. Sometimes Google has really dumb advice, like ‘You should compress the code you’re using from google.com!’ Really? So why don’t you compress it, or tell me ‘Use this code instead from us! It’s already compressed!’ In theory, all of Google’s jquery code has a compressed version, but that’s not what most people see, so telling us to use it but not how is pretty idiotic, in my opinion.

    I always tell people to look into minifying their output. That means you use a tool to make your HTML all mashed up together when someone looks at your source code. This simple step has amazing results for most sites. It took my Google Speed score from 71 to 81. Any score above 75 is a ‘good’ score from my experience (Microsoft gets a 77, after all, and while Google gets a 99, their main page is pretty minimalistic).

    The point to all this is that your pagespeed is dependent on more than just how fast DreamHost is running. If you tell me that your site is slow, the first thing I do is look at a static page (I may even make one for you if I can’t find one). From there, maybe I’ll poke at the server, but most of the time it’s been your site’s configuration. I say this from a place of over 15 years of self-hosting: I’m nearly always the cause of my own problems.

    Of course, if it’s your WordPress site being a slug, start with caching plugins and feel free to ask us for advice. If you have a wild and wooly, never been seen before, WP problem, don’t be surprised to see me showing up in your ticket.

  • Instagram oEmbed

    Instagram oEmbed

    This isn’t hard, so it’s just a nice example of how to handle instagram.

    wp_oembed_add_provider('#http://(www\.)?instagram\.com/.*#i', 'http://api.instagram.com/oembed?url=', true);

    Per usual, I have a file called oembeds.php in my mu-plugins folder, where I toss all these. This will work with and without www in the URL. I will warn you, Instagram’s embed is ugly! Here’s http://instagram.com/p/QU1OfbHBTe/

    http://instagram.com/p/QU1OfbHBTe/

    See? No formatting, nothing to tell you it’s bloody Instagram.

    Meanwhile, here’s the tweet it came from:

    Much nicer, eh? Of course, Instagram is weird, in that they don’t let you browse images.

  • Command Line Mac Trash Tricks

    Command Line Mac Trash Tricks

    RM TrashWarning! I’m going to talk about the ‘rm’ command which is a super-deadly command in the linux world. No matter what, never ever ever consider running it unless you’re certain you know what it does!

    I review a lot of plugins, which means I download them all to my laptop, review all the code, possibly install them, and then delete. This means, on any given week, I have 5000 items in my trash. And this is without unzipping! (Yes, we get a lot of plugins, and TextWrangler lets me review most of them in their zips.)

    When I forget to empty my trash every day, I end up waiting hours for the GUI empty to run unless I use rm -rf from inside the ~/.Trash/ folder. The real command is this:

    $ rm -rf ~/.Trash/*

    I like this because it’s crazy fast compared to the GUI, and

    But sometimes I actually just want to commandline my trash. I’ll be banging on things in Terminal and a very simple ’empty trash’ command would be nice, right? OSX Trash lets me type trash -l to see what’s in my trash, and trash -e to run the normal empty command. It’s better than a lot of other scripts, because if I type trash filename and there’s already a file with that name in the trash, it behaves like Mac Norm. That is, it’ll rename my second file ‘filename date’ and I won’t have file conflicts!

    The only thing it’s missing is a ‘trash -p’ command, which would let me run the force rm and just dump it all. Yes, I know rm works, but if you’ve ever typed it in the wrong window, you know why it’s a terrifying command. Still, back to the age old rm commands, what happens when you have that annoying locked file error? Like me, you probably kvetch about quitting everything to delete.

    More command line magic!

    $ cd ~/.Trash
$ chflags -R nouchg *
$ rm -rf *

    Finally, to make this full circle, I made a dead simple alias to prevent me from fat fingering the rm too much:

    alias trashdump='rm -rf ~/.Trash/*'

    Fast, efficient, and potentially deadly, but less than manually typing it in all the time. Deleted 2000 files in seconds, versus minutes.

  • Passwordless SSH

    Passwordless SSH

    I’m incurably lazy, and as we all know, lazy techs like to automate (ltla?).

    I ssh a lot into my personal servers, and I get tired of having to type ssh account@server.com, and then enter my password. So I got smart.

    iTerm ProfilesSince I’m on a Mac, the first thing I did was grab iTerm2. This lets me create simple profiles so with a click, I can log in to any of my servers. When I was using Windows, I used PuTTY and the add-on for Connection Manager.(The real PuTTY CM site is gone, and binarysludge just keeps a copy on hand for the same reasons I do. You never know when you need it. Mine’s in my Dropbox storage.)

    What I really loved about PuTTY CM was that I could fill the pref file with my accounts and passwords, and then one-click connect to any of my servers. This was as The Bank Job, where I had a couple hundred servers to do this with, and when I had to change my password, I could search/replace that file. I know, it’s not secure. At DreamHost, I had the same, but they scripted it so I can sudo in with a handy call that I’m in love with. As long as I remember my password, I’m fine. But see, I told you, I’m horribly lazy and I hate having to log in with my password, then sudo again with my password.

    The first step for this is to make an rsa key pair. This is a fancy way of telling both computers to trust each other, so on your personal computer (we’re assuming linux here), go to your home folder and type this:

    [Laptop] $ ssh-keygen -t rsa

    You’ll be presented with a series of informative notes and questions. Accept all the defaults, and keep your passphrase empty.

    Generating public/private rsa key pair.
Enter file in which to save the key (/home/ipstenu/.ssh/id_rsa): 
Created directory '/home/ipstenu/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/ipstenu/.ssh/id_rsa.
Your public key has been saved in /home/ipstenu/.ssh/id_rsa.pub.
The key fingerprint is:
3e:4f:05:79:3a:9f:96:7c:3b:ad:e9:58:37:bc:37:e4 ipstenu@[Laptop]

    This saves your public ‘key’ in the .ssh folder (yes, it’s a folder)

    Now we have to setup the server (halfelf.org for example):

    [Laptop] $ ssh myaccount@halfelf.org mkdir -p .ssh
myaccount@halfelf.org's password:

    This will SSH into halfelf as ‘myaccount’ and create a folder called .ssh. You only need to do this once, so after you set up the key for one computer, you can skip this the next time.

    Finally we’re going to append the public key from my laptop over to HalfElf, so it trusts me:

    [Laptop] $ cat .ssh/id_rsa.pub | ssh myaccount@halfelf.org 'cat >> .ssh/authorized_keys'
myaccount@halfelf.org's password:

    The reason we’re appending is so that if I decide I want to add my Work Laptop, I can just make the key, and then repeat that last command and it will add it to the bottom, trusting both.

    There’s a caveat here, which caught me last week. I set everything up for my new server, ElfTest, and then moved the server to a VPS. The IP changed, so the trusted key was invalid. You see, every time you connect to a server for the first time, it asks you to trust it. If anything in that fingerprint changes, you have to re-trust. This is annoying:

    The authenticity of host 'elftest.net (111.222.333.444)' can't be established.
RSA key fingerprint is f3:cf:58:ae:71:0b:c8:04:6f:34:a3:b2:e4:1e:0c:8b.
Are you sure you want to continue connecting (yes/no)?

    After you respond “yes” the host gets stored in ~/.ssh/known_hosts and you won’t get prompted the next time you connect. When it became invalid, I had to go edit that file and delete the entry for elftest (it’s partly human readable, so it wasn’t too bad).

    If you hate this as much as I do, and you feel you’re immune to man-in-the-middle attacks, there’s a nifty command:

    ssh -o "StrictHostKeyChecking no" user@host

    This turns off the key check. Generally speaking? Don’t do this. I’ve actually only done it once. (This was at the bank, where I was behind so many firewalls, if you’d gotten to my computer, I was in trouble anyway.)

  • WordPress Multisite Subdomains Without Wildcards

    The easiest way to run a Multisite network with subdomains is to use wildcard subdomains, because they’ll automagically map anything.yourdomain.com to yourdomain.com and WordPress will in turn translate that for you.

    When you’re on shared hosting, you can’t do that. But don’t worry! If you’re willing to do it manually, every time you have a new subdomain, you can still have subdomains! This is really easy, if weird.

    Go to manage domains on your Panel and click on ‘Add New Domain / Sub-Domain’

    Add your subdomain as ‘mysub.yourdomain.com’ and check the box to remove www (it’s a subdomain, you don’t need it, and it causes weird issues with some plugins).

    Set the Web Directory to where you have your main domain installed (normally this will be /home/username/yourdomain.com ) – yes, I really mean exactly the same. This is what wildcards do for you, but since you don’t have it, you need to do this. It should look like this:

    That’s it! Now you just scroll down and press Fully Host This Domain and wait till it’s provisioned. Once that’s done, you can go to mysub.yourdomain.com and it will take you to yourdomain.com! Add in a subdomain within WordPress called ‘mysub’ and everything will work exactly like it should.

  • Command Line WP

    Command Line WP

    In my new job, there’s a lot of command line work to be done. DreamHost has a mess of scripts I’m getting my comfort with, but also they’ve got this cool thing implemented on a lot of their servers called wp-cli, and that’s what I’m going to talk about today.

    wp-cli is a command line interface to do a lot of sneaky snazzy WP things. While most people are running towards the GUI world of pretty UI and clicks, some of us really like command lines because they’re fast. I mean, I wrote my own command line upgrader just because I wanted to (and was having PHP permissions woes at the time). Command line is just something server people are always going to like, much like people who love driving a stick-shift, or who want to hand-make their own dough for pies. We like to have that extra level on control.

    Aside from being control freaks, however, we CLI jockeys are also insanely lazy. If we can get everything done without having to touch the mouse, or lift our hands from the keyboard, we’re happy. If we can automate things so that all the WordPress installs on a server are magically upgraded in one fell swoop, we’re ecstatic. We all dream of being that guy who walks into a room, presses three keys, and saves the day. (I’ve been that guy, but remember he comes at a cost. I’ve also been the guy who presses three keys and reboots the money trading servers in the middle of our busiest time. Read twice, press enter once.)

    Where wp-cli takes off is in the speed you can perform basic tasks. Typing wp or wp help will get you a list of commands. If you try to run any command outside the WP folders, you’ll get a nice error message. Using Multisite, you have a cool advantage of installing a plugin once and updating it for all your sites. But in cases where you need to have things separated, wp-cli fills the void by letting you script updates. Imagine just writing a simple shell script to upgrade your plugins on all sites?

    Some of you perked up. There are a lot of cases where you don’t want to run Multisite (separate users, special code, whatever), and updating multiple sites under those custom installs really can be a pill. wp core update can be easily scripted to run off a list of your installs, or to just trawl through your directories, look for WP, and update when it’s there.

    Installing

    If you want to install this just on your own account, the directions for installing are on the wp-cli page. But me, I wanted it on my server for all my accounts. Obviously my DreamHost server has it, but this site is still on LiquidWeb (for myriad reasons, one of which is the same as why I didn’t bank at the company where I worked, old habits).

    Their directions are, via git, to install in ~/git/wp-cli, which I don’t want. I decided to put it in /usr/share/wp-cli/ and to do this I just su’d into my root account. Otherwise I could do it all prefacing with sudo, but I’m dangerous like this.

    My first hurdle was the issues I’ve had on git before, simply put the damn thing times out. The fix was so stupidly simple, once I really read into how git works. All I had to do was tell it ‘Use https.’

    git config --global url."https://".insteadOf git://

    Suddenly my commands started working and I was able to run the install directions (modified a little):

    git clone --recursive git://github.com/wp-cli/wp-cli.git /usr/share/wp-cli/
cd /usr/share/wp-cli/
utils/dev-build

    This ran without a hitch. And any update for this, since I’m only ever using trunk, will be as easy as git pull now and then.

    Now on my server, when I try to run certain commands I git this:

    Fatal error: Out of memory (allocated 38797312) (tried to allocate 17 bytes) in /home/userID/public_html/wp-includes/widgets.php on line 635

    Two important things to note.

    1. This only happened on one of my accounts.
    2. 37 Megs is a real weird amount of memory.

    I happen to know I usually allocate 64M for my PHP processes, but even bumping this up to 128 didn’t change the fact that at 37M, everything crapped out. I happen to work with one of the leads on wp-cli, and Mike (aka GetSource) let me bounce ideas off him. He offered to help with any questions, but I learn best by doing, so once I sorted out the basics, and was still stumped, I appealed to his greater familiarity. By the time I logged off to clear my head and get dinner, we decided it had to be user permissions. After all, every account on the box used the same PHP instance. Every account had the same rights, etc. It had to be something funny about the profiles, which I’d buy since this server has some accounts that are 15 years old, and it’s the oldest one having the most issues.

    When I picked it back up a day later, I learned something surprising. At first I could get this to run every time on a site that has bbPress, but then I discovered any time I ran a big search (like wp theme status on my multisite, which worked for all other commands), it would also fail. So clearly there’s a memory shenanigan running around here. I tested with and without APC, switched back and forth between PHP handlers (fCGI, suPHP, DSO), and I tried bumping the memory all the way to 128M. Nothing would get me past the weird 37M. In desperation, I changed my php Memory limit to -1. This means no limit. And now it failed on 32M. As I started testing various possibilities, I came across a moment where I set-faulted (this would be from APC cli, don’t use it) and finally grabbed Alex Rabe’s WP Memory Usage, which tells me I was using “Memory : 8.3 of 128 MByte” on the plugins page, so I know WP knows it can have 128M. This lead me down a path of ‘What PHP is CLI using?’ After digging around and verifying it was the same, I started looking at how I’d locked down my server.

    This is where I started banging my head on my keyboard.

    Shell Fork Bomb Protection is a cool thing, in that it stops people from running rough-shod over your server. Of course they way it does this is by restricting the processes you can run via shell. And wp-cli is, say it with me, shell. Once I turned it off, everything worked. I’m not sure if this is something I’d want to do for every server, but since I can count, on one hand, the number of people with access to mine, and I know their passwords are secure, I’m okay with it.