dev

Upgrading old WXR files with wp-cli

Leave a comment

I recently had cause to try to import an old WordPress WXR export file into a more recent version of WordPress. There are some simple differences in the way the old files and the new files are formatted that keep this from working. The usual rigamarole for getting around this is to install a throwaway copy of the version of WordPress that the export file was generated with, import the file, and upgrade WordPress until you’re at the latest version. Then you export and the WXR is updated. That’s kind of painful and lame, though.

So, riding the wave of my recent fervor for wp-cli, I made a wp-cli command for doing the conversion. It’s called… convert-wxr.

Usage looks like this:

wp-cli --file=file-to-covert.wxr --outfile=converted-file.wxr

If you don’t specify an outfile, it just spews to the screen (you can redirect output to a file). It won’t clobber an existing file.

The script just does some simple regular expression and string replacements based on the differences I found between older and more recent WXR files. It’s entirely possible I missed some differences, but the conversions I tested seem to work well enough.

Colorized Svn Diffs in Sparrow

Leave a comment

For a year now, I’ve had mail forwarded from my work email to my personal so that I could check mail in only once place. With some vacation on the way and not wanting to have thousands of messages keeping me from efficiently checking personal mail via my phone while computerless for a week, I decided to split the accounts back up. But I don’t want to have to check two accounts for mail on a daily basis, so I wanted to use a mail client. I had been using Sparrow to check mail on my phone and liked it quite a bit. This morning, I downloaded the app for my computer and also gave Thunderbird (which I used for years) another quick spin.

Well, I’ve become such a junkie for the Gmail way of doing things that using Thunderbird’s just not tenable. It feels like I’m using a TRS-80 or something, and the lack of threading by default (maybe you can get an extension to handle it) made me cringe. Sparrow provides a much nicer user experience and handles the threading beautifully, but it doesn’t do anything smart for colorizing svn diffs, which I’ve written about before as a problem with the default Gmail experience.

I decided to see if I could fix this, and it turns out that you can. Just go into /Applications/Sparrow.app/Contents/Resources/conversation.css on your Mac and add these lines to the bottom of the file:

