Global Timestamps And Visitor IP Address Variables

It's a common need to acquire a timestamp or visitor ip address for a form submission or other logicical operation. In SQL+ items we can use the built-in tokens $timestamp and $datetime. However, prior to Build 692 items like Simple Email and Email+ did not have access to these values.

This has been addressed, as we now have this pseudo-global declaration on all pages (form, builder and confirmation) :

// Global Timestamps
$timestamp = time();
$datetime = date('Y-m-d H:i:s', time());

$remote_ip = $_SERVER['REMOTE_ADDR'];

This means we can use these PHP values in any place that support the PHP token.

This means we can create an Email+ item with the following Email Message:

This is the raw timestamp: ${timestamp}

This is the datetime: ${datetime}

This is the visitors ip address: ${remote_ip}

And in the received email, we will get:

This is the raw timestamp: 1283616488

This is the datetime: 2010-09-04 11:08:08

This is the ip address: 127.0.0.1

Of course we can always create own own timestamps or ip blocks in the PHP Top Code block as needed.

Here you set ID Name and Encode Type. ID and Name are html properties, and should not be changed in most circumstances. Encode Type allows you set set a form up for file uploads, however, FormBoss will automatically set this property for you when you add a file upload field element, so you typically do not need to change it.

One thing to watch out for: DO NOT use form for the ID or Name property of your form as this will break Internet Explorer!

Allow Direct Access To This Page?
[Form Pages Only]
This checkbox allows you to bypass a FormBoss continuity check which would ordinarily block you from viewing this page if you hadn't visited the jobs 'prior' form pages first.

The chief use of this feature is for application development where you have multiple page jobs where Builder pages intermingle with Form pages.

For example, you have a Builder page as the first page of a job, and the second page is a standard form page. A user who tries to visit the form page will be bounced back to the first page of the form, as FormBoss would assume the user is trying to "skip" ahead in a normal multi-page form. Of course this is exactly what we would want in a "all forms" job, but not want we need in an application job with mixed page types.

Thus, this checkbox lets you bypass the security check which means a user can access any form page at any time, regardless of the pages they have "skipped" in the normal form flow.

Form Target
Added in Build 653, this option lets you set the form target, though please note this is only meaningful for Form Pages. This is useful for times when you want the form submission to open in a new window, or some other special circumstance. For reference, the default value is _self, which opens forms in the same window. _blank would open in a new window.

Form Persistence?
New in Build 689, this feature allows us to persist our from responses across multiple-browser sessions. In other words, we save and reload our form fields responses even if the user shuts down the browser.

This feature is set on a per-page basis, which means we can choose to not save specific pages form fields, such as a sensitive payment info page, for example. That said, while this is a powerful feature you need to be certain to activate the feature for new pages, as it is deactivated by default. The key then is that FormBoss doesn't enable this mode by default, you do. Take care when doing so however, as saving user data can be potentially disastrous if it falls into the wrong hands.

Currently we support two modes of persistence:

IP Based: In this mode we use the users remote IP address as a key. This is the simplest method to use, as it requires no further action from you--simply enable this mode and your users responses are saved. However, while simple it could be considered the least secure, as we can never guarantee the authenticity of the IP address, and also any user data could be later picked up by a third party if the form is not fully submitted. For example, a user fills out the form on a public computer but doesn't submit the form, the users form values will be reloaded for the next user even if the browser has been shut down.

Session Based: In this mode we rely on a SESSION value called fb_entry_id for loading form fields. This method takes a bit more setup compared to IP Based because we do not create this SESSION variable and value for you. You must create it, and in general this is the result of a login page. The database field for this value is a VARCHAR(255), which means while numeric values will work, you can and should use more distinct(difficult) keys when possible.

Even without a full database login process you can easily test this mode by adding this code to your PHP Top Code Section on the first page of a form:

<?php
session_start();
$_SESSION['fb_entry_id'] = 10;
?>

