PHP Contact Form

A while back I downloaded code for a contact form with captcha. After much effort, it has now been working on one of my Web sites for almost a year now. So over the last couple of days I finally got around to putting it on one of my other Web sites. I transferred all the relevant files from one site to the other (6 php files, 2 js files, and 1 css file). Other than a few cosmetic changes, the files on both Web sites are identical. Yet the captcha image doesn’t display on the second Web site.

I’m not sure what question to ask. Perhaps some of you will have ideas. Here’s some additional technical information.

Both Web sites are on my VPS, so I have root access to the server. Both accounts are set up identically. I checked both cPanels and WHM and could find no differences. So it baffles me why the same code (the captcha image) doesn’t work on both!

Thanks.

Ken

Sounds like you have a file path screwed up.

This is one reason why relative file paths are superior.

Without having access to your server, all I can state is the obvious…

Break things down into smaller pieces.

Are all the files there?

In the same directories?

Check the paths as mentioned above.

Determine what does and does not work, so you know where to look for the issue.

All the paths are relative. For both Web sites, all the files are in a single directory–public_html. Also, all nine files for the contact page are present and accounted for. Finally, in the main file, contactform.php, it is the following line that doesn’t return an image:

<div><img id='scaptcha_img' style='margin-top: 20px; margin-bottom: 20px;' src='show-captcha.php?rand=1' alt='Captcha image' /></div>

On the Web site where the code is working, I can add the following line immediately after the above line and the captcha is then displayed twice.

<img src="show-captcha.php?rand=1" alt="No captcha image" />

Inserting this same line on the Web site that is nor working, and no image appears.

show-captcha.php calls two other functions: fgcontactform.php and captcha-creator.php. I inserted debugging echo statements as the first and last lines in each. Both files are executed and exit, returning to show-captcha.php. But no captcha image is created. Again, these files are identical on both Web sites. The mystery continues… :slight_smile:

Is whatever the script is using to generate the image (GD?) set up the same on both servers?

Can you post a link to each site?

Not that it helps, but lots of people think CAPTCHA sucks…

Maybe this is a hint from the Heavens to use a better approach? :wink:

Thanks so much for all these responses!

Mittineague: Unless I misunderstand your question, it should be–I copied the files from the working Web site to the second Web site.

mikey_w: Absolutely. Here are the two links. The contact page comes up on both, but the captcha is displayed only on the first Web site:

http://rediscoveringthebible.com/contactform.php

http://ammiministry.org
http://ammiministry.org/contactform.php

Mikey, your suggestion about a “hint from the Heavens” might very well be the case. Both Web sites are Christian Web sites! :smile:

Ken

I wonder if these errors are interfering

ReferenceError: changeToBlack is not defined contactform.php:1:0
ReferenceError: changeToWhite is not defined contactform.php:1:0

Mittineague: Well, you caught a bug for me! changeToBlack and changeToWhite are two javascript functions that operate on the menus in both Web sites. In Rediscovering the Bible, they were in the SSI include statement, which also contained the html for the menus. In Ammi Ministry, they were on every page; the SSI include statement contained only the html code. Without these functions, the menu items did not change color when you put the mouse over them. I now put the functions in contactform.php, and so the menu items change color as they should, Unfortunately, this fix seemed to have no effect on generating a captcha image. :frowning:

You see, it was a sign from above! :wink:

It is rather ironic I am trying to help out with CAPTCHA considering that I have never implemented it?!

My advice is to consider using the alternative approach that I took for my Contact Form…

  • Sanitize Form Data
  • Add a Honeypot
  • Check for Form Completion Time (i.e. Too Fast and Too Slow)
  • Check for Cross-Site Remote Forgery (CSRF)
  • Adjust Firewall Settings
  • Track User’s IP and Hostname

If you do those things, I believe they are as effective as CAPTCHA and much easier from a UX standpoint!

What about this suggestion?

Thanks, Mikey!

Concerning reply #10: Is there code that I can download to do all this, like there was the php code that included captcha? It sounds like most of the bulleted list are things I have to do myself. I have root access to my VPS Web server, but most of these things I don’t know how to do. Also, what is “UX”? To be honest, I think I will need to stick with the code I have.

Concerning reply #11: Yesterday I checked with technical support for the company that provides my VPS, and they were almost useless. They said (somewhat inaccurately) that my problem was a “coding” or “development” issue and that they can’t help with that. But I asked them about whether the GD library was installed on the server. The answer was yes. Here’s what is installed:

