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 );
$db->initilize();
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?
Brent
$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 );
$db->initilize();
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?
Brent
".