With a free dB meter, I’m watching this train average 90dB’s the entire way through the tunnel.

This morning’s train was pushing 100dB’s. Surely this is bad for everyone’s hearing. I felt compelled to use my earplugs rather than gut it out.

I guess a shout out to Earlove is in order

Fortunately, I’ve run across a couple scripts to fix the problem.  Unfortunately, by the time I need to migrate another site I usually forget where the scripts are.  To allay this problem the next time I migrate a site, I’m putting the links here so I’ll have them forever.

The normal one I use is by a guy named James:

http://www.bangheadonwall.net/?attachment_id=227

fix_serialization.php

I’ve used this many times with no incident.

And in the  course of writing this blog I came across another which looks more general, well-written, and sounds like it would do the job just as well.

http://interconnectit.com/124/search-and-replace-for-wordpress-databases/

searchreplacedb-1.0.2

Hope this helps someone else out there.  And if it doesn’t, well, at least it helped me….

The problem is that Reverbnation doesn’t actually provide an iCal url for easy consumption. They have an RSS feed, but things like Google Calendar can’t import that. So I wanted to convert the RSS feed into an iCal format. I could have set up a daemon on my own server to do the conversion, but I wanted to come up with an option that would be possible for others, too.

I eventually tried doing the conversion with Yahoo! Pipes. You can see the pipe here:

http://pipes.yahoo.com/stackedsax/reverb

Click “More options” and grab the iCal link.  Use the link to import into whatever calendar program you use.

For others to use this for your band, you can

1. ‘Clone’ the pipe
2. ‘View Source’ on your copy
3. Change the first step of the pipe to use your Reverbnation feed.  ie:
   • SELECT * FROM rss WHERE url=”http://www.reverbnation.com/rss/artist_shows_rss/justinancheta”
   • SELECT * FROM rss WHERE url=”http://www.reverbnation.com/rss/artist_shows_rss/mybadassband”
4. You can then grab your own iCal and use for your own purposes like importing the iCal into Google Calendar.

A caveat: occasionally the iCal from the pipe wouldn’t come up, and I couldn’t figure out why — possibly ReverbNation thinking Pipes was trying to DOS it? I would flip between Pipes V1 and V2 and it would start working so I believe Reverbnation might be blocking Yahoo!’s servers after a certain number of requests.  Switching to V2 servers made things work for a little time and then it would be blocked again.  However, this is just a theory.  I’d be interested to see if others find it to work reliably.

I posted this workaround on a thread on ReverbNation’s support page, and it looks like some others have already used it to good end.

Again, this isn’t the solution that I ultimately ended up using — read all the other ArtistData poss for that — but it’s one way of attacking the problem of your fellow musicians’ ineffective communiction skillz.

Continuing my saga of building a better band website, I spent a lot of time smoothing out my approach to keeping the band’s schedule in line on all of the ziillion sites that list band dates.

The goals were these:

1. Have a single place to enter dates.  Two places is too many.
2. Update the various social networks with new show dates (Facebook, MySpace, Twitter)
3. Update tons of other entertainment-related sites that we have profiles on, in particular making sure ReverbNation is updated
4. Be able to show the concert dates on my personal calendar without any extra work from me.
5. Be able to show concert dates on our WordPress site in a visually-pleasing manner.

The simple answer is that I employ Artistdata as the central source of truth for all of my bands’ dates. They handle the first three very well, and you can read for yourself all the sites that they update. The details, however, warrant a lot of conversation.

I’m going through all of the pieces of this puzzle one by one. Here, I’ll discuss what I did to get my dates displaying on my website via a custom WordPress plugin.

ArtistData WordPress Widget

Once I knew that the calendar dates would get disseminated far and wide on many other sites, I turned to the question of displaying the dates on our own website.

Sure, I could have used the HTML widget that ArtistData or any number of other sites would provide for us, but with all of them I found that it would be difficult to customize the look and feel in just the right way.  I could do it, but it might take just as much time to code my own widget as it would take to hack apart someone else’s HTML to suit my needs.

