Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How To

  • Understanding Plugin Stats on WordPress

    Understanding Plugin Stats on WordPress

    So you’ve have a plugin and you’ve finally released it on WordPress.org to allow the masses. It’s going well, you’ve run a couple revisions with no major issues. But how can you tell how ‘well’ your plugin is actually doing?

    Realistically, you’re going to have to wait a while, maybe even a year, for things to even out realistically. After a year, you should have something like this on your Stats panel and this CAN be explained!

    Here’s what Ban Hammer’s stats look like. It’s just about a year old right now.

    1) Initial Release – This was when I released it and started pimping it.

    2) First Major Revision – This was when I started adding in more features, making the code faster, and debugging something.

    3) Certified for 3.0 – This was … well, yeah, that.

    Look at how the spikes ramp up a lot. The first one is moderate, the second one is twice the first, and the third is another moderate change. It’s not impressive, my plugin is for a pretty niche market and I don’t expect it to be hugely popular. Impostercide gets about 80 a day right now, compared to the 10 to 30 Ban Hammer got in its first days. But the basic picture is pretty clearly painted.

    It’s not quite an exponential jump for each update, but the update is what’s telling you who is really using your plugin.

    Let’s look at the very popular WP Super-Cache plugin:

    His spikes are pretty static, standing at 11k downloads on every major release. That’s really impressive, but it gives a far more realistic understanding of your plugin and how many people are really using it.

  • Switching to WordPress MultiSite Breaks Links

    As of WordPress 3.1 you can NO LONGER remove the blog slug via the method described in this post! – Feb 28 2011

    Warning: WordPress MultiSite is not for the newbie!

    Most people I know who are using MultiSite (formerly WPMU) are people who have always been using that fork of WordPress. With the advent of MultiSite, a built in way for people to move from single ‘blog’ installs of WordPress to a multiple site structure, more and more users want to move to it, which is great. But. There are some weird ‘problems’ with MultiSite that cause a lot of users to think it’s broken. It’s not, it’s just different.

    My friend Andrea wrote a nice tutorial about how to create a network, and generally when I need help, I scan WPMU Tutorials first. Or I tweet at her. One of the things we’ve talked about is the way WordPress MultiSite changes your blog links.

    When I changed https://ipstenu.org from single to multi, my links were changed from https://ipstenu.org/YYYY/MM/PostName to https://ipstenu.org/blog/YYYY/MM/PostName, which I did not want! Thankfully, I knew a lot of people had this problem beforehand and I fixed it quickly, which I will explain here, but first, here’s why it’s done that way.

    Normally, when we use pretty permalinks (that’s the part of your URL that looks ‘pretty’ instead of code-like) on a blog, all we have to worry about is not conflicting with post names and page names. If you have an about page, generally the URL is https://ipstenu.org/about. Since WordPress has to translate https://ipstenu.org/?p=2 into that to be pretty, you can’t also have a blog post with the same URL. How would the software know WHICH page you wanted? Simple enough. For details on that, you can read Otto’s post on Category in Permalinks Considered Harmful.

    When you add in MultiSite, suddenly the code has to check for something more: is this new Site named something that breaks my existing links?

    There are two kinds of MultiSite, and I use them both. You have SubFolders and SubDomains. Subfolders gets you URLs like https://ipstenu.org/code and SubDomains gets you https://halfelf.org/. If you use SubFolders, WordPress takes an extra step to make sure that pages named ‘code’ don’t break when you have a new blog with the same name. To help do that, it kicks your blog URLs from your main blog (i.e. https://ipstenu.org/) up a level to a new URL: https://ipstenu.org/blog/. For those of us who move from Single to Multi, this breaks our old links.

    Thankfully there are a couple fixes which can tide you over until WordPress 3.1 is released. The developers plan on having this ‘fixed’ or at least editable by then, so at the worst, you can go from having a blog slug to ‘news’ or ‘pasta’ or whatever.

    .htaccess

    If you want to keep the blog folder, but you want to redirect your old posts, .htaccess is your friend.

    If I wanted to redirect all YYYY/MM/DD posts to /blog/… I would add this:

     
    RewriteRule ^/([0-9]{4})/([0-9]{2})/([0-9]{2})/(.*)$ https://ipstenu.org/blog/$1/$2/$3/$4 [L,R=301]
    

    What I actually did on another site was this:

    RewriteRule ^/([0-9]{4})/([0-9]{2})/([0-9]{2})/(.*)$ http://domain.com/blog/$4 [L,R=301]
    

    And I changed my permalinks to just post name. This was risky, in a way, but it matches how I use the site better.

    Plugins

    There are a couple plugins that can help you here. Thinking in WordPress made a plugin for WPMU, but I’ve heard it doesn’t quite work yet.

    Andrea (and her husband Ron) have a Remove Blog plugin that can also help you.

    I’m sure there are others, but I mostly recommend Andrea and Ron’s. And not just because I like them.

    Hack

    If you’re dead-set on doing this, and you don’t want to use a plugin, there is a manual way to do this. Remember, by doing this you will BREAK the ability of WordPress to check for conflicts between your main site’s urls and any new site. If you’re using SubDirectory SubDomain MultiSite, this should be fine. Hell, I’m doing it. If you’re using SubFolder, I really don’t recommend this at all.

    You ready?

    • Login to your admin site.
    • Go to: Super Admin > Sites > Edit
    • Scroll down to “Permalink Structure” and remove the “/blog” part
    • Save

    That’s it.

  • bbPress 1.x Functions

    bbPress 1.x Functions

    Since I don’t actively develop for bbPress 1.x at this time, you’re on your own with these ones.

    bbPress is a forum platform by the same people who do WordPress. It’s very much a barebones bulletin board system (which makes layers on layers of bb jokes). bbPress is not for the non-techy at this point. It’s still in alpha mode, with a lot of rough edges, and is comparable to WordPress 1. Maybe. Most of the features are done as plugins, rather than defaults, so you don’t get things like PMing and Quick Tags and inline images. You have to add in plugins for that. While I was using it, I wrote a few of my own plugins and hacks to make things work like I wanted.

    All of these hacks can be directly applied to the functions.php file of your theme.

    Change ‘Sticky’ to an image

    If you make a topic sticky it gets ‘pinned’ to the top of the forum. This great for things like announcements etc. It’s really annoying that it’s hard to change. I wanted a post-it image to show that it was pinned, so I made a function to delete the default function and replace it with my own.

    This goes in your functions.php for your theme, just like it would for WordPress

    <?php
    // This sets sticky label as an image
    remove_filter('bb_topic_labels', 'bb_sticky_label', 20);
    function my_sticky_label( $label ) {
            global $topic;
            if (is_front()) {
                    if ( '2' === $topic->topic_sticky ) {
                            return sprintf(__('<img src="/images/sticky.png" alt="&#91;sticky&#93;" /> %s'), $label);
                    }
            } else {
                    if ( '1' === $topic->topic_sticky || '2' === $topic->topic_sticky ) {
                            return sprintf(__('<img src="/images/sticky.png" alt="&#91;sticky&#93;" /> %s'), $label);
                    }
            }
            return $label;
    }
    add_filter('bb_topic_labels', 'my_sticky_label', 20);
    ?>
    

    Change the text of a ‘Closed’ topic

    By default when you close a topic it renames the topic to Closed: Topic Name. I wanted to change that to Read Only: Topic Name, so what I did was delete the old closed filter and replaced it with my own.

    <?php
    // This sets closed lable to read as 'read only'
    remove_filter('bb_topic_labels', 'bb_closed_label');
    function my_closed_label( $label ) {
            global $topic;
            if ( '0' === $topic->topic_open )
                    return sprintf(__('[Read Only] %s'), $label);
            return $label;
    }
    add_filter('bb_topic_labels', 'my_closed_label');
    ?>
    

    Woopra

    If you use Woopra to monitor traffic and Gravatar for icons, you may notice that just slapping Woopra’s tracker in the bottom of your site doesn’t show the Gravars. Since bbPress themeing is what it is, I put this in my theme’s footer.php file to make gravatars show up in my Woopra console. The trick was getting it to extract the logged in user’s email. So here it is. Put this in your footer file and Woopra will show gravatars.

    <!-- Woopra Code Start -->
    <?php
            global $user_id, $user_email, $user_identity;
            $woopra_name = bb_get_current_user_info( 'login' );
            $woopra_email = bb_get_current_user_info( 'email' );
            if ( $woopra_name == '') {
                    echo "<script type=\"text/javascript\">";
                    echo "\n";
            }
            else {
                    echo '<script type="text/javascript">';
                    echo "\nvar woopra_visitor = new Array();";
                    echo "\nwoopra_visitor['name'] = '$woopra_name';";
                    echo "\nwoopra_visitor['email'] =  '$woopra_email';";
                    echo "\nwoopra_visitor['avatar'] = 'http://www.gravatar.com/avatar/" . md5(strtolower($woopra_email)) . 
                    "&amp;size=60&amp;default=http%3A%2F%2Fstatic.woopra.com%2Fimages%2Favatar.png';";
                    echo "\n";
            }
    ?>
    var _wh = ((document.location.protocol=='https:') ? "https://sec1.woopra.com" : "http://static.woopra.com");
    document.write(unescape("%3Cscript src='" + _wh + "/js/woopra.js' type='text/javascript'%3E%3C/script%3E"));
    </script>
    <!-- Woopra Code End -->
    
  • Woopra Gravatars

    Woopra Gravatars

    At one point, I used Woopra to monitor my traffic. At the time, I also used Gravatar for avatars. Woopra has this awesome ability to show the gravatars of the person visiting, based on their email. Except it wasn’t working with my theme.

    Normally I’d just slap this in my footer.php theme file to make gravatars show up in my Woopra console, but I happen to be using a Theme Parent (ThemeHybrid – which I’m also using here) and I don’t want to have to hack my theme any more than I have. The glorious thing is that Justin, in his wisdom, made a function I could plug into. So I made a new function (my_woopra_footer) which lets me extract the user’s email and ID name, parse it through, and spit back the right data. It’s weird, and I don’t suggest you use it unless you’re using Hybrid’s theme.

    /* Woopra */
    function my_woopra_footer() {
            global $user_ID, $user_email, $user_identity;
            echo "\n";
            ?>?
                    <?!-- Woopra Code Start -->?
                    <?script type="text/javascript">?
                    var woopra_visitor = new Array();
            <?php
    
            if (is_user_logged_in()) {
                    echo "\n\t\twoopra_visitor['name'] = '$user_identity';";
                    echo "\n\t\twoopra_visitor['email'] =  '$user_email';";
                    echo "\n\t\twoopra_visitor['avatar'] = 'http://www.gravatar.com/avatar/" . md5(strtolower($user_email)) . 
                    "&size=60&default=http%3A%2F%2Fstatic.woopra.com%2Fimages%2Favatar.png';";
            }
            echo "\n";
            ?>
                    var _wh = ((document.location.protocol=="https:") ? "https://sec1.woopra.com" : "http://static.woopra.com");
                    document.write(unescape("%3Cscript src='" + _wh + "/js/woopra.js' type='text/javascript'%3E%3C/script%3E"));
                    <?/script>?
                    
            <??php
    }
    
    add_action( 'wp_footer', 'my_woopra_footer' );
    

    As a sidebar, I still think Woopra is an amazing tool. It just had all sorts of weird issues on my sites and I backed off, trading it for Google Analytics. Yeah, I know.

  • Ban Whack-a-Mole

    Ban Whack-a-Mole

    If Ban Hammer is too much for you, I understand. But you still want to smack down users from a specific domain? Otto came up with this and it works nicely.

    Copy the code into your theme’s functions.php file (just make one if you don’t have one) and change the call to .ru to whatever it is you need. I’m not 100% sure what would happen if you added in multiple calls, but this is perfect for banning just ONE annoying person.

    function no_russians($login, $email, $errors) {
            if (strpos($email, '.ru') !== FALSE) {
                    $errors->add('email_banned', __('ERROR: This email address is not allowed, please choose another one.'));
            }
    }
    add_action('register_post', 'no_russians', 10, 3);
    
  • Sucking Clams, Kosher Style

    ClamAV is an tool that you put on your server and it detects malicious software. In short, it’s a server virus scanner and most servers use it to scan email for viruses. Now those of you who use stuff like McAffee and Norton and other virus scanners for your email, you may not know that servers also scan for that stuff as well, and try to kill the emails before they ever get to you! Yeah, think about how many emails with viruses you get. Personally, I’ve never had a problem with viruses and not because I use a mac. It’s because I pay attention to the content and context of an email before I open any attachments.

    But this is about ClamAV and server-side scanners.

    The story starts with my twice a week check of my server. I like to keep tabs on what it’s doing, how it’s doing, what’s going on, etc etc. I was a little surprised to see my server load spiked. Server load is sort of how you know how hard your server is working. A high load means its looking at a lot of work. A low load is ‘better’ but you have to admit that you’re going to have SOME load, so you may as well figure out what’s a good load for you. I’ve had problems with WordPress and right now I’m using WP Super Cache (See “I take it back. WP-Super-Cache is a Super Hero” from September 2009).

    The point is, I know that a spike like this is okay:

    That spike there was when I ran a small upgrade. You’ll notice how after the moment, it drops back down and has a happy nice day? That’s how things are supposed to work. A spike with traffic and then everything’s happy again. Great.

    So what does this mean?

    Yeah, I took a look at that, paled, and asked myself ‘What in the four hells is going on!?’ I did the logical thing and looked at the date and time. Noon on Monday I’d made a change to the firewall, moving from the perfectly acceptable, though harder to manage (no GUI), APF Firewall to CSF. That move was a TEENY bit on the spur of the moment, as I wasn’t having any problems with APF per se, but I was being hit up by a lot of spammers and my usual attacks of http:BL and Bad Behavior weren’t cutting it. They’re front end fixes to the ongoing spam problem, alas. I hate spammers.

    Worried that my new firewall was ‘bad’, I started to Google if CSF caused high server loads. And found nothing. So I went back to the beginning and checked top. Top is a unix command that you use to see what’s using up resources on your server. It’s like Task Manager for Windows, but it’s a lot more informative. Top lets you see details and sort and basically when you want to find out what ran off with the spoon and killed your server, baby, I’m the bottom and log on to top. Top showed me, interestingly enough, that ClamD was using between 70 and 90% of my resources. On a slow week, like the net generally has for entertainment sites between Christmas and New Years, that’s not really a problem. There’s not a lot going on with the sites I host right now, the extra CPU usage wasn’t a problem. Come back on January 20th, though, now that’s a problem.

    But the thing of it is, back in September, I optimized my server and I remember reading on multiple places that ClamAV and ClamD use up a lot of resources and people turn them off. So I did.

    Isn’t that much nicer?

    The real question, at the end of the day, is if having ClamAV turned off causes more problems than having it on? So far, no one’s breached my servers, though that’s a function of my firewalls, and SpamAssassin seems to be taking care of the spam emails, which is where most viruses come from in my experience, unless the server’s hacked, at which point I’m kind of screwed anyway. But what I find myself wondering now is if it’s dangerous to not be using ClamAV or what. And I don’t have an answer to that yet.