Gossamer Forum
Home : Products : Links 2.0 : Discussions :

Modify Confirm

(Page 1 of 2)
> >
Quote Reply
Modify Confirm
I just looked for a mod similar to the Add Confirm mod that would do the same thing for those who wish to modify a link.

I realized that even with the id/password (password modify) mod in place, when someone submits their updated information through modify.cgi, they might wish to correct something.

Without the confirmation page, they would need to wait until the link was verified by admin before they could redo their mistake!

Does this mod exist?

------------------
BruceS
Quote Reply
Re: Modify Confirm In reply to
You're the best! Smile

I had a feeling it would be the same type of mad as the add confirm one.

Now I can remove the password.cgi reference I put in the Modify Error template. They won't need that email, now, will they? They'll get the info when the changes are validated! Smile

Now you should post this in the resources officially! Don't ya think?

------------------
BruceS
Quote Reply
Re: Modify Confirm In reply to
One step further!

I got an idea. Since we now have a system where site owner's wishing to modify their link can enter their ID and Password using modify_first, and the password shows up as astericks. And I have assigned a common password for those links that were derived originally from sources other than the link owners.

Rather than use the hacked Recommend it script for owner's of existing links that weren't submitted by them but wish for administration, how about this.

1) I list the ID number with the link # <%ID%> in link.html

2) Add a global in site_templates.pl
Code:
GPass => xxx
(Where xxx = common password)

3) Make a copy of modify_first.html and call it modify_second.html.

4) Put a notice on modify_first.html "If you are the owner or person responsible for... etc. with a link to modify_second.html

5) Instruct them to locate the link ID they wish to modify. And make sure they CHANGE the astericked password to the one of their chosing. Also WARN Them that "ALL MODIFICATIONS WILL BE VALIDATED - DO NOT ATTEMPT TO MODIFY A RESOURCE YOU ARE NOT RESPONSIBLE FOR!"

6) In the password input filed:
Code:
Password: <input type="password" Name="Password" value="<%GPass%>" maxlength="20">

Since I will still need to validate the modified link to confirm their ownership, I now can do that from the admin, and save the need to exchange emails approving the new password. Plus this way, if validated, they don't need to go back to make their changes.

My only concern is about the new Modify Confirm page which will reveal the password in plain text. If they don't change it, they will now have the common password.

I think the password should be revealed in the password confirm page for those who may be using the system to change the password!

I suppose that if this happened, I could then change the common password and block that ISP.

Can you see any flaws or anything I have overlooked?

------------------
BruceS

[This message has been edited by BruceS (edited January 24, 2000).]
Quote Reply
Re: Modify Confirm In reply to
 
Quote:
Now I can remove the password.cgi reference I put in the Modify Error template. They won't need that email, now, will they? They'll
get the info when the changes are validated!

That's fine...But I would still include a link to the password.cgi file in your main modify page.

About your idea...I think you missed my point with hacking the Recommend It Mod...What you are recommending is that people who are not associated with the link, but want to provide suggestions, will write data to the modified.db. I see this as a huge administrative nightmare.

Simply using an email form is a lot more efficient and uses less server resources.

But you can try your idea and see if it works.

Regards,

------------------
Eliot Lee
Anthro TECH,L.L.C
www.anthrotech.com
* Be sure to visit the Resource Center for FAQ's, Modifications and Extra Goodies!!
* Search Forums!
* Say NO to Duplicate Threads. :)
----------------------







Quote Reply
Re: Modify Confirm In reply to
Elliot, see above, but first.... oops, I see you did!

