Glutton for punishment ...

Beauregard T. Shagnasty wrote:

Ed Mullen wrote:

Take a look at the site in my sig address. I just changed it to have
both a fixed top header and fixed footer. Tested in all major
browsers I know of and it seems to work just fine.

I think the fixed areas need borders. Make it apparent those areas won't
move.

Done for the footer. For the header I disagree that it's needed. It's
highly unlikely anyone would arrive at a page on my site and not be at
the top. And, once there, if they scroll down surely they'll remember
and not be confused by the lack of a border on the header.

Not that I like fixed headers/footers; all they do is take up
valuable space in your visitors' viewport.

Fair enough. I'm just playing around at this point. I may tire of this
myself after a bit. :-)

The hover effect on all your links -- ordinary link changes to a green
button -- also makes the surrounding text jump about. That's
disconcerting.

The Back button on a failed 'contact form' is JavaScript dependent. Why
not use a simple link that works all the time?

Yes, I know. However, if I offer a link to contact.php none of the
user's data will be retained. I suppose I could take the actual button
off and just say "Use your browser's Back button to return to the form
and make corrections." <pondering> Hmm. Hmm.</pondering> Oh, ok!

Obviously, in your comments, please state your OS, version, browser
and version, and any functional issues.

Ubuntu 8.04. Several browsers.

And feel free to yell about drop-down menus and such as will please
your heart. I have rather thick skin.

Ok. :-) Drop-down menus suck!

Happy to be of service! ;-)

--
Ed Mullen
http://edmullen.net
"I will arise and go now, and go to Innisfree." - W. B. Yeats

Gazing into my crystal ball I observed Ed Mullen <ed (AT) edmullen (DOT) net> writing
in news:37jrdp.u5.17.1 (AT) news (DOT) alt.net:

The Back button on a failed 'contact form' is JavaScript dependent. Why
not use a simple link that works all the time?

Yes, I know. However, if I offer a link to contact.php none of the
user's data will be retained. I suppose I could take the actual button
off and just say "Use your browser's Back button to return to the form
and make corrections." <pondering> Hmm. Hmm.</pondering> Oh, ok!

If you let the form post to itself, you won't have that problem.

--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

Beauregard T. Shagnasty wrote:

Ed Mullen wrote:

Take a look at the site in my sig address. I just changed it to have
both a fixed top header and fixed footer. Tested in all major
browsers I know of and it seems to work just fine.
The hover effect on all your links -- ordinary link changes to a green
button -- also makes the surrounding text jump about. That's
disconcerting.

Forgot to respond to this one in my other reply. Yes, I know. I've
played around to try and prevent that but haven't figured out any way to
have the effect without the, uh, effect.

If this were a commercial site I'd be doing things a lot differently.
However, it's just a hobby for me and, as such, is there to amuse me as
much as anything. :-D

--
Ed Mullen
http://edmullen.net
Only in America are there handicap parking places in front of a skating
rink.

Adrienne Boswell wrote:

Gazing into my crystal ball I observed Ed Mullen<ed (AT) edmullen (DOT) net> writing
in news:37jrdp.u5.17.1 (AT) news (DOT) alt.net:

The Back button on a failed 'contact form' is JavaScript dependent. Why
not use a simple link that works all the time?

Yes, I know. However, if I offer a link to contact.php none of the
user's data will be retained. I suppose I could take the actual button
off and just say "Use your browser's Back button to return to the form
and make corrections."<pondering> Hmm. Hmm.</pondering> Oh, ok!


If you let the form post to itself, you won't have that problem.

The form is posting to a PHP script for processing that includes not
just error detection but spam processing as well. So I think that's not
an answer for me. Or am I misunderstanding your suggestion?

--
Ed Mullen
http://edmullen.net
"I'd rather be in Biscuit City with my banjo in my hands ..." - Gordon
Lightfoot

Adrienne Boswell wrote:

