The guy who coded most of JW Player’s core and plugins has also produced a handy WordPress plugin that lets you integrate JW Player into your WordPress site, and for the most part it works beautifully.

There’s at least one exception: While you have the option to integrate the sharing plugin via the plugin’s settings in WordPress, you have one global field for “embed code” that can’t really accept anything useful. You have to URI escape anything that goes in there (which wouldn’t be so bad if there was a way to URI unescape the output), and there’s no way to add a MEDIAID variable in there so that your embed code can be dynamic (which is a complete dealbreaker for almost every user).

Well, I needed this feature, so I found a workaround. And I didn’t want to go hacking into the plugin code (so that I could update it later, without clobbering my fix), so the way I did it was through a PHP regex in my theme’s functions.php.

I first did two things, only one of which should be necessary: In the plugin configuration, I set my custom embed code to [FIXME], which is what my regex will look for, and replace with something useful.

Second, I edited sharing.xml in the WordPress plugin’s plugins directory, to use the sharing-3 repository, rather than sharing-1. I just prefer version 3′s interface, but I also figured newer was probably better. All I did was change the value of the <repository> field from sharing-1 to sharing-3.

But here’s the fix: In my theme’s functions.php, I added a filter for the_content (set at priority 999 so it would run after the JW Player plugin has already replaced my shortcode with the complete embed code), which finds the MEDIAID, and finds my [FIXME] placeholder, and assembles a good embed code. <embed id=”1″ /> is obviously not good embed code; that’s just for simplicity/illustration. You’ll want to replace that with your custom embed code, and here are some ideas on how to do that cleanly.

Theme functions.php

Caveat: This only fixes the players in the post body, and not the one generated for the og:video tag for playable embedding on Facebook. I’ll be figuring that out later, and eventually adding the code to this piece, for anyone that needs it.

The only thing that gave me pause when I suddenly found myself needing a new laptop after the death of my 15″ Macbook Pro was the fact that there was no option for a matte screen. Even though the Air’s screen is not quite as glossy as those of its peers, I hate (with the sort of burning passion reserved by developers/designers for seemingly inconsequential details such as mildly objectionable fonts and colors) glossy displays where a certain shade of red could be lord knows what wrong color depending on what angle you’re viewing at or what in the room is reflecting off your screen. Yes, we’re talking about the most minuscule of nitpicky details, and I’m a psycho, but whatever. I ams what I ams. So before I even turned my new Macbook Air on for the first time, I had installed a Power Support anti-glare film.

Over the course of the past 8-10 months or so or however long I’ve had the Air, I’ve changed the film a few times, due to OCD more than necessity. I’ve tried a bunch of less expensive films.

However, the Power Support films are the only ones that really do give you a great matte display, just like the ones Apple provides optionally for the Macbook Pros. No one even asked me, let alone paid me to tell you this. Just a public service announcement from one psychotic design geek to all others.

If you have an Air, buy a bunch while the company / product is still around.

First, a few general rules. These rules will occasionally need to be broken, but if you start off by at least trying to follow them, you’ll give yourself a more stable foundation.

• Host all of your images online (or via a CDN/S3) and use absolute URLs. Of course.
• Use old-school tables to position all of your elements. I know you spent a lot of time weaning yourself off them and mastering div tags positioned with CSS, but email clients rarely handle that stuff properly. For email, we’ve gotta take it all back to 1998.
• When you do use CSS (which is by no means recommended against), put your styles either in-line, or in the body tag. Many email clients will chuck your head tag completely.
• Set alt attributes for all of your images and links. I’ve seen email clients discard images and links that didn’t have alt attributes.
• Explicitly setting border-collapse on your tables to collapse with CSS seems to help kill certain table spacing-related quirks.
• Validate your HTML at w3.org. Get it as close to perfectly valid as possible (necessary hacks may make perfect validity impossible).

Now there’s one thing in particular that has given me an extraordinary amount of hell when doing HTML emails, and that is background images. Particularly when it comes to Outlook’s nasty habit of chucking them.

If you’re okay with having one big background image behind everything, you can apply a background image via CSS to the body tag. That actually works in Outlook. However, put your CSS inline or within the body tag (see above). I’ve also heard that you need to set repeat-y if you go this route; that setting CSS background-repeat to no-repeat will actually lose the background image completely in Outlook. Not sure if that’s always the case or what.