ins { background-color: #cfc; text-decoration: none; }
del { background-color: #fcc; text-decoration: none; }

Then restart Sparrow. You’ll have lovely green and pinkish diff lines rather than impossible-to-read underlined text. Of course, I don’t imagine this’ll survive any software updates (or at least any that touch the css file — I’m not sure whether Sparrow does partial/differential updates or not), so chances are that this’d need to be reapplied after any update, hence my storing the fix here for my future reference.

UPDATE: I tried this fix with the free version of Sparrow. Since I like the software so much, I decided to help fund it by paying the $9.99 to support it. A nice side-benefit of paying is that the ads that appear in the free version to support it go away. Unfortunately, so does the ability to hack the CSS. When I modify the CSS in the paid version, it crashes on startup. I guess there’s some kind of checksumming going on or something. So for now, I’m back to using the free version with the svn diff colorization and an ad. I’m happy still to have supported development on the project but do wish I could use the premium version with my custom CSS.

WordCamp Nashville

2 Comments

A couple of months ago, I attended the two-day WordCamp in Atlanta, and when I learned a few weeks ago that there was to be a WordCamp in Nashville (about three hours from home), I snapped up a ticket. This was Nashville’s first WordCamp and seemed to be a great success. I had signed up to help staff a happiness bar in the afternoon and so wound up attending only two sessions. My notes follow.

The Blank Screen: Overcoming Fear of ‘Pressing from Scratch’, presented by Mitch Canter.

I had actually heard of Mitch before via a local contact and was curious what I might learn from him about starting a WordPress theme from scratch, something I’ve never really done (being not at all gifted with design talents). Although he had some slides and some high points he wanted to hit, Mitch offered a pretty informal, somewhat discussion-driven format, and it worked well. He was funny and engaging, a very capable speaker. The high points I jotted down from the session:

  • Designers have to work with their developers before putting a design on the screen; else you wind up making beautiful things that the coder may not be able to implement.
  • If you’re working with the 960 grid system (something I didn’t know about), check out 960.gs, which gives you Photoshop templates for creating layouts more efficiently.
  • Establish a process/framework to speed up dev, to build a comfortable flow for your work, etc. That is, condense repeat actions into a formal set of processes/templates/etc. so that you’re not actually starting from scratch each time you start from scratch.
  • Mitch tends to start with static html pages (with lorem ipsum type content) to do most of the design outside of WordPress, and then he goes back in and substitutes in loop functions just before he pushes content to the client’s servers. I asked about local dev environments like XAMPP, and he said he also uses/advocates those. As XAMPP/etc. may be a little more technical than some designers are able to deal with, the static build may be reasonable for some.
  • He mentioned using github to deploy changes to his parent theme framework, though it wasn’t clear to me why that was terribly significant. I think he uses github over the core plugin/theme repository because he has some MIT-licensed components.

Child Theme Frameworks, presented by Ryan Green.

Ryan is the head of UX+UI at cjAdvertising in Nashville. He gave a much more structured talk than Mitch, and it was full of good information for any new to the notion of child themes. After defining UX (sort of the nexus of design, interactions, usability, and analytics), he made sure the room understood what he meant by a child theme and a framework and then jumped into the advantages and disadvantages of using a framework. Advantages:

  • You start with a bulletproof theme.
  • If you break something with your child theme, you just delete/disable it and still keep all the core functionality of the parent while sorting out what went wrong. In other words, it’s sort of like working with a net.
  • You can roll multiple themes from one parent. He gave the example of a seasonal theme for a given site. If you have your core functionality in a parent theme framework, then you can just override the styles, etc., in the child themes and swap those out easily with little risk to how the site actually works. This is obviously an advantage if you do lots of work within a vertical market that tends to require rubber-stamped functionality but varying designs.
  • If you’re using as your parent theme one that’s updated via the core themes repository, you can keep up to date easily with security patches at a reduced risk to the site’s functionality. One nasty alternative is to hack your parent theme locally, in which case updating becomes a pain and exposes your site to vulnerabilities. Extending a parent theme lets you keep up with updates while managing your changes to the theme within the child.
  • You may need to know less PHP if you go this route. That is, given a parent theme that has all the functionality you want, your child theme can simply replace the style sheet, which lowers the barrier to entry for designers who aren’t comfortable wrangling PHP code.
  • Visual design principles can be baked in. So if you find yourself working always within the 960 grid system, you choose a framework that adheres to the 960 principles and save yourself some grunt work.

Now for the disadvantages:

  • You can get locked into a nightmare theme. So maybe you’ve picked a dud but don’t know it until you’re halfway through a project whose core functionality depends on the theme you’ve chosen. Bummer.
  • If you choose a minimalist parent theme, you have to do more design work. (This struck me not as a disadvantage of the practice of using theme frameworks but more as a caution to choose your parent theme wisely.)
  • If you choose the wrong parent theme, you can be bitten by code bloat. That is, some themes that try to be all things to all people add so much extra stuff that they might not really be suitable for your purposes, while adding surface area for vulnerability and performance issues. This, again, is more a caution to choose wisely than a compelling reason to consider rolling a custom theme for each site or rubber-stamping an established theme rather than making a child theme.

Next, he talked about what makes a good theme framework:

  • It respects the grid (has consistent spacing, uses a common grid system, has a clear visual hierarchy among elements).
  • It uses modern code like HTML5, CSS3, jQuery, etc.).
  • It’s easily remodeled. By this he meant that widget areas, nav areas, and so forth can be easily moved around and tweaked. These themes use what Ryan called the “House-Hunters approach” — the theme is essentially move-in ready.
  • It demonstrates a concern for usability; it’s responsive, IA-friendly, works well for those with disabilities.

A few frameworks he’s used:

  • Genesis
  • Thematic
  • Thesis
  • Stumblr
  • Others: Skeleton, Starkers, Whiteboard, Roots, Bones

I’m too lazy to find links for them all. Advantages these generally had in common were that they tended to already have lots of pre-made child themes you could riff on and they’re tried and tested by thousands of users. Thematic (by Automattic) makes it easy to change layout. Genesis has a standard top-nav layout and is generally more corporate out of the box. Thesis has great typography and is optimized for fast load time. Stumblr has minimal configuration options, a Tumblr-style layout, and is very content-focused. He didn’t mention the _s theme recently published by the Automattic theme team, though I didn’t ask  why; maybe it’s too new for him to have looked at much, or too bare-bones (by design) to be generally useful to designers who need a more fleshed-out template for a starting point.

I didn’t jot down any of the questions Ryan fielded, but there were several, and I thought this was a very good session overall — not terribly advanced stuff but a great overview for designers who may not have had much exposure to the concept of child theme frameworks.

The Afternoon

I spent my afternoon in a little cafe area between the rooms designated for the user track and the developer track. Ostensibly I was there to staff a happiness bar to field any questions people had about WordPress, but nobody asked me any questions. This may have been a sign that the sessions were really well suited to the audience, that people were reluctant to miss a session to ask anybody anything.

I did sit and chat for a good long time with Rami Habal, VP of Product with event sponsor wordnik, which I’m going to test drive a bit because it looks neat. We chatted natural language processing, he demo’d a WordPress plugin they’re working on in beta, and it even came out that he had been a Flock user. I also chatted with one Cindy Wall, who works with the Belcourt theater in Nashville and turns out to be a Moby-Dick enthusiast like me. I actually shoehorned myself into a discussion by these two by showing off my goofy little Moby-Dick word frequency analysis site, which married some of the sorts of things wordnik does with some of the literary stuff Cindy had been talking about. And, oddly enough, it turned out that Cindy had run across a blog of mine in her recent searches pertaining to Moby-Dick. So it turned out to be a small world in Nashville this weekend.

Miscellaneous

This was the third WordCamp I’ve attended, and in terms of sessions, it was for me the best so far, even though I attended only two. Sessions at the other two have been more mixed for me in terms of quality, but both I attended this weekend were very solid.

Registration went smoothly for me. It seemed like a few people slipped into the first session a little late, but that may well have been as result of their own tardiness and not of any registration snafu. The shirts and badge/schedule thingies looked great. WPEngine provided little swag bags including a pretty nice little notebook that I actually used to take my notes. There were free muffins from a local eatery and free coffee from I know not where. You had to fend for yourself for lunch, but there were a couple of restaurants within very reasonable walking distance, and the organizers had negotiated coupons to get a discount on lunch. The barbecue joint does catering, so I did wonder why they hadn’t just had lunch brought in. I suspect the venue didn’t allow food in the classrooms we used, or perhaps adding catering to all the other organizational hurdles for a first-time WordCamp was just too much. This isn’t a gripe — just something I wondered about.

With just two concurrent sessions at any given time, we used two classrooms, and it turned out that the developer track was a lot more popular than anticipated, so the developer room was standing-room only for both sessions I attended. This wasn’t a bad development, and it’s certainly something the organizers will learn from.

Even though I didn’t get to attend many sessions, I had fun at this WordCamp. I think Nashville had a great first time out, and I’ll look forward to going back next year.

Custom Feed Links in WordPress

2 Comments

At a WordPress meetup tonight, the question arose of how to override default feed links for a WordPress site. For example, what if you’re using FeedBurner and want to just change the links in your source to the relevant FeedBurner links without hacking your theme? I don’t know if it’s the best way, but it looks like this is pretty easily done with a plugin that, in its simplest form, looks like this:

<?php
function feedme_remove_feed_links() {
        remove_theme_support( 'automatic-feed-links' );
}
add_action ( 'after_setup_theme', 'feedme_remove_feed_links', 11 );

function feedme_add_feed_links() {
?>
<!-- CUSTOM FEEDS HERE -->
<?php
}
add_action( 'wp_head', 'feedme_add_feed_links' );

Of course, you would need to make the feedme_add_feed_links() function do something a bit more useful, and in an ideal world, you’d provide an admin screen that allows people to specify their links.

One important detail that may not jump out at you is that when adding the “after_setup_theme” action, you need to give it a priority higher than 10. Else it just goes into a stack with all other of its sibling actions with the default priority and may be (in fact seems to be) overridden by one of them.

Starting the Knoxville WordPress Meetup

Leave a comment

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

2 Comments

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.