Design Notes
These are notes you can input that help you and other production staff understand your confirmation elements logic and purpose. This text is never used in the live form in any way, it is only for internal development.

The logic takes the form of:

Variable 1 | Condition | Variable 2

For example, let's assume we have a radio item in our form with the Name/Value of opt_1. The radio item has two possible vales, 'Yes' and 'No'. If the value of opt_1 is 'Yes' we want to send an email, if no, we do not.

We would write the Confirmation Condition PHP Code as such:

#{opt_1} == 'Yes'

In other words, we use the token for our field variable like we would in other property boxes, that is, a pound sign (#) followed by the Name/Value of the field in braces. Recall that at run time this token evaluates to the value set by our forms users, which in this case will be the value of the radio button with the Name/Value of opt_1.

We then set the comparison, in this case out comparison is equal too, denoted with the double == sign. Finally, because we know our radio item is a string value that can be 'Yes' or 'No', we wrap the value we want to check for in single tick marks.

On the raw code side, FormBoss wraps the token call in an isset() block, which is further wrapped in the proper PHP if() syntax:

if(isset($_SESSION['qs']["{$_SESSION['entry_key']}"]['opt_1']) && $_SESSION['qs']["{$_SESSION['entry_key']}"]['opt_1'] == 'Yes') { // condition code start

When run, if the users set value for the radio box was 'Yes', we would process this confirmation element.

Using Array Based Form Elements (Checkboxes)
PHP Treats checkbox items a little differently than other elements. The good news is the only element that needs this special attention is a checkbox field. The difference then, is that in order to use checkbox items we need to place an index indicator just after the field Name/Value token.

For example, lets say we have a checkbox field that had the Name/Value: email_condition and has two elements: Recipient A and Recipient A

To process this field in our condition statement we need to append the proper index of the field used for checking the condition using PHP array index format. It may sound confusing, but it's quite simple when you see it:

#{email_condition[0]} == 'Recipient A'

In short, the non-array way would be to simply use:

#{email_condition} == 'Recipient A'

But because we need to check an array index (again, because PHP treats checkbox items as arrays), we simply add the [0] part before the closing brace (}).

How do we know which array index to use (the number part)? In our example the checkbox field has two values; array indexs start with 0, so the first field, Recipient A, is [0], where Recipient B would be [1].

This numbering simply climbs up by 1 for every checkbox item you add.

Redirect Address (Fully qualified)
This is the address of the page you would like to redirect to.

A page redirect is the last element to be processed on the confirmation page, so if you have any other processing elements, they will work as expected.

Note: All redirects will open the link in the same window as it's called in unless you specify a redirect delay (please see below).

Redirect Address Dynamic Variable Support
The Redirect Address field supports PHP variables; the way you'll include these variables depends on weather you use the Delay Before Redirection setting or not.

Case 1: You do not have a value in the Delay Before Redirection box:
Include PHP variables using a wrapping brace as in:

{$php_var}

Case 2: You are using a value in the Delay Before Redirection box:
Use a full PHP echo statement as in:

<?php echo $var; ?>

You can use these dynamic variables to perform logic after your form has been submitted. For example, you may have a form that when submitted you redirect your users to a special offers page. This page is on another server so you cannot transfer the session, but you can transfer information using a query string.

You could also use this feature in a situation where you have an iFrame include form on one page and want to collect more information on another page, this second page being in a totally different format than the first (such as going from small window to a full page form). The problem will arise in that the redirect call will need to replace the first window with the second, full page window. This can only happen if we use the redirect delay, and using the PHP variables we can then transfer the initial form fields data as well.

One final hint: It helps to remember that with the PHP Top Code block we can add any custom code we need to a page. This is important in terms of dynamic variables we use here, as sometimes we'll need to process a value first from say, another form field or _GET variable, then plop that variable into the Redirect Address box.

Delay Before Redirection
This field, if set with a integer value, will delay the Redirect Address from loading for the number of seconds you place in this field. Please be aware, if you place a value in this box it will override any Custom Redirection Code logic, and will instead load the address from the Redirect Address field above. This is done because the custom logic advanced programmers would use could use its own delay code, or would perform more advanced operations this field does not yet support.

Also be aware this redirection call is based on Javascript, and may not be available to all browsers and user configurations. However, the upside of using the JavaScript redirect, as noted in the Hints and Tricks section above, is that your redirect will cause the entire window to load your new content, as opposed to just the iFrame.

For reference, you can use this JavaScript to perform a full page redirect:

<script type="text/javascript">
   function redir() {
	setTimeout("window.open('http://www.yahoo.com', '_top', '', false);", 10);
}
</script>

Delayed Redirect Target
New to Build 671, this feature allows us to set to the window the timed redirect will attempt top replace. By default this is set to _top, which means the form frame will replace the entire window. This is particularly useful in cases when the form is embedded in a larger page via an iFrame, and you want the redirect to replace not just the iFrames contents, but the entire window.

By contrast, sometimes you will not want this, you will only want the iFrames contents to be replaced. If this is the case, you will want to use _self or experiment with the other options.

Custom Redirect Code
As the WWW Redirect module is the last bit of code to run on all confirmation pages, you can provide custom redirect code logic to handle special cases such as a redirect based on user input. For example, you could use this code to redirect to the value of redirect_site, a select field element created on the first page of our form:

// custom redirection 
$site = $_SESSION['qs']["{$_SESSION['entry_key']}"]['redirect_site']; 
switch($site){ 
	case 'Yahoo.com' : 
		header("Location: http://www.yahoo.com"); 
		break; 
	case 'Amazon.com' : 
		header("Location: http://www.amazon.com"); 
		break; 
	default : 
		header("Location: http://www.formboss.net"); 
} 
exit;

IMPORTANT NOTES: Unlike the PHP Head Code property of all form pages, the Custom Redirect Code you create cannot be enclosed in PHP tags (<?php and ?>), as they are already created for you. Wrapping your code in braces will cause your pages to fail.

It is also important to note that FormBoss will attempt to process some clean up routines after a Delayed or Standard Redirect (not using Custom Redirect Code), but will not do so unless told when using Custom Redirect Code. This behavior has an important consequence:

By default all saved $_SESSION data from the users session remains intact after a Custom Redirect Code redirect.

This means a user could be redirected from your form page, hit the back button on their browser, and all their previously filled in form fields will still be set.

This may be desirable in some cases, other not. To keep session data you do nothing, as this is the default behavior. To erase all session data, starting with Build 617 you can issue a call to:

clear_fb_session();

Which is a simple function that clears all FormBoss session data. Now when a user hits the back button after the redirect the form fields will be blank.

Dynamic Variables Support
As of build 623 this field now support the inclusion of dynamic variables in the form of:

PHP Variables:
$php_var or ${php_var}

Field Variables
#{field_name}

Important Update Note: As of build 630 It is important to note that field variables such as #{text1} and PHP variables such as $var or ${var} will be returned as raw variables, that is, in the form of:

$_SESSION['qs']["{$_SESSION['entry_key']}"]['text1']

Why does this matter? Because the field variable isn't tucked away in braces as was previously the case (pre-Build 630), you can now use field variables to process more complex logic such as switch statements and the like.

For example, we may have a text field with an Name/Value of text1 with a dollar value of 14.50 as the fields entered value. We could use the following code in the Custom Redirect Code area:

if(#{text1} == '14.50'){
echo 'hit';
}

Which would return hit. Thus, the value returned by our token isn't treaded as a simple string.