Log in

No account? Create an account
LiveJournal Development [entries|archive|friends|userinfo]
LiveJournal Development

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

January 22nd, 2002

(no subject) [Jan. 22nd, 2002|01:09 am]
LiveJournal Development

1) http://goathack.livejournal.org:8012/patches/hideshow-2002-01-16.patch
When a person is hiding their friendsof, show their friendsof in userinfo.bml if they're currently logged in. (Also indicates on that page that the friendsof list is hidden.)

2) http://goathack.livejournal.org:8012/patches/talkpost-2002-01-22.patch
* Clean up the talkread tables: xhtml
* easier-to-read code
* format the username/password/login boxes better.
(This last one was the reason for the patch; the boxes as they are on the site now weirdly wrap in my browser.)

Both tested on a just-updated copy from CVS.
link5 comments|post comment

login on comment [Jan. 22nd, 2002|08:05 am]
LiveJournal Development


[mood |curiouscurious]

just noticed this is live on the site now. just for laughs, i checked the "login?" box when i was commenting on a friend's post. at the time i was already logged in with my cookies set to "never" expire. so i posted the comment, and it said that i was now logged in. great. close my browser, reopen it, come back to livejournal, and i'm logged out. i understand why this happened, but is it what we want to happen? is it a bug? should we have a button on the resulting page after you post the comment that says "change expiration mode to never"?
link9 comments|post comment

PATCH: bug-fix, talkpost_do.bml [Jan. 22nd, 2002|12:55 pm]
LiveJournal Development


As noticed here, checking the login box on talkpost.bml does not check to see if you're using the cookie.

The problem was that $FORM{'usertype'} gets changed from "cookieuser" to "user". By the time my original code came, it didn't take that into account. Now, it also checks for $cookie_auth.


I tested this, and it works.
link3 comments|post comment

Current Focus -- still. [Jan. 22nd, 2002|01:16 pm]
LiveJournal Development


I've applied a ton of patches this morning & afternoon, but I really don't want to be working that. Patches are never perfect, so I end up cleaning them all. Normally I don't care at all, but lately I'm focusing on cluster work.

So in the meantime, expend your energy on rigourosly testing the new code in CVS. Make a user... move that user to a cluster... test everything using that clustered user. If anything is unclear, submit a documentation patch. If anything is broken, point it out, and/or fix it.

I'm loving the flood of patches lately, but until cluster stuff is live, the only patches I'll take or even look at are those related to clustering.

BTW, xb95 in addition to a bunch of other stuff last night updated the clustering docs:
See revision 2 stuff.

I'll also happily take LJFUNC patches for ljlib. Every function should optionally have a new field in its LJFUNC area also: "funcclass" which can be one of, say: "db" (for DB connection related things), "text", (for text processing/escaping), etc, etc... anything undefined will be lumped together. But in the docs Opi's generating, it'd be nice to group functions by their type, next to similar functions.
link9 comments|post comment

Bit of an update... [Jan. 22nd, 2002|02:21 pm]
LiveJournal Development


[mood |tiredtired]

okay i am stuck here.

i was reviewing the code al ittle bit (i'm not a perl programmer though)
and i think that the problem lies here:

# executable perl code blocks
if ($type eq "_CODE")
if ($option_ref->{'DO_CODE'})
&get_form_data unless ($FORM_READ);
return &eval_code($data);
return &inline_error("_CODE block failed to execute by permission settings");

this is in bmlp.pl.
it's probably a way how IIS handles SOMETHING... i'm not exactly sure though... maybe somebody can help me out with exactly how this section works... and maybe i can fix it up or... i could have not installed a modules or something stupid like that..

anyways whatever the problem is, thanks a bunch :)
link7 comments|post comment

Revisiting Patch to see_request.bml [Jan. 22nd, 2002|02:46 pm]
LiveJournal Development


Has there been further consideration regarding patching up see_request.bml (see http://www.livejournal.com/talkread.bml?itemid=20552316)

----[itemid #20552316]----
I would like to request the following patch be applied to see_request.bml so that support volunteers can see additional information with regards to the status of the request. For example:

Status: open (still waiting for approved answer)
Status: open (answered, but still needs help)
Status: open (answered, awaiting closure)

You can find the diff at http://www.callete.com/~highway/see_request_119.diff

The patch has been tested and it does work.
link1 comment|post comment

bug [Jan. 22nd, 2002|04:40 pm]
LiveJournal Development


A short time ago, editjournal_do.bml was changed so that, after editing a post, the success-hyperlink pointed to talkread.bml instead of the user's journal. When this happened it created a condition where, when someone edits the entry and removes all text in order to delete the entry, clicking on the succes-hyperlink yields an error because the entry no longer exists.

I would submit a patch but I'm not leet.
link5 comments|post comment

(no subject) [Jan. 22nd, 2002|08:03 pm]
LiveJournal Development


Trying to xhtml dystopia.. as well as understand a bit more about xhtml...

Looks like the bagkground part of body|table|td|tr|etc tags is no longer valid...

So what can be used instead?
stylesheets? do all or most browsers support this?
link19 comments|post comment

[ viewing | January 22nd, 2002 ]
[ go | Previous Day|Next Day ]