Anyway, as I’m sure those (one) of you who use this plugin will notice that the Flock-to-LiveJournal custom gropu mapping isn’t particularly friendly. Well, hopefully future releases of JournalPress will fix that, but since it might be a while before that happens, here’s how to do it manually.

The problem with LiveJournalⁱ is that its friends group UI is shit. It’s so shit, in fact, that I’d wager the vast majorioty of the userbase doesn’t even use it, despite it being one of LJ’s greatest features.

For whatever esoteric reason, LJ does custom group mappings as a bitmask. If a post has a bitmask of 0 it is assumed to be Friends Only.ⁱⁱ Every other number corresponds to a custom-definable group. The bad news, is that LJ displays these groups to you as names, while it uses them as numbers. And WP-Flock needs the numbers.

Here’s how you find them:

1. Hit up Update Journal.
2. View Source (usually Ctrl+U or Cmd+U).
3. Now for the fun part; find the location in the source code where it displays your friends groups.
4. You’re looking for the thing that says custom_bit_xx. The ‘xx‘ there is the bitmask number you’re after.
5. …
6. Profit.

That’s the basics.

Astute multiple-journal users out there will notice that there is only one bitmask field for each Flock group. This means that if you’re going to use them, your group bitmasks between your journals must match up. That is to say, my anthro group at LiveJournal and JournalFen have to both have the bitmask ID of 3 (they do). This is kinda a pain to set up, and I plan on making all this a bit more user-friendly in future releases, but for now you’ll have to deal with it.

Oh, and for the record, the default LiveJournal Server groups and their equivalent bitmasks are:

1. Family
2. Local Friends
3. Online Friends
4. School
5. Work
6. Mobile View

1. Har har, that’s funny; implying there’s only one!
2. Note that “having a bitmask of zero” actually means that the post has a decimal “lock number” of one: For those of you who missed high school maths, 2⁰ = 1. Publicly visible posts, on the other hand, have a decimal lock number of 0, which is not actually representable as a power of two, and hence does not have a bitmask.

permalink » comment? » 403 words posted in: JournalPress, WP-Flock, bloglife:livejournal, wordpress:plugins

So yeah. You can now download the “pre-release” alpha of WP-Flock, if you’re feeling brave and adventurous. For those of you who are Googling this or reading it via a crosspost to a community, WP-Flock is a simple, flexible LiveJournal-style way of friends-locking posts made to a WordPress blog. It also integrates with JournalPress v0.2.1 and higher (expect the auto-update within the next day).

I think the plugin needs a couple of weeks of “live” testing before I go nuts at WordPress.org, which is why I’m just going to run it here at β for a while. Those of you who are brave may also give it a stab, but I’m a little leery of some of the logic in it — as well as its ability to play nice with other plugins — hence the uncharacteristic reluctance to release. Still, it… seems to work.

Go me.

For those of you who are reading this via my journal or one of its mirrors, it means that you are going to start missing posts (or at least the ability to comment thereon) unless you register. I’ve installed OpenID,ⁱ so you may use that to login rather than a “full” registration, should you so desire. Note, however, that you will still have to update your profile with an email address in order for me to add you to custom groups; this is a quirk in the data passing and if you don’t like it, you can bite me, entitlereader.

1. Currently it only seems to work with LiveJournal URLs. I’m not sure why this is, but I’ll have a poke at it in the next couple of days and see if I can’t get that fixed.

permalink » 5 comments » 298 words posted in: JournalPress, WP-Flock, WordPress, releases, wordpress:plugins

So it’s been raining a bit in the last couple of days, which is always novel and unusual. The storms have been harsh, though they don’t usually last longer than about ten to twenty minutes. Still, it’s good for the garden. And photo-ops, too.

The first photo was a pretty amazing thing to walk out into. It was about 8:30 pm, so just on dusk, and a big-but-brief storm had just passed over. I haven’t seen the sky that colour since the 2001 bushfires ripped the city apart. Luckily, the other day the air was crisp and damp, not dirty and choking. No Ragnarökk this weekend.

The second photo is just a rainbow, since I don’t think I’ve actually seen one in years. Actually, when I was driving to my parent’s house after taking this the rainbow acquired a twin (that is, a second rainbow just above this one), but I figured taking a photo while driving would be kinda dangerous. Rainbows are so weird; how did nature manage to come up with something so incredibly tacky and artificial-looking?

Either way, the thing “ended” a good distance up in the air so there went that plan. That’s 0 out of 2 for this weekend: No Ragnarökk, no Ásgarð. Sheesh.

So anyway, for pretty much every other situation you’ve got to intercept every single query WP makes against the DB, check if it’s looking for posts, then inject a JOIN or WHERE as appropriate. And did I mention you can only do this once.

My first plan was to use arrays serialised into post and user meta values in order to do the group checking, but the SQL injection thing kinda put paid to that idea. So I bit the bullet and created a properly normalised table to hold the data like a good girl, and some clever LEFT JOINs mean that was working pretty well, except… bam. Same problem on the injection.

Tssch.

I’m 90% sure I can do what I need to do with the current structure using the single SELECT statement that WP requires, but it’s going to require some serious SQL fuckery purely because the relationship between a posts/users and groups is n:m (and, of course, there’s no guarantee that it’ll play nice with other plugins that hook the same queries, which is the real kicker).

It would perhaps be easier to de-normalize the capabilities table so that all groups are thrown into the one delimited field — instead of being inserted as separate rows — but ugh. That has its own issues too. It’d be easiest of all I think to do it both ways for all users and posts (then I could choose which one I needed), but the idea of doing that makes my skin crawl…

… which sucks, since I’m pretty sure it’s exactly what I’m going to be ending up doing. Shit.

Edit:

Okay, I (almost) got it. Only thing to do is take out some of WP’s original clauses…

WP-Flock SQL

permalink » 2 comments » 578 words posted in: Photos, WP-Flock, WordPress, weather, wordpress:plugins

I spent a bit of time checking out Role Scoper last night as a potential solution to the age-old “f-locked posts on WordPress” chestnut. It looks like it works okay, but it is massivley over-complex for the job. We’re talking shotgun and nail territory here. There are a whole host of similar plugins but… eh. All of them are okay but none of them are perfect.

So this morning I sat down and started working on WP-Flock, which is the current name for the ever-changing-JournalPress-integrated-friends-groups plugin I’ve been talking about writing since I migrated from sk.log.

After some consternation, I decided that the main thing I was going for was simplicity. LJ’s sytem of simple groups works well there and it worked well in sk.log, so I figure stick with what you know.

On, and the other piece of joyous news is that apparently WordPress feeds can support HTTP auth,ⁱ so that’s that hurdle down.

… now if only I could figure out the API hook for adding extra fields to a user’s profile page.

1. Still not sure if this is native or not, only that I’ve seen it supported in other plugins, so it’s possible.

permalink » 10 comments » 196 words posted in: JournalPress, WP-Flock, WordPress, programming:development, wordpress:plugins