Bug solved - moving on...
Dec. 13th, 2009 08:00 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
grimsnifferWell, bug-154 is currently fixed and waiting for a review and eventually a commit. My fix seems to pass all scenarios I can think of, but with me not yet knowing the Dreamwidth site very well, I won't be surprised if it has to be edited a little.
The bug involved the "Reply" and "Thread from Start" links not appearing in comments that are opened in new pages (having the ?replyto argument).
The core2.s2 file has a print_interaction_links() function that's in-charge of printing the interaction links to entry and reply comments (Those Link/Reply/Thread From Start etc.) comments you see under each post and entry you read.
This function had a conditional that would display the "Parent" and "Thread from Start" links only if their values were not null in the hashref passed to said function by ReplyPage.pm. So then it was just a matter of going to ReplyPage.pm, finding the hash and adding the relevant values. For some reason (which still escapes me) the hash-ref wouldn't accept variables declared earlier in ReplyPage.pm, even if they were in the same scope as it is. Meaning I couldn't use the various objects already declared creating the comment itself. So I basically had to declare these values in the hashref by creating a comment object out of the dtalkid I already had, and assigning its parent_url() return value to the value in the hashref (or the threadroot_url() return value, to the threadroot_url value in the hashref). This passed it all to print_interaction_links() in core2.s2 and voila! All works. Tested it in quite a few scenarios (comments of entries, comments of comments, entries as parents, heavily nested comments, different themes, etc.), and it seemed to work well. Let's see if someone manages to find something I've missed.
I was planning on publishing a proper walkthrough (and crosspost it to![[site community profile]](https://s.dreamwidth.org/img/comm_staff.png)
dw_dev_training), detailing my work process in solving this bug - but since this was my first bug working on Dreamwidth, the learning process was rather complicated. Took me about a week on-and-off to figure it out, and I'm not sure I can recreate all the phases I went through. I'll take a look at my notes in the coming days and see if I can glean the proper workflow (or at least the major parts of it).
Now starting work on bug-2208. Hopefully it won't take me as long.
The bug involved the "Reply" and "Thread from Start" links not appearing in comments that are opened in new pages (having the ?replyto argument).
The core2.s2 file has a print_interaction_links() function that's in-charge of printing the interaction links to entry and reply comments (Those Link/Reply/Thread From Start etc.) comments you see under each post and entry you read.
This function had a conditional that would display the "Parent" and "Thread from Start" links only if their values were not null in the hashref passed to said function by ReplyPage.pm. So then it was just a matter of going to ReplyPage.pm, finding the hash and adding the relevant values. For some reason (which still escapes me) the hash-ref wouldn't accept variables declared earlier in ReplyPage.pm, even if they were in the same scope as it is. Meaning I couldn't use the various objects already declared creating the comment itself. So I basically had to declare these values in the hashref by creating a comment object out of the dtalkid I already had, and assigning its parent_url() return value to the value in the hashref (or the threadroot_url() return value, to the threadroot_url value in the hashref). This passed it all to print_interaction_links() in core2.s2 and voila! All works. Tested it in quite a few scenarios (comments of entries, comments of comments, entries as parents, heavily nested comments, different themes, etc.), and it seemed to work well. Let's see if someone manages to find something I've missed.
I was planning on publishing a proper walkthrough (and crosspost it to
dw_dev_training), detailing my work process in solving this bug - but since this was my first bug working on Dreamwidth, the learning process was rather complicated. Took me about a week on-and-off to figure it out, and I'm not sure I can recreate all the phases I went through. I'll take a look at my notes in the coming days and see if I can glean the proper workflow (or at least the major parts of it).Now starting work on bug-2208. Hopefully it won't take me as long.