Lee (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
randomling) wrote in ![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
dw_dev_training2012-03-12 09:20 pm
randomling) wrote in dw_dev_training2012-03-12 09:20 pm
Entry tags:
Bug walkthrough: 2886
Hi!
I wrote a bug walkthrough, which I have hidden behind a cut.
This is my very first patch so it may be rather odd and wander-ey.
The first thing I did was figure out how to grep. I had never grepped anything before, so it took a quick question in IRC and some actual reading of the Wiki entry to figure out what I was doing wrong. Note to both self, and any new greppers: don't forget to add the place you want to search, or your poor dreamhack gets VERY confused.
Once I'd worked out HOW to grep, the next challenge was working out WHAT to grep. The uselang=debug option didn't seem to work on the pages I was hunting for, and "links" obviously returned a huge number of mostly-irrelevant results. Searching for "links list" went a bit better and I downloaded some relevant files (on which, a bit more in a paragraph or two). Finally, I hit on searching for the text which appears on http://www.dreamwidth.org/customize/options?group=linkslist - namely, "Use this form to create a list of links to appear on your journal."
This led me to cgi-bin/LJ/Widget/LinksList.pm, which I promptly downloaded.
A couple of newbie challenges I had along the way:
1. Downloading files! I use TextWrangler as my text editor, so I wanted to download the files onto my machine rather than editing them through one of the Terminal editors (which sounds terrifying!). I couldn't connect to my dreamhack through Filezilla at all until I realized that all I needed to do was add sftp:// to the server path! (I still haven't worked out how to use TextWrangler to FTP to my dreamhack, but it is theoretically possible.)
2. Making TextWrangler open some of the files once I had them. TW recognizes a lot of programming languages but not BML or S2 - in the end I had to add the .bml and .s2 file extensions to TW in Preferences/Languages, and now TW shows and opens them just fine. Yay!
Now that I had LinksList.pm, it was time to work through the code and figure out where the bit I needed lived, what it did and how it did it.
I made use of a bunch of comments for this, because TextWrangler's syntax highlighting makes it easy to distinguish different elements, and I find it quite easy to flick through the file just reading comments to figure out where I am.
Eventually, I found the right subroutine - and was immediately intimidated by the code! I've been hacking Perl for about six months, and most of the code I'm comfortable with is quite simple. A lot of the Dreamwidth code seems reasonably complex; because it's so large, and doing so many things, including interacting with a database, there are modules all over the place, and huge numbers of hash references.
It turned out that the subroutine I was interested in was called render_body and was, quite simply, building a text form and saving the user's input into a hashref, which then gets passed back to Links.pm for processing (on which more later).
So I decided the most sensible thing to do was to start by adding a textfield to this form for hover text. Made sense! And honestly, I pretty much copy/pasted the code, made a couple of edits to change the names of variables, and uploaded to my Dreamhack.
This was the point where I discovered the difference between CVS and the live code! I'd been downloading from (and uploading to) the CVS folder rather than the live version of the code, so I was uploading, restarting Apache, and.... nothing. It was weird! It was only oncesophie explained what version control was that I realised what I was doing wrong.
Anyway, I fixed that problem - and bang, I had a new textfield. Like the pirates who don't do anything, however, it... didn't actually do anything yet.
Next job was to figure out what the code did with the data from render_body. It seemed like a no-brainer to find out where this particular sub was called. I can't honestly remember now (I didn't keep enough notes on the process to write a proper walkthrough!) but I think that what I did was grep for render_body. I'm pretty sure that returned more results than I could handle (every Widget has a render_body subroutine that handles the way it displays in the sidebar). So I eventually figured out that this would be called with LinksList::render_body, and this, somehow, led me to Links.pm.
Where I promptly panicked again. This was the place where information was passed to the database - which meant, argh, SQL! I am sort of teaching myself SQL but I'm very unfamiliar with it, and seeing it in practice was kind of confusing!
sophie walked me through the next part. She explained how to change Links.pm so that the information it was being passed from the web form went into the database. Then she explained how to change update-db-general.pl to insert a new field into the links table to look after the hover text I had created.
(And I have just discovered that update-db-general.pl is nowhere in my patch file. This is clearly a mistake that I need to fix! Excuse me while I fix the code, generate a new patch and upload it to Bugzilla...)
Once that was all figured out, I had more magic - I was able to enter links, including hover text, onto my 'hack, and they would stay there when I refreshed the page!
So I'd got them into the database. That was part one.
The next stage was figuring out how to get them out again. This was more than a bit confusing, because the code that actually serves various bits of content is complicated, and distributed over a number of files, and I had quite a bit of trouble working out where the code I needed lived.
It turned out that it was mostly in core2.s2. So I dug around. Along the way, I filed Bug 3985, and after a few false starts and mishits, I finally managed to get the hover text showing up on my test user's journal page.
Victory!
Then I thought about testing, and after that I noodled around doing other things (get a job! Learn Javascript! Um...), and didn't really work on any DW code for about three months...
Anyway. Three months later, I returned, asked a few pointed questions about testing, and got some very helpful answers from![[staff profile]](https://www.dreamwidth.org/img/silk/identity/user_staff.png)
denise and others. I tested the code, fairly minimally. After the testing, I made a change to my code, stripping any HTML tags from the hover text before sending it to the database. Then I patched it and submitted it.
Now that I'm waiting (with bated breath!) to hear whether or not my patch passes review and gets committed, I... well. I'm taking yet more online courses, looking for work (again!) and picking up another bug to work on from Bugzilla.
This development thing is sort of addictive.
I wrote a bug walkthrough, which I have hidden behind a cut.
This is my very first patch so it may be rather odd and wander-ey.
The first thing I did was figure out how to grep. I had never grepped anything before, so it took a quick question in IRC and some actual reading of the Wiki entry to figure out what I was doing wrong. Note to both self, and any new greppers: don't forget to add the place you want to search, or your poor dreamhack gets VERY confused.
Once I'd worked out HOW to grep, the next challenge was working out WHAT to grep. The uselang=debug option didn't seem to work on the pages I was hunting for, and "links" obviously returned a huge number of mostly-irrelevant results. Searching for "links list" went a bit better and I downloaded some relevant files (on which, a bit more in a paragraph or two). Finally, I hit on searching for the text which appears on http://www.dreamwidth.org/customize/options?group=linkslist - namely, "Use this form to create a list of links to appear on your journal."
This led me to cgi-bin/LJ/Widget/LinksList.pm, which I promptly downloaded.
A couple of newbie challenges I had along the way:
1. Downloading files! I use TextWrangler as my text editor, so I wanted to download the files onto my machine rather than editing them through one of the Terminal editors (which sounds terrifying!). I couldn't connect to my dreamhack through Filezilla at all until I realized that all I needed to do was add sftp:// to the server path! (I still haven't worked out how to use TextWrangler to FTP to my dreamhack, but it is theoretically possible.)
2. Making TextWrangler open some of the files once I had them. TW recognizes a lot of programming languages but not BML or S2 - in the end I had to add the .bml and .s2 file extensions to TW in Preferences/Languages, and now TW shows and opens them just fine. Yay!
Now that I had LinksList.pm, it was time to work through the code and figure out where the bit I needed lived, what it did and how it did it.
I made use of a bunch of comments for this, because TextWrangler's syntax highlighting makes it easy to distinguish different elements, and I find it quite easy to flick through the file just reading comments to figure out where I am.
Eventually, I found the right subroutine - and was immediately intimidated by the code! I've been hacking Perl for about six months, and most of the code I'm comfortable with is quite simple. A lot of the Dreamwidth code seems reasonably complex; because it's so large, and doing so many things, including interacting with a database, there are modules all over the place, and huge numbers of hash references.
It turned out that the subroutine I was interested in was called render_body and was, quite simply, building a text form and saving the user's input into a hashref, which then gets passed back to Links.pm for processing (on which more later).
So I decided the most sensible thing to do was to start by adding a textfield to this form for hover text. Made sense! And honestly, I pretty much copy/pasted the code, made a couple of edits to change the names of variables, and uploaded to my Dreamhack.
This was the point where I discovered the difference between CVS and the live code! I'd been downloading from (and uploading to) the CVS folder rather than the live version of the code, so I was uploading, restarting Apache, and.... nothing. It was weird! It was only once
sophie explained what version control was that I realised what I was doing wrong.Anyway, I fixed that problem - and bang, I had a new textfield. Like the pirates who don't do anything, however, it... didn't actually do anything yet.
Next job was to figure out what the code did with the data from render_body. It seemed like a no-brainer to find out where this particular sub was called. I can't honestly remember now (I didn't keep enough notes on the process to write a proper walkthrough!) but I think that what I did was grep for render_body. I'm pretty sure that returned more results than I could handle (every Widget has a render_body subroutine that handles the way it displays in the sidebar). So I eventually figured out that this would be called with LinksList::render_body, and this, somehow, led me to Links.pm.
Where I promptly panicked again. This was the place where information was passed to the database - which meant, argh, SQL! I am sort of teaching myself SQL but I'm very unfamiliar with it, and seeing it in practice was kind of confusing!
sophie walked me through the next part. She explained how to change Links.pm so that the information it was being passed from the web form went into the database. Then she explained how to change update-db-general.pl to insert a new field into the links table to look after the hover text I had created.(And I have just discovered that update-db-general.pl is nowhere in my patch file. This is clearly a mistake that I need to fix! Excuse me while I fix the code, generate a new patch and upload it to Bugzilla...)
Once that was all figured out, I had more magic - I was able to enter links, including hover text, onto my 'hack, and they would stay there when I refreshed the page!
So I'd got them into the database. That was part one.
The next stage was figuring out how to get them out again. This was more than a bit confusing, because the code that actually serves various bits of content is complicated, and distributed over a number of files, and I had quite a bit of trouble working out where the code I needed lived.
It turned out that it was mostly in core2.s2. So I dug around. Along the way, I filed Bug 3985, and after a few false starts and mishits, I finally managed to get the hover text showing up on my test user's journal page.
Victory!
Then I thought about testing, and after that I noodled around doing other things (get a job! Learn Javascript! Um...), and didn't really work on any DW code for about three months...
Anyway. Three months later, I returned, asked a few pointed questions about testing, and got some very helpful answers from
denise and others. I tested the code, fairly minimally. After the testing, I made a change to my code, stripping any HTML tags from the hover text before sending it to the database. Then I patched it and submitted it.Now that I'm waiting (with bated breath!) to hear whether or not my patch passes review and gets committed, I... well. I'm taking yet more online courses, looking for work (again!) and picking up another bug to work on from Bugzilla.
This development thing is sort of addictive.