My modify.cgi was changed to accomodate the password mod. therefore the sub main {
has been replaced it now appears as:
Code:
sub main {
# Replaced for password mod 1/23/00.
# --------------------------------------------------------
local (%in) = &parse_form;

# We are processing the form.
if ($in{'Submit'}) {
&process_form;
}

# Otherwise we are displaying the form (in site_html.pl), displaying
# the entrance (Asks for Link ID and Password)
else {
if ($in{'ID'} =~ /^\d+$/) {
my (%rec) = &get_record ($in{'ID'});

if ($rec{$db_key} eq $in{'ID'}) {
if ($rec{'Password'} eq $in{'password'}) {
&site_html_modify_form (%rec);
}
else {
&site_html_modify_failure ("Password Invalid: $in{'password'}");
}
}
else {
&site_html_modify_failure ("Unkown Link ID: $in{'ID'}");
}
}
else {
&site_html_modify_first;
}
}
}
Rather than just replaceing the if statement and leaving the else as is, and screw up your find and replace above, I thought I'd just ask for a further instructions.

And the sub process_form {
Code:
sub process_form {
# --------------------------------------------------------
my ($key, $status, @values, $found);
local (%original);

# Make sure we have a link to modify.
# Following line deleted for password mod 1/22/00 along with line below "if($data...


# Let's check to make sure the link we want to update is actually
# in the database.
open (DB, "<$db_file_name") or &cgierr("error in validate_records. unable to open db file: $db_file_name. Reason: $!");
$found = 0;
LINE: while (<DB> ) {
(/^#/) and next LINE;
(/^\s*$/) and next LINE;
chomp;
@data = &split_decode($_);
if ($data[$db_key] eq $in{'ID'}) {
$in{$db_key} = $data[0];
$found = 1;
%original = &array_to_hash (0, @data);
last LINE;
}
}
close DB;
!$found and &site_html_modify_failure ("Sorry, link was not found in the database") and return;

# Since we have a valid link, let's make sure the system fields are set to their
# proper values. We will simply copy over the original field values. This is to stop
# people from trying to modify system fields like number of hits, etc.
foreach $key (keys %add_system_fields) {
$in{$key} = $original{$key};
}
To me it seems like just replacing that part of the sub would be ok since it sends visitor to confirm page and then activates the new sub (splits up the work over two pages, but I thought i'd be sure!

anything else I missed?

------------------
BruceS

[This message has been edited by BruceS (edited January 24, 2000).]
Quote Reply
Re: Modify Confirm In reply to
I will take your advise, and stick with the modify confirm issue first, after that I'd like to address one more thing about my suggestion!

------------------
BruceS
Quote Reply
Re: Modify Confirm In reply to
No...This Mod does not exist.

Good suggestion.

It could easily be implemented using similar codes found in the Confirmation Mod for the add.cgi file.

Regards,

------------------
Eliot Lee
Anthro TECH,L.L.C
www.anthrotech.com
* Be sure to visit the Resource Center for FAQ's, Modifications and Extra Goodies!!
* Search Forums!
* Say NO to Duplicate Threads. :)
----------------------







Quote Reply
Re: Modify Confirm In reply to
Here is what you need to do:

1) Replace the following codes in the sub main routine of the modify.cgi file:

Code:
# We are processing the form..
if (keys %in != 0) {
&process_form;
}
# Otherwise we are displaying the form (in site_html.pl).
else {
&site_html_modify_form;
}

with the following codes:

Code:
# We are processing the form.
if ($in{'send_form'}) {
&send_form;
}
elsif ($in{'process_form'}) {
&process_form;
}
else {
&site_html_modify_form;
}

2) Replace the following codes in the sub process_form routine in the modify.cgi script:

Code:
# Print out the modified record to a "modified database" where it is stored until
# the admin decides to add it into the real database.
open (MOD, ">>$db_modified_name") or &cgierr("error in modify.cgi. unable to open modification database: $db_modified_name. Reason: $!");
flock(MOD, $LOCK_EX) unless (!$db_use_flock);
print MOD &join_encode(%in);
close MOD; # automatically removes file lock
# Send the admin an email message notifying of new addition.
&send_email;
# Send the visitor to the success page.
&site_html_modify_success;

WITH THE FOLLOWING:

Code:
# Send the visitor to the Confirmation page.
&site_html_modify_confirm;

3) Add the following sub-routine:

Code:
sub send_form {
# --------------------------------------------------------
my ($key, $status, $line, $output);

# Print out the modified record to a "modified database" where it is stored until
# the admin decides to add it into the real database.
open (MOD, ">>$db_modified_name") or &cgierr("error in modify.cgi. unable to open modification database: $db_modified_name. Reason: $!");
flock(MOD, $LOCK_EX) unless (!$db_use_flock);
print MOD &join_encode(%in);
close MOD; # automatically removes file lock

# Send the admin an email message notifying of new addition.
&send_email;
# Send the visitor to the success page.
&site_html_modify_success;
}

4) Add the following sub-routine in your site_html_template.pl file:

