Where Contact Form Spam Bots Go to Die!
This document is the change log for the current version (version 17) of FST, as well as the prior versions (version 14+). There are many new features in version 14+ (which is why this document is now using MarkDown for formatting), so that information is included here. Change logs of prior versions is in the formspammertrap-change-log-prior-versions.txt that is included in the distribution zip file. Refer to the change logs for the various versions to add new functionality to your contact form.
We recommend updating to the latest FST version for all of the new features, and new and upgraded documentation. Version 17 has many new and improved features (see below).
The latest version should be back-compatible with your settings used in prior version, so you should be able to upload the latest version to your site without changing your contact page code. (Except version 17 requires PHPMailer files.) Testing is always good, though, as is referencing the documentation and change logs to understand the new features and bug fixes.
The 'formspammertrap-all-settings' file (included in the ZIP file you received) contains all of the settings, along with usage notes. Some features are explained in the documentation (PDFs).
Remember that you enable your options via the FST_MORE_FIELDS() function in your page code. Do not make changes to the 'formspammertrap-contact-functions.php' file. All options you specify are validated for proper values and type. Some settings are checked via the 'sanity check' process that will display (or email) any errors on your form.
We encourage you to read the included documentation (PDF), as that will help you implement a basic contact form, and provide information on how you can customize your contact form with the many options in this version.
We can help with implementation for a reasonable cost. Information is on the FST web site. We've also added a blog to the FST site with additional tips and information: https://www.FormSpammerTrap.com/news .
Improved checking of required fields, especially if you are adding additional fields that are required, and if you are removing any of the standard four required fields ('yourname', 'youremail', 'yoursubject', 'yourmessage'). This requires that you specify the required fields in the $FST_REQUIRED_FIELDS array (defaults to the above required fields).
Enhanced the field sanitation of the form data when submitted with a new fst_sanitize_field() function. It sanitizes all possible input types using htmlcharacters() function for UTF-8 encoding (for multi-byte characters).
If your form does not have a field called 'yoursubject' (normally used for the message subject), the submitted email will have a subject as defined by $FST_XEMAIL_SUBJECT (default is "Contact Form Message:"). The contents of the 'yoursubject' field (if exists in your form) will be appended to that $FST_XEMAIL_SUBJECT value.
Note: strongly recommended to have these field names in your form:
Without those field names, you may not get the information needed from your form. It might also cause incorrect form error messages.
The AFTERMSG value of $FST_XCUSTOM_FIELDS array is shown for all types (previously not shown for CHECKBOX types). The AFTERMSG is optional.
Reinstated the use of the session ID as part of the bot checking.
Fixed the redirect for spambots to the $FST_XSPAMMER_URL value (default is the FST site). The redirect happens after a five second delay; the $FST_XGO_AWAY_MSG message is displayed before the redirect.
. 3FST version 17.00+ now uses the PHPMailer package to send mail. (I've been struggling to get file attachments to work properly in all environments; PHPMailer makes it much easier.) You must to add the additional PHPMailer files to your site. See documentation for instructions. Files available from https://github.com/PHPMailer/PHPMailer .
That means that there are additional files to install, not just the FST 'functions' file. Full information is in the DOCs. Make sure you copy the three PHPMailer files into the 'phpmailer' (case sensitive) subfolder of wherever you put the FST functions file on your site.
This major enhancement has several settings you can define (including using your SMTP mail server). Again, read the docs.
Note that using file attachments in your contact form (or sending file attachments) will require using PHPMailer. If you don't use PHPMailer, you cannot use a file attachment button in your contact form (unless you roll your own mail sending process using FST_MAIL_ALT function in your form page code).
If you add a file upload button to your form, and you don't install the PHPMailer files, the mail message may not be delivered or contain incomplete information. The message will include a warning if this happens (although you might also get the "Sanity Check" warning). We strongly suggest adding the PHPMailer files to your site.
Note that a WordPress-based site using FST forms will already have PHPMailer installed.
You will see an error screen if you do not have the required PHPMailer files in the 'phpmailer' subfolder of your contact form page (this is done via the "Sanity Check' process).
The $FST_CODE_INSERT can be a code string, as well as an array. The code string is not checked for any syntax or validity. You could really break things (or even risk malware attacks) if you aren't careful with this block of code. Make sure you properly escape quote characters.
Added these additional settings to allow for a popup JS alert message; useful when FST form is a popup
/* POP THE THANKS MESSAGE (since version 17) if set true, an JS alert with a 'thanks' message will display on form submission and the message is sent (PHP mail() returnes true)
/* POP THE THANKS MESSAGE TEXT (since version 17) the 'thanks' text to display if the FST_POP_THANKS flag is set true (above)
$FST_POP_THANKS_MESSAGE = "Thanks for contacting us. We will reply as needed.";
In WordPress site usage, adjusted the phpMailer 'From Name' to be the blog name, rather than "WordPress".
Changed the 'go away' message default to something more polite (although not sure why you would want to be polite to spammers): $FST_XGO_AWAY_MSG = "Invalid form submission; submission cancelled.";
Added information in the "Using FormSpammerTrap in WordPress" document (PDF) that you will need to create a Child Theme for your custom template. This will allow your custom template to 'survive' a theme update (otherwise, the custom template is deleted during a theme update).
If FST_XWRITELOG enabled (enables writing a debug log), and the form submit failed (the fst_go_away function called), the debug log will show you the reason why the submit failed. An approximate line number is shown in the log file message. This is mostly for our convenience, but can also be used to track submit failures if you want to track them. The log file is stored in the file (including folder, which much already exist) defined by $FST_XWRITELOGFILE. Default value is maillog.txt in the current folder. (Note: log file no longer date/time stamped.)
Added additional bot checking for the proper session ID.
Added additional hidden field to show the FST version number; useful for debugging.
Added the PHPMailer version information if you set $FST_SHOW_VERSION true.
The FST_XEMAIL_ON_DOMAIN value - the recipient of the message, which is normally set in your contact form, will default to noreply@yourdomain . Note that if the email address doesn't exist, there is no indicator other than not receiving the message.
FST_FROM_EMAIL, FST_FROM_NAME is used as the recipient of the email. Default will be noreply@yourdomainname and yourdomainname (respectively).
All emails sent via the new PHPMailer process will be HTML formatted. If you don't use the new PHPMailer process, files sent via your form (optional) will not be attached to the message. You might also get a 'Sanity Check' error message. PHPMailer is required.
Text message changed for file upload area (in the $FST_LANG_TEXT array): "thumbnail_shown_here" => "List of selected files will be shown here"
The ID value of the Submit button is now a variable you can set: $FST_SUBMITBUTTON_ID , with a default value of 'fst_submitbutton'. You can change that if the name conflicts with other element ID's (since element ID values have to be unique) that you might use in your forms or scripts. There are few instances where you might have to change the submit button ID: most will be if you use that ID value in other elements on your page.
Related to the new $FST_SUBMITBUTTON_ID setting, there are CSS values that use the button ID name to set the styling of the button; the default values of '#submitbutton' and '#submitbutton:hover'. If you override those CSS values for your own button styling, and you change the $FST_SUBMITBUTTON_ID value in your form, make sure that you specify the CSS rules for that button ID in your form page.
We're working on a new WordPress plugin that will create the WP FST template for you, as well as create a FST Contact Page that uses the [formspammertrap] shortcode. Look for details on the FST site. The plugin will have all FST code built-in to the template.
The use of the $FST_XCC_EMAIL and $FST_XBCC_EMAIL might cause deliverability issues, if you have
If you use the $FST_SHOW_HEADER development setting true (to show the email header appended to the message), you might have deliverability problems, or the message might end up caught as spam. This is because the email header will have several email addresses in it, and that often triggers spam filters.
Enhanced the WordPress shortcode that can be used with the WordPress template on your site. Adding attributes to the shortcode will allow you to override the settings related to the following:
An example usage to send the email to an address on another domain (instead of myname@thisdomain.com for a site on thisdomain.com), and also BCC to another email address, you would place this shortcode with parameters in the WordPress page that uses the FST WordPress template:
[formspammertrap email="fred@thisdomain.com" bcc='mary@here.com"]This would result in the email being sent from the contact form on example.com to
Note that the email addresses in the shortcode will override the values in the FST_MORE_FIELDS function of your template.
You could set the email parameter to a non-existent address on your domain, and then the CC value to another domains' email address. This would be especially helpful if your WP settings have an admin email that is not on the site's domain. If you didn't do this, you'd get a Sanity Check error.
If you want to specify multiple email recipients, use a shortcode similar to this (note the use of quotes, and a comma to separate values):
[formspammertrap bcc="jim@here.com, mortimer@snerd.com"]Additional parameters may be added in future versions; use the Contact form to indicate your interest in more parameters. FST also sets a constant for the shortcode attributes for possible future use.
The shortcode and the optional attributes (tags) should be lowercase. The values should be in single or double-quotes (preferred), especially if the values contain spaces. Using quotes is a good practice for shortcode parameters.
Changed the mail process to use the wp_mail function on WordPress sites. This should improve the handling of mailing messages via a contact form on WordPress. See also the 'minor bugs' section on enhancements to the mail header.
Added a new option to force use of the PHP mail() function, even on WordPress sites. By default (since version 16), using FST a WordPress site (normally via a WP template) will use the wp_mail() function. That function uses the built-in PHPMailer functions to send mail on WordPress sites. PHPMailer is a bit more robust and less prone to spam detection than the PHP mail() function.
Added new option $FST_SHOW_HEADER to show mail header array as extra text in the sent message. Enabled if true; default is false (disabled). Useful to help debug mail header issues.
Added new optional parameters to the $FST_CONTACT_DATABASE optional settings. (This setting allows you to set up a database where contact information from the form is stored in a database. We use this feature on the FST contact form, as a checkbox for saving your contact data.) The new optional parameters allow you to specify default values for additional fields.
The $FST_CONTACT_DATABASE is an array of values. The new parameter is a sub-array in that array.text If your database had fields of 'status' and 'source' (both character fields), and you wanted default values of 'ACTIVE' and 'LANDING PAGE' stored in those fields, the additional parameter would be
$FST_CONTACT_DATABASE['FIELD_DEFAULTS'] = array(
'status' => 'ACTIVE',
'source' => "LANDING PAGE')In this example, the FST 'sanity check' will check for the existence of the fields called 'status' and 'source', and that the 'FIELD_DEFAULTS' array element (in the $FST_CONTACT_DATABASE array ) is a two-dimensional array, and that each array element has a value. If problems are found, they will be shown on screen or in an email to the admin (depending on the $FST_SANITY_CHECK_EMAIL setting). The Sanity Check is not perfect, but it will check for obvious errors. Fully testing your form is good idea; for instance, make sure the table field type is correct for the default data you specify in this array element.
When you specify the optional FIELD_DEFAULTS in the $FST_CONTACT_DATABASE array, The database save/update process will take those two values (if they exist, and if they are an array, and if there are values) and use them in the INSERT or UPDATE database commands. Make sure the fields are the proper type for your values.
Note the uppercase format of the above: "FIELD_DEFAULTS", and $FST_CONTACT_DATABASE. That is recommended, as PHP is sometimes picky about the case of field names. Of course, you will also need to define the rest of the $FST_CONTACT_DATABASE array. See the docs for more information on how to use the "Save Contact to Database" feature.
Improved the code that builds the email's header elements. (Also see section on wp_mail() and mail() header settings.)
Fixed the Sanity Check process to lowercase the domain name and primary email address to not cause Sanity Check errors. Also improved the process for checking domain name and primary email address are on the same domain. This should get rid of some false positives of the email domain check matching the domain name.
Adjusted how the headers are built for the mail command to take into account the difference between how the PHP mail() and WordPress wp_mail() functions process headers.
Added a 'sender' header element to better ensure delivery without being marked as spam. Sender value is the same as the FST_FROM_EMAIL value (must be on site's domain).
Fixed checking for a custom field having a value before adding it to the message to be sent; it caused a 'warning' error in PHP 8.0+.
Fixed/enhanced the 'required field' message $FST_LANG_TEXT (if enabled by setting $FST_SHOW_REQUIRED_MESSAGE to true) to show the colors via the following classes (which you can override with your CSS rules in your form)
Fixed the textarea field not changing to the 'valid' color when text is entered. Text and textarea validation just looks for characters, and does no other checking.
Adjusted the default $FST_LANG_TEXT['show_required_message'] value to "required field" .
Improved the extraction of the TLD domain from the site page URL that is used to verify the $FST_FROM_EMAIL matches the site's domain.
Added the FST version number to the Sanity Check version.
Corrected some code that was causing warning errors in the error logs. Plus fixing some minor spelling errors.
Added additional and enhanced comments about the new settings that were added in this and prior versions.
Some corrections/enhancements to this document, including prior version information.
Note that the Verify Message (if enabled) is only in English; there is no FST_LANG_TEXT array for that text in this version. You can override the text of the message, or use your own language, with the FST_CONTACT_VERIFY_MESSAGE_DATA array (see Settings documentation).
New options for specifying the styling of the input fields: background and border colors, border style and radius. Border styles are available for top/right/left/bottom sides of the border. There are separate settings for required, valid, and invalid input fields.
Added a background color for required fields (although you can customize via the above new feature). Previously (starting with version 14) only border colors showed required fields. This helps with dark themes, as the border may not always be visible. By default, required fields are shown with light yellow background. Invalid data is shown with light red background. Data that is validated for that field is shown with light green background. (See also above item for customizing those colors.) FST_MORE_FIELDS are sanitized before use.
Improvements to the process of building/merging the custom CSS, as defined by FST_INPUT_REQUIRED / FST_INPUT_VALID / FST_INPUT_INVALID that is used by any required input fields.
Also improved the display of the border/background/text colors used by the input fields to use the above CSS rules (which you can override).
If you have set an optional input field as 'read-only' in it's array element, the font color is set to the 'Valid' field text color array element: FST_INPUT_VALID['background-color']. You can't click on a read-only field.
Additional fields defined via $FST_XCUSTOM_FIELDS array have added settings:
Added option to enable showing a 'required' message above the form. This is enabled with the $FST_SHOW_REQUIRED_MESSAGE setting, set in the FST_MORE_FIELDS function in your contact page code; default is false (don't show it). If enabled (true), uses the FST_LANG_TEXT['show_required_message'] language array element, default message is "Required fields are shown with a red border".
global $fst_lang_text;
$fst_lang_text['show_required_message'] = "Your message here";Added HTML5 field validation via the 'type' parameter of the input tag. with HTML5, fields are validated client-side by the browser when the form is submitted, not the submit process on the server. Any errors are shown with a tool-tip by the browser. See https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation for details. You can add additional field validation if needed by using the FST_CUSTOM_AFTER_SUBMIT() function in your contact page code.
The CSS for 'input' tags has been changed to
Added additional optional buttons for the form:
Related to the new buttons, you can now set the $FST_CONTAINER_ID value. This is the 'id' of the entire form. It's main use is to support the 'form close' button, but can be used for your own CSS styling. This is different from the FST_FORM_ID setting, which is the ID of the form inside the form container.
Added CSS of 'pointer-event' to the file "browse" button (if added) to ensure the button will work correctly
SSL (HTTPS) is now required for FormSpammerTrap-enabled pages. This is checked during the 'sanity check'. If SSL is not working properly, you get the Sanity Check error message (see documentation). You will need to contact your hosting support to get SSL enabled.
Added a new element to the FST_LANG_TEXT array for the text that is shown for required fields. The default value is FST_LANG_TEXT['required'] => "(Required)" . This replaces the $FST_MSG_REQUIRED setting.
Info: The display of the Sanity Check message on the screen is set by the $FST_SANITY_CHECK_EMAIL default value of false. This will display the Sanity Check failure message on screen instead of the form. Useful while building/testing your form, but you may want to set it true in production to send emails to the FST_XEMAIL_ON_DOMAIN address.
Fixed the formspammertrap-sample-contact-extended-test.php sample file to remove the 'size' attribute from the added 'select' tag (it was causing the select dropdown to not be a dropdown).
Changed the CSS rule for the input tags to be specific to the FST form, in case there are other input fields on the page.
Updated the formspammertrap-sample-contact-extended-test.php sample file to show a hidden field. You specify a hidden fields with the FST_MORE_FIELDS array. Leave the labelmsg or aftermsg fields blank, or that text will appear on the form, even though the field is hidden.
Fixed the 'verify' query parameter to be 'id'. A clarification regarding the verify message sent if enabled - if ...
... the message to the subscriber will include the $FST_CONTACT_VERIFY_URL plus a parameter of 'id=
Field types 'select' and 'textarea' have the same background color as input fields (unless overridden by your custom CSS rules).
Additional CSS media rules added and corrected for proper responsive display of the FST form on smaller screens. (You get to make the rest of the page responsive.)
Some minor CSS changes to the 'submit' button; rounded edges to match other buttons, and a hover color change, plus some padding inside the button. The submit/reset/clear buttons now have a similar size/padding, with different background colors. As with all default CSS, you can override in your form by adding CSS code after the formspammertrap_contact_css() function call.
Minor CSS inline style (margin-top=0) added to checkbox fields for better horizontal alignment of checkbox with it's label.
Changes to the 'required' text used in first column of field labels to use the CSS colors assigned to FST_INPUT_REQUIRED CSS, without the borders (just the text color and background color).
Change to the 'required fields' displayed at the top of the form to use the FST_INPUT_REQUIRED CSS, without the borders (just the text color and background color).
Some code efficiencies, and removing some leftover commented debugging commands.
Documentation updates.
This version adds support for client-visible messages in other languages (which you define). Note that debugging messages (as from the sanity check) are not part of the translation settings.
Important notes to implement:
global $FST_XSUBMIT_BUTTON_TEXT;
$FST_XSUBMIT_BUTTON_TEXT = "Enviar"; // 'submit' in SpanishYou can see the default values of the language array on this page: https://formspammertrap.com/v14/formspammertrap-language-english.php .
Form fields are now displayed in a CSS grid to help make the form more responsive on all screen sizes
New CSS to define the three columns of the grid
In FST_CUSTOM_FIELDS array, the MAXCHARS and MAXLENGTH array parameters are used for the columns and rows for the textarea input field.
Changed the way that jquery is loaded; now done as part of the formspammertrap_contact_script function .
Added code at the top of the main functions file to set the session cookie_secure true, to remove the error message shown in the developer console of "cookie 'phpsessid' will be soon rejected because it has the 'samesite' attribute set to 'none' or an invalid value, without the 'secure' attribute. " This is required for PHP version > 7.3. Should not affect sites running older PHP versions (but you should really upgrade; besides, FST requires at least PHP version 7.2).
Added a PHP version check at the very top - if not 7.2+, a 'fatal' message will display and the whole form will 'die'.
Additional sanity checks when $FST_CUSTOM_FIELDS_ONLY set true (for custom form fields)
if you have the FST_ADD_CHECKS() function on your form to do additional field checking, it should return an error message string, not an array. (Although an array will be converted as needed.)
note that you should have that function if you are doing only custom fields, as normal field checking is disabled with FST_CUSTOM_FIELDS_ONLY enabled.
The entire file upload/send/store process was re-done for efficiency (but mostly to make it work better).
A 'file upload' browse button is shown (if you add it to the form)
Note that your $FST_UPLOAD_EXTENSIONS must be properly formatted, with a leading period in front of the file extension. (Although, for compatibility with prior versions, FST will add the leading period if needed. Wasn't that a nice idea?)
Note that $FST_UPLOAD_EXTENSIONS should include possible variations, like '.jpg' and '.jpeg'.
You cannot use wildcards in $FST_UPLOAD_EXTENSIONS, so '.jp*' will not be valid and will be ignored.
The 'sanity check' will look for valid extensions, using the MIME list taken from these two sites. If the extension doesn't belong to a valid MIME-type, a sanity check error message will be displayed (or emailed). See these sites for information about valid MIME types and extensions:
For file uploads in the form:
File uploads are checked according to their actual mime type, not just the file extension. There is also 'directory traversal' sanitation. You should still exercise caution with all uploaded and/or emailed files.
wp_enqueue_script wp_enqueue_script("jquery");
add_action('wp_head', 'formspammertrap_contact_css'); // css used by the form; will be put into the <head> section
// all scripts need to be in footer area to get delays to work (v 14)
add_action('wp_footer', 'formspammertrap_contact_script'); // javascript used by the form; will be put in the </head>
add_shortcode( 'formspammertrap', 'formspammertrap_shortcode' );
include_once("FormSpammerTrap/formspammertrap-contact-functions.php");If you have any questions or comments about the new features, or suggestions for improvement, please use the Contact form on the FST site.
And thanks to those that have been able to donate to the support of this site and the code. There's a ton of hours in this, and your support is appreciated. Even a short "Huzzah!" via the contact form is appreciated.
Rick Hellewell - Somewhere Opposite Mutiny Bay, WA - 25 Feb 2022