[root@server ~]# rpm -qa | grep gd
gdbm-devel-1.8.0-36.el6.x86_64
gd-2.0.35-11.el6.x86_64
gdbm-1.8.0-36.el6.x86_64
gd-progs-2.0.35-11.el6.x86_64
gdk-pixbuf2-2.24.1-5.el6.x86_64
eggdbus-0.6-3.el6.x86_64
gd-devel-2.0.35-11.el6.x86_64

I still don’t know where the library resides on the server. Nor were they able to explain why the php code on the one Web site was (apparently) able to access the library, while the code on the other Web site was (apparently) not.

One other thing came up while talking with technical support. Much to my embarrassment, a php.ini file was in the public_html directory for the Web site where the captcha is working, while no such file was in the public_html directory for the Web site where it is not working. So with much excitement I copied it there, but STILL the captcha did not work. :frowning: I haven’t yet had a chance to look at the file to see if there are any items that are unique to a specific Web site on the VPS.

In addition to talking with technical support on the phone, I also submitted a ticket that reviewed all my attempts to determine the problem. I’ll paste it here–maybe you’ll see something there that is worth persuing. Here it is…

If you’ll notice, I have eight accounts (Web sites) set up on my VPS. This problem deals only with two of them:

    /home/kmorgan (rediscoveringthebible.com)
    /home/ron (ammiministry.org)
    
    Some time ago, I downloaded free code to create a contact form page on my Web sites. It consisted of nine files: 6 php, 2 javascript, and 1 css.
    
    contactform.php
    show-captcha.php
    fgcontactform.php
    captcha-creator.php
    class.phpmailer.php
    thank-you.php
    fg_captcha_validator.js
    gen_validatorv31.js
    contact.css
    
    All the files for each Web site, including these nine files, are in public_html.
    
    The contact page with captcha is working on rediscoveringthebible.com, but it is not working on ammiminsitry.org. Compare:
    
    rediscoveringthebible.com/contactform.php
    ammiministry.org/contactform.php
    
    You will notice that on ammiministry.org, the contact page does not produce the captcha.
    
    Here are some facts that make this a real mystery.
    
    (1) I created both Web site accounts using WHM. I followed the exact same procedure for both.
    
    (2) I copied the nine contact form files from 
    
    /home/kmorgan/public_html (rediscoveringthebible.com)
    
    to
    
    /home/ron/public_html (ammiministry.org)
    
    I made only a few cosmetic changes to the files once they were copied to /home/ron/public_html. Therefore, for all intents and purposes, the files on both Web sites are identical.
    
    So why does the captcha work on rediscoveringthebible.com but not on ammiministry.org?
    
    You will notice that the main php file that actually creates the Web page is contactform.php. The function call that should produce the captcha is this line:
<div><img id='scaptcha_img' style='margin-top: 20px; margin-bottom: 20px;' src='show-captcha.php?rand=1' alt='Captcha image' /></div>
    In an attempt to locate the problem, I followed the execution sequence by using the debugging technique of placing a series of echo statements in show-captcha.php following the execution to fgcontactform.php and then into captcha-creator.php. There execution continued into 
    
    function DrawChars($code)
    
    The for loop stopped during its first pass with $i = 0. The if statement was executed, but no echo statement was displayed after this line:
    
    $this->logger->LogError("imagettftext failed");
    
    Again, I emphasize that this is the same code executed on rediscoveringthebible.com, where the captcha works.
    
    Anyway, I am no expert in php, but apparently "imagettftext" is a php built-in function. A little research seemed to indicate that to work, this function needs the "GD library."
    
    This is pretty much all I know. In an ssh session as root, I looked around for such a library but could not find it. But if rediscoveringthebible.com was able to access it, why was ammiministry.org unable to? Again, as far as I know, everything between the two is identical--the WHM accounts, the settings, and the php code.
    
    Any help you can provide in tracing the problem would be most appreciated.

P.S.: That’s the end of the ticket. I don’t know what this forum software is doing–different fonts, bold face where I have none, and scroll bars! I better not comment further. :slight_smile:

Get your CAPTCHA working and if interested come back here and ask later and I can try and help.

I can’t help you with CAPTCHA since I’ve never done it.

User Experience. It is the “look and feel” of a website.

CAPTCHA is not user-friendly… why captcha is bad

Mikey, I don’t think you have seen all of my post #12. I’ve been trying to get it to post correctly, but this forum software is not behaving. Anyway, I don’t think you have seen the ticket that I filed with my server technical support. It’s in my post #12.

P.S.: In your post #13, the second quote you cited from me had reference to the bulleted list you gave, not the captcha problem.

