Hello.

Well, it has been awhile since I have posted a Thread in this Forum. Welp, I have come across an interesting and mysterious problem.

My Related Categories do not print correctly. There are no longer number of links, they do not appear in a bulleted list, and when you click on the link, they go no where because <BR> and <LI> codes have become embedded in the URL.

For Example, go to:

vlib.anthrotech.com/Archaeology/

Look at the Related Categories....

They are printed like the following:


I have not made any changes to the nph-build.cgi file recently.

I have added codes from Widgetz's search and category sort scripts, found in the following Thread:

CATEGORY and SEARCH SORT.. (mods)
www.gossamer-threads.com/scripts/forum/resources/Forum3/HTML/003409.html

I am not using the complete scripts posted in this Thread. I am using codes from the search.cgi for the sort and order stuff. I am also using the defined tags via the sub site_html_sort_link routine. I have revised this routine to look like the following:



I took out all the conditional nph-build.cgi codes, because I am not using the category.cgi script and I thought that those codes are not necessary.

The search engine works fine....To see it in action, go to:

vlib.anthrotech.com/bin/search.cgi

As you can see in the following codes...I have not changed the Related codes in the sub build_category_pages:



This is all very strange. Before (as of a week ago, which I have not made any major modifications to my scripts) the Related Categories printed in the following manner in the LINKS MANAGER CONSOLE:


NOW, they print in the following manner:


Any thoughts or suggestions are greatly appreciated.

Widgetz,

Did I make any major booboos with the revisions I made to your codes?? Thanks for any insight you can provide.

Thanks in advance.

Regards,

------------------
Eliot Lee
Anthro TECH,L.L.C
www.anthrotech.com
----------------------






[This message has been edited by Eliot (edited January 14, 2000).]

[This message has been edited by Eliot (edited January 14, 2000).]

BTW: I did temporarily solve this problem by using Wordpad to replace the <br> with ~~. Yet when I added a new category with related categories, the problem persists. I did delete this test category from my site, since my site is live and highly active.

But any thoughts on why this problem with the Related Categories is happening, I would greatly appreciate them.

Regards,

------------------
Eliot Lee
Anthro TECH,L.L.C
www.anthrotech.com
----------------------

Okay -- I'm having this problem as well.

I have the alt categories mod installed, and I think that the following in db_utils.pl is what is causing the problem:


This:

exists $in{$name} ? ($in{$name} .= "~~$value") : ($in{$name} = $value);

--------------------------------------------------------------------------------

was replaced with this to neatly format the alt categoryies field in the results pages:

code:
--------------------------------------------------------------------------------

exists $in{$name} ? ($in{$name} .= "<br>$value") : ($in{$name} = $value);



Has anyone come up with a workaround so that this code doesn't affect the display of the related ategories? Right now it is generating page breaks instead of properly formatting the bullet list.

Any help would be greatly appreciated -- I have removed all of my related categories pending a fix...

Best,

Screenking

Put ~~ in place of <br>, per this thread:

http://www.gossamer-threads.com/...cgi?post=26061#26061


Leonard
aka PerlFlunkie

THat messed up my formatting though (I display ALT categories on my results page, and the funky display with the tildas breaks my frames. I did the following slight mod to improve the display:

In add.cgi under sub main I changed:

&parse_form

to

&parse_form_alt

and in db_utils.pl, I added in the following subroutine just after sub parse_form:

sub parse_form_alt {
# --------------------------------------------------------
# Parses the form input and returns a hash with all the name
# value pairs. Removes any field with "---" as a value
# (as this denotes an empty SELECT field.
#
my (@pairs, %in);
my ($buffer, $pair, $name, $value);

if ($ENV{'REQUEST_METHOD'} eq 'GET') {
@pairs = split(/&/, $ENV{'QUERY_STRING'});
}
elsif ($ENV{'REQUEST_METHOD'} eq 'POST') {
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
}
else {
&cgierr('You cant run this script from telnet/shell.');
}

PAIR: foreach $pair (@pairs) {
($name, $value) = split(/=/, $pair);

$name =~ tr/+/ /;
$name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
($value eq "---") and next PAIR;
exists $in{$name} ? ($in{$name} .= "<br>$value") : ($in{$name} = $value);
}
return %in;
}

I tested it out -- everything seems to be in order. Because the parse form routine is unchanged for all of the admin activities, nothing is messed up, and my related categories are built just fine. Because all links have to be validated first, the admin module parses the form display through the old parse_form so it's formatted correctly in the DB. While the admin doesn't look as pretty, I really don't care since I'm the only one that sees it anyways.

Forgot -- same thing should be done with modify.cgi to keep alt categories display results nicely formatted with <br> tags. Admin uses old parse_form routine so all is well -- until I add in the next mod...

Glad ya got fixed!
Thanks for posting your code, too!


Leonard
aka PerlFlunkie