Half-Elf on Tech

Thoughts From a Professional Lesbian

Author: Ipstenu (Mika Epstein)

  • Auto Multisite Registration

    Auto Multisite Registration

    There are plugins for this, and I’m rather fond of them. If you just want all new users to be added to some (or all) sites, then I suggest you use Multisite User Management. It’s a great plugin, and lets you pick and chose. But similar to how sometimes you want users to register per site, you may have a situation where you want users to be added to any and all sites when they visit.

    So how do we do this? It’s really not that painful, just make a add-users.php file in your mu-plugins folder with this:

    <?php
    
    /*
    Plugin Name: Add Users
    Description: Add users to blogs when they visit.
    */
    
    function helf_add_users( ) {
        global $current_user, $blog_id;
    
        if(!is_user_logged_in())
        return false;
     
        if( !is_user_member_of_blog() ) {
            add_user_to_blog($blog_id, $current_user->ID, "subscriber");
        }
    }
    
    add_action( 'wp' , 'helf_add_users' , 10);
    

    This code will automatically detect “John Doe is logged in.” and “John is not a member of this site.” If both of those are true, then it says “We will add him as a subscriber.” You can change subscriber as you see fit.

    Would it be more efficient to just do this check on registration? Sure. But there are moments you don’t want this. If you wanted to get extra sneaky, you could set this to only run on a specific page, and make that page password protected.

    If we want to add in a couple extra layers, that’s also not terrible. Let’s say we want people to press a button ‘Join This Site’? I have to admit, this actually took me longer to hash out than I wanted it to, mostly because I decided if I was going to do this, I should do it all the way.

    That’s why I came up with Join My Multisite, which is a handy plugin to give you some more options. It’s per-site configurable, so your site-admins will get to decide if they want everyone logged in user to be added to their site, or if they want a widget, or if they want nothing at all. I put some time into thinking about if it would be a good idea to have the network admin be able to pick, but when I got down to brass tacks, I realized there was no way to easily force a widget (i.e. the button to join the site) for all sites and make it always look good. If you need that, you should fork the plugin and hard-code in the widget.

    Join or Die

    In a way, this is an extension of the old ‘Add Users Sidebar’ plugin, which drifted off into the wayward lands of not-supported. I never looked at that code, though, and instead wrote all this from scratch.

    In addition to all that, Join My Multisite gives each site the ability, if registration is open, to easily make a per-site registration page. That one was Mason James’ suggestion.

  • Cloudy With a Chance of Upgrades

    Cloudy With a Chance of Upgrades

    We’re all being seduced by the cloud. Amazon’s AWS has become so popular and so, seemingly, inexpensive, that people are looking at it to run a website, instead of traditional hosting. Understanding the cloud actually was the first post on this site, and while two years ago I struggled to comprehend it, today I find myself at a loss many times when asked ‘Do I need the Cloud?’

    I don’t need the cloud for webhosting, and you probably don’t either.

    My Sky

    Yes, I have a semi-cloudlike host on LiquidWeb right now, for seven of the ten domains I manage (the other three are all on their own hosts, one of which being my me Elf Dreams, where I talk about DreamHost stuff). I don’t plan on moving the other seven simply because it’s a massive effort. It’s easier to move yourself across country than it would be to move all my sites, re-build the server as I need it, get the code for the new OS (CentOS vs whatever I move to). Heck, I’m dreading upgrading to CentOS6 because of how annoying that is.

    The point is that I do know and understand what the cloud is and does. It’s very cool, if you’re big enough to need it. Most indie sites are not.

    How the cloud works, in general, is based on the shared resources principal. Everyone shares all the resources in the cloud at all times. If you think back to shared hosting, everyone shares all the resources on that server. The difference between the cloud and the shared is that the cloud has infinite expandability (kind of, but you get the idea), where as a shared host is limited to what it is physically. But when we were back on shared hosting, we used to have a problem with bad neighbors. You know, the other guy on your server who got tweeted by Felicia Day or Wil Wheaton, and suddenly all the sites on your server went down like a bad quiche.

    That can happen on the cloud too.

    It’s not exactly the same, but when you’re on a cloud, you’re on a server with a lot of virtual machines (VM). A VM is a “completely isolated guest operating system installation within a normal host operating system” which is a confusing concept. The reason they’re good is that a VM isolates your hardware in a funky way, making reboots faster, while letting your VM instances share a bunch of hardware and become faster. The flip side to this is that you’re still on a real server. Instead of everyone sharing the same CPU/RAM, you get partitions so I can only use X amount and you can only use Y, and thus we don’t kill each other, until we start slaughtering input/output.

    Disk I/O (input/output) can be best explained if you’re an older computer user. Remember when we used to play “Where in the World is Carmen San Diego?” and we’d press a button to ‘travel’ and that old floppy drive would grind like a cheap espresso brewer? That’s I/O. The disk is being read and the data is being input from the disk and output to your Apple IIe. The basic concept of this still exists, and it makes sense when you remember we have to read the data off somewhere. So if you happen to be on a box that is getting a lot of traffic, and using a lot of disk I/O, then you’re going to be slow.

    Hole in the SkyThere are ways to mitigate this, of course, but that isn’t the problem. The problem is that you don’t always know that you need to, or how you should. And even if you do know, it’s not always very easy to do it, so the little guy, who doesn’t have the resources to do it themselves, or the money to hire someone, are left hoping that they’re okay, and often end up paying more than they need to.

    And this is why you and I don’t need the cloud yet. The cloud is something I might need, but for now, there are no benefits I don’t already have with a well optimized server and a well built site. If I was a bigger site, or a company, I’d be looking at it as my next upgrade, and studying my past growth. It took me almost 10 years to grow to need a VPS, and it will likely take me at least 5 more before I need to seriously consider cloud. By then, something new will be the big thing, so the best thing I can do is study nginx and keep a finger on the pulse of web technology.

    Of coures, the one major advantage to the cloud, and the reason I still see it as being around for a while, is the ability to scale up and down. A webhost provider can cannily utilize that to provide scalable shared hosting, so if you have a bad neighbor, they can be scaled up with less impact to you. But so far as I know, we’re only there with VPS demi-cloud providers right now. Give it time, and the cloud as we know it today will be tomorrow’s low-end hosting.

  • Subdomains Back Where They Belong

    In my last post, I talked about how I did something dumb with my subdomains.

    How did I install subdomains?

    Stupidly. Or rather, stupid for DreamHost. See, many other hosts, when you make a subdomain, come up with this structure for your files:

    /home/ipstenu/public_html/
                             /subdomain1
                             /subdomain2
                             /addon.com
    

    So when I made my subs, I made them similar to that. What DreamHost does is this:

    /home/elftest/elftest.net/
                 /db.elftest.net/
                 /addon.com
    

    I suggest you do the default! If you didn’t, however, there is a way to fix it. It’s a two step process.

    1) Move the files.

    I found it easier to do this in Unix $ mv elftest.net/trunk trunk.elftest.net (this moves and renames all in one). If you wanted to do it via FTP, just drag and drop, then rename.

    2) Change the location in Panel.

    Go into your panel, edit the domain, and change elftest.net/trunk:
    before: elftest.net/trunk

    To trunk.elftest.net:
    after: trunk.elftest.net

    Give it 5 to 10 minutes, and you’re done!

    tl;dr to the whole thing is this: Trust the tool! (Sharon, that was for you!)

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