At first, I hunted down the question of whether I could make ArtistData join forces with GigPress, an existing WordPress plugin that handles calendaring for band sites and provides a bunch of widgets and shortcodes for band-specific purposes.

While I could get ArtistData to update GigPress’s database with new and changed dates, there was no way to do the reverse.  Since ArtistData doesn’t have an API to programmatically update show dates in their database, I was stuck with one-way replication.  If anyone made a change directly on the WordPress site, that change would never make it back to ArtistData and would never update the rest of the sites that carry our information.

I decided that I would just roll my own WordPress plugin.  We will manage event stuff only at ArtistData, not in two places.

I looked at the features the GigPress provides and modeled my plugin around providing those same features.  So far, I have implemented shortcodes, sidebar widget, and template tags.  I have inly implemented a handful of the 15 or 16 variables that GigPress offers with their shortcodes, but they’re enough for my personal needs at the moment.  I haven’t done the bits around custom CSS and custom HTML, but I think that should be fairly quick work when I sit down at this again.

As part of this plugin, I spent a lot of time investigating proper ways of writing a wordpress plugin.  There are a lot of really bad examples out there, but I took my initial cues from Jay Fortner’s site.  I’d like to believe that the plugin that I wrote is a reasonably clean and intelligently laid-out plugin.  It sure beats a lot of the dross I’ve encountered in other plugins.

You can see the work in progress on this plugin in a couple different places:

• http://www.frobeck.com/shows/
• http://www.justinancheta.com/shows/
• http://www.powers-that-be.com/shows/
  

All of them need some work on the front-end details.  I got to a certain point with my redesigns of all these sites and then got distracted by other projects.  I’ll probably return to these to finish up the details in another couple weeks.

The main question is what to do about offering the plugin to others.  I’ve spoken to the developers at Artistdata and they expressed interest in the plugin.  We have yet to sit down and discuss the options there, though.  I could alternatively offer the plugin as a purchased WordPress plugin, or just offer it up for free.  I’m somewhat interested in selling the plugin for downloads, if only because I’d have a reason to figure out the infrastructure to do all that.

For the moment, I’m going to see if there is any more interest on this conversation or this suggestion or this suggestion to see if interest in this plugin is sufficient for me to continue doing the work to release the plugin to the world somehow.

Continuing my saga of building a better band website, I spent a lot of time smoothing out my approach to keeping the band’s schedule in line on all of the ziillion sites that list band dates.

The goals were these:

1. Have a single place to enter dates.  Two places is too many.
2. Update the various social networks with new show dates (Facebook, MySpace, Twitter)
3. Update tons of other entertainment-related sites that we have profiles on, in particular making sure ReverbNation is updated
4. Be able to show the concert dates on my personal calendar without any extra work from me.
5. Be able to show concert dates on our WordPress site in a visually-pleasing manner.

The simple answer is that I employ Artistdata as the central source of truth for all of my bands’ dates. They handle the first three very well, and you can read for yourself all the sites that they update. The details, however, warrant a lot of conversation.

I’m going through all of the pieces of this puzzle one by one. Here, I’ll discuss the nuances around how to get the ReverbNation dates to update from the data in ArtistData.

ArtistData to ReverbNation

This part of the integration was tricky to figure out.  A lot of my bands liked updating at Reverbnation and didn’t want to lose the fans who checked the info on this site.

The problem was that getting the data out of Reverbnation was difficult.  There is an RSS feed, and that is good enough to power a basic wordpress widget, which is one o my needs.  But there was no iCal feed, so I was going to have to build that functionality somehow if I wanted easy integration with my calendar.  I’m extremely lazy when it comes to putting dates into my calendar, so I need it done for me automatically or else I’ll never show up to my gigs.  Solving the iCal part of this was a must and was where ReverbNation fails to provide.

I did take a crack at converting ReverbNation’s RSS feed to an iCal format by creating a Yahoo! Pipe with this experiment.  But I found that this pipe wasn’t perfectly reliable and I could never tell whether it was something I had done or whether it was some inherent wonkiness with Pipes itself.

Fortunately, ArtistData provides both an RSS and an iCal feed.  The problem with using ArtistData as the source of truth for all the concert dates was that ReverbNation didn’t seem to be able to import from an external feed — and it certainly didn’t import from ArtistData.

