Half-Elf on Tech

Thoughts From a Professional Lesbian

Author: Ipstenu (Mika Epstein)

  • 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.

  • grep vs ack

    grep vs ack

    I do a lot of things by command line. Still. It’s faster, it’s easier, and in many cases, gives me more control. And as I always mention, people who use command line are people who really lazy. We don’t like sixteen clicks. If we can copy/paste and change one thing, we’re happy.

    For ages, when I wanted to search my local repository of plugins, I’d whip out something like this:

    grep -R "base64" ~/Development/WP-Plugin-Dir/* > ~/Development/WP-Plugin-Greps/base64-grep.txt

    This works, but it’s slow and it’s not very pretty. The file output is a mess and it’s painstaking to sort through and understand.

    /home/me/Development/WP-Plugin-Dir/jetpack/class.jetpack-post-images.php:                ob_start(); // The slideshow shortcode handler calls wp_print_scripts and wp_print_styles... not too happy about that
/home/me/Development/WP-Plugin-Dir/jetpack/modules/comments/comments.php:                ob_start();
/home/me/Development/WP-Plugin-Dir/jetpack/modules/contact-form/grunion-contact-form.php:                ob_start();
/home/me/Development/WP-Plugin-Dir/jetpack/modules/custom-css/custom-css.php:            ob_start('safecss_buffer');
/home/me/Development/WP-Plugin-Dir/jetpack/jetpack.php:                  ob_start();
/home/me/Development/WP-Plugin-Dir/jetpack/jetpack.php:          ob_start();

    On the other hand, there’s this:

    ack --php 'ob_start' ~/Development/WP-Plugin-Dir/ > ~/obstart.txt

    That actually gives a rather similar output:

    /home/me/Development/WP-Plugin-Dir/jetpack/class.jetpack-post-images.php:36:               ob_start(); // The slideshow shortcode handler calls wp_print_scripts and wp_print_styles... not too happy about that
/home/me/Development/WP-Plugin-Dir/jetpack/modules/comments/comments.php:138:              ob_start();
/home/me/Development/WP-Plugin-Dir/jetpack/modules/contact-form/grunion-contact-form.php:264:              ob_start();
/home/me/Development/WP-Plugin-Dir/jetpack/modules/custom-css/custom-css.php:350:          ob_start('safecss_buffer');
/home/me/Development/WP-Plugin-Dir/jetpack/jetpack.php:872:                        ob_start();
/home/me/Development/WP-Plugin-Dir/jetpack/jetpack.php:928:                ob_start();

    That’s ack, which claims to be better than grep, and I’m kind of agreeing. Let’s look at the small differences.

    • Line numbers. That will help me find the code later.
    • Only searching PHP files
    • Recursive by default
    • Ignores SVN and other similar folders.

    How do you do only PHP files in grep?

    grep pattern $(find . -name '*.php' -or  -name '*.phpt' -or  -name '*.php3' -or  -name '*.php4' -or  -name '*.php5' -or  -name '*.phtml' )

    Right. Like I’m going to remember that.

    And we can make ack better. Let’s ignore a folder:

    ack --ignore-dir=akismet 'string'

    How about customizing my output so I can check how often a plugin is doing_it_wrong()?

    ack --php --group 'ob_start' ~/Development/WP-Plugin-Dir/ > ~/obstart.txt

    That’s a little easier to read.

    /home/me/Development/WP-Plugin-Dir/jetpack/modules/custom-css/custom-css.php
350:            ob_start('safecss_buffer');

/home/me/Development/WP-Plugin-Dir/jetpack/jetpack.php
872:                    ob_start();
928:            ob_start();

    Just want a list of the filenames?

    ack --php -l 'ob_start' ~/Development/WP-Plugin-Dir/ > ~/obstart.txt

    Or what if I want to search all instances of ob_start() in jetpack/jetpack.php? You can make ack sit up and beg.

    You can see that ack is a lot more powerful right away when it comes to being able to quickly use the data without a lot of parsing. There are some catches with ack, though, like it has a whitelist of file types that it will search, so if you don’t tell it to search .html, it won’t. That’s a small price to pay for me.

    The documentation is written in nerd, so I generally find looking at concrete examples is more helpful. Do you have tricks with ack (or even grep) that save you time and money?

  • 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.

  • phpMyAdmin vs CMS

    By ‘CMS’ I mean WordPress, Drupal, whatever.

    So here’s a funny. I moved my DreamHost site to a VPS, so I could learn nginx (I’m still a newb) and suddenly I couldn’t get to my phpMyAdmin anymore! Before someone says it’s DreamHost’s fault, this is actually due to how I installed subdomains (which I don’t recommend) and configured nginx (still optomizing). That said, not every CMS is flexible enough for this, so if you have this problem too, here’s a work-around.

    As you know, you’re supposed to go to http://mysql.elftest.net which then sends you to http://elftest.net/dh_phpmyadmin/mysql.elftest.net/ to get to your phpMyAdmin page. Except it gives you a 404 styled like your site instead.

    Solution? Make a fake subdomain.

    I made db.elftest.net (which has nothing), but now I can go to http://db.elftest.net/dh_phpmyadmin/mysql.elftest.net/ and log in!

    How I buggered my subdomains, and how I fixed it, is another post.

  • Encrypted Search Terms

    Encrypted Search Terms

    A recent stats viewing, with search terms high-lighted.I haven’t seen a lot of people kvetching about this, which surprises me.

    If you like to look at JetPack’s stats and happen to giggle over your search terms, you may have noticed encrypted_search_terms showing up. Your search terms are what other people use in order to find you. So for example, someone found my blog by typing “forever alone” (which doesn’t make any sense to me, but okay).

    About a year ago, Google made search more secure, by letting you search via https. If you’re logged in to Google anything, you will be searching via https, which means no one knows what you searched for. Jetpack sees it as ‘encrypted search terms’ and Google Analytics sees it as ‘not provided.’ This is all great for the user, and the tin-foil hat me loves it! Except that now all we users see is encrypted search terms, instead of anything of value.

    As the number of people who use Google whatevers grows, the value for my search terms is going to plummet. In fact, taking a look at things, my ‘not provided’ numbers have doubled. It used to be that maybe 1% of searches showed up like this. I was around 13% for an average month in January, and now I’m looking at 30%. I am losing the ability to see what search terms are good for my site, and this makes it hard to manage my SEO.

    Oh. SEO. I hate you.

    I laud Google for doing this and at the same time decry them. Yes, having users protected while they search is awesome, it means my data is safe and it’s less easy for people to mess with me. As a user, I think this is good. As a website guru, I wince a lot. Without the feedback of users’ search terms, it’s very hard to know what does and doesn’t work. And the worst part is the majority of your users don’t even know they’re doing this. They know they’ve signed in to Google email, and they’ve signed in to Google+, and that’s it. They don’t know the ramifications.

    I don’t pretend to be an SEO expert, but what I do claim is to have common sense, and to valiantly fight against the will to be stupid. It’s pretty obvious to me that encrypting my results rips out my ability to, for free and with no cost to my users, be able to determine what works and what doesn’t on the fly. Many times, when I tweak a site, I follow the stats and see what pages are hit more often, by whom, and when. Now there are work arounds to loosing that immediate feedback, but when you think about it, almost all involve you having to pester your users.

    A/B testing is the least intrusive way about it, but for a lot of people, it’s complicated to do on a small, simple website. The basic idea is to ‘draw’ users to two different versions of the same site, and see which one gets more traffic. Max A/B is a good WordPress plugin for that. That said, your users may notice that the site one of them sees isn’t the same as another, and it means you have to up-keep two versions for a while.

    Google Is WatchingGoogle, naturally, isn’t very consistent here. They generate their live traffic information via your cellphones. Whenever an Android user opts into location tracking, Google constantly monitors their location. If a whole mess of users are slowing down on the 405, guess what? Traffic. Now, arguably your data is ‘safe in their hands’, but that’s impossible to prove. If you haven’t yet, read Cory Doctorow’s “With A Little Help”, especially the story “Scroogled.”

    Basically what Google’s saying is ‘You can’t use their data, but we can. Trust us.’ Nothing makes me start to trust someone less.

  • 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.