[Previous entry: "Future Google page rank"] [Next entry: "Another Greymatter Bug in the 1.3.1 upgrade"]

07/13/2005: "A bug in Greymatter 1.3.1 causing nested borders"

When I upgraded my main Oracle Security Blog from version 1.3 of Greymatter to 1.3.1 I came across a bug. When I viewed all my pages to check that they looked OK i found that the main index page and the monthly archive indexes had a problem. The border around each entry was nesting. I.e each entry seemed to be inside each other. I investigated the Greymatter source code and found the problems. Below is the description I posted in a bug report to the greymatter forums:-

Hi Everyone,

I have just updated my blog (http://www.petefinnigan.com/weblog/entries/index.html) from 1.3 to the latest 1.3.1. The upgrade went smoothly but when I have rebuilt all my indexes and entries I had two problems. The first was that on the main index page the borders around the entries were nested inside each other so that by the end of the page I had every border nested inside each other. I tracked down the problem to the fact that my gm-templates.cgi file had the date grouping footer entry missing for the main index page. I did not upload the template file as I did an upgrade. I can only surmise that the update function when writing the template did not write the </div>
back into the template (line 14). I did not look further for the bug as I simply uploaded my old template which fixed the issue.

My second problem was that the same issue occurred with the archive index pages for each month. The date grouped entries which have borders were nesting inside each other. The issue again was that the </div>
in the date archive footer variable was not getting written to the HTML files. This time the entry was present in the gm-template file (line 77) correctly. I tracked the problem down to a bug in the code in gm-library.cgi at line 2491. The line is shown below:-


# added $dategrouping flag checking : 1.3.1
# flipped cracker 6/29/2004
if (($nextdatemark ne $indexcurrentdatemarker) && ($dategouping eq " open") && ($thisentryopenstatus eq "open") && ($indexentrycounter ne $newstayattopnumber)) {
if ($gmdategroupingfooterarchivetemplate ne "") {


There are two bugs in the use of the new $dategrouping variable - the first is that it is spelled $dategouping (i.e. the "r" is missing) and the second is that the check for "open" includes a space in front of the word "open". I fixed the line as :


# added $dategrouping flag checking : 1.3.1
# flipped cracker 6/29/2004
# Pete Finnigan 26-06-05 - fixed variable name dategrouping and removed space before "open"
if (($nextdatemark ne $indexcurrentdatemarker) && ($dategrouping eq "open") && ($thisentryopenstatus eq "open") && ($indexentrycounter ne $newstayattopnumber)) {


and uploaded the gm-library.cgi file. I rebuilt the archive templates and they are now built correctly.

Please add this latter fix to the next update. Or if anyone else has had this issue I hope these solutions will help

Thanks

kind regards

Pete