A Good Imagination and a Pile of Junk

I get an awful lot of hits (in relative terms) from google image searches for this or that thing that I’ve posted a pic or link to a pic of back in the distant past.  Generally speaking I don’t mind so much, hits are hits I suppose.

But it does suck bandwidth in a manner not pursuant to the purpose of this narcissistic netstead, so the perpetrators need to die in rivers of blood.

Or maybe I can figure out some way to get wordpress (or the underlying server configuration) to ignore certain referrers.

Just a thought.

In preparation for a big blog change, I’m tweaking this site so that the permalinks aren’t the query string ones but are “fancy” instead.

This means any existing links to individual entries on this site are gonna be broken in about 3 minutes.

I figure there are probably like… 6 in the world anyway.

I need that opening clip of Samir in Office Space, screaming at his steering wheel having what anyone who has ever sat in traffic knows is a perfectly fucking reasonable temper tantrum.

I’ve just spent the better part of 2 hours banging my head against a desk and playing indiscretely with large sharp objects while trying to get xmlrpc to hit this site.

I’ve done a lot of xmlrpc programming. I know it’s not magic. Google docs works beautifully.

The python code is dead simple. Set about four fields and flip the switch.

I was getting 301s. Of all fucking errors, 301s. “moved permanently.” Checked the logs, nothing.

While LOOKING at the logs, I said “ooh, someone’s banging on my site, can’t have that.” So I blocked the ip address from getting here.

Well…

GUESS WHOSE FUCKING IP ADDRESS I BLOCKED!

That’s right, Freak Boy Wonder managed to lock himself out of his own site. That’s some fine police work there Lou.

I was able to log into the wifi network of an unsuspecting neighbor and fix that particular stroke of brilliance.

I spent 45 minutes following threads of php code through the server side interface (which supports Blogger, metaWeblog, Movable Type, and everyotherdamnthing.)

Pulled down the wordpresslib library, thinking that might exist because of some bizarre peculiarity in the wp host code.

Same thing.

*twitch*

Then I had that moment, that one thought that I can almost rely on when things have gone from black to darker.

“Wouldn’t it be stupid if I needed a trailing forward slash on the filename?”

Now, a file path (on a real OS or online) is “blahblah.com/directory/directory/directory/file” The existence of a “/” means that the preceding is a path. If you’re specifying a file, you don’t need one on the end.

*sigh*

UnLESS you’re calling an xmlrpc server (in wordpress only?)

So yes. It’s all fixeded now.

But I don’t feel any better.

Now on to the FTP code.

My PHP fu is predictably pitiful. I need to extract text from a free standing block of html and make sure I exclude stuff that’s text inside an anchor tag.

Now, to do so with significant alacrity do I invoke a “real” parser? Or do I just play regex games?

Meh.

Last year I spent a fair amount of energy importing my old posts from other blogs into here.  It totalled a little over 3000 posts spanning 6 years.

I still see incoming references to old uccu urls.  It wouldn’t have been SUCH a nightmare to accomidate that.

The way to do it would’ve been:

- Tag the old posts with the old post id and ‘uccu’

