The heart-breaking story of a code baby

The world of WordPress in 2007 was very different than it was today. It was newer and much smaller (it certainly was not powering 26% of the internet), but as designer and developer with only static HTML websites under my belt, it was a great entry point to building dynamic, content-managed websites, so I dove in.

In those days I primarily designed and built small websites for bands, and they all had one need in common: they needed to list their live shows and tours. The plugin landscape for managing events was grim – my options were either plugins meant for generic event listings that offered almost none of the features a band would typically need (with obtuse management interfaces), or plugins which were poorly-supported and quickly-abandoned. So I read the first few chapters of PHP and MySQL for Dynamic Web Sites and wrote GigPress 1.0.

For the next couple of years GigPress was my baby, getting frequent updates with new features, internationalization, custom templates, and much more. But much as GigPress was built because I needed it to exist, so too did it languish when it was no longer essential to me. Eventually I started using other CMS’ more often than not, so my passion and impetus for improving GigPress fell off a cliff.

For several years I kept GigPress alive via mostly bug fixes and compatibility updates. Last year I finally decided that the best hope for bringing my baby from its extended adolescence into adulthood would be to find it a new home. I started poking around, and it didn’t take long to find The Events Calendar and Modern Tribe.

I think the team behind The Events Calendar is a great fit for GigPress for two key reasons.

First, they have years of experience building tightly-executed and finely-focussed features which serve the specific needs of someone managing events in WordPress. Some of the top feature requests for GigPress (syncing Facebook events; calendar views; front-end event filtering; ticket sales) in fact already exist as add-ons to the core Events Calendar product.

Secondly, they are an established company with a long history working with WordPress, and they have a business model that’s sustainable. You can give away your plugin for free all day long, but as soon as you hit a certain scale, support becomes a burden, and creating revenue from plugins in WordPress takes an infrastructure which is prohibitive for many small developers. Modern Tribe has a formula that works, and which can ensure that GigPress stays active and relevant for the long haul rather than slowly dying of neglect.

These folks seem genuinely excited about supporting GigPress users and taking the plugin to the next level (if you’ll pardon my terrible cliché) in the coming years.

But what does it mean for me, the charismatic drummer/webmaster whose band is positive they’ll break big if they can just get that opening slot on next year’s SXSW Party Poppers Hot Wings afternoon stage?

Here’s what this means for the 20,000+ of you who use GigPress on a regular basis:

• GigPress will continue to work as it always has, receive updates, and offer support – only now it will be the folks at Modern Tribe on the other end of terminal as opposed to my pallid visage.
• GigPress as it is today will always be a free, open-source plugin (after all, it can’t really be any other way).
• Eventually, once Modern Tribe is able to make available feature-parity with GigPress, there will probably be an upgrade path to The Events Calendar, or some version of it.
• I think that’s it.

Thanks to everyone who’s used GigPress on an ongoing basis, those who’ve evangelized for it, and also those who’ve thrown a few bucks my way over the years. This tool (GigPress, not me) is in good hands, and it’s only going to get better from here.

For more info on the acquisition from the Modern Tribe folks, check out their announcement and the related blog post on The Events Calendar website.

Version 2.3 of GigPress, which I released over the weekend, now gives you the option of outputting structured data markup into your GigPress pages. This replaces the old hCalendar markup which was previously included in the default GigPress templates, and which was frankly always a little unwieldy to implement properly.

The new structured data output uses JSON-LD format, which is output into the body of your page inside of the script tag, letting it be completely separate from the markup which displays your shows on the page. You can read more about it on the Google Webmaster blog, where they just announced this new feature.

If you’re installing GigPress for the first time, this option is enabled by default. If you’re upgrading from a previous installation, you’ll need to enable it by visiting the GigPress Settings page and checking the box for outputting structured data. Version 2.3.2 enables structured data output even when upgrading in order to increase adoption.

But it’s not often we get the luxury of rewriting projects that work sufficiently as they are, and that don’t actually help sustain us financially (as much as writing software that people use and love may sustain us on other levels). So, I finally decided to abandon that dream for now and get to work on adding some requested features and cleaning up a few things.

GigPress 2.2 is no ground-breaker, but it should be a welcome update for most. Check the changelog and review the updated docs for the details.

I hope this finds you all with heads above water, making your way through the bizarre labyrinth of existence with limbs intact.

The next planned update is version 2.2, which I hope will include some sort of “I’m Attending” feature, a “pending” show status, and perhaps an overhaul of permissions in GigPress (basically mimicking WP’s roles and permissions). But time will tell!

I just committed version 2.1.9, which as usual fixes some bugs and tweaks a few things. I’m also happy to say that based on testing with the WordPress 3.0 Release Candidate, GigPress is good-to-go for 3.0.

Thanks as always for the support and kind words about GigPress. Stay classy.

