Java* Jive *: -script

So after an age, I finally repaired my WordPress backend and a few other bugs in the system. Those links to the right, for instance — they’re supposed to be in reverse chronological order, such that the most recent links are to the top. For over a year it has, instead, been randomized. That was a workaround that I figured would do until I worked out the actual problem.

On the backend none of the Javascript seemed to work properly. I couldn’t get a word count for an entry. The tag cloud was broken, as was every pulldown menu. It was hell to edit an old entry from the “All Posts” menu.

All this time I had assumed that the bugs were related to some malicious activity last summer. I was puzzled that the problems remained, as I knew I had cleared out all of the problem code. Turns out… no. At some point, and I don’t remember doing this, I must have added a line of code related to Google Translate. Somehow its JQuery request interfered with the WordPress hierarchy, and they canceled each other out.

So just now I removed that line, and… it works. Everything is perfect again.

That’s a bit of a weight off. It’s sort of depressing to watch something that you’ve worked hard on fall into disrepair and to have no recourse to fix it.

Mind you, the site is ready for a rewrite anyway. One of these days when life isn’t too complicated, I may do just that.


One of my lingering WordPress problems deals with UI elements labeled with the “hide-if-no-js” category. Presumably the idea is that if the page fails to load the required javascript code then it will just ignore the element rather than hanging and refusing to do anything else that the page needs to do.

Presumably the reason that I can’t view or easily add tags to my posts, and that I can’t easily change a post’s visibility or publishing date, and that I can’t easily upload and insert an image, is that the page is not locating the required javascript — or the javascript in question is somehow faulty.

So I’ve got a great half-explanation on my hands that goes nowhere to actually solve my problem. What I guess I need to do is figure out what code my post-new.php page is looking for, ascertain whether the code is in fact where it’s supposed to be, and either find and replace it or not, and fix it if so.

This may be a perfectly simple exercise, but from here it feels daunting.

UPDATE: I’ve gone through and systematically re-uploaded all of the standard WordPress files except for those in the root directory, so that would seem to narrow things down. I’ve now just got 22 possible culprits to weed through.

UPDATE 2: Okay, I dunno. I’ve gone through and visually compared all of the remaining files, and combed through the unique files for code that doesn’t belong, and I’m turning up nothing. So I’ve no clue why I still have this problem with POST.PHP (and, to a lesser extent, with POST-NEW.PHP).

Update 3: It’s not a browser issue, either. I knew it wasn’t, because the pages used to work just fine in Chrome. I hit the same problems in Opera as well, so there’s something on the server side that just isn’t working.


My golly, I like Perl — what an intuitive language. Reading the first O’Reilly llama book, I find my mind whizzing paragraphs beyond what is being stated; by halfway through most of the example problems it’s quite evident where the code will go, what will be likely problems, and generally what must be done once the code gets there, excusions made for functions of which I’m not aware (and there are some neat ones).

If I were a bit more familiar with unix, however, this would all be somewhat more contextualized.

Nice llama. Good llama.

Been gnawing away at all of the HD space I freed while down in NH, by way of wildly ripping to mp3 every disc which seems appropriate and throwing the results into a now quite-lengthy playlist. Gives me an excuse to read — Edgar’s thinking too hard to do anything particularly noteworthy while I’m ripping, so I have a bit of an open moment to, for a while at least, actually look away from the screen.