Code:
sub site_html_modify_confirm {
# --------------------------------------------------------
# This routine determines how the add success page will look like.

my $category = shift;
my $clean_category = &build_clean($category);
$category ?
($category = qq~$clean_category <input type=hidden name="Category" value="$category">~) :
($category = &build_select_field ("Category", "$in{'Category'}"));
&html_print_headers;
print &load_template ('modify_confirm.html', {
Category => $category,
%in,
%globals
});
}

5) Create a new template file: modify_confirm.html. Make this similar to the add_confirm.html file.

6) Change the following input field in your modify.html file:

Code:
<input type="SUBMIT" value="Modify Resource">

to the following:

Code:
<input type="SUBMIT" name="process_form" value="Modify Resource">

7) Make sure that you use the following input field in the modify_confirm.html file:

Code:
<input type="SUBMIT" name="send_form" value="Modify Resource">

Hope this helps.

BTW: Since this directly relates to a Mod in the Resource Center and you are inquiring about a code hack to fit your purposes, the better forum to post these types of requests is in the Modification Forum.

Good night!

------------------
Eliot Lee
Anthro TECH,L.L.C
www.anthrotech.com
* Be sure to visit the Resource Center for FAQ's, Modifications and Extra Goodies!!
* Search Forums!
* Say NO to Duplicate Threads. :)
----------------------







