Rusty's Blog

Advanced Google Analytics and WordPress integration presentation from WordCamp Atlanta from Rusty Tanton on Vimeo.

This is a video of the presentation I gave at WordCamp Atlanta on January 9, 2009 about integrating Google Analytics with WordPress. I’ve made a few updates to the slides and code samples since I found out afterward it’s against Google’s terms of service to track visitors by name.

I didn’t get to attend the opening sessions of WordCamp Atlanta because the weather was horrible and we didn’t want to drive home in it in the dark last night, but I’ll be there today.

Due to aforementioned weather, the schedule has been pushed back an hour today, which means my presentation on advanced Google Analytics-Wordpress integration starts at 11 a.m. instead of 10 a.m. now. Here is the Google Doc I’ll be referencing, which also links to some code samples in case you’re having trouble deciding which session you want to attend in that time slot.

If you didn’t buy a ticket, the good news is due to the weather the organizers will now accept walk-up registrations when they hadn’t planned to before. You’ll need exact change though (the registration page says they’re $55, so I’m presuming that’s how much they still cost).

Looking forward to seeing you there!

Atlanta’s first Wordcamp Atlanta, one of a series of conferences focused on all things WordPress, is coming next month.

I will lead a session on advanced Google Analytics integration with WordPress. Here is a tentative set list, with the caveat that the schedule hasn’t been released yet. I don’t know what my block of time looks like, so this list may be condensed or expanded depending on how much time I have:

• Advanced Segmentation: pass information from WordPress into Google Analytics custom variables so you can segment page views by author name, visitor name, category or whatever else you can think of
• Conversion rates: use goals and funnels to track what percentage of your visitors are leaving comments, signing up for your email newsletter, buying your ebook, etc.
• Tracking Javascript applications: add tracking to visitor interactions in your Javascript applications, or intercept Javascript events added by WordPress plug-ins and add tracking to them
• Campaign integration: automagically generate campaign IDs for your posts, track them across RSS, Twitter, Facebook, email and more
• Custom reporting: make sense of all this new information

This session will be oriented toward programmers with a heavy focus on coding and implementation strategies. I’m presuming you have experience with at least some of the following: WordPress theming, Google Analytics, HTML, PHP and Javascript.

Hope to see you there! WordCamp Atlanta will take place Jan. 8-9 at ATDC. Tickets are available here for $45.

So, you’ve got a website running Drupal. Nothing new will be added to it, but you’d like to keep it on the web forever and ever. Maybe it was created for an event, and the event is over. Or maybe you had a site with a lot of custom modules, and you decided it would take too much time to upgrade all the custom modules.

Whatever your reason, it’s not a good idea to leave Drupal (or any software) running on the site if you’re not planning to constantly apply upgrades. If you don’t keep the software up-to-date, your server will be hacked. It’s not a question of if, it’s a question of when.

The good news is it’s generally not too hard to make a cache of all the pages on the site that are available to anonymous users and replace your Drupal installation with them. Plain HTML doesn’t require a babysitter and doesn’t hog server resources like Drupal does. Here’s one way to go about mothballing your Drupal site. Don’t blame me if anything blows up, these are just suggestions to get you started.

Read the rest of this entry »

I’d like to think I learned something during three years running a site which hosted several hundred audio podcasts, some of which have been heard by thousands of people. By running, I mean co-running, along with Amber who will be writing a post similar to this one soon.

Sometime during the next year we’re going to convert the site to a static cached archive for posterity which will require little effort and expense to maintain. Once that’s done, that will mark the end of our experiment.

What follows here are a few random things I’ve learned. Much of this will sound negative, but really even the stuff that went wrong I view as positives because I’ll know what not to do next time. There’s a pretty good chance I will read this over a few times and want to write a “totally super awesome positive stuff” post later, because this certainly isn’t a comprehensive overview of my experience. To use a word old people would use, I treasure the relationships and experiences that came from running the site, and greatly appreciate all the work people put into it.

Read the rest of this entry »

A few of you may have noticed PodCamp Atlanta had a really kickass first year in 2007, and then nothing happened after that. Why? A few reasons, I think:

1. Amber did almost all the organizing of the first one herself. She moved on to organize Sex 2.0, and organizing PodCamp Atlanta 2 apparently was more work than the person who was supposed to do it anticipated it would be. So it languished, and the dates kept getting pushed out. The next one is supposedly scheduled for sometime later this year or in 2010, but I’ll believe it when I see it. And lest it sound like I’m just throwing this one person under the bus, I should note that not much of anybody else in the community stepped up to help her out when it was clear she wouldn’t be able to handle it on her own.
2. The first PodCamp Atlanta happened when there were barely any cheap or free social media events/tech events of any size in Atlanta (other than SoCon, I can’t name one, but it’s possible there were others I wasn’t aware of). So there was pent-up demand. Not long after, many such events started popping up. Barely a week passes now without a similar event. Perhaps as it should be, demand for a new PodCamp would depend entirely on people with an interest in podcasting, which leads us to…
3. Podcasting is sooooooooo 2007. Which is to say, the hype around podcasting and the curiosity about making podcasts among people who weren’t already making them has waned. Contrary to the (insert tech that’s more than a year old) is dead meme that inevitably goes around, podcasting is actually more popular then ever. But I posit it’s a different kind of popularity: that of a familiar commodity, not one of an emergent new technology.