After a lot of research and talking with ReverbNation support, I discover a somewhat-secret feature of ReverbNation: they DO read feeds from JamBase, BandsInTown and Eventful.  You just have to create a profile on one of those other three sites and then email support(at)reverbnation(dot)com and ask them to hook it up.

ArtistData, meanwhile, sends event data to all three of those sites, so putting in a calendar date in ArtistData should wind up getting to ReverbNation eventually.

It’s not a perfect solution.  The updates to JamBase/BandsInTown/Eventful can take a day or two to register.  ReverbNation only scrapes data from those sites every Friday morning, so your update can sometimes take a little over a week to make it to ReverbNation.  Not great if you have lots of sudden gigs, but good enough for now.

In response to Jon Burr’s question, here’s a breakdown of what to do:

1. Login to ArtistData
2. Go to Tools -> Concert Databases
3. Go to BandsInTown, Eventful, and Jambase and make sure each one is activated
4. Add a new show in Artistdata.  These should get posted to BandsInTown/Eventful/Jambase within a few days
5. Email support(at)reverbnation(dot)com and ask them to hook up feeds from these three sites to your ReverbNation account.  Here’s what I wrote to them:

Hi there,

I’ve been a part of this discussion:

http://support.reverbnation.com/reverbnation/topics/rss_feed-tpzqv?from_gsfn=true

And I’d like to add some feeds to one of the bands I play with, the Justin Ancheta Band.

His Reverbnation account is:

justinancheta
http://www.reverbnation.com/justinancheta

The relevant links on Jambase and Eventful are:

http://www.jambase.com/Artists/60971/Justin-Ancheta/Shows
http://www.bandsintown.com/JustinAncheta/upcoming_events

I’m not sure if Eventful has a pertinent link for Justin yet, but it does have a few of his shows listed:

http://www.bandsintown.com/JustinAncheta/upcoming_events

Thank you very much for hooking this up,

.:alex:.

And they got back to me the following day letting me know that it had been hooked up.  For the record, they only hooked up our JamBase feed, but it seems to be working just fine.  I never could quite figure out whether I needed to set up accounts on BandsInTown/Eventful/JamBase for this all to work, but I did anyway.

At the end of the day, the ability to update in just one place and having to wait a couple of days for the event to make it to ReverbNation is far better than relying on someone in the band remembering to update multiple websites with the date information.  Making things as simple as possible, even at the cost of the speed of the update, seems like a reasonable trade-off.

Since this blog is focused on WordPress sites, the solution here is to employ two tools:

• W3 Total Cache
• Cloudfront

W3 Total Cache is a free WordPress plugin and Cloudfront is a Amazon service.  Combined, the two tools do almost all the heavy lifting and relieve the burden of serving 5 billion individual requests for your homepage when the fans come looking for the tour dates announcement.

W3 Total Cache

I used to use WP Super Cache for some WordPress websites I created in the past, but a friend pointed me to W3 Total Cache and I instantly fell in love.  In particular, the minification an CDN integration pieces were what I needed, and W3 Total Cache has what I required.  I want to discuss the CDN integration only for the moment.

Amazon Cloufront

Cloudfront is one among a bevy of cloud services Amazon provides.  It edge serves your files, meaning.  Services such as Akamai and Limelight are probably faster and have more features, but they’re expensive and most of us couldn’t even afford to think about their pricing tiers.  Amazon’s services, meanwhile, only require that we have a Amazon account and so far this elaborate and high-tech setup has cost me well under a dollar a month.

Setup:

Create a Cloudfront distribution using Origin Pull

In times past you had to use S3 in order to use Cloudfront.  You then had to set up some crazy sync from your website to S3 and tell Cloufront to pick up your files from S3.  Don’t do this!  It’s no longer necessary!  There’s a simple way!

Instead of using S3 as the origin for your files, you can now set your website to be the origin directly.  If someone asks Cloudfront for a file it doesn’t have, Cloudfront will quickly grab the file directly from your website, cache it, and serve it.