This code starts a PHP session, then creates our SESSION element: fb_entry_id with a value of 10. This value will now be used for all communication throughout this form session. Again though, in a real environment this value must come from a logic script of some sort, which can of course build right in FormBoss using the Query Module.

In short then, to use SESSION Based persistence all we need to do is supply a PHP session element called: fb_entry_id. That's it. No other setup is needed. So long as this session element exists and contains a unique(!) value, FormBoss will automatically use this value to populate existing form entry values.

The key to implementation then is not so much providing this value, but rather how the value is created in the first place.

A good place to do so is in your login script, specifically, grab the unique ID field of the user table and set:

$_SESSION['fb_entry_id'] = $login[0]['id'];

Doing so essentially says "when this user logs in they have a unique ID created by my database. As no other user has this ID in the system, I can use this value to set the fb_entry_id session element. Then, when a user hits a page that uses SESSION Based form persistence, FormBoss will automatically take this value and, for every page the user completes, add a list of values to the fb_job_entries_tmp table. When the user hits the same page again, be it 5 seconds later or 5 days later, so long as the user has the same fb_entry_id SESSION value set we'll grab any values from the fb_job_entries_tmp table and pre-populate the form.

This cannot be stated strongly enough: This method is by far much safer than IP Based because it assumes the user had to authenticate to reach the form in the first place. A good analogy of the proper use of form persistence would be online tax software. I trust such systems, but only because I need to login before any forms with saved values are shown.

Important Notes

In both modes the persistent values are only cleared when the user submits the form. This means we need to always pay close attention to what data we save, especially when using IP based persistence.

It's important to note we do not need to set a persistence value on our confirmation pages, only for form pages.

As of Build 694 this feature has been expanded to include saving all elements of a form field, including such data to properly populate the Simple SQL module such as the fields label property.

Another major enhancement in Build 694 is the ability to allow our forms users to return to any previously completed page in the form. This allows for much more advanced form persistence, in that we now effectively allow our users to return to the last page they were on, as opposed to the old way of saving form field responses but forcing users to start at the first page of a form.

Limitations
At this time we do not save File Elements.

This feature requires FormBoss 2 and the full FormBoss database. This means you cannot use this feature for client forms that use the stand-alone entry viewer.

Global Text Color Override
New to Build 671, this feature allows us to set the global text color property for all label elements on that page. This is very handy if we have to change the text color and our form contains many items--changing each item would be tedious. Please note however, that this operation effects all label fields on that page.

Global Font Weight Override
New to build 685, this field lets us set the font weight of all page elements.

Font Family
Select the Font Family to be used in the confirmation page. All field elements will use this font as default, however, you can always set individual item styles using the Extra Attribute(s) JS Style Etc text area available for each field item.

Custom Font
Input your own font name in this text box to create unique designs and form looks. Also useful when a client requests a font that is not available in the default set.

Center Form
Check this box to have FormBoss center your output form. This is most useful when you have a FormBoss form as the only element on the page, as in a standalone form.

It is important to note that the style of the center will differ slightly depending on whether you have a Free Form or Sortable Page:

- Sortable Page - FormBoss will add a small 15px pad to the <formboss-output-div> to push form elements out from the containing div's edges. This is done because if you have a background color applied to your form via Form Bg Color, your form items will touch the edges of this div, which looks unprofessional.

Also, while the default width of your form will be set via style sheet to 500px, this can be changed by setting the appropriate value in the Width Property of the POSITION AND SIZE editor, located below the EDIT FORM ATTRIBUTES box.

- Free Form Page - FormBoss will create the centering div style only, no pad is added.

Form BG Color
Sets the background color of the <formboss-output-div>, the wrapper div all forms are created with. It is important to note that as most html pages have default margin applied, setting the Form BG Color will not make the entire page background this color. To do that, you need to set the Body BG Color property as well. This setup gives you maximum control, as the page and form can have different colors.

