wyntarvox: (Default)
[personal profile] wyntarvox
I'm working on t/console-changejournaltype.t One reason it fails is that the console command "change_journal_type" hasn't been updated to be WTF-friendly. This is fairly straightforward to fix, but there's another problem with it.

The can_execute sub for change_journal_type checks for either of two things: a) the user executing the command has the appropriate priv; OR b) $LJ::IS_DEV_SERVER is true. The test, however, only cares about whether the temp_user has the appropriate priv. When the test tries to have temp_user execute change_journal_type without the appropriate priv, it expects the command to error with an inappropriate priv error. However, because on my Dreamhack I have $LJ::IS_DEV_SERVER set to true, the command in fact succeeds which in turn causes the test to fail.

My question is, is it okay to set $LJ::IS_DEV_SERVER to false to get the tests to pass, or should they pass regardless (so we have to rework the tests, for example, to pass if temp_user has the appropriate priv or if $LJ::IS_DEV_SERVER is true)?
fputchar: (Default)
[personal profile] fputchar
Hey all, I was wondering if someone could be so kind as to point me in the exact direction in the DW source code that is responsible for creating the RSS feeds for accounts/reading pages? Also if you happen to know where the corresponding responsible code is in the LJ source I'd rather appreciate it.

Thanks!
jd: (wax lips)
[personal profile] jd
While I was looking at livejournal.js, I noticed that it uses the DOMContentLoaded event to start initializing things going before all the images and video content finish loading, instead of waiting for the window.load event (which occurs after everything finishes loading, including large files). But esn_inbox.js doesn't do this; instead, it waits until window.load to enable the controls, pagination, etc. This is a problem because if you have notifications that have a lot of large filesize content, like videos or large images, or if an image is hosted on a really slow server, you have to wait until it downloads (or times out) in order to be able to do anything with the inbox.

Is it possible to make esn_inbox.js use DOMContentLoaded, and fall back to window.load for browsers that don't support it (which, as I understand it, is anything not Mozilla-based)? I tried copying code out of livejournal.js into appropriate spots in esn_inbox.js, but I'm not entirely sure that this will work (I have no way to test any of this). Thoughts on this code? ) I'm asking here because I'm not sure if what I'm trying to do is even possible (or if it is, if it will work the way I think it will), and because I don't have a dev env set up. If this is fine, I can migrate to zilla, but I'm not sure how to generate a patch.
yvi: Dreamsheep with Replicator pattern (Dreamsheep - Replisheep)
[personal profile] yvi
So, I am currently in the first stages of working on http://bugs.dwscoalition.org/show_bug.cgi?id=1574 ( "Last active entries" module) and it's actually going quite nicely :)

However, I am a bit stumped on where to put a function I need. Namely, I need a function that, depending on what journal the module is in and who is viewing it, returns the last x active entries in that journal (maybe not the full Entry objects, though, still working on that).

My first thought was cgi-bin/LJ/User.pm , as it would be good to have $u->get_recent_active($remote) or something like that. But now I am leaning more towards putting it in cgi-bin/DW/Logic/LogItems.pm , which has the functions $u->watch_items and $u->recent_items . However, my idea only semi-fits the module description.

Or maybe it should be in cgi-bin/LJ/S2.pm?

Yes, I am still confused by where to put stuff. Any ideas?
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
[personal profile] afuna taught me something very useful today while I was having some trouble with something I was working on: in .bml pages, line numbering (for things like error messages, etc) start from the first line of <?code blocks, not from the first line of the file.

Everyone else probably knew that, but in case you didn't, now you do. :)
wyntarvox: (Default)
[personal profile] wyntarvox
I understand why the max recursion limit exists, but at the moment it's sort of ugly in its execution with regard to comment threads.

For example, if a comment thread exceeds the limit the layer dies as expected. However, there's no obvious indication beforehand that it's going to happen, so someone doing something as innocent as commenting effectively ruins the remainder of the comment threads on the entry. Now, you can see the rest of the comments if you view the entry in a site scheme, but that's not immediately obvious to Joe User.