• GigPress 2.1 requires WordPress 2.8 or newer, and is fully-compatible with WordPress 2.9
• The GigPress widget has been overhauled for the better (multiple instances, and some new options), but this means that existing widgets will need to be reset due to the changes
• Along with the widget changes comes changes to the gigpress_sidebar() function.  If you currently call this function directly (as opposed to using the widget), you’ll need to make a quick update your template.  Refer to the updated docs for details.
• There are a couple of variable changes for the sidebar-list-footer template regarding the display of the feed links and the link to the main shows page. If you’re using a customized version of that template, a quick look at the new default sidebar-list-footer.php will show you the way.

Be sure to review the docs for the new monthly/yearly archive menu and implement it on your site if it makes sense.  It’s been an oft-requested feature, and I think folks will find it very useful.

First, though, I want everyone to be aware that as of GigPress 2.1, GigPress will only be fully-compatible with deprecated versions of WordPress for 6 months after a major point release. This means that I’m discontinuing support for WordPress versions prior to 2.8 with GigPress 2.1, and with the imminent release of WordPress 2.9, I will only guarantee that updates will be compatible with WordPress 2.8 until mid-2010.

At this point WordPress is a very mature platform with an excellent auto-updating mechanism. There is no good reason to run outdated versions. The number one reason people cite — plugin incompatibility — is a sign of a larger problem. Any plugin that isn’t compatible by default — or cannot be brought up to speed with minor changes — is a plugin that is not fit to run, as chances are it’s not using official APIs. Maintaining compatibility with old versions of WordPress prevents me from embracing new features, and generally makes development a PITA.

OK, onwards. The two major updates in 2.1 are an overhauled widget and a new front-end date filter.

The new widget uses the excellent widget class introduced in WordPress 2.8, meaning you can now have multiple instances of the GigPress widget, all with discrete settings. I’ve also added the ability to filter the widget listing by artist, tour, or venue.

As part of the widget changes, the gigpress_sidebar() function got an overhaul as well, now behaving much like the gigpress_shows() function. This means changes to your templates if you’re calling the function directly — the docs will be updated when 2.1 is released with instructions.

The new date filter is a dynamically-created dropdown menu that lets visitors filter any list of shows created with the GigPress shortcode by year or by month. The menu can be created either by adding a new parameter to your existing shortcode (show_menu=yearly or show_menu=monthly), or by calling it directly via its own shortcode (or directly in your templates as a function).

I’ve also added both year and month parameters to the GigPress shortcode, so you can limit your initial display of shows to a particular date range. This means, for example, that if you have 3 years of past shows, you can write your shortcode with a year parameter of the current year (or perhaps a limit of n shows), and then include the date menu to allow filtering of past shows to display shows only from specific months or years. (When using the date menu, any limit parameter in your shortcode is ignored.)

I’d like to get some folks to install the 2.1 beta and put the new features through their paces before I release this into the wild — especially people who use GigPress with multiple artists, or who have a large database of shows. If you’re interested, please drop me a line and I’ll hook you up.

Some of the new features have already been covered in the previous post, but I’ll recap here and touch on some of the other additions as well.

I do strongly encourage you to read the updated documentation — it explains the new shortcode parameters, templating and other features in more detail. Please also note that GigPress 2.0 requires WordPress 2.6.5, and that due to the scale of the rewrite, this release only includes localizations for Bulgarian, Dutch, French, German, Norwegian, Russian, and Swedish. Hopefully more translations will come in soon.

New features

GigPress now supports multiple artists — perfect for record labels or booking agencies. If you’re using GigPress for a single artist or performer, don’t worry — the multi-artist feature won’t get in your way. If you only have a single artist in the database, GigPress won’t needlessly display your artist name.

Venues are now saved in the database — no more re-entering data for shows played at the local clubs or anywhere else. You can easily add new venues on-the-fly when adding a new show as well, and edit venue info at any time.

GigPress is now completely template-driven — customize some or all of GigPress’ output using modular templates for both the main shows display and the sidebar widget. From small language changes to complete rewrites of the HTML, it’s up to you. All of your changes are safe from plugin upgrades, so customize-away.

More calendar-iffic-ness — GigPress now includes both Google Calendar and iCal download links for each show, plus an iCalendar feed for all shows, each artist’s shows, and each tour’s shows. RSS feeds have also been added for each artist’s shows and each tour’s shows.

Import from CSV — import a history of past shows, or move shows between GigPress installations using the built-in CSV export. Artists, venues and tours will be matched-up and/or created during the import process, and duplicate shows will be skipped.

Some other changes of note:

• The age restrictions menu is now customizable — add any type of age restrictions you like to the “Age restrictions” dropdown.
• You can now control the title of automatically-created related posts using simple tokens which represent the artist, date, city and venue of the related show. Plus, you can choose to publish the related post on the day of the show (for those using a future-posts plugin.)
• You can now optionally display full country names instead of country codes.

As always, please review the changelog for the blow-by-blow.

A note about tours in GigPress 2.0

The behaviour of tours has changed somewhat in version 2.0. First, tours no longer have a display order — instead, they are dynamically grouped within the list of shows, with a heading, and then with a CSS class applied which makes them visually distinct from the other shows. Because of this, the “group by tour” option is gone, as tours are always grouped, but within chronological order.

So if you have 3 shows, then a tour of 5 shows, then a break with 2 one-off shows, then the tour resumes with 5 more shows, all of the dates will be in proper order, with two groups of shows for the tour, each with an inline heading, each visually distinct from the non-tour shows.