NO COLOR HINT: To make a form have no color applied to the background element, (the default is white), select all text in this field and hit delete. If the delete works, the text display will show 000000, then when you select the element again, a single # sign. This is helpful when you need to place your form in a graphical layout where you want your form to 'float' above an image, for example. This tip goes for the Body BG Color property as well.

Body Bg Color
Set the <body> tag background color. This is done via style sheet selector on <body>, so it may not always be appropriate for your page. See Use body BG Color below for more information.

Use Form BG Color
Check this box off to prevent any color information from being applied to the form element.

Use body BG Color
Because setting a background-color style on the <body> tag is not always desirable, you have the ability to disable this feature all together with this check box. Unchecked means no style sheet is created, which means the body tag is left untouched by FormBoss.

JS Error Color | Formerlly known as [ Form Error Block Color ]
Updated in Build 683, this property sets the background or field outline color of any elements marked invalid per your form fields validation settings. For example, if you mark a field as required and the user selects this field and then leaves it without setting any value, the area around that field elements will be highlighted with this color.

** Please note this field has had another small name change, prior to build 673 it used to be Form Error Color **

Use Error Color
New to Build 673, this option lets us disable the error block color. This is handy when we have a complex background for our forms, or when we want to create a custom error style, such as turning the field elements a different color, and so on.

Please note however that as of Build 683 this box must be checked when using the Field Highlight JavaScript Error Display Type display type.

As of Build 700, this option can be unchecked to remove the line from the Simple Icon Notice from the JavaScript Error Display Type selection.

JavaScript Error Display Type
New to build 683, this option lets us set the appearance of our JavaScript (client side) error checking notice.

The default is Field Highlight, which means the offending field is outlined in the color you specify in JS Error Color.

We can also choose Block Highlight; this mode surrounds the entire form element (including label) with a div of the color specified that is set in JS Error Color.

As of Build 700 we can select Simple Icon Notice. This option places a small warning icon next to the offending field, as well as a line, colored per the value in JS Error Color, connecting the field item and the icon. This style is perhaps the most well rounded, in that it works well with all FormBoss layout modes and label positions.

It's important to note however that some error styles will work better out-of-the box than others, all depending on which layout mode and options our form has. The options we set for the field item also play an important roll in determining the final look and feel of our validation solution.

For example, in the new Simple Icon Notice setting, unchecking Use Error Color removes the line that connects the form field and the error icon. For text fields this can be a very pleasing effect, but not very effective for radio and checkbox items, as the error icon will seem to float away from those fields.

A second example is that we do not show error messages when in Free-form mode. This is because in a free-form layout spacing between elements is key, and in tight layouts we sometimes cannot afford to have extra content scattered in our design. Thus, FormBoss takes the safest approach possible and only shows the error line if Use Error Color is enabled, as well as the error icon.

Lastly, the colors we use will make a big difference in the look of our solution. By default the JS Error Color setting is red to work best with the default error style of field highlight. However, this will not look as good as a light gray if using the Simple Icon Notice style.

That said, the default settings will generally work best across the wide variety of form layouts we create, though we can always experiment with various colors, options, and so on.

The most important consideration then is simply making sure we test our forms validation settings to make sure users know how to effectively and quickly remedy submission issues.

Form Link Color
This will be the color of any links you create in your form. It sets the value of the following css definition:

