So yes, if you have ever wondered the best way to use setInterval, the dude at Wall of Scribbles done figured it out for you:

setInterval(): the sneaky basterd child of JavaScript

.test {
    -moz-border-radius-topright: 4px;
    -webkit-border-top-right-radius: 4px;
    border-top-right-radius: 4px;
    -moz-border-radius-topleft: 4px;
    -webkit-border-top-left-radius: 4px;
    border-top-left-radius: 4px;
}

can be written like this:

.test{
    @include border-top-right-radius(4px);
    @include border-top-left-radius(4px);
}

But wait? This is what Compass ACTUALLY outputs (And I always forget that MS has decided to jump into the vendor pre-fixed CSS3 game also. Yay.):

.test {
    -moz-border-radius-topright: 4px;
    -webkit-border-top-right-radius: 4px;
    -o-border-top-right-radius: 4px;
    -ms-border-top-right-radius: 4px;
    -khtml-border-top-right-radius: 4px;
    border-top-right-radius: 4px;
    -moz-border-radius-topleft: 4px;
    -webkit-border-top-left-radius: 4px;
    -o-border-top-left-radius: 4px;
    -ms-border-top-left-radius: 4px;
    -khtml-border-top-left-radius: 4px;
    border-top-left-radius: 4px;
}

I love Konquerer and Opera, really I do, but not at the expense of all that extra cruft in my CSS that only .5% of my total visitors will ever use. So how do I globally remove all Opera and Konquerer vendor-prefixed CSS3 from my Compass processed CSS?

At the top of your base SCSS file, add the following Compass variables:

$experimental-support-for-opera:false;
$experimental-support-for-khtml:false;

Now the results are what I want:

.test {
    -moz-border-radius-topright: 4px;
    -webkit-border-top-right-radius: 4px;
    -ms-border-top-right-radius: 4px;
    border-top-right-radius: 4px;
    -moz-border-radius-topleft: 4px;
    -webkit-border-top-left-radius: 4px;
    -ms-border-top-left-radius: 4px;
    border-top-left-radius: 4px;
}

Some people are angry that it is an arbitrary editorial control mechanism, so there’s been a huge fracas on the wp-hackers email list. Quite hilarious, actually, given the relatively small impact that the code itself has.

Lost amongst all of the brouhaha was John Bloch’s contribution on how to easily remove the filter:

remove_filter('the_content','capital_P_dangit');
remove_filter('the_title','capital_P_dangit');
remove_filter('comment_text','capital_P_dangit');

Simply add that code to your functions.php file and call it a day

Feeds are also useful as content sources for people too lazy to write their own stuff. I know, I know, it sounds awful to say it that way, but that’s the reality of it all. If you had awesome content bursting out of your own ears, you’d never need to pull in someone else’s finely wrought content.

Back to the point, this is how a trillion how-to tutorials on the web teach you to pull a feed into WordPress, serverside:

<?php 
include_once(ABSPATH.WPINC.'/rss.php');
wp_rss('http://feeds.feedburner.com/wprecipes', 3); 
?>

The problem with that method is that that it is deprecated. From the WordPress Codex:

This function has been deprecated. That means it has been replaced by a new function or is no longer supported, and may be removed from future versions. All code that uses this function should be converted to use its replacement if one exists. See also wp-includes/deprecated.php. WP_RSS Function Reference

That function does exist, but you’d never know it, if judging by the lack of “airtime” it gets on the tutorial sites.

Here’s the proper way to retrieve a feed into WP, in a useful little mini-feed-loop that I put together:

<?php
include_once(ABSPATH . WPINC . '/rss.php');
$feed = 'http://example.com/feed/';
$rss = fetch_feed($feed);
if (!is_wp_error( $rss ) ) :
    $maxitems = $rss->get_item_quantity(3);
    $rss_items = $rss->get_items(0, $maxitems);
    if ($rss_items):
        echo "<ul>\n";
        foreach ( $rss_items as $item ) : 
            echo '<li>';
            echo '<a href="' . $item->get_permalink() . '">' . $item->get_title() . "</a>\n";
            echo '<p>' . $item->get_description() . "</li>\n";
        endforeach;
        echo "</ul>\n";
    endif;
endif;
?>

Basically, fetch_feed() uses SimplePie to do in a “way mo betta way” what wp_rss() uses magpieRSS and Snoopy HTTP to do. SimplePie’s documentation and ease of use is awesome, even if the functionality to retrieve the feed looks more complicated on this end.