Ed Mullen <ed (AT) edmullen (DOT) net> wrote:
[Beau wrote:]
The Back button on a failed 'contact form' is JavaScript dependent.
Why not use a simple link that works all the time?

Yes, I know. However, if I offer a link to contact.php none of the
user's data will be retained. I suppose I could take the actual
button off and just say "Use your browser's Back button to return to
the form and make corrections." <pondering> Hmm. Hmm.</pondering
Oh, ok!

If you let the form post to itself, you won't have that problem.

Ahh, just what I was going to say. <g>

On my forms, I post form to self, and if there are errors or omissions,
I display a list above the form, with gentle "try again" message:

Possible errors:

* Please enter your name.
* Please enter your email address in the form janedoe (AT) example (DOT) com
* Please enter a Subject for your message.
* Please enter a comment or question before submitting the form.

Years ago, when I discovered a form/script actually could post/call
itself, sliced bread became 2nd on the list. ;-)

--
-bts
-Friends don't let friends drive Windows

Ed Mullen wrote:

Adrienne Boswell wrote:
If you let the form post to itself, you won't have that problem.

The form is posting to a PHP script for processing that includes not
just error detection but spam processing as well. So I think that's
not an answer for me. Or am I misunderstanding your suggestion?

You can see a simple example of self-processing here:

http://safalra.com/programming/php/contact-feedback-form/

It already checks for typical spammer input (cc/bcc), but you could
certainly expand it to use your IP-blocking mechanisms.

$crack=eregi("(\r|\n)(to:|from:|cc:|bcc",$body);

I never found a need to block by IP, since the spammers are almost
always using the bot machines of innocent compromised users, and the IP
changes with every attempt.

Here is a typical attempt by a spammer at one of my sites:

==========================================
Name: vdekuedgtzy
Email Address: kpregownhzwlw (AT) czkrsp (DOT) com
Comment:
gLqxv4 <a href="hXXp://mkaxyjedbyct.com/">mkaxyjedbyct</a>,
fzcljmrgppev,
[link=hXXp://xcyrujhnatbn.com/]xcyrujhnatbn[/link],
hXXp://kruwnzryajad.com/
==========================================

Note "http" munged as "hXXp" for this post. Other than that, it is
exactly as the spammer sent it. The IP address was somewhere in
Romania, but his next attempt a few minutes later was from Japan.

--
-bts
-Friends don't let friends drive Windows

Beauregard T. Shagnasty wrote:

Ed Mullen wrote:

Adrienne Boswell wrote:
If you let the form post to itself, you won't have that problem.

The form is posting to a PHP script for processing that includes not
just error detection but spam processing as well. So I think that's
not an answer for me. Or am I misunderstanding your suggestion?

You can see a simple example of self-processing here:

http://safalra.com/programming/php/contact-feedback-form/

The only problem I see with that script/example is that it contains the
actual email address to which the form is to be sent. Simply by reading
the source of the contact.php form page a spammer can harvest my email
address. That's why I post to a different page (which can't be
accessed) for processing.

It already checks for typical spammer input (cc/bcc), but you could
certainly expand it to use your IP-blocking mechanisms.

Hmm. I don't filter IP addresses. Ah! You may have looked at the
source of my contact.php page and seen a comment regarding filtering. I
forgot to strip that out (done now, thanks!) after I was done playing
with ip filtering a long time ago and decided it wasn't worth it for the
very reasons you cited. :-)

--
Ed Mullen
http://edmullen.net
I know you believe you understand what you think I said, but I'm not
sure you realize that what you heard is not what I meant.

Ed Mullen wrote:

Beauregard T. Shagnasty wrote:
You can see a simple example of self-processing here:

http://safalra.com/programming/php/contact-feedback-form/

The only problem I see with that script/example is that it contains
the actual email address to which the form is to be sent. Simply by
reading the source of the contact.php form page a spammer can harvest
my email address. That's why I post to a different page (which can't
be accessed) for processing.