.formboss-output-div a:link { color:#0D00AE; text-decoration:none; }

In short, any link inside of your .formboss-output-div will be effected, though not any any other fields in say, a page your FormBoss form has been included in.

Underline Links
Choose weather to have your links underlined or not, per your forms stylistic goals.

Page Margin
Starting with Build 626, You can now set the desired page margin in pixels. The default value is 5, though you may find some iFrame include scenarios with IE will display a white border around the edge of the form. Setting this value to 0 will eliminate this white border.

Layout Grid Overlay - Used to be known as [ Grid Overlay ]
This feature lets you display a series of grid elements underneath the contents of your form layout. You have several styles to choose from, some will be better for "dark" forms and other for "lighter" ones. The last option, Combo 50x50 is a compromise between all other styles. Please note the number after the overlay name is the spacing in pixels between each vertical and horizontal line.

Table Layout Options

Extra Head Code
Part of the JWiz feature set, places any content typed into the text area into the <head> portion of your page code. This means you can add <script> content, link to external css files, add meta tags, or add any other code that belongs in the head tag.

Included Javascript Library
Because coding in vanilla JavaScript can be tedious, FormBoss allows you to automatically link leading JavaScript libraries into your page simply by selecting which one from this menu. Not only are the appropriate code file(s) included, but the proper <script src=""> attributes are added to your source code. The included libraries are:
Prototype 1.6.1 standalone or with Script.aculo.us 1.8.1
jQuery 1.4.2 Production / Development / with jQuery UI
Dojo 1.2.3 Base or Full Dojo Toolkit (Toolkit requires an unzip to work)

Together with the Extra Attribute(s) JS Etc attribute available on most field items you can produce dynamic forms with very little effort. Please see http://www.formboss.net/jwiz for some examples of what's possible.

You will also notice several variations of the Prototype and jQuery libraries. These are included to make sure we only include what's absolutely necessary to build the job, while at the same time providing easy access to the most powerful non-standard features of each library.

Tooltips [ Tool Tips ]
Starting in Build 669, when we include one of the two Prototype JS libraries we automatically gain the ability to add tooltips to our forms. To do so, we need to add the following code to the forms elements Extra Attribute(s) JS Etc field as:

class="fb-tooltip" title="Hi, this is a tooltip!"

In other words, we add a class attribute of fb-tooltip, then set the title attribute to be the text of the tooltip.

*update* To make tooltips even easier, this method, while still working, has been automated by form field items Tooltip Options.

Token Support
As of Build 700, and now updated in Build 705, we can use FormBoss 2 Tokens in this code area. The token code is wrapped in an isset() block, which means even if the token isn't set, the code will still be valid in terms of PHP syntax. That is, if the token is not set or has an empty value, the Page Code will simply be empty where this token is placed.

Insert Custom Head Code Blocks
These links allow us to quickly add custom code blocks to our form. Even better, we can add to this list with our own code blocks. To learn more, please open your FormBoss directory and navigate to your FormBoss install: app/helper_code/ReadMe.txt

In Build 714 and higher we now have a shortcut link to this file.

PHP Top Code
This code will be inserted before any other page code is run, including all FormBoss generated PHP and HTML code. This code must be wrapped in proper PHP tags, which is why you will notice the Insert PHP Tag convenience item located directly below the PHP Head Code text area box.

You can use the code section in the part to query a database to hold values which will later populate field items, perform your own internal code routines--basically anything you need can go in this section, so long as it's valid PHP and wrapped in php script tags.

This can be especially important for Confirmation pages and the HTTP Request module, as the code inserted into the Page PHP Head Code section runs after the HTTP Request as finished, whereas the code in this field, the Page PHP Top Code, runs before. This means you can create custom variables that your HTTP Request can use for processing.

This visual should help you distinguish between the different code blocks and where they will end up on an exported page:

PHP Head Code
This code will be inserted just after the internal FormBoss session creation routine and P3P header. This code must be wrapped in proper PHP tags, which is why you will notice the Insert PHP Tag convenience item located directly below the PHP Head Code text area box.

You can use the code section in the part to query a database to hold values which will later populate field items, perform your own internal code routines--basically anything you need can go in this section, so long as it's valid PHP and wrapped in script tags.

Custom Redirection Example
You may run into a situation where you need to redirect the user to a new page after some code has run in this area. For example, you could be creating a login form that checks credentials, if they match, we want to send to user to a new page. Typically we can handle this with a PHP header("Location: some_url.php"); call, but for forms that are included into a page using the iFrame technique, this will not work, as only the iFrame would populate with the new page content.

The solution is to use a JavaScript based redirect which will ensure the entire page contents is redirected to the new page, not just the iFrame. Below is a full example of code that checks a database for user login details, and based on weather they authenticated or not, sets a flag to echo out the JS redirection code.

<?php
// connect to db
$db_vendor = 'mysql';
$db_mysql_socket = '';
$db_hostname = 'localhost';
$db_catalog = 'delivery';
$db_mysql_port = '3306';
$user = 'formboss';
$pass = 'test';
$dsn = $db_vendor . ":unix_socket=" . $db_mysql_socket . 
		";host=" . $db_hostname . ";dbname=" . $db_catalog . 
		";port={$db_mysql_port};";
 
// create db object
try{
   $dbh = new PDO ( $dsn, $user, $pass );
   $dbh->setAttribute ( PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING );
}catch(PDOException $e){
   die($e->getMessage());
}
                     
// assign variable values
$email = $_SESSION ['qs'] ["{$_SESSION['entry_key']}"] ['CustomerEmail'];
$pwd = $_SESSION ['qs'] ["{$_SESSION['entry_key']}"] ['CustomerPassword'];
 
// create query logic
$sql = "SELECT ProfileID, CustomerName FROM CustomerProfile 
		WHERE CustomerEmail = :CustomerEmail AND CustomerPassword = :CustomerPassword";
 
try {
   $stmt = $dbh->prepare($sql);
} catch (PDOException $e) {
   echo $e->getMessage();
}
 
// bind values to our prepared statement
$stmt->bindValue(':CustomerEmail', $email, PDO::PARAM_STR);
$stmt->bindValue(':CustomerPassword', $pwd, PDO::PARAM_STR);
 
// execute the query
$result = $stmt->execute();
 
if ($result) {
   $row = $stmt->fetch (PDO::FETCH_ASSOC);
   if($row){
	  // set a session var for logged in users
      $_SESSION ['logged'] = 'true';
      // collect vars from query if needed
      $user_name = $row['CustomerName'];
	  // set a flag that the user has logged in, use the redirect code below
      $pass = 1;
      // redirect to the success page
      // header ( "Location: http://something.com/admin/" );
      // exit (0);
   } else {
      header ( "Location: page0.php?fail=1" );
      exit (0);
   }
}
?>
<?php
// if the user has logged in, redirect using JS to the correct page
if($pass) { 
?>
<html>
<head>
<script type="text/javascript">
function redir() {
	setTimeout("window.open('http://something.com/admin/', '_top', '', false);", 1000);
}
redir();
</script>
</head>
</html>
<?php } ?>
          

Page Layout
Free Form or Sortable page, can be changed at any time and will remember field positions.

Field Snap
In Free Form layouts, how many pixels each move increment is snapped too. Set to 1 for no snapping.

Form Snap?
Off by default, this allows you to have the page snap to the top of the form on load. Useful if you have a large page layout who's submit button is only accessible by scrolling down the page. When a user is directed to the next page, the form will 'snap' to the top of the FormBoss form, where if no snap was enabled, the user would be stuck at the bottom of the page and would have to scroll up.

Show Error Text (formerly Show JS Text)
If checked, Javascript validation messages will be shown to users along with the error field highlight. This is helpful in cases where an error may not be obvious, such as Password fields that need to match each other. However, you may find the error text doesn't match your forms style, which is why this element is switchable.

Show JS Alert
When a user hits the submit button of a form with errors a JavaScript alert box will either show or not based on the value of this checkbox.

Default JS Errors
When a user activates a field and then leaves it, a client-side (JavaScript) check is performed to see if the field has been filled out correctly, 'correctly' being dependent on what your set criteria for that field is. In many cases you will want to customize the error behavior of FormBoss, the following paragraphs explain some basic concepts in this regard.

When you set a field as required by clicking the Required checkbox, the default behavior is to simply turn the background around the field element to a light yellow. You can however, display an error message to the user by checking the Show JS Text checkbox in the Page Properties area. By default, this error message is shown in the format of:

You must supply a {field_name}

With {field_name} being the Name/Value property of that element. This format works fine in most circumstances. However, you can also show a custom error message to the user. To do so you must uncheck the Default JS Errors checkbox. At this point you have a choice on what to do next. If you leave the Validation Error Message box blank, you will show a default error message of:

Please check field for possible errors

If you place a value into the Validation Error Message box, that will be displayed instead.

This means you do not need to rely on FormBoss to create required field validation error messages for you, you can create custom ones.

It should be noted that this error handling behavior only applies to users leaving field blank or unchecked. REGEX validation is slightly different, in that for those types of errors you always use the value of the Validation Error Message box.

JS Error Image
If you select a color form this box a small error icon will display next to a field that had been ruled as invalid by the JavaScript validating engine. This only works for sortable pages.

JS Error Color - [ Now know as JS Error Text Color]
Added as of Build 623, this field lets you define the color of the text displayed next to fields that have validated as false. Please note this only has an effect if you have checked the Show JS Text checkbox.

Page Title
The name of the Page if using forms in a stand-alone manner. That is, if you create a form where you use the form as a stand-along page, this will become the page title. However, many users will elect to insert forms using the iFrame method, in which case this field will have no effect.

Page Meta Description
The HTML meta description of this page.

Page Meta Keywords
Any page keywords you would like this page to have.

Page Name/Page Action/On Fail/On Success
The actual names of your exported php form pages and support files. These must include .php.

FormBoss Page Naming
FormBoss makes the task of form creation as easy as possible by automatically naming the various pages used to create your forms. For most users this is a good thing, as even the most basic FormBoss forms consists of several files. That said, FormBoss is also a professional level tool that gives advanced users total control. The end result is a hybrid model where page naming in FormBoss is something most users simply do not need to be concerned with, but pro users can get into if need be.

Page naming is not especially tricky but does take some getting used to. For instance, not only does FormBoss create and name the .php form page, it also creates an XML validation file (which must be named the same as the .php form file), as well as a "_process.php" file which manages the form processing tasks. In short, it helps to know what files FormBoss is creating as this will make naming them easier.

Where Page Naming comes into play and possible issues...
For all users, FormBoss automatically managing the naming of your form files generally works fine, but when creating complex forms with multiple pages you may inadvertently "trick" FormBoss into thinking the 'page flow' is different than what it should be.

For example, their may be situations that where you create a series of form pages, then create a confirmation page, then add more form pages, then delete the confirmation page.

If you perform these steps, the automatic page numbering system that FormBoss uses to route your form pages from one page to the next may be 'broken', in that the pages after the confirmation page will not be numbered correctly in relation to the pages before the confirmation page, which is now gone. The end result is your form will no longer process entries all the way through, as at the point where the chain is broken, and you will receive a missing file error.

Unfortunately, the FormBoss page naming system (which is based on incrementing numerical values) simply cannot handle all work styles and production workflow's, thus it will be important to make sure the entries in the Page Name, Page Action, On Fail, and On Success text boxes make sense for your form.

It cannot be stressed enough though, that in the vast majority of cases you simply do not need to worry about page naming. If you ever do though, below is an explanation of each field:

Page Name
When you 'view' a form page, this is the name of the file you're loading. It contains the html markup for your form page, as well as PHP logic for handling security and other tasks.

What's important for naming is by default the file is named as: pagen.php, with n being the page number. For each subsequent form page you add, be it a form or confirmation page, the n is simply incremented by 1. However, as stated above the pagen.php file is not the only file created when you build a form. For every pagen.php file there are two other files created: pagen.xml and pagen_process.php.

pagen.xml is the xml file used for JavaScript validation. It must be named the same as the php page but with the .xml extension. You do not need to worry about the actual naming of this file though, as it simply takes the value of Page Name and adds the .xml.

pagen_process.php is the file used to 'process' a form page after it's been submitted. In contrast to the .xml file, you do have control over the name of this file. This is a vitally important file which takes us to the next text field in the FormBoss editor:

Page Action
You'll notice the default value created by FormBoss for this field is the Page Name with an underscore and the word process, followed by .php.

You can name this file whatever you like, though the default of simply taking Page Name and adding _process.php is probably going to be the easiest to manage in the long run.

It may help to think of this file as the one that FormBoss 'hands off' the information collected on pagen.php to be processed.

The next two fields, On Fail and On Success, are also vitally important as they tell the _process.php file where to go in the event the form submission was done correctly or not.

On Fail
If the user fails to fill out the form correctly per your requirements, the On Fail page will load. If you think about this, the On Fail page should simply be the last page they tried to fill out, which is going to be the same 'page' your looking at in FormBoss at that moment. That's why you notice the On Fail field is the same as Page Name. If the form submission processing fails, go back to the page they were just on, FormBoss will handle all the error codes and messages for you.

The reason why you can edit this field at all is that advanced users may want to limit the number of tries a form can be filled out, create their own error pages, and so on.

On Success
Conversely, the On Success page should be where we take the user if the form submission was a success. You'll notice that by default the value of this field is simply the Page Name from above but with an index that's one higher. For example, if you current page is page1.php, the On Success page name will be automatically set to page2.php.

If you have a multi-page form, this should be the name of the next page in the sequence. If you are going to a confirmation page, this should be the name of the confirmation page.

As an example...
On a simple two-page form, FormBoss names the first page: page0.php, then when you create a confirmation page, it is automatically called page1.php. All page naming is handled for you, including the .xml and _process.php files, as well as the On Fail and On Success pages. If you look at the job folder, you will see the following relevant files:
page0.php
page0_process.php
page0.xml
page1.php
page1_process.php
page1.xml

One Final Note On Page Naming...
Because the vast majority of your page names will be just fine when left to the default behavior, that is, leaving FormBoss in control, the only real issue you'll run into is having the change the index number of a page(s) when you remove a confirmation page that is between two form pages (which should hopefully be a relatively rare occurrence, as confirmation pages should always be the last thing added).

For example: let's say you had pages: 0(form),1(confirmation),2(form),
And then removed page 1(confirmation). If you do this, page 1 (old page 2) is still named page2.php. This is a problem because page0.php will still have page1.php in the On Success field, something that clearly won't work, as we no longer have a page named page1.php, only page0.php(form) and page2.php(form).

To fix this we need to change the Page Name of page2.php to page1.php.

In these cases we simply need to update the numerical indexes, something that FormBoss makes very easy. When you type in the Page Name field you'll notice the values in Page Action and On Fail automatically cascade down to match the value of Page Name. If you prefer to only change the Page Action or On Fail individually, type directly into that field.

Thus, we would select page2.php (the bottom page), and in the Page Name field, change the 2 to a 1. This will automatically update the Page Action and On Fail fields for us, and now our form will work just fine.

Lastly, your page naming should work from top to bottom. The top should start at 0, each page down should simply be 1 higher. This is the default FormBoss behavior, and works perfectly fine in just about every situation.

Use Background
If checked, FormBoss will place any image you upload* by clicking the Upload Background Image button into the form as that pages background image.

APACHE UPLOAD ERRORS (uploaded images do not show up)
* There is a known compatibility with some Apache Web Servers and mod_security when trying to upload images. A simple workaround is available, which you can find here.

BG Layout Format
Choose between None, Repeat X, Y or Both.

This section contains settings for controlling form access and security.

As of Build 695 Builder pages can also take advantage of these security settings, particularly with regard to the page login features. Do note however, that not all properties make sense for Builder pages, such as Entry Limit, so not all are supported.

Please take special note, the IP Limit fields will ONLY WORK when creating a form that sends results to the internal FormBoss result browser via the Simple SQL field item. This is because the IP check relies on the existence of records in the FormBoss fb_job_entries table to work. If you are creating a job that only send to email or SQL+, you must create a Simple SQL field item for these options to work!

Entry Limit
Set a number other than 0 to limit the number of entries per user-ip. Caution should be used with any IP based restriction, as it can be circumvented by simply switching ip's.

Entry Limit Duration
Select a value from the drop-down to permit when--if at all--a user can post another entry. Select Forever to permanently limit entire's to 1, or select from Day, Week, Month, or Year.

IP Limit Error Message
The message to display to a user who has reached the IP submission limit. The default text should suffice in most instances, though when you set a custom duration you may want to include this information to help the user understand why they cannot post again.

You can use the HTML text editor to 'spruce' up this field, and this is recommended. However, please note that unlike other HTML editor fields such as Header and Body Copy that inherit text styles from the form body, you will need to explicitly set a text style for this field, otherwise the browser default font is used, which rarely looks professional.

Enable Page Login?
This feature, introduced in FormBoss 2 Build 695, allows us to block access to the form unless a satisfactory username and/or password combination is provided. It can be enabled and disabled at will with this dropdown menu.

For standard form pages the login logic is active until the user provides a correct login. This login access is then valid for that form until they submit the form through to its confirmation page. At that time the SESSION element which has validated the login will be destroyed, and any subsequent visit to the form will once again require a login.

For Builder pages a successful login will remain valid until the browsers session is destroyed, e.g., they quit the browser.

User Name
As the name states, this is the user name a visitor would need to provide to the login form. The most important aspect of this field is it's not required. Should you leave this field blank, FormBoss will create your form with just the password field present.

Password
This field, regardless if we supply a username or not, is always required. It's best to make this only as complex as the form requires.

Login Attempts Limit
Select from 3, 5, or unlimited. This system is session based, which means the users browser will be locked out if the maximum number of attempts is reached, but not after a browser restart. For maximum security it is recommended to use a more robust login solution such as the FormBoss Form Persistence SESSION based system. It is for this very reason that the default value is unlimited, as we should not rely on this system for hyper sensitive forms such as financial data.

Login Message
This is the message that displays above the login form.

Login Error Message
Should a user supply an incorrect username/password combination, this is the message that displays to the user. This field, along with the next two, support HTML, though for consistencies sake it's usually best to leave these as plain text.

Login Attempts Error Message
Should a user supply an incorrect username/password combination over the limit specified in the Login Attempts Limit drop down, this message will be shown to the user.

Comma Delimited Accepted Domain List
Setting a value in this text area will force all form users to use the form from that individual or set of originating domains. For example, if your web site: coolexample.com should be the only place someone can use this form, place coolexample.com in the text area. Please note you should include the Top Level Domain (.com, .org, .net) and the hostname--For example formboss.net.

To find out your current domain, create a blank page and run this code on it:

<?php echo $_SERVER['SERVER_NAME']; ?>

For development purposes, you will often use localhost if your web server is on your local development machine.

If you need to include more than one domain, make sure to use a comma separator between each host and TLD!

Form Is Accepting Entries
This box is checked on by default, but if at anytime you wish to disable a form, uncheck this box. The form will not load when a user visits the form, and a message (see below) displays informing the form is not active.

Non-Active Form Visitor Message
If you choose to disable a form, this is the message displayed to the end-user when the form 'fails'. By default the message is: Sorry, this form is currently disabled. It is advisable to provide a more detailed message for any disabled form.

As with the IP limit field, you can use the HTML text editor to 'spruce' up this field, and this is recommended. However, please note that unlike other HTML editor fields such as Header and Body Copy that inherit text styles from the form body, you will need to explicitly set a text style for this field, otherwise the browser default font is used, which rarely looks professional. To add a font simply select the text and click in the Font Family drop-down menu of the TinyMCE editor instance.