Using WP’s fetch_feed()/SimplePie functionality, you have a lot more control over how you display the feed. I just showed an example pulling the link, but it’s really easy to pull any/all of the data out of any RSS feed, something that you couldn’t do as easily with the old busted style.

I’ve been using the WordPress 3.0 RC1, RC2, and RC3 for a while, using the WordPress Beta Tester plugin, and so far it’s been relatively painless. A few of the plugins weren’t working, which I stupidly forgot to note, so that I could pass it along to the plugin developers, but overall it has been very stable.

Who’s to say how much of a pain it’s going to cause me at work, given the proprietary nature of some of my company’s in-house developed plugins. We try to build things the “WordPress” way, so hopefully there are only a few minor hiccups.

As to security, I once again wish that WordPress would adopt a two-pronged release strategy. Yes, go ahead and release the latest, greatest bleeding edge version as your main release. But please, PLEASE, start a long-term-support (LTS) branch. Or not. Whatever.

The back-end is a touch cleaner, although I can’t exactly put my finger on all the changes, other than the color. (I suppose I could do a side-by-side, but that would be too easy, wouldn’t it.)

Long story short, I’m working on building some new theme templates that take advantage of the new menu system and a few of the other additions. It’s exciting finding a new theme function! (NERD!)

I’ve been looking at it for quite some time, but I’ve finally pulled the trigger. My website/blog/home of the awesome sauce, dangayle.com, has now been ported completely over to Posterous. As a web designer, I love the fact that I could totally do whatever I stinkin’ wanted on my site. I could host images, I could scrap the design at will and start over (which I have done, just not recently). WordPress really is one of the best solutions for a lot of people’s needs. But, as it turns out, it’s not the solution to MY needs.

WordPress = Boring and old and crappy

The problem is that I’m bored with it. I’m sick of the micro-updates that totally jack up the website every three months because someone introduced a new bug into the system. The fact that they haven’t branched WordPress into a secure long-term support (LTS) branch and a current branch has ruffled a few feathers, including mine. I’m sick of having to deal with updates. And, quite honestly, I’m bored with PHP, the foundation upon which the WordPress empire was birthed. No offense to PHP programmers, but the language feels old tech. I’m not even a fully qualified programmer, but I can see it. It Python the be-all, end-all? Judging by the size of the stupid O’Reilly “Learning PHP” and “Programming PHP” tombs, Python must be a beast. I don’t want to learn it simply because I like the O’Reilly books, but I don’t want to heave those things around. Maybe Ruby is the answer. Anywho, I’m straying off the point.

Easier to post = more posting = better blog

And while I control it, I never post to it like I should. A blog that no one posts to is simply fruity. Posterous makes it easier to post to because it uses an interface that I use all the time: email. I’m always emailing stupid videos or interesting links or whatnot to people. What I like about Posterous is that I can simply add post@posterous.com to the recipient list, and BOOM! Tough Actin’ Tinactin. I mean, BOOM! Posted to my blog. Like this John Madden Youtube video:

In conclusion

There really isn’t a conclusion. It’s going to be an ongoing debate in my mind, and at my place of work, what is the best platform/what is the best programming language/etc. I honestly think that we should be able to accomplish anything we can think of at this point, and if it’s a language or a platform that is getting in the way, then it’s old tech. Time to bring out yer dead and toss it on the pile, even if it’s not quite dead yet. So, yes, Posterous. I like it. I got it set up, posts imported, domain transferred, everything. Less than an hour. Sweet.

I spotted this video on Lukas Mathis’s ignore the code blog, and I thought it was worthwhile re-posting it here.

One problem though, when you realize that it doesn’t exclude YOUR visits from the logs. (Wow! There are a lot of Macintosh users with Firefox in the Spokane vicinity looking at my blog! I must be popular!)

To exclude your IP or host from the stats analyzer, locate the following file on your server, and open it with your text editor of choice:

/tmp/awstats/awstats.DOMAIN.conf

Locate this section in the .conf file:

# Do not include access from clients that match following criteria.
# If your log file contains IP adresses in host field, you must put here
# matching IP adresses criteria.
# If DNS lookup is already done in your log file, you must put here hostname
# criteria.
# Note: Use space between each value.
# Example: "127.0.0.1 163.84. 201.101.51.1"
# Example: "localhost abcxyz"
# Default: ""
#
SkipHosts="YOUR IP AND ANY OTHER YOU WANT TO EXCLUDE"

Within the SkipHosts="YOUR IP AND ANY OTHER YOU WANT TO EXCLUDE" section, enter the IP address of your network connection, and hit save.

Voilá! You are now skipped from your stats. Apparently, this doesn’t work retroactively, so you should see your stats changes from this point on.