How I cleaned my MailChimp mailing list

Back in August I did a little of spring cleaning and cleaned out my mailing list for my WordPress podcast network WPwatercooler.

The idea was that the number of opens and click through’s are pretty low and the number of people that were joining the show as participants was getting smaller so what I did is I took a list of all the people that were recently on the show for the last 12 months and added them to a do not remove list and then went through and removed all the folks that have never opened one of the emails and got rid of them. I went through and looked at all the people that haven’t clicked on the links in the emails and I set them with a special tag that I will at some point clear out. The reason why I did this is I wanted to figure out who the audience actually is and by having a bunch of people receiving the email I had this bit of a hesitation whether or not my efforts were actually worth doing sending out this weekly.

So a bit of background regarding this I send out an email each week asking people if they would like to be on the show. I also include links to the previous episodes so that they can view at their leisure and watch one of those episodes. I think it pretty important considering we have had some people on the show as speaking participants who have never seen the show before. Primarily these folks are marketers looking to get the word out about their thing, which is all fine and good except they don’t know any of the in-jokes or the reason why we make fun of a particular person or say a particular thing so really we would much rather have people on the show that have actually watched the show at some point in their life.

One thing I’m not a fan of is having big numbers for the sake of having big numbers when really those numbers should equate to actions that are occurring on the thing that I’m putting so much time and energy into. So by clearing out the closet of all the old craft I am able to really talk to the people that I know are engaged in the content are willing to participate and would like to be notified of the latest posts. I’m pretty happy with the results because with my 300 people subscribed to the mailing list I am able to determine that a good percentage of them are actually opening and clicking on the links. So far an average of 23% opens and 3.5% clicks is pretty awesome.

One of the other reasons why I wanted to clear out that mailing list is because I wanted to have a good idea as to whose actually doing what on the mailing list and are they actually involved. This helps me with running house ads on the mailing list as well as looking to see if advertisers are interested in running ads for my audience too.

Early on I started running ads for my friends products on the mailing list in hopes that I can drum up some data to determine how many people are actually clicking on those particular links. So far by including offer codes and other things like that I am seeing some click throughs which is pretty good. I think overall it’s a good idea for me to run a test like this so that way if potential advertisers are interested in running ads for a very niche market which WPwatercooler to be WPblab and CommunityConnections are that the advertiser or potential advertisers Well actually know that my mailing list is worth advertising on and will hopefully want to run an ad on the show as well.

Podcasting is a business is really interesting there’s a lot of moving parts with it from creating good content distributing the content tracking to see how many people are actually cooking on or doing things through that content and then using third-party tools to track how all of those efforts are resulting overall.

If you’re someone like me that has a mailing list and you’re noticing that your click through rates and open rates are really low I would highly consider going through your mailing list and seeing how much bait you can cut. Sending out emails to people that aren’t even going to look at the email let alone click on it or do we need type of actionable thing with it I feel isn’t worth sending an email to. Obviously there are many types of million lists and content and mailing lists that this very hard and fast rule doesn’t apply to you but to me and my content a lot of it has to do with actionable items.

Are you looking to get the word out about your WordPress product? Run an ad with us!

WordPress 3.6 “Oscar” version released: advanced autosave, Spotify

The latest version of WordPress, version 3.6, is now available and includes a beautiful new blog-centric theme, autosave and post locking, a redesigned revision browser, native support for audio and video embeds, and improved integrations with Spotify, Rdio, and SoundCloud.

Matt Mullenweg Co-Founder of WordPress speaking about the future of WordPress at WordCamp San Francisco 2013.

New features in the WordPress 3.6 “Oscar” release

  • The new Twenty Thirteen theme inspired by modern art puts focus on your content with a colorful, single-column design made for media-rich blogging.
  • Revamped Revisions save every change and the new interface allows you to scroll easily through changes to see line-by-line who changed what and when.
  • Post Locking and Augmented Autosave will especially be a boon to sites where more than a single author is working on a post. Each author now has their own autosave stream, which stores things locally as well as on the server (so much harder to lose something) and there’s an interface for taking over editing of a post, as demonstrated beautifully by our bearded buddies in the video above.
  • Built-in HTML5 media player for native audio and video embeds with no reliance on external services.
  • The Menu Editor is now much easier to understand and use.

Developer features

  • A new audio/video API gives you access to metadata like ID3 tags.
  • You can now choose HTML5 markup for things like comment and search forms, and comment lists.
  • Better filters for how revisions work, so you can store a different amount of history for different post types.
  • Tons more listed on the Codex, and of course you can always browse the over 700 closed tickets.

WordPress 3.5 can be downloaded from their website.

Author information

Jason Tucker

Web Developer at Tucker Pro

Jason Tucker is a web developer, systems administrator and a father of three. Jason owns Tucker.Pro a web development company and is host of WPwatercooler a weekly WordPress web development and design YouTube channel and podcast. Jason also blogs over at WPMedia.Pro where he talks about working with audio and video on the web.

The post WordPress 3.6 “Oscar” version released: advanced autosave, Spotify appeared first on Stabley Times.

Website Development Podcasts

I’m always looking for new things to inspire me in my work. Running my own company and not having anyone on staff to bounce ideas off of can seem tricky at times. Inspiration comes in may forms, and one of them for me is podcasting. I like the idea of listening to conversations even if I’m not able to participate.

