![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
kareilaHere'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:
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:
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!
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!
