meludame: zombie-walking stick figure of a man with the text "must have coffee" in all caps. (Default)
[personal profile] meludame

Hi! I'm [personal profile] meludame, I usuablly dabble in styles-related bug and this is the bug write-up I did for my latest.

Description:

Some of the older DW styles do not print the page subtitle even though the option is there on the customize style page. Styles that are concerned are the following:

  • Brittle, Negatives (doesn't print the title either)
  • Skittlish Dreams, Sunday Morning, Transmogrified
Proposed fix:

Edit the layouts concerned to add in the missing feature. Edit the relevant portion of the CSS to make the change as unobtrusive as possible for the user of said styles.

References files:
Files edited:
  • For each layout, styles/$layoutname/layer.s2 (in either dw-free or dw-nonfree).

Bug Diary )

Thanks:

I would like to thank the members of #dreamwidth and in particular (but non-exhaustively) [personal profile] sophie, [personal profile] kaberett, [personal profile] geekosaur, [personal profile] momijizukamori and [personal profile] ninetyd for their coaching, cheering and reassurances as I worked my way through this bug. Y'all are amazing :)

Note: Another copy of this entry lives in my journal.

crschmidt: (Default)
[personal profile] crschmidt
So, when I woke up this morning, in #dreamwidth, there was a discussion of a bug in auto-expanding lj-cuts in a particular entry. It looked interesting enough that I figured I would poke at it, since there was a theory it was a Javascript bug, and Javascript is a language I speak. (The actual bug was that clicking on a particular lj-cut expansion would expand to a different lj-cut text, now filed as Bug 4435.)

First, I didn't even know how to expand LJ-cuts inline. So I started from pretty much nothing here. :) But in the end, I think I found the bug, and attached a patch to Zilla, so I figured I'd write up my process.

Start: (6:46) Okay, clicking on the cut gives the wrong thing. Open up my browser's web console, and check the HTTP request that it's sending is right -- it specifies cutid=1, but is given one from a much later cut. (6:48) To me, this suggests that the problem is server side (not Javascript), so I have to dive into code I can't just load in my browser. I experiment a bit more to ensure that this appears to be the case, and determine I can't see any evidence that this is client side. (6:58).

I Googled 'dreamwidth code' (which didn't get me very far), then 'dreamwidth mercurial', which got me to the hg repo (even though it was the 5th result) first. After realizing I couldn't figure out how to check out the code from there, I went back to the first hit for that search, the opensource page, and made my way through to the wiki and from there to Getting Started and from there to Scratch Installation and from there to Downloading the code from which I grabbed bootstrap.pl, and from there to the one line I wanted: 'hg -q clone http://hg.dwscoalition.org/dw-free'. (Yes, if I knew mercurial better, I probably could have done this without following any of those steps ... but I didn't. In fact, I didn't even have mercurial installed at the time. So I also installed that.)

So, it's now 7:04, and after grep -r-ing for rpc_cuttag, I find cgi-bin/DW/Controller/RPC/CutExpander.pm, and realize that all the work in the cut expander is done by LJ::CleanHTML. My memory of working on LJ almost a decade ago was that this particular chunk of code was a hairy, nasty, mess -- as is almost any code that parses HTML -- so I was unsurprised to find that little has changed ;)

After looking briefly at CleanHTML (07:11), I decided that this was almost certainly a side effect of the particular entry text -- simple tests showed that this worked, but this entry was clearly failing. I checked briefly whether any community mods for that community might be in #dreamwidth -- the answer to which was no. (07:12).

At 07:15 I summarize my progress so far to the channel:
  1. Javascript is doing fine. IT's asking for the right cut. The server side is broken.
  2. The server side RPC mechanism is likely doing the right thing; there's no smarts there.
  3. Once it gets past that, it goes into the CleanHTML code, which in addition to being the gnarliest perl code I've ever not touched, definitely behaves very differently when in "looking for cut mode"
    than it does otherwise, so it's not super-surprising that this fails.
At 07:19, I basically declare defeat: without the source text for the bug, it will be very difficult to debug, but I continue to read the CleanHTML source anyway, trying to understand it slightly better. It's clear that lj-cut handling isn't trivial. I find a couple interesting things in the code, but nothing that calls to me as the source of the bug.

this gets long )
Total time: ~2 hours, start to finish, with a lot of stumbling around to figure out how things were supposed to work, and I'm still not particularly sure that I did things right, but it does look like I actually fixed the problem... the question is really just whether it also made anything else worse :)
randomling: A wombat. (Default)
[personal profile] randomling
Hi!

I wrote a bug walkthrough, which I have hidden behind a cut.

Long walkthrough is LONG. )
liv: Stylised sheep with blue, purple, pink horizontal stripes, and teacup brand, dreams of Dreamwidth (_support)
[personal profile] liv
So I was kind of an embryo dev for a long time, fixing little things in S2 and getting [personal profile] fu to turn my fixes into patches. I'm most proud of the first version of the Page Summary gadget and reworking custom reading page colors, including a mini-template thingy for layout makers. I decided I really ought to be making my own patches, which I viewed as graduating from embryo to baby. This turned out to be a bit of a saga, but now I've done it, I thought I'd contribute a bug write-up.