The holy grail here is applying background images to table cells. It doesn’t really work in Outlook. There is, however, a hack that I’ve found, and that is the main thing I wanted to share here today:

Outlook can’t (or refuses to) render basic CSS, but it does know VML (Vector Markup Language), which is what Microsoft Office uses to position elements in Word and Powerpoint. So what we’re doing is targeting Outlook specifically, and hitting it with some VML.

Here’s a trick to let you Facebook app developers do a couple of things that are typically considered impossible.

Let’s say you have a Facebook app with a Page Tab, and you want to pass it some dynamic variables from an external site or a share post. While you can link directly to a tab by appending an ?sk=app_ to the page URL (example), any custom, non-Facebook variables appended to the URL won’t be passed through to your tab page.

Another problem: Let’s say that tab page has links to sub-pages that load within the main tab iFrame (a la target=”_self”). That’s all easy enough, and pretty common. But what happens when you want to link to sub-sections of your tab page from an external site or share post?

You can’t get variables in through the “front door” so to speak, but you can pass them around the back, using what I call “the cookie trick” (or, inexplicably, “cookie party,” when it’s late in the office and we’re all loopy and/or drunk). The trick involves using a redirect that stores dynamic variables in a cookie, and then sends a user to the tab. When the tab loads, it grabs the data it needs from the cookie, and then deletes it. It’s completely transparent to the end-user.

Here’s all it takes. First, a redirect script:

Then, your main tab page just needs to check for the cookie, get what it needs, and then delete it:

Voila. You just send your vars to something like redirect.php?var=foo, and they’re slipped to your tab via the cookie.

If you want to link to a sub-page, just pass the sub-page path into your redirect.php as a variable, and then use a PHP header() redirect, or output a line of Javascript to send your users where they need to go.

Here’s an example of a deep-link to one of four mini-games in a Page Tab I built for The Black Eyed Peas Experience game: http://promethiumtorch.com/bep/redirect.php?goto=whatsyourgroove

Essentially it boils down to three steps:

1. Geocode a table of addresses to latitude and longitude coordinates using the Google Maps API (only need to do this once).
2. Geocode a query string to get its latitude and longitude coordinates.
3. Query addresses from DB by comparing latitude and longitude using the Haversine formula.
4. Bask in the warm glow of trigonometry.

Let’s start with the DB table. Since we’re going to be querying based on latitude and longitude, those two fields should be set as keys. Your MySQL server will probably cry if you don’t do this. And your queries may be noticeably slow.

Populate your table of stores, leaving the latitude and longitude fields blank. Then, you can fill those fields by looping through the table, pinging them against the Google Maps API, and popping off AJAX calls to update your DB table:

(You’ll need to include the Maps API Javascript, and jQuery will help you with the AJAX calls.)

You’ll want to query your table of stores, assembling an array of address strings, and encoding them to a JSON array or something using the row IDs as the keys. Then, loop through it:

You can update a DB, right? Your insert.php would look something like this:

If you hate Javascript (or just suck at it), you could go with this super simple PHP route to get latitude and longitude from Google (thanks Weston):

That’s step one, the hardest part, the part that only needs to be done once. Once you’ve got that groundwork done, your DB is ready for real user queries.

First, take the user’s input query and Geocode it, using either method above (Javascript or PHP), to get the latitude and longitude. Once you have those, you can do one clean MySQL query to get locations ordered by distance (replace QUERY_LAT and QUERY_LON with the latitude and longitude returned from Google, respectively):

Fuck yeah, math.

We’re assuming that the default weight is 1, and that a weight of 0 would exclude an item from the result set. Whether or not there is a “maximum” weight is irrelevant to this algorithm.

The idea is that you first sum all of the weights together, to get a grand total of the combined weight of all items in the result set. Now imagine all of your results lined up in a straight line, with the size of their spot in the line determined by their weight. So if the first item has a weight of 50, its spot in line goes from points 1 to 51. If the second item has a weight of 20, it goes from points 52 to 72. And so on, with the last item ending at that cumulative total we calculated.

What you then do is pick random numbers between (and including) 1 and that cumulative total. Whatever item is occupying that position in the line is your winner. Repeat for as many results as you need.

If your data is in a MySQL database, you can add a running cumulative count to the results array using a MySQL variable:

Then you iterate through a loop for as many random selections as you need, counting up to the item whose cumulative_sum contains your random number. For example, in PHP:

All in all, very efficient.