Here are my fave WordPress and Web Developer podcasts:

ShopTalk Podcast – A live show about front end web design. By Chris Coyer and Dave Rupert
Your Website Engineer – Your Resource for WordPress with Dustin Hartzler

WP Late NIght is a roundtable discussion podcast about WordPress and the community surrounding it. Hosts Brad Williams, Dre Armeda, and Ryan Imel.
Aftertaste is the WPCandy show that starts when our other shows stop. Listen to casual WordPress talk with show co-hosts and interviewees.

CSS-Tricks Screencasts By Chris Coyier – CSS-Tricks Screencasts is focused on showing you tips, tricks, techniques about web design.
In Beta By 5by5 – In Beta is a talk show about the ever-changing state of web-based and open source software. Hosted by Gina Trapani & Kevin Purdy.

I’ll post my other fave podcasts at a later date. I’d love to add more to this list, if you know of any leave them in the comments below and I’ll share them here. What do you listen to?

Using Git with Dandelion for staging and production deployments.

I’ve been recently setting up my local development environment using a combination of a few pieces of software and web services to get this going. In upcoming blog posts I’ll be going over each of these in detail, for now here is my list:

  • DesktopServer
    Local development server that uses XAMPP and some magic. I’ve heard it described as “awesome” and “awesome in a bottle”, from the same person in the same sentence.
  • git
    The man page describes git as “the stupid content tracker”
  • Tower
    git for people that like a graphical user interface
    the remote repository where git will push my code to
  • Dandelion
    The secret sauce to pushing my ready for staging or ready for production code to the server(s)


So the part I’m going to focus on today is Dandelion which is a script that Scott Nelson on github created and describes as the “Incremental Git repository deployment”. What Dandelion does is something I don’t want to have to manage myself… anymore. You see I use to keep track of what files I changed and then only “deploy” the files I thought I changed up to production or staging if I had a staging server in place. What Dandelion does is it leverages git’s recent commit status to deploy only the changed files up to the webserver.. It’s pretty awesome.

The code is written in Ruby and is pretty simple to install and get running:

  • I followed these steps on how to get Ruby and RubyGems installed on my MacBook Pro running Mountain Lion. It requires that you install Xcode and the Command Line Tools to get it going.
  • Once Ruby and RubyGems are installed you need to load up Terminal and run the following:
    $ sudo gem install dandelion
  • You’ll also need to run the following as well:
    $ sudo gem install net-sftp
  • From there we can test that dandelion is working:
    $ dandelion
    Invalid command: 
    Usage: dandelion [options] []
        -v, --version                    Display the current version
        -h, --help                       Display this screen
            --repo=[REPO]                Use the given repository
            --config=[CONFIG]            Use the given configuration file
    Available commands:
        status    deploy
  • Now that we have Dandelion installed we just need to configure our production server so we can deploy our local get repo and it’s committed changes to production.
  • Create a new file in the root of your website directory. Mine live here: /Users/jason/Documents/Websites/ so I go into:  /Users/jason/Documents/Websites/  which is the directory that I use with DesktopServer for my site and create a new text file in there called dandelion.yml and input the following:
    # Required
    scheme: sftp
    username: myusernamehere
    password: mysuperlongCraz7Pazsw0rDh3re!2938474
    # Optional
    - .gitignore
    - dandelion.yml
  • Instead of repeating what the github readme says I’ll referrer you to here:
  • Optionally you can create additional file for your staging server if you like. If you do name it staging.yml and this one producton.yml and I can show you how to deploy to each by adding in a switch.

Tricking Dandelion into thinking we’ve already deployed (time saver)

Lets assume that recently downloaded a copy of your whole website to your local and haven’t done any changes at all yet. One thing that fustrated me when I used dandelion for the first time was that it wanted me to deploy EVERYTHING since it hasn’t taken note as to what hasn’t been deployed yet. What it does is it uses the SHA hash from git to figure out what it has deployed to the production site. So to get around pushing all those changes to the server I cheated and got the current SHA hash and tricked dandelion into thinking that has already been deployed for the first time. Here is how:

Execute Dandelion from the terminal while your present working directory is your website root folder, mine being: /Users/jason/Documents/Websites/

$ dandelion status
Connecting to s
Remote revision: ---
Local HEAD revision: 7e8116749a78890e599561b0d674311a512f839a

Notice how it’s reporting there is no remote revision, let’s trick it into thinking the current version is there (which it is for the most part). Create a new file on the remote server called .revision and put in that string of text from the output of ‘dandelion status’ we ran earlier.


then upload it to the webroot of the remote webserver, in my case it was ‘’  Now run dandelion status and you should see Remote revision and Local HEAD the same SHA hash. Now you can run dandelion deploy and it will deploy all of your changed files in that commit. We fancy now huh?

How to deploy to Production and Staging.

Dandelion has a great switch called “config” that allows you to specify which .yml  (in our case production.yml and staging.yml) that you want to deploy, it’s syntax is simple, just change the name of the yml you want to deploy to.

$ dandelion –config=staging.yml deploy

$ dandelion –config=production.yml deploy

Let me know how things go in the comments below.