The email is in the PHP portion of the script, not the HTML part. It
can't be read by anybody except those with FTP access to your files. All
my forms have the TO address set like this example. Try safalra's script
yourself on a test page and you will see the address is not visible when
reading browser source.

But if that still bothers you, set your email address in a global
include file (don't we all have those?), and just use the $variable in
the contact script.

It already checks for typical spammer input (cc/bcc), but you could
certainly expand it to use your IP-blocking mechanisms.

Hmm. I don't filter IP addresses. Ah! You may have looked at the
source of my contact.php page and seen a comment regarding filtering.
I forgot to strip that out (done now, thanks!) after I was done
playing with ip filtering a long time ago and decided it wasn't worth
it for the very reasons you cited. :-)

Yes, you are correct; that's what I saw.

Oh, while we're talking about the 'source' of your contact page, here's
a question: why all those type="hidden" thingies in there? None of
those should be necessary if you posted the form to self.

I don't use CAPTCHAs either. I hate those suckers!

--
-bts
-Friends don't let friends drive Windows

Beauregard T. Shagnasty wrote:

Ed Mullen wrote:

Beauregard T. Shagnasty wrote:
You can see a simple example of self-processing here:

http://safalra.com/programming/php/contact-feedback-form/

The only problem I see with that script/example is that it contains
the actual email address to which the form is to be sent. Simply by
reading the source of the contact.php form page a spammer can harvest
my email address. That's why I post to a different page (which can't
be accessed) for processing.

The email is in the PHP portion of the script, not the HTML part. It
can't be read by anybody except those with FTP access to your files.

DUH!

All my forms have the TO address set like this example. Try safalra's script
yourself on a test page and you will see the address is not visible when
reading browser source.

I'll give that a try. Thanks for the tip.

But if that still bothers you, set your email address in a global
include file (don't we all have those?), and just use the $variable in
the contact script.

Ooh! Nice trick!

It already checks for typical spammer input (cc/bcc), but you could
certainly expand it to use your IP-blocking mechanisms.

Hmm. I don't filter IP addresses. Ah! You may have looked at the
source of my contact.php page and seen a comment regarding filtering.
I forgot to strip that out (done now, thanks!) after I was done
playing with ip filtering a long time ago and decided it wasn't worth
it for the very reasons you cited. :-)

Yes, you are correct; that's what I saw.

Oh, while we're talking about the 'source' of your contact page, here's
a question: why all those type="hidden" thingies in there? None of
those should be necessary if you posted the form to self.

Err, the answer at this moment is: I don't remember! I'll have to look
that up. :-[

I don't use CAPTCHAs either. I hate those suckers!

Me too. But it has reduced spam somewhat.


--
Ed Mullen
http://edmullen.net
When he who hears does not know what he who speaks means, and when he
who speaks does not know what he himself means, that is philosophy -
Voltaire

Ed Mullen wrote:

Beauregard T. Shagnasty wrote:
I don't use CAPTCHAs either. I hate those suckers!

Me too. But it has reduced spam somewhat.

Here's another itty-bitty trick to keep the spammers away from your
form.

Typically, the spammers scour the web looking for contact forms to
exploit. Once they find one, they add the URL to their bot-sending
scripts and feed it to many/hundreds/thousands? of bots to go hit your
form. I've set all mine up thusly:

In that global include file:
$contactpage = "contact.php";

In all the places that link to the form (your menu, your footer, etc):
echo "<a href='$contactpage'>Contact Ed</a>";

If a persistent spammer finds your form and won't let go, simply change
the value in the include file to, say,
$contactpage = "aacontact.php";
then FTP in, upload the new include file, and rename the contact form
file to that new filename.

So, one variable change and one filename rename, and the spammer gets
only a 404 - which you'll never have to worry about. My sites are rarely
bothered by spammers.

--
-bts
-Friends don't let friends drive Windows