I mention all this for a couple of reasons.

First, someone at Georgia Tech offered a venue and some administrative support for another PodCamp Atlanta. The offer was made on the Google Group to anyone who would grab the reigns and do a little work to make it happen.

My belief is PodCamp was something that was great for Atlanta in 2007, but its time has passed and that the time and energy at this point would be better spent on something else. I think if the demand was truly there for a sequel to this event, that the community would have stepped up and made it happen already. It didn’t.

However, neither Amber or I would be doing any of the organizing, so our opinion doesn’t count any more than anyone else’s. If you think I’m wrong (or if you think I’m right for that matter), please say so.

In the short term, if you have energy to burn, volunteer to help Derek and Swoopy with the Dragon*Con podcasting track. Even if they are past needing help with anything this year (don’t know, you’ll have to ask), they probably wouldn’t mind having new contacts to keep in mind for next year.

Second, you may have also noticed our podcast production of Mostly ITP has slowed down, and that there are fewer active podcasters on the Georgia Podcast Network now than there were a year or two ago.

The site has been running on Drupal 5 ever since the redesign from a little over a year ago. I could write a lengthy screed on the positive and negative aspects of running a website with Drupal, but unfortunately for this question I have to focus on one glaring negative: modules are not compatible from one major version to the next.

That means when you upgrade a site running Drupal to a new major version, it can be a serious undertaking if you have a bunch of custom modules like we do on the Georgia Podcast Network. Drupal 7 is coming out soon, and once that happens Drupal 5 will eventually stop getting necessary security patches.

So, we have a decision to make sometime in the near future:

1. Do a lot of work to get the modules running on Drupal 6 or Drupal 7
2. Move to a different system
3. Shutter the site completely/convert it to an archive of static pages

I’ve done a little preliminary research, and it would actually be pretty easy to port the data out of Drupal and into Wordpress MU. It would require me to build at least two Wordpress themes though (one for the front page/directory, and one customizable theme for individual podcasts), which wouldn’t be a trivial amount of work. So what I’m trying to decide is whether it’s worth the effort to either port it to Wordpress MU or to upgrade the modules, or whether it’s time to move on. I would love to get some honest feedback from people who use the site.

If you have a podcast on the site, don’t worry yet, I’m just thinking out loud. If we were to decide to shut the site down, you’d get all your data and we could set up redirects to your new hosting so search engines and iTunes/RSS subscribers wouldn’t miss a beat. We would make sure a transition went as smoothly as possible. And there’s still a strong possibility Mostly ITP would live on hosted on a separate site somewhere.

If you read part 1 of my tutorial, you’d hopefully know how to port a simple display widget from the Wordpress 2.7 procedural widget API to the new Wordpress 2.8 object-oriented widget API. You’d also know a little about why coding widgets are better than slapping a bunch of code in your sidebar. You did read it, right? No? I’ll wait, I’ve got time.

Okay, good. The part we didn’t cover because it would have made the tutorial ridiculously long was porting configurable forms for the widget admin area. So that’s what this part is about.

Read the rest of this entry »

Wordpress 2.8 introduces a new object-oriented Widget API (based on Alex Tingle’s MultiWidget class) which is an improvement over the procedural API for Wordpress 2.7 and before. It’s not a revolutionary leap, but it does make coding widgets which need to appear multiple times on a page easier, automates some administrative form handling, and makes code better-organized and easier to follow.

The bad news is the new API isn’t backwards compatible without a little work. So here is the first part of a multi-part guide for porting a Wordpress 2.7 widget over to the new Wordpress 2.8 API.

Read the rest of this entry »

With the economy in the crapper, there are going to be a lot of online services folding or cutting corners to survive. This is a good time to make sure you are keeping local copies of any work that is important to you.

Read the rest of this entry »

Have I mentioned before that I lurrrrve Dropbox? I lurrrrve Dropbox. You install a small program on each computer you want to access files on, the program runs in the background, and you never think about it again. Copy a file to the Dropbox folder on one computer, and it’s there waiting for you in the other computer’s Dropbox folder.

One of the nice features of Dropbox is it offers version control. So if something goes terribly wrong with a file, you can roll it back to an older version.

This set off a light bulb: hey, I could use this as an automagic CVS/SVN style code repository that I would never have to bother logging into and typing a bunch of arcane commands.

If you use the built-in Apache on Mac OS X for LAMP development like I do on my laptop, this is can be accomplished easily in a couple of steps:

1. Create a subfolder under your Dropbox folder. I called mine htdocs.
2. Open up the Terminal application, and create a symbolic link to the htdocs folder somewhere where the web server can see it. Your command might look something like this:

   ln -s ~/Dropbox/htdocs ~/Sites/htdocs

That assumes your Dropbox folder is stored under your home folder, and that your Mac OS X built-in web server has a pretty standard configuration where each user has a Sites folder.

If you followed the method I outlined above, you will then be able to access this folder in a browser at a URL that will look something like http://localhost/~<username>/htdocs/

If you want to get fancy about it (or if really long URLs bug you), you can edit your Apache config file to point to a subfolder in your Dropbox folder, but this works for me.

I suspect you could also easily use it to do version control on local MySQL databases by changing the data folder to a subfolder of your Dropbox. I haven’t bothered because I don’t have any data in my MySQL databases that matters much to me.

These tips come with no warranty. It’s possible you’ll run into some goofy permissions issues, but I have yet to.