Of course, things are never quite so simple as they first would appear.  As of the writing of this article, Amazon’s web interface wouldn’t let me set my website as the origin.  So even though you CAN set any site as the origin, Amazon’s tools won’t let you set this setting.  When I entered “http://www.frobeck.com” as the origin, Amazon’s GUI automatically changed this to “http://www.frobeck.com.s3.amazonaws.com”.  Not good.  No way around it as far as I could see.

Which left me looking for some other tool to set this setting properly.  A bunch of tools would let me interface directly with the API, but that was overly nerdy for me in this particular moment.  Instead, I just used a trial version of Bucket Explorer.  To set a custom origin with Bucket Explorer:

1. Login (the hardest part for me because I couldn’t paste my Access Key)
2. Click “Distribution”
3. Click “New”
4. Click the “Custom” tab
5. Check “Set Custom Origin”
6. Set your “DNSName” to your website’s url (http://www.frobeck.com in this example)
7. Set HTTP Port to 80 and HTTPS Port to 443
8. Go back to the “General” tab and create 4 CNAMEs (at least):
   1. cdn.frobeck.com
   2. cdn1.frobeck.com
   3. cdn2.frobeck.com
   4. cdn3.frobeck.com
9. Set a description for this distribution in the Comment if you like
10. Click “Create”
11. In the distribution list, copy the “Domain Name” that was created for this distribution.  We’ll use it in the next step.

Step 1: Create 4 CNAMEs

Yeah, I had you add 4 CNAMEs to your distribution.  Seems crazy and stupid.  But this will allow us to take advantage of a feature of W3 Total Cache in a later step.
My VPS runs WHM, so in cPanel, you’d do something like:

1. Click “Simple DNS Zone Editor”
2. In “Add a CNAME”, enter:
   1. Name: “cdn.frobeck.com”
   2. CNAME: <the “Domain Name” from Step 11 in the previous section>
3. Click “Add CNAME Record”
4. And repeat for every CNAME you need created.  Every cdn[x].frobeck.com will point at the same Cloudfront distribution.

Set the settings in W3 Total Cache

In General Settings:

1. Go to the “Content Delivery Network” section
2. For “CDN”, check “Enable”
3. For “CDN Type” check the first option, “Mirror”
4. Click “Save Changes”

Switch to the “CDN” settings panel.  Then:

1. For “Replace site’s hostname with”, enter: cdn.frobeck.com
2. Click Add CNAME
3. Repeat Step 1 for the other 3 remaining CNAME’s, cdn[x].frobeck.com
4. Click “Save Changes”

Total cache will use these CNAMEs to deliver certain specific files.  cdn.frobeck.com will serve the CSS, cd1 will serve JS in head, cdn2 the JS after body, and cdn4 for the JS before the body.  When a modern browser sees these files, it will download them all in parallel since they re coming from different hostnames.  If we came from a single hostname, those files would block each other and downloading would happen in serial.

I could go into a lot of other very fancy features that I’ve set with Total Cache — but I’m wait until another blog for that.

That’s it!

There’s not that much to it. Create your distribution, create some CNAMEs, set a few settings in W3 Total Cache and you have a hassle-free, cloud-enabled site. This approach is dirt cheap, totally simple and well worth the 20 minutes it will take you to set it up. You can always get even fancier later with your CDN, but with this setup you’ll be better prepared for your million-strong fanbase.

In particular, I’ve been madly doing all the sites for the bands I play in.  I finally got fed up with them either being:

• non-existent
• bad
• in flash
• ugly
• never updated
• embodying everything that truly bad band websites embody

They might not have been that bad, but it felt that way to me.

I set out to accomplish a couple things with the new sites:

• allow all band members to update them
• make them look better
• have a single source of truth for all show updates
• ultra-simple music player
• put the right infrastructure for when we get really wickedly super-famous

There’s a lot of meat in these topics.  A lot of people do band websites badly, and the reason is that there are tons and tons of options to wade through — a lot of them bad.  I’m going to pick through the details in a series of blog posts, each one aimed at one of the subjects above.

Stay tuned.  I’m going to start on the first in the series right now.