fmbadhandler not allowing php pages

[Nisitiiapi]

Pages on a website I am redesigning for a client use some php scripting to generate. However, for some reason, the page I have for bad_template does not seem to allow the php scripts in the page code to run.

I have set TEMPLATEDIR=""
I have set TEMPLATEURL=$SCHEME.$SERVER."/_formmail/form_templates/"
All the pages involved have .php as their extension.

I have tried TEMPLATEURL with no trailing slash and also using "http://www.sitename.com/_formmail/form_templates" to no avail.
Although the site doesn't use sessions, I have tried giving formmail its own unique session name (and done it in verifyimg.php, formmail.php, and fmbadhandler.php).

The strange thing is that some php on the page executes. For example, there is an email link in the corner that a simple line of php base64_decode. However, the page calls an external php script at the end -- that is what is not running. At one point, I had it calling an external php script in another spot that was not running (it was going to the php script but ignoring all php and just inserting html and javascript from the php script into the webpage where it should be deciding between the html or the javascript depending on the user's settings for javascript, as it does on other pages with no problem). The php is not in the source for my bad_template, so it is being dealt with at some level.

I can't seem to figure out what is stopping the external php scripts from running. This is the php that is not running:

at the beginning of the page:

<?php ob_start(); ?>

at the end of the page:

<?php
include_once ( $_SERVER['DOCUMENT_ROOT'].'/replacePngTags.php' );
echo replacePngTags(ob_get_clean());
?>

If you go to the page directly through the browser, it displays fine, so the php is good, it's just not being processed when it goes through fmbadhandler.

Thanks in advance for the help.

[russellr]

Hi,

Is this for good_template or bad_template or both?

Can you open the template with a browser and does the PHP run (I think you said you could, but need to confirm)? You should see your $fields in the browser.

[Nisitiiapi]

Thanks,

It's just bad_template, but also my contact form if you use the $return_link in bad_template. All pages open fine and all php runs fine if you go directly to the pages in the browser. The form is at http://www.sjndnlaw.com/contact.php and the bad_template is at http://www.sjndnlaw.com/_formmail/fo...tact_error.php. To view the problem, you have to use IE (it's not visible in Mozilla or Opera because they don't need the php code). If you make a mistake on the form (if you have javascript enabled, type an incorrect response to verifyimg or else disable javascript - the form has javascript checking, but uses formmail for users who don't have javascript), the bad_template page will show backgrounds for a couple of the images. If you use the link to return to the form, the same problem will be there (even though it wasn't on the original form). Thanks again.

[russellr]

Hi,

I can't see any problem.

I disabled JavaScript and tried your contact form. It looked perfect.

I made entry errors on the form, and got your bad_template. Again, perfect.

When I returned to the form, it looked just right again!

The one problem is with the email and realname fields being re-filled when returning to the form. This is a known limitation, and the workaround is described here: http://www.tectite.com/vbforums/showthread.php?t=729

[Nisitiiapi]

Did you try it in Internet Explorer -- it only happens with it (the php script sniffs for IE and runs if the user's browser is IE). The problem is the lost transparency on the logo at the top and the address on the bottom. Mozilla and Opera are fine because they don't execute the php anyway since they render png transparency properly on their own. It's doing it on IE for me still -- I could try another comp, but since it's all server side, it shouldn't matter.

To me, the odd thing is, I have another include for the menu that is working fine and a line of php base64_decode that is working fine. It's only the last include that doesn't seem to be running - I believe that script rewrites the page, holds it in the buffer, and then outputs the buffer. I wonder if fmbadhandler is also outputting from the buffer and it won't do both.

Thanks.

[russellr]

Hi,

Yes, IE 6.0.

If it's a subtle thing I might not have noticed.

I'll try again.

[russellr]

Hi,

OK, I can see it now.

What's happening is that your PHP code is trying to figure out the browser by assuming that the page is being opened by a browser. It's checking the $_SERVER or $HTTP_SERVER_VARS array.

However, in FormMail and FMBadHandler, templates are opened by PHP on the server and then the output is sent to the user's browser. So, there is no browser.

However, FMBadHandler knows that this is a problem, so it transmits the user's browser information to the template when it opens it. So, your PHP code in the template can still find out about the user's browser even though the user's browser isn't actually opening it.

In this HOW TO guide: http://www.tectite.com/fmhowto/adverror.php
look for the section titled "Dynamic Web Sites".

So, in the template, you just need to check the $_GET array for "USER_AGENT" instead of (or as well as) the $_SERVER array for "HTTP_USER_AGENT".

If that's not clear, post your current browser checking code, and I'll tell you what to change.

[Nisitiiapi]

That was the problem for the bad_template. Thanks! Very, very much appreciated.

I changed the code in the script from:

$msie='/msie\s(5\.[5-9]|[6]\.[0-9]*).*(win)/i';
if( !isset($_SERVER['HTTP_USER_AGENT']) ||
!preg_match($msie,$_SERVER['HTTP_USER_AGENT']) ||
preg_match('/opera/i',$_SERVER['HTTP_USER_AGENT']))
return $x;

to:

$msie='/msie\s(5\.[5-9]|[6]\.[0-9]*).*(win)/i';
if ( !isset($_SERVER['HTTP_USER_AGENT']) ) {
if ( !isset($_GET['USER_AGENT']) ||
!preg_match($msie,$_GET['USER_AGENT']) ||
preg_match('/opera/i',$_GET['USER_AGENT']) )
return $x;
}
if ( !isset($_GET['USER_AGENT']) ) {
if( !isset($_SERVER['HTTP_USER_AGENT']) ||
!preg_match($msie,$_SERVER['HTTP_USER_AGENT']) ||
preg_match('/opera/i',$_SERVER['HTTP_USER_AGENT']) )
return $x;
}

That works great for bad_template (although, if you see any way to improve my changes, please do), but if you use the $return_link to go back to the form, the problem is still there. What I noticed was that $USER_AGENT becomes Fmbadhandler/1.11. This seems to come from the line of code fputs($f_sock,"User-Agent: FMBadHandler/$FMBH_VERS (FormMail Bad Handler from www.tectite.com)\r\n"). This is what $_SERVER['HTTP_USER_AGENT'] becomes and $_GET['USER_AGENT'] seems empty. I tried chaning this to fputs($f_sock, "$s_agent/r/n") and also just commenting out the line, but either way $_SERVER['HTTP_USER_AGENT'] is apparently nothing. Since the check won't apply the script if $_SERVER['HTTP_USER_AGENT'] is not set, I imagine that is why it's not running. Is there any way to pass the actual browser user agent string to the $return_link?

I'm only so-so with PHP, so I could be missing something obvious and not even know it. Thanks once more.

[russellr]

Hi,

(I've had to re-write this because what I wrote originally was misleading...)

When processing the return link, FMBadHandler opens the original form from the server (just like it does with $TEMPLATEURL template processing) does some substitutions and then sends the output to the user's browser.

It's quite complicated, but that's the only way it can work.

FMBadHandler sets USER_AGENT when it opens the form in the return_link processing.

So, you simply need your new PHP code in your original form as well as your template.

[Nisitiiapi]

That's what I thought, but it doesn't seem to be passing it. I put my new code directly in the php script being called so it would apply to all pages on the site. But, to be certain, I put the code directly into my this_form page -- no luck. I tried to put in a line of php into the page that is this_form "echo 'User agent:'.$_GET['USER_AGENT']" to see what it would read and it's blank when you go to $return_link - it should appear at the bottom of the page, but it only says "User agent:". If I do the same on bad_template, it displays "User agent:Mozilla blah, blah", as you would expect.

I am using TEMPLATEURL and TEMPLATEDIR is left as "" in both formmail.php and fmbadhandler.php. Sorry if this is being a pain -- wouldn't be an issue if IE rendered PNG transparency correctly in the first place. Thanks again.