Starting the Knoxville WordPress Meetup

Back in September, I started the Knoxville WordPress Meetup group, and we’ve been meeting ever since. Last week, Jane Wells, who does project management (and many other things) for the downloadable WordPress software, announced that the WordPress Foundation was working toward helping foot the bill and provide resources for local meetup groups, and she followed the announcement up yesterday with an account on her personal blog of how her startup of two local meetups had gone. I thought I’d update here with the progress of my little group as well.

We held our first meetup in October. I paid for the meetup.com registration out of my pocket (one of the things the foundation’s support will prevent the need for) and just proposed a time, date, and place. I tweeted about it and posted to Facebook, but these aren’t terribly great advertising channels for me, as most of the people who follow me on Twitter aren’t local (I’m a hermit in real life), and most of my local Facebook friends could care less about a WordPress meetup. I also have a hangup about spamming people. I was surprised when people started joining the meetup group and even more so when eight or nine of us showed up for the first meetup. We met at a Panera, and the agenda included basically a meet and greet, plus discussing what we might like to cover at future meetups. We settled on second Tuesdays at 7:30 as our general meeting times.

One of the attendees, Mike, whom I’ve known for upwards of a decade by now, happens to be on the board of a local organization that has a small space for coworking and community technology-related meetings. He offered the space for future meetups, and I took him up on it, not least of all because I’m shy about flying any sort of flag about myself and my interests in public places like Panera. A restaurant was great for a first meeting, but I was happy to have a dedicated, private facility at my disposal, and we’ve met there ever since. I’d say we could probably grow to 20 or so people in this facility before needing to find something bigger.

In November, we had a smaller crew, and though I had hoped that some of the WordPress novices (or at least those who blogged but didn’t really know much about theming or development) would show up to take advantage of what I had billed as a theming workshop, we were mostly a few developer types. I gave a little presentation about theming and we chatted a bit, but it wasn’t, to my mind, the most successful of meetings. I had hoped some of the more technical among us could help some of the less technical with specific problems they were having with their themes (hence the “workshop” title), but it wound up being me giving some info without any application of it. (That said, some of the info seemed to be new and interesting even to the developers who showed up.)

One of the challenges, when you’re a small group with mixed experience (ie, developers and non-developers) is finding a way to hold meetings that interest everybody. Topics that require too much technical knowledge will stink for the novices, and many topics that would be helpful for the novices would be a snooze for developers. As you get bigger and can break into smaller groups, I suspect this becomes less of a problem, but when you can count your attendees on one hand, or one hand and a couple of fingers, splitting up isn’t really a great option.

For our December meeting, we were again a smallish crew, and I gave a presentation on securing your WordPress blog. It seemed to be pretty well received, and of course, although I was giving a presentation, we also had back-and-forth and sidebars where needed.

I was too lazy busy over the holidays to put together any sort of presentation, so for our January meeting, I proposed the topic “Bring a Question or Problem,” figuring that even if those present didn’t know the answers offhand, we could go hunting for answers and help each other out. With eight confirming that they would attend, I thought we might be on the verge of having a lift in our attendance numbers, but only five of us showed up. Still, there were some good beginner questions and one slightly more technical question I really enjoyed trying to help out with. The format here worked very well for our small group. Mike proposed in the Meetup forums that even when we have some formal topic or presentation, we keep it fairly brief and dedicate a hefty chunk of our time to Q&A, and I think he’s got the right idea. Of course, if nobody has any questions, I guess we’ll wind up having a short meetup.

So, there’s a history of the Knoxville WordPress meetup to date. Our regular time slot in February falls on Valentine’s Day, and I’m working on trying to figure out whether to cancel or move the meetup. Our topic will be “Squeezing Performance out of WordPress” (something I need to read up on a bit beforehand). This is one of those tricky ones that would be easy to make too technical for novices and not technical enough for developers, so finding the right balance may be tricky. I’ll probably err to the side of simplicity but try to have a little more technical info in my back pocket for any sidebars that come up among the developers.

Our meetup page boasts 23 members, though we’ve never yet beat the attendance record we set at our first meeting. Those of us who have shown up pretty regularly seem to have a good rapport, and I enjoy the meetups. They force me to formalize some of the vague knowledge I have about using certain features of WordPress, which is part of why I started the group to begin with.

Stage

For a long time at my day job, one of our big web site issues has been the staging of database-driven content. Particularly if you’re editing Drupal pages that have a lot of markup in them, publishing a node can be sort of scary, as it goes live instantly with any bugs you’ve introduced. In theory, Drupal’s preview feature can be used to view your changes before you commit to them, but this too is scary, as the content isn’t rendered exactly as it will be once published. Further, using vanilla Drupal with its preview function to stage content requires that you roll out changes one by one. If you want to group changes for a mass rollout, the best you can do is wrap your changes in html comments and uncomment them one by one during deployment, hoping you don’t fat-finger anything in the process. I’ve always thought this would be a pretty difficult problem to solve, but yesterday, I came up with what feels like a satisfactory method for staging content.

The new stage module addresses both safety-netted staging of individual content and management of change sets.

It works by tapping into Drupal’s revision system, which already allows you to track changes to content over time and to revert to older content. For specified types of content, any additions or edits are published using the normal Drupal workflow, but on publish, the revision number is pinned at its last blessed point. You can edit or add any number of documents, and they all remain pinned at their pre-edit revision until you roll the whole batch of changes forward. When you roll a batch forward, all the revision numbers are brought to their most recent and pinned there until the next deployment. In the administration section, you identify staging and production servers. If you view an affected node from one of the specified staging hosts, you see the latest copy; if you view it from a production host, you see the pinned version.

This workflow is ideal for environments in which fairly frequent milestones are deployed. Because of Drupal’s handy dandy revision system, you can compare versions of the content across pushes to see what’s changed.

The module is hot off the presses this morning and so is probably still buggy and feature-poor, but it’s a start.