Those of you who have been using “tours” as “artists” pre-2.0 can automatically migrate all of your tours into artists by visiting a special URL on the new “manage artists” screen, like so:

http://yourwebsite.com/wp-admin/admin.php?page=gigpress-artists&gpaction=import-tours

Also of interest

I’m now handling all support for GigPress through Get Satisfaction. This will hopefully help GigPress users learn from each other by searching the support history there, and subsequently cut down on support emails.

I’ve also setup a Twitter account for GigPress, so you have another avenue by which to get news of updates and pending features — or cool examples of GigPress in the wild — pushed your way.

And lastly, you’re reading this on the newly-designed GigPress website. Not really my usual design aesthetic for sure, but I thought this would be a good place to play with a slicker design style, and use some progressive-enhancement with CSS3 properties and transparency. I hope you like.

I welcome your feedback as always. (As well as your donations!)

UPDATE: I may have lied about the whole “no templating” thing. And it’s looking like this will actually be GigPress 2.0, not 1.5. That’s it — carry on!

So, what’s new in version 1.5? The big feature that I’ve been asked about (and promising to deliver) for a while is multiple bands. Labels and booking agencies will be happy to hear that multi-band is finished and ready to go for GigPress 1.5. On upgrade, all of the shows in your database will be assigned to your first artist, which will be created based on the contents of your “band name” setting. From there, add as many artists as you like, and choose them from a drop-down when adding new shows. The tours feature remains of course, and you can have multiple artists on the same tour (tours relate only to shows, not directly to artists).

With more data to manage for each show, I decided it was time for the upcoming shows administration to get overhauled. As you can see below, it’s now much easier to find specific shows, with a unified screen that gives the ability to filter based on date (past or upcoming), artist, tour, and venue. Plus, shows in the admin are now paginated (as are all other relevant screens in the GigPress admin).

Shows administration in GigPress 1.5

As you might have gleaned from the screenshot above, while re-engineering the plugin to add the new relationship for artists to shows, I decided to honour another oft-requested feature, which is a venues database. Apparently a lot of you folks play the same venues frequently, and are sick of re-entering it all the time (despite help from browsers’ intelligent form-filling). When you upgrade to GigPress 1.5, your new venues database will be automatically populated with all of the venues previously played.

This step and some other design tweaks have (I think) made the add a show screen much more user-friendly, easier to digest, and more efficient. Here’s a little QuickTime snippet of it in action:

So what else? Export to CSV has been updated and improved to comply with the new multi-band setup, and you can now import shows from a CSV file (a properly-formatted CSV file of course). I’ve done my best to ensure that you can import shows right over your existing database without fear of duplicating data, and after trying to match up the imported shows with existing artists, venues and tours, the import will create new artists, venues and tours if necessary. (I’m still working on the import process, it being the remaining 10% of the admin-side work to be done.)

From here, there’s a lot of front-end work to be done to incorporate the multi-artist aspect and figure out how to best present this new level of hierarchy. I also plan on expanding the capabilities of the [gigpress] shortcode, with the ability to control grouping, filter by artist, etc. The RSS feed is also getting the ability to filter by artist, tour, venue, or any combination thereof by using a simple query string in the feed URL. I’m also hoping to add pagination to the front-end (even if I’m not entirely sure how yet, haha).

What’s not going to be in GigPress 1.5? Templating. Any sort of templating. Sorry, I really wanted to, and spent a lot of time thinking about it, but there are just too many conditionals involved, and I’m not about to write my own template parsing engine. For now, you’re stuck with the markup I write and the classes I add.

After I get the front-end stuff finished, I have to send out updated language files to all of the kind people who’ve translated GigPress into 15 different languages. So, I can’t promise when you’ll see it in your plugin update notifications, but hopefully sometime in September.

One last note – GigPress 1.5 will only be compatible with WordPress 2.6.5 and higher, so if you’re running an older (and consequently insecure!) version of WordPress, and depend on GigPress for your site, consider this your call to upgrade.

That’s it for now. Thanks for all the kind words and support for the plugin. If you’re as excited as I am about version 1.5, maybe consider making a donation to the cause?

I’m stupidly busy right now, and I don’t see it letting up anytime soon, so major updates (like, uh, multi-band and pagination support) may be a little ways off, sorry to say. I am a terrible person, I know.

I made a number of architectural changes to GigPress in version 1.4, and one that apparently didn’t get as thorough a review as it should have was the upgrade function that checks to see if anything needs to be added to GigPress’ database tables.  Hence the typo.  Hence the piss-poor performance that some of you have seen.  (Why this only affected some hosts and not others I don’t fully understand … perhaps some sort of SQL caching at work?) 

So please, everyone, upgrade to version 1.4.4 and let me know if it resolves your performance problems (well, the ones related to GigPress that is – if you want help with your other, more personal performance problems, that costs extra). I’m still looking for someone who might review how GigPress builds its queries to see if we can bring the number of queries down however.

This version also adds a couple of new small features and a couple of new translations — see the release notes for details.