- Add a rewrite rule to the magic whatchamacallit file that would redirect all the /uccu/*html links to a cgi.

- Add a cgi that redirects to a WordPress searche for the post number from the intended url and ‘uccu’.

- Tada!

But I didn’t tag the uccu posts.  After seeing what happened when I tagged the old radio userland posts (massive proliferation of tags and an OldRadioBlog tag) I thought differently.

Well that was wrong.

Now I’ve got people who are getting cached google results coming in to this site and landing on the homepage, which is almost certainly the last thing they want.

Yeah.  Looks like it’s time to do some site work.

I keep getting that wonky bullshit whenever I use an embedded YouTube link. But I don’t seem to see it on any other WP blogs.

The embed posts ok, but there’s always html cruft surrounding it.

What gives, anyone know?

UPDATE: Yeah. Figured it out. It was my WordPressWikiPlugin. It was wikifying words in href tags. whups.

Any WordPress users out there have any success with the ScribeFire FireFox blog authoring plugin?  It’s a cute little posting app that I enjoyed a bit back in the MovableType days of UCCU.  But it doesn’t seem to want to work against WP.

When it does a test login the error message seems to indicate that ScribeFire is attempting an http get request when a post is the only thing supported by xml-rpc.  I dunno. That seems pretty off.  I s’pose I should try farting around against my local WP instance (which I’d forgotten existed, frankly.)

Lemme know if you’ve got any ideas

For some reason, when I imported all the 3400 or so posts from the previous two incarnations of this blog the comment status was set to ‘closed’ on all the imported posts.

I just logged in to the WP database and ran some DML to open everything. So we’ll see what happens.

I’ve got to tackle the clashing of my two WordPressPlugin scripts.  On one hand, there’s the simple regular expression issue of mixing render-time processing transforms that create href tags out of plain text (nesting them is really icky.)

But what I had NOT anticipated is the fact that php or WordPress (I’m not sure which) imports the plug-ins into the same namespace, so I’ve either got to give everything retarded prefixes, ‘class’ify the code for namespace partitioning, or use a common library (taking the plugins away from OneFilePerScript land, which I don’t like at all.)

Merging the two plugins is not an option, even though it’s the simplest technical solution available.  The difference between the two at this point is really about three lines of code.

I suppose that simple fact dictates the solution.

Ickypoo.

So I’ve been grinding on the WordPressWikiPlugin and it’s in pretty good shape.  In fact, it’s in such good shape that I’m going to use this post as the documentation page for a while and see how that works out.

Currently the feature set (meager as it is) looks like this:

The WordPressWikiPlugin is a rendering time filter.  It scans the content of a post looking for WikiWords (two or more words capitalized, jammed together, no consecutive caps.)  When it finds them it does two important things:

1. Scans the database for posts with a title matching that WikiWord and replaces that text with a link to the post in question.
2. IF the page does NOT exist and a blog author is logged in, it uses the original WikiWiki convention of placing a link with the text ‘?’ after the WIkiWord.  If that link is clicked it takes you to the CreateNewPost page with that title filled in.

It doesn’t do any additional formatting, since WordPress handles that relatively well.  I will probably add some complex external linking stuff as time goes on.

CurrentIssues:

• There is a perfect lack of documentation of the “User Level” field of the user data structure.  So the “if an author is logged in” is a bit wonky at best.  It DOES detect if someone is logged in and if their user level is 10.  But I think that’s the admin level.  Tough to tell with no documentation.  I’m going to have to experiment with this.

And no, it’s not uploaded to this site just yet.  I have a bit more testing to do on my local installation before it’s ready to be released into the wild.

UPDATE: Ok, I’ve activated it on this blog (dogfooding and all) but I don’t have so many things linking back and forth yet, so it’s a little sparse. That’s ok. Notice that the link in the first line does indeed bring you to this post though. When I look at it, the missing links do have the “page does not exist” question mark link, which works really well. So I’m pretty happy with that so far.

I’m trying to decide what the path between here and public release is. There’s not really so much I want in the 0.1 version that’s not there now. I have to fix the user level thing. But it might be ready to go after that.

It links to the previous post “This is a post” just by virtue of the fact that I put that title in quotes in the edit box in WordPress.

This is a piece of functionality I miss from Radio Userland.

This post will be linked to by the next post by merely putting the name of this post in quotes.

It’s a test of my new wiki-ish wordpress plugin.

I’ve never been able to get image posting to work here. Any one know if that’s a WordPress defect?

Seems like a trivial enough interface. Click the “add media” button with the image next to it (I’d include screen shots but, well… that would be silly)

But when it uploads the file (I’m largely convinced it actually does) It seems to redirect me (with the “upload a file” shadowbox) to a login page for the site.

It’s really irksome.

Not the emptiest, mind you. That’s different.

RadioUserland had a feature I really loved. Well… it had several (and it’s craptasticular language wasn’t one of them.)

If you typed “a phrase in quotes” it would look through all of your blog post titles for that phrase. If it found it, it would automagically turn the quoted phrase into a link.

I was shopping around for a WordPressWiki plugin and came up with something called “Blicki” which doesn’t work and hasn’t worked in some number of versions. But I figured, how damn hard can php be?

It didn’t really have much that would help and a lot of the library functions it relied on in the WordPress codebase either aren’t there or don’t behave quite the same.

After about an hour and a half I have the thing done. With the comment header it’s 66 lines from and not so bad if I do say so myself; especially considering that it’s a first php effort.

I’m going to use it as a basis for expanding in to a full blown wiki plugin, so I’m not planning on dumping it out into the world at large in it’s v0.1 state.

But if anyone’s interested in it in the meantime, lemme know. I don’t see any reason not to shoot the file over.