Gossamer Forum
Home : Products : Gossamer Links : Version 1.x :

A few bugs...

Quote Reply
A few bugs...
1.If you remove a link from an Alternate Category, all links in the entire Alternate Category will be removed. The code is in the file admin.cgi in the sub alternate_categories around line 441:

$db->do ("DELETE FROM CategoryAlternates WHERE CategoryID IN ($del));

change it to:

$db->do ("DELETE FROM CategoryAlternates WHERE CategoryID IN ($del) AND LinkID = $id");

2.If you delete a field from your Links database using the built-in Table Maintenance functions in the admin, the fields in Links.def aren't renumbered in sequential order. The only problem I've found (could be more) with this is that it can throw off your default search order in Links.pm:

$LINKS{build_sort_order} = "isNew,isPopular,Title";

For example, if you have 20 fields, numbered 1-20, and decide to delete one of them, say the field numbered 4, Links will only delete that line in Links.def and leave everything else alone. So you would have fields numbered 1 - 3 and 5 - 20 because 4 was deleted. When you build your pages, the links won't be sorted properly (depending on which field was deleted) because the map function in the sub build_sort_links in the file nph-build.cgi will incorrectly read the position of the fields numbered 5 - 20: they are actually fields 4 - 19. In the example, if isNew is numbered 12, it's actually number 11 and instead of being sorted by isNew, the links will be sorted on the field directly after isNew and so on.

I haven't come up with a fix with this one, other than to manually edit the Links.def to re-number the fields. The fix would go in the sub delete_field in the file editor.cgi about line 424:

# Update the .def file.
delete $db->{db_def}{$field};

<-- fix would go here: go thru each field after the deleted field and change the position number to ($pos_num - 1) -->

$db->write_to_file ( $file );
return "The database has been successfully updated.";

I played with it a bit but haven't gotten anything working.

3.With the extended template parser, if you use a field in the templates that contains the sequence "eq" (or "lt" or "gt", though less likely), the parser will choke on it because it's reading the tag as an "eq" as in 'equal to'. I haven't looked at this one at all except to comment out the entire line that does the check for "eq" (I don't use it anyway).

Those are all the bugs I have found thus far. There is/was a bug with the search in the admin, but I believe Alex posted a fix?

Quote Reply
Re: A few bugs... In reply to
Thanks for the bug notices. I've included the fix for 1, and came up with this for 2 which fixes it:

my $field_num = $db->{db_def}{$field}[0];
for ($field_num .. $#{$db->{db_cols}}+1) {
my $tmp = $db->{db_cols}[$_];
next unless ($tmp);
$db->{db_def}{$tmp}[0] = $db->{db_def}{$tmp}[0] - 1;

in sub delete_field in editor.cgi line 445.

As for the template parser, what did you use? I tried <%notequal%> and it worked fine (didn't treat it as a comparision). I think as long as you avoid spaces in your names you should be ok.

Thanks for the great feedback!



Quote Reply
Re: A few bugs... In reply to
Hello Brent!


Alex did not respond to this message after my explaination. Is that something that is similar to what you discovered?

Secondly, you came up with this great Alternate Category mod, I beleive. Actually I am struggling to use it as a Multiple_Category mod. Perhaphs you can help solving this Kilometer long listing Links SQL does for categories (Alex told me that it is a custom modification and that I should pay for it).

The problem is "More the categories longer is the listing of the pop-up of add/modify/admin.cgi Smile".

I was one of the first to buy the Links SQL and till today there is more that quarter megabytes of messages written by me and there is absolutely no solution given by Alex, for e.g. import of database through editor.cgi from access etc. Links SQL needs a lot of development.


[This message has been edited by rajani (edited November 02, 1999).]

[This message has been edited by rajani (edited November 02, 1999).]
Quote Reply
Re: A few bugs... In reply to
As for 'renumbering' the fields, if that wasn't directly addressed in a bug fix, it can be fixed by simply 'resyncing' the .def file. So, after doing table modifications, resync the .def (not a bad idea anyway). It will write out a new .def with the current table information.

Maybe Alex can fix this by just putting a call in to 'resync' after table modifications.