this is really, really basic! )

After several false starts (don't worry, I won't write up the saga of my horrendous attempts to make a color theme, which I'd expected would be an easy beginner bug and turned out to have hidden complications), it took me just a couple of hours from opening the bug to submitting a patch. OK, a couple of hours for 12 lines of code is not particularly impressive, but I was trying lots of things for the first time. I hope that as my babyhood phase progresses those effort-minor bugs will actually be a minor effort!
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
I decided to take on Bug 1512 as a quick hit, and thought I'd do a walkthrough so people could see my process!

(I like having walkthroughs. I think we should do them more often!)

My process )
kareila: "PERL!" (perl)
[personal profile] kareila
Here's my take on a simple bug I patched in five minutes. Most of the bugs I investigate are not this quick, but I wanted to use a simple example to encourage people to get their feet wet. Many of the bugs that get filed are actually not very complex, especially if they have the "effort-minor" keyword.

The bug in question here is bug 1362, "If journal title == user name, name doesn't display on profile." So we have to look at the code that generates the profile page. As a longtime LJ user, I happen to know that the canonical reference to the profile code is in /userinfo.bml, and the /profile and /info links on the user pages redirect to that. But if you didn't know that, you could either spend some time in the code looking around until you found it, or ask a developer to give you the starting point. In my personal experience, I asked for starting points for the first two or three bugs I did, and after that started looking around more on my own to get a feel for where important things tended to live.

The next thing for a new developer to realize is that because user-visible strings are supposed to be translatable for different languages, they are not (read: not supposed to be) stored in the code file itself, but in a companion file with the suffix .text. This is well documented in the section of the DW wiki that talks about English-stripping. In this case, if I look in htdocs/userinfo.bml.text, I find that "Name:" has the translation label of .label.name. We need to find out where this is being printed.

Somewhat confusingly, I don't find any references to .label.name in userinfo.bml itself, which means it's being called in another part of the code. So on the command line, I use grep -r to find all references to .label.name. The grep command is a developer's best friend, and the main reason to have a checked out copy of the code as opposed to browsing the repository through the web interface. One of my favorite techniques (not needed for this bug) is to grep 'sub function_name' to find the definition of a function, ignoring all the places the function is merely called, which you would see if you just grepped 'function_name'. Anyway, this command shows me that .label.name is called from cgi-bin/DW/Logic/ProfilePage.pm, line 357: grep -r \.label\.name .

The reported problem is that the name doesn't print if the name equals the journal title. We can see the code is doing exactly that:

unless ( $name eq $u->prop( 'journaltitle' ) ) {
    $ret->[0] = LJ::Lang::ml( '.label.name' );
    $ret->[1] = $name;
}

So all we have to do is remove the conditional surrounding the statements, and it will always print the name. Problem solved! I'm not going to spend time here talking about how to generate a patch and test a fix, because that's covered elsewhere.

My point is that the main work here was just finding the code to fix. The actual change was pretty trivial. I'd go so far as to suggest that beginning developers look at many different types of bugs to figure out what parts of the code are involved. Even if you can't figure out what changes need to be made to fix the bug, you'll still learn a lot in the process.

Anyway, that's a bugfix from my perspective. If you think I was too vague anywhere and you want more details, just ask!
foxfirefey: Dreamwidth: social content with dimension. (dreamwidth)
[personal profile] foxfirefey
This is a walkthrough for how I tackled Bug 858 - Private messages strip (rather than escape) HTML. I'm not a very experienced DW developer, so you're going to see me do a lot of bumbling around as I try to figure things out. But, I'm going to document all of my wrong turns and head scratchings in the hopes that seeing the whole process laid out from start to finish might help people who aren't sure how to go about things. I will note ahead of time that some of the issues I run into won't happen to people on Dreamhacks--they're due to my setup not being completely right.

To be honest, this walkthrough is a bit advanced and best suited for people already comfortable with the command line and coding. I'm going to do another one soon and hope that it doesn't go as awkwardly as this one did.

Table of contents:
  1. Preparation
  2. Finding the relevant code to make changes on
  3. Making the changes
  4. Testing
  5. Troubleshooting
  6. Patch evaluation and clean up
  7. Submitting the patch
  8. Hindsight
  9. Lessons Summary
  10. Notes Summary

The Walkthrough )

I hope this has been a useful walkthrough of the process of bug fixing and banging your head against things until they work. If anybody has questions about the contents here, or suggestions about things I should have done differently, feel free to comment!

Profile

dw_dev_training: The stylised 'd', with the word 'dev' above, and the word 'training' at the side, representing the dw_dev_training comm. (Default)
Dreamwidth Development Training

January 2017

S M T W T F S
1234567
891011121314
151617 18192021
22232425262728
293031    

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jun. 28th, 2017 05:32 am
Powered by Dreamwidth Studios