I'll be the first to admit that I'm definitely no programming expert so I may be asking the impossible... Can we only kill the function that causes the recursion limit in a way that'll let the remaining comment threads on an entry get printed? It was also mentioned to me that perhaps we could look in to printing the comment threads iteratively rather than recursively? At the least, can/should we prevent people from making the nth comment that'll hit the recursion limit and therefore break the rest of that entry's comments?
foxfirefey: A wee rat holds a paw to its mouth. Oh, the shock! (thoughtful)
[personal profile] foxfirefey
Lately I've been thinking that a couple of items should be added to the site scheme menus.

1. In the Explore menu, a link to the interests.bml page. This will let people more easily find the popular interests page. Paid users will more easily be able to find the "find similar users" feature. It's possible this might be redundant based on the search box being interests by default, but I don't think it would be a bad idea to add another item to this very short menu. I also know that a lot of people would prefer the search box to use "Site and Account" by default, so it might not always be interests in the future.
2. In the paid menu, a link to payments history. It's related to shop stuff, that menu is really short. Some people might never really need it, but it makes it easier to access for people who don't look carefully at the buy paid accounts page.

I've edited my devhack to have these items pretty easily by modifying cgi-bin/DW/Logic/MenuNav.pm and vi bin/upgrading/en.dat to have a menunav.shop.history and a menunav.explore.interests. I feel like Interests should go on the top of the Explore menu and Payment History should go on the bottom of the Shop menu. I've made Interests always show up and Payment History show up if payments were enabled *and* the person is logged in.

Is this a good idea? Should I submit a patch for it? Is there something I'm missing in the process of editing the site navigation?
ysobel: (tech support)
[personal profile] ysobel
I'm working on a bug (well, a trio of bugs) that, I will admit, are not open beta blockers -- which also means I'm not going to pout (too much *G*) if the questions don't get answered immediately -- but I've gotten to a place where I can't totally proceed on my own.

...it *looked* easy! )

(I know y'all can't spare time for extensive handholding right now, but any pointers would be helpful. <3 )
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
[staff profile] mark
Here's a quick and dirty guide to things you will need to watch for when touching files and how to help us convert everything to Apache 2 / mod_perl 2 compatibility.

1) The Request Object

Never call Apache->request.  If you need the request object, use BML::get_request() which will do the Right Thing to return the appropriate request object for you to mess with.

2) $ENV{LJHOME} is Dead

You should use $LJ::HOME instead.  (Caveat: if you're writing a command line tool, you may need to use the environment variable, depending on what libraries you load... but for web context, always use $LJ::HOME!)

3) Methods become Hashes

In a move that I don't particularly understand, now we must pluralize some things and treat most things like a hash.  If you are used to this:

   $r->header_in("Host")
   $r->header_in("Host" => "bar");
   $r->notes("Something")

Then you should now get used to this:

   $r->headers_in->{Host};
   $r->headers_in->{Host} = "bar";
   $r->notes->{Something}

Not much of a change.  This goes for all of the header calls: headers_in, headers_out, err_headers_in, err_headers_out, etc as well as notes and pnotes.  There are probably other changes I've missed that do this too.

4) $r->send_http_header defunct?

I've yet to figure out a replacement for this function.  It seems to not be required anymore?  The modules seem to do the right thing, at least in all of the cases I've tried, without ever calling this.

5) ...?

I'm sure I'm missing something.  But at this point, if you want to start grepping through dw-free for header_in, send_http_header, notes, etc and then start fixing it, go for it!  It's appreciated, as there are still many files that have these.

As a second/other thought, I've been debating creating an LJ::Request object that we can use instead of Apache2::RequestRec (or whatever it is).  That way, if we ever need to change the way something works (i.e. upgrade to Apache 2.2 / mod_perl 2.2?) then we can change that one module.

Opinions and discussion are welcome, of course!

Profile

dw_dev: The word "develop" using the Swirly D logo.  (Default)
Dreamwidth Open Source Development

July 2025

S M T W T F S
  12345
6789101112
13141516171819
20212223 242526
2728293031  

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 31st, 2025 11:16 pm
Powered by Dreamwidth Studios