Quote Reply
Re: Modify Confirm In reply to
Remember my suggestion I gave you via email...ONE MOD AT A TIME! Like in the Movie,"What About Bob?"..."baby steps to the modify mod"..."baby steps to the expanded modify mod" (which I won't gaurantee that I will provide the codes for).

Wink

BTW: Do you know how long it took me to develop the Anthropology Virtual Library? OVER TWO YEARS! One year and a half years of raw coding and editors. And eight months using LINKS to get it to the point where it is now...and I am still working on improving it.

If you think that your site will develop overnight into the ideal site...you've got another thing coming. It takes time to develop sites both from the technical end and design end. Be more patient. It will come...in time.

Another suggestion I have is to buy a Perl book that will teach you codes that you can implement into LINKS.

Smile

Regards,

------------------
Eliot Lee
Anthro TECH,L.L.C
www.anthrotech.com
* Be sure to visit the Resource Center for FAQ's, Modifications and Extra Goodies!!
* Search Forums!
* Say NO to Duplicate Threads. Smile
----------------------









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

[This message has been edited by Eliot (edited January 24, 2000).]
Quote Reply
Re: Modify Confirm In reply to
I am sorry, I don't understand. The password mod is in place and working. So how does this defy your advise?

I believe you gave the modify confirm on the basis of the modify.cgi as is originally stood. Now, prior to going any further (as I suggested above:
Quote:
I will take your advise, and stick with the modify confirm issue first, after that I'd like to address one more thing about my suggestion!

If you are saying that the coding to integrate both the password and modify confirm are too complicated to integrate at this time (ie: either one, or the other), then so be it. I will put that off for now.

I just thought that since you offered the modify confirm based on the original modify.cgi, the revised version for password and confirm could be put into place without a big deal.

I am understanding more about how perl works daily just like most programming I have learned, but I do plan on getting a reference book on the subject very soon!

Thanks,

------------------
BruceS
Quote Reply
Re: Modify Confirm In reply to
Can this work with the Password Mod?

I've been hacking around with it, but so far no luck.

Thanks.
Quote Reply
Re: Modify Confirm In reply to
Yes...It can...And I have it working with in my modify.cgi script.

Regards,

------------------
Eliot Lee....
* Check Resource Center
* Search Forums

Quote Reply
Re: Modify Confirm In reply to
Yep, I got it working. It's a nice feature. Smile
Quote Reply
Re: Modify Confirm In reply to
Good for you.

Regards,

------------------
Eliot Lee....
Former Handle: Eliot
* Check Resource Center
* Search Forums
Quote Reply
Re: Modify Confirm In reply to
Eliot,

I am glad to hear that DogTags has gotten this to work.

Actually, you had previously provided me the consolidated mod a few weeks ago, and (taking you advise re: one at a time) I put it aside until I finished the one I am about to tackle. I have posted elsewhere about this but have not received any replies.

That is regarding integrating WebAdverts. I belive I wish to use it with SSI, and have seen too many different opinions on this.

In another thread, you said that you had it workin on Anthrotech without any mods. I asked if you would explain.

I have seen a routine which would work by adding a global and sub routine. which is fine if you are not going to target by keyword or category.

Please take a moment and consolidate your explaination. I am sure there are may who will benifit!

------------------
BruceS
Quote Reply
Re: Modify Confirm In reply to
Please go to the Resource Center and look at the FAQ about WebAdverts...I am using the IFRAME option.

If you have problems with the FAQ or can't get it to work, and you have THOROUGHLY searched the Modification Forum, then post a new Thread regarding WebAdverts in the Modification Forum...BUT please check out the FAQ in the Resource Center, and search all Threads by FIND IN PAGE option for the last year for WebAdverts Threads FIRST!

Regards,

------------------
Eliot Lee....
Former Handle: Eliot
* Check Resource Center
* Search Forums
Quote Reply
Re: Modify Confirm In reply to
I'm getting a very strange problem.

I use AnthroRules' suggestions for modding the Add Confirm mod for a Modify Confirm mod mentioned below, and the LWP URL checker, and the Password Mod, and AnthroRules Link Lookup Script.

When I click the Submit button on modify.html, the modify_confirm.html page builds with all the right information, but somehow the modify.html page gets attached to the bottom of modify_confirm.html. I can't see what's causing this.

There's no Include code at the bottom modify_confirm.html, but I can't see the problem.

Then, on the next page, enter a Category and AltCategories (required), then hit Submit. You'll see what happens.

In modify.cgi:
Code:
sub main {
### --------------------------------------------------------
local (%in) = &parse_form;

### We are processing the form.

if ($in{'send_form'}) {
&send_form;
}
if ($in{'modify_form'}) {
&process_form;
}
if ($in{'Submit'}) {
&process_form;
}

If I use if/elsif/else above, I get 500 errors.

Code:
sub process_form {
# Send the visitor to the Confirmation page.
&site_html_modify_confirm;

Code:
sub send_form {
# --------------------------------------------------------
my ($key, $status, $line, $output);
# Print out the modified record to a "modified database" where it is stored until
# the admin decides to add it into the real database.
open (MOD, ">>$db_modified_name") or &cgierr("error in modify.cgi. unable to open modification database: $db_modified_name. Reason: $!");
flock(MOD, $LOCK_EX) unless (!$db_use_flock);
print MOD &join_encode(%in);
close MOD;
# automatically removes file lock# Send the admin an email message notifying of new addition.
&send_email;
# Send the visitor to the success page.
&site_html_modify_success;
}

In site_html_template.pl
Code:
sub site_html_modify_confirm {
# --------------------------------------------------------
# This routine determines how the add success page will look like.
my $category = shift;
my $clean_category = &build_clean($category);
$category ?
($category = qq~$clean_category <input type=hidden name="Category" value="$category">~) :
($category = &build_select_field ("Category", "$in{'Category'}"));
&html_print_headers;
print &load_template ('modify_confirm.html', {
AltCategories => $altcategories,
Category => $category,
altcategories => $altcategories,
category => $category,
%in,
%globals
});
}

In modify_first.html (and visitor has ID and password), I use:
Code:
<INPUT TYPE="Submit" VALUE="Submit">

modify.html:
Code:
<input type="SUBMIT" name="modify_form" value="Modify Resource">

The above is different than what AnthroRules provides in this thread. I had to change it because of the LWP URL Checker that processes anything using name="process_form".

modify_confirm.html:
Code:
<INPUT TYPE="Submit" NAME="send_form" VALUE="Submit Changes - Hit Only Once">


Thanks for taking the time to help. Much appreciated.

[This message has been edited by DogTags (edited May 12, 2000).]
Quote Reply
Re: Modify Confirm In reply to
Looks like your sub main is a bit naked. Wink Looks like you are missing a bunch of codes.

In my sub main I have an if, elsif, and a series of nested else statements.

BTW: Where did you get the design idea for your footer section of your new site??? And the header part of your site?

I wonder where....Looks mighty similar to my old and new site layout.

Wink

Regards,

------------------
Eliot Lee....
Former Handle: Eliot
Anthro TECH, L.L.C
anthrotech.com
* Check Resource Center
* Search Forums
* Thinking out of the box (codes) is not only fun, but effective.




[This message has been edited by AnthroRules (edited May 11, 2000).]

[This message has been edited by AnthroRules (edited May 11, 2000).]
Quote Reply
Re: Modify Confirm In reply to
Absolutely !! I love your site. I think it's just what a link site ought to be. Actually, once I get the programming figured out, I'm gonna concentrate on a custom look throughout. I want to do custom graphics and provide tutorials on how to do them. So, the look should change quite a bit after the gearbox gets working.

I didn't include the full section before because the password function seems to be working fine. Here's the full sub main section:

Code:
sub main {
### --------------------------------------------------------
local (%in) = &parse_form;

### We are processing the form.

if ($in{'send_form'}) {
&send_form;
}
if ($in{'modify_form'}) {
&process_form;
}
if ($in{'Submit'}) {
&process_form;
}

### Otherwise we are displaying the form (in site_html.pl), displaying
### the entrance (Asks for Link ID and Password)
else {
if ($in{'ID'} =~ /^\d+$/) {
my (%rec) = &get_record ($in{'ID'});

if ($rec{$db_key} eq $in{'ID'}) {
if ($rec{'password'} eq $in{'password'}) {
&site_html_modify_form (%rec);
}
else {
&site_html_modify_failure ("Password Invalid: $in{'password'}");
}
}
else {
&site_html_modify_failure ("Unkown Link ID: $in{'ID'}");
}
}
else {
&site_html_modify_first;
}
}
}

I think the problem is with the confirm hack. I'm gonna go back and undo everything. Then, I'll try to get everything BUT the confirm hack to work (password, LWP URL checker, Look up), and then afterward try to incorporate the confirm thing. It is strange how modify.html gets tacked onto the end of modify_confirm.html. Smile
Quote Reply
Re: Modify Confirm In reply to
I guess the main problem I'm having is joining phoenix' Password with the Confirmation mod. I thought I had it, but I just noticed the prob mentioned above.

For instance:
The sub main in standard modify.cgi is:
Code:
sub main {
# --------------------------------------------------------
local (%in) = &parse_form;

# We are processing the form..
if (keys %in != 0) {
&process_form;
}
# Otherwise we are displaying the form (in site_html.pl).
else {
&site_html_modify_form;
}
}

The sub main for Password mod :
Code:
sub main {
# --------------------------------------------------------
local (%in) = &parse_form;

# We are processing the form.
if ($in{'Submit'}) {
&process_form;
}
# Otherwise we are displaying the form (in site_html.pl), displaying
# the entrance (Asks for Link ID and Password)
else {
if ($in{'ID'} =~ /^\d+$/) {
my (%rec) = &get_record ($in{'ID'});

if ($rec{$db_key} eq $in{'ID'}) {
if ($rec{'Password'} eq $in{'password'}) {
&site_html_modify_form (%rec);
}
else {
&site_html_modify_failure ("Password Invalid: $in{'password'}");
}
}
else {
&site_html_modify_failure ("Unkown Link ID: $in{'ID'}");
}
}
else {
&site_html_modify_first;
}
}
}

And then, the piece of sub main provided by AnthroRules:
Code:
# We are processing the form.
if ($in{'send_form'}) {
&send_form;
}
elsif ($in{'process_form'}) {
&process_form;
}
else {
&site_html_modify_form;
}

I can't seem to find the right combination to accommodate Password and Confirmation.

[This message has been edited by DogTags (edited May 11, 2000).]
Quote Reply
Re: Modify Confirm In reply to
Thanks for the compliment. I appreciate it. I just finished a multiple page submission hack for the add.cgi...check it out when you get a chance. I most likely will not release the hack because it is not easy to install, and people will basically have to use my complete add.cgi script, which I would have to scale back a lot to make it easy for people to install.

Anyway...I think the problem is the following codes you have in the sub main routine:

Code:
if ($in{'send_form'}) {
&send_form;
}
if ($in{'modify_form'}) {
&process_form;
}
if ($in{'Submit'}) {
&process_form;
}

I have the following codes:

Code:
if ($in{'submit_form'}) {
&process_form;
}
elsif ($in{'send_form'}) {
&send_form;
}

then the series of nested else conditional statements.

And I have all the Mods you mentioned and a few more custom code hacks of my own.

Regards,


------------------
Eliot Lee....
Former Handle: Eliot
Anthro TECH, L.L.C
anthrotech.com
* Check Resource Center
* Search Forums
* Thinking out of the box (codes) is not only fun, but effective.


Quote Reply
Re: Modify Confirm In reply to
I can't stand it. That's all it was.

Plus, it was not the LWP URL Checker that was causing the problem. It was the Automatic Duplicate URL Checker that was causing some of the configuration probs. I installed this long ago because of many similar submissions and completely forgot about it.

I changed to:
Code:
if ($in{'submit_form'}) {
&process_form;
}
elsif ($in{'send_form'}) {
&send_form;
}

There's no:
Code:
else {
&site_html_modify_form;
}
at the end, as shown in the original directions at the start of this thread. Just below, I provided the entire sub main that works for me. It uses the above-mentioned simple change.

Everything works. Thanks, AnthroRules! Smile Smile

So, for anyone trying to combine:

1. Password Mod (Phoenix) - Resource Center
2. modify.cgi Confirmation Page hack above (AnthroRules) derived from the Add Confirmation Mod (Phoenix) - Resource Center
3. Automatic Duplicate URL Checker (Gerrit Jahn) - Resource Center

Here's the total sub main that works for me. I use the piece of sub main that AnthroRules provides at the bottom of this thread, not the one the top:

Code:
sub main {
### --------------------------------------------------------
local (%in) = &parse_form;

### We are processing the form.

if ($in{'submit_form'}) {
&process_form;
}
elsif ($in{'send_form'}) {
&send_form;
}

### Otherwise we are displaying the form (in site_html.pl), displaying
### the entrance (Asks for Link ID and Password)
else {
if ($in{'ID'} =~ /^\d+$/) {
my (%rec) = &get_record ($in{'ID'});

if ($rec{$db_key} eq $in{'ID'}) {
if ($rec{'password'} eq $in{'password'}) {
&site_html_modify_form (%rec);
}
else {
&site_html_modify_failure ("Password Invalid: $in{'password'}");
}
}
else {
&site_html_modify_failure ("Unkown Link ID: $in{'ID'}");
}
}
else {
&site_html_modify_first;
}
}
}

Then,

for modify_first.html:
Code:
<INPUT TYPE="Submit" VALUE="Submit">

for modify.html:
Code:
<input type="SUBMIT" name="submit_form" value="Modify Resource">
This is different than what AnthroRules has above. I found that if I used name="process_form", the Automatic Duplicate URL Checker routine would run in db_utils.pl and return a "Duplicate URL error - already listed!" error. That's why modify.html had to be changed to name="submit_form".

for modify_confirm.html:
Code:
<input type="SUBMIT" name="send_form" value="Modify Resource">

Then, follow the rest of the directions by AnthroRules and the authors of the other mods.

BTW, I looked at the multi-page add.cgi. It looks great. I use some multi-page forms using AlienForm 2, and they are very helpful. Breaking things up makes it easier on your visitors, and it gives the site a more professional look. Super nice !

Thanks, again, for your help. Smile This one was really nagging me. I hope my note here helps.

[This message has been edited by DogTags (edited May 12, 2000).]

[This message has been edited by DogTags (edited May 12, 2000).]
Quote Reply
Re: Modify Confirm In reply to
Glad you got it to work....

And the value for the input field, process_form, has caused me NO problems, so I don't know why it is causing you problems.

AlienForm is fine, but integrating LINKS templates was really nice. Also, I dealt with the author of AlienForm and he seemed like a real jerk, so I did not install his script.

Regards,

------------------
Eliot Lee....
Former Handle: Eliot
Anthro TECH, L.L.C
anthrotech.com
* Check Resource Center
* Search Forums
* Thinking out of the box (codes) is not only fun, but effective.


Quote Reply
Re: Modify Confirm In reply to
See my edited note just above, AnthroRules. The reason that process_form was giving me trouble was not because of the LWP URL Checker. It was because of the Automatic Duplicate URL Checker that I had completely forgotten about. It uses process_form in db_utils.pl. That was the bugger. But the code that I provided above works great. Hopefully, it will help someone else.

As far as I'm concerned, you have a superb links site - a terrific example for anyone to learn from.

Many thanks, again. Smile Smile

[This message has been edited by DogTags (edited May 12, 2000).]
Quote Reply
Re: Modify Confirm In reply to
Good...thanks for the explanation.

Glad you like my site...it has been a year of hard work upgrading it from a static site produced with Front Page to a Perl/CGI driven system.

Regards,

------------------
Eliot Lee....
Former Handle: Eliot
Anthro TECH, L.L.C
anthrotech.com
* Check Resource Center
* Search Forums
* Thinking out of the box (codes) is not only fun, but effective.


> >