I have read all of your posts. As stated, since I have never implemented, me trying to help you with CAPTCHA wouldn’t make sense. (That would not only require me to learn it, but then figure your problem out on a server I don’t have access too.) I am also weak with System Admin stuff.

I’m sure someone else can help you here.

If you really get stuck, you can try the approach I mentioned… (I would start a new thread in the PHP section called “Seeking Alternative to CAPTCHA”

Back to your current problem…

Like with any insurmountable programming issue, you need to keep breaking things down and isolating where the issue is.

I think @Mittineague may be on to something about GD, but that is way out of my area.

Whenever a web host doesn’t know the answer they usually blame it on your “programming”. It could be, but it could be a VPS issue - not my area of expertise.

Sorry I can’t help me…

Maybe @cpradio or @Jeff_Mott might have some ideas?

If you create a simple temporary file you can check configuration

<?php
phpinfo();
?>

But I recommend you delete it immediately after you’re done checking it.

Do you happen to be using this for the captcha? If so the likely cause of the captcha not working is that the domain needs to be registered under your captcha account. If that isn’t it this all sounds like an oversight with the configuration for the captcha on your end. Copying source from one place to another is rarely a seamless process and requires modification of environment specific configuration.

Mittineague and Oddz: Just letting you know that I’ve read both of your posts. Thanks so much for your suggestions. I’ll experiment and respond later this evening (I’m on Eastern Time).

Ken

Okay, here’s the result of more investitgation.

(1) As I mentioned in my post #12, I discovered that /home/kmorgan/public_html (the Web site where the captcha works) HAD the file php.ini, but that /home/ron/public_html (the Web site where the captcha does NOT work) did not have that file. So I copied it to the latter directory, but the captcha still did not work.

(2) I looked through the php.ini file, and it had no reference to the Web site where the captcha works. So despite being identical files, I wouldn’t think there’d be any problem with the identical file on both Web sites.

(3) Next, I created a php file with the code suggested by Mittineague in his post #16. I put the code in both public_html directories and ran the code for both Web sites.

(4) Then I (laboriously!) compared the configuration fot the two sites. There were several places where the Web site URL was listed, but somehow both configuration tables had the correct site listed.

(5) I did find some difference, howver, and they all were related to the term “PHPSESSID.” Here’s the breakdown:

rediscoveringthebible.com (where the captcha works)

The word occurs in only one line in the table headed “session.” In the line, “session-name,” PHPSESSID occurs both in the column headed “Local Value” and the column headed “Master Value.”

ammiministry.org (where the captcha does not work)

The word occurs numerous times.

(a) It appears in the line of the table headed “session” exactly as it did in the configuration for rediscoveringthebible.com.

(b) In the table headed “Environment” it appears as part of the “Value” for the “Variable” HTTP_COOKIE":

cprelogin=no; cpsession=closed; langedit=; lang=;
PHPSESSID=6a5fad68177da53dd7d79f3519d4af49

This same line appears in the configuration for rediscoveringthebible.com, but the second line is missing:

cprelogin=no; cpsession=closed; langedit=; lang=

(c) In the table headed “PHP Variables,” there are FOUR differences between the two configurations. The following two lines appear in the configuration for ammiministry.org, but neither line even occurs in the configuration for rediscoveringthebible.com:

_REQUEST["PHPSESSID"]           6a5fad68177da53dd7d79f3519d4af49

_COOKIE["PHPSESSID"]            6a5fad68177da53dd7d79f3519d4af49

In the third difference, this is the line in ammiministry.org:

_SERVER["HTTP_COOKIE"]         cprelogin=no; cpsession=closed; langedit=; lang=;
                                PHPSESSID=6a5fad68177da53dd7d79f3519d4af49

But this is the line in rediscoveringthebible.com, again the second is missing:

_SERVER["HTTP_COOKIE"]         cprelogin=no; cpsession=closed; langedit=; lang=

The fourth difference is the same as the third difference: for the variable “_ENV[“HTTP_COOKIE”],” the second line with the word “PHPSESSID” is again missing in the configuration for rediscoveringthebible.com.

I didn’t notice any other differences between the two configurations. It surprises me that there are any differences at all. How could they occur when the two accounts were set up identically at the time created on the server and when both had the same php.ini file?

But if this difference is at the root of the problem of the captcha not working for ammiministry.org, I don’t know how to change its configuration to match the one for rediscoveringthebible.com.

By the way, I have Firefox set up to allow cookies for both Web sites.

Any help would be most appreciated. Thanks.

Ken

The domain wouldn’t be listed in the source code or configuration of the site. It is necessary when configuring captcha on the website.

https://www.google.com/recaptcha/admin#list