August 4th, 2002

Session code

I believe all the bugs related to moving to the session-based login code are fixed. Thanks for all the bug reports so far.

Get your goathacks and such all updated and report any last bugs before this goes public on

customview skip links: bug or not?

Hmm. I'd go about fixing this myself, but I'm not sure whether or not it's actually a bug. On pages loaded with customview.cgi, "Next N" and "Previous N" links point to the user's default views, not the custom view itself. So, eg, on a friends page custom view, the links go to /users/davidglasser/friends?skip=40, not /customview.cgi?user=davidglasser&styleid=123456&skip=40. Is this a feature (page has same HTML as it would be if made into the real view) or a bug (the links do not do what I would expect)?

(Oh, and the checkcookies option is totally undocumented, but that's another issue entirely.)
  • ljnp4u

Just a question...

Since this is my first one, uhm, what do I do with it next ?

main -> livejournal       htdocs/tools/memadd.bml
--- /home/ljnp4u/cvs/livejournal/htdocs/tools/memadd.bml        Thu Jun 27 21:19:16 2002
+++ /home/ljnp4u/htdocs/tools/memadd.bml        Sun Aug  4 07:53:19 2002
@@ -184,7 +184,7 @@
              $dbh->do("DELETE FROM memorable WHERE memid=$memory->{'memid'}");
              $dbh->do("DELETE FROM memkeyword WHERE memid=$memory->{'memid'}");
              $title = $ML{'.title.deleted'};
-             $body = "<?h1 .error.deleted.title h1?><?p " .
+             $body = "<?h1 $ML{'.error.deleted.title'} h1?><?p " .
                      BML::ml(".error.deleted.body", { 'desc' => $memory->{'des'} }) .

Sorry, needed some updating before it would appear right. I've updated the cvs with --sync on my goathack. What do I do with the diff exactly ?
PS: By the way, I've done some extensive grepping for "<?p [.]" and "<?h1 [.]" all over /htdocs, and I was extremely fortunate to come across this one I think.

Massively converting userid's to usernames.

The getevents protocol mode lets you specify 'usejournal' to retrieve events from a community, but it doesn't tell you who posted each event. This sucks.

I was looking into fixing this, but ran into trouble. I can add posterid to the select, but then how do I convert the posterid's to usernames? I could call LJ::get_username() 500 times1, but that's slow. If the useridmap table existed on cluster dbs, I could just do a join on it, but I think it's only on the master. Should I do a select on the master's useridmap table putting 500 items in the where clause? or... what?

1 I'm assuming worst case scenario, using the syncitems selecttype...