Enabling Conditional Logic for a Feed

Enabling Conditional Logic for a Feed

SummaryFeed SettingsExample

Summary

Conditional logic can be used to specify when a certain feed should process based on the form data. This is useful for subscribing users to mailing lists and sending payment information to different services.

Feed Settings

Enabling conditional logic for a feed can be done in the feed settings. This will need to be done for each feed associated with the form. If conditional logic is not configured, the form will process the first feed it finds.

Example

In this example we are using conditional logic to determine if the form data should be sent to one of two payment services, either Authorize.Net or Stripe.

First, we add a field to the form which allows the user to choose a payment method. We』re going to use a drop down field labeled Gateway with the choices of Authorize.Net and Stripe.

Then we create a feed for each service via the specific add on』s feed settings page. Conditional logic is enabled and the criteria is set so that the gateway equals the appropriate payment method for that feed. Click here to view a video demonstration.

When the user is on the form, they will be presented with the Gateway field which allows them to select which payment gateway they wish to use. Then when the form is submitted, the conditional logic will determine where the payment information is sent. If they select Authorize.Net as the Gateway, then the payment information will be sent to Authorize.Net. If they select Stripe as the Gateway, then the payment information will be sent to Stripe.

Form Body CSS Selectors

Form Body CSS Selectors

ContainerField ListContainerList ItemsField InputsInput ContainerDescription ContainerRequired Field Indicator (Asterisk)

Container
Contains the main form content

example: the form body section (div) – applies to all forms
1body .gform_wrapper .gform_body  {border: 1px solid red}

example: the form body section (div) – applies just to form ID #1
1body #gform_wrapper_1 .gform_body {border: 1px solid red}

Field List
Container
unordered list used to structure all of the form elements

example: the form list container (ul) – applies to all forms
1body .gform_wrapper .gform_body .gform_fields {border: 1px solid red}

example: the form list container (ul) – applies just to form ID #1
1body #gform_wrapper_1 .gform_body .gform_fields {border: 1px solid red}

List Items
Individual list items containing each form element

example: the form list item (li) – applies to all forms
1body .gform_wrapper .gform_body .gform_fields .gfield {border: 1px solid red}

example: the form list item (li) – applies just to form ID #1
1body #gform_wrapper_1 .gform_body .gform_fields .gfield {border: 1px solid red}

Field Inputs
Input Container
Wraps the actual form element inside the containing list item

example: input field container (div) – applies to all forms
1body .gform_wrapper .gform_body .gform_fields .gfield .ginput_container {border: 1px solid red}

example: input field container (div) – applies just to form ID #1
1body #gform_wrapper_1 .gform_body .gform_fields .gfield .ginput_container {border: 1px solid red}

example: input field container (div) – applies just to specific form field (based on the unique parent element ID – replace 「XX_X」 with your actual element ID)
1body .gform_wrapper .gform_body .gform_fields  #field_XX_X.gfield .ginput_container {border: 1px solid red}

Description Container
Contains the field description inside the containing list item

example: input field description container (div) – applies to all forms
1body .gform_wrapper .gform_body .gform_fields .gfield .gfield_description {border: 1px solid red}

example: input field description container (div) – applies just to form ID #1
1body #gform_wrapper_1 .gform_body .gform_fields .gfield .gfield_description {border: 1px solid red}

example: input field description container (div) – applies just to specific field description (based on the unique parent element ID – replace 「XX_X」 with your actual element ID)
1body .gform_wrapper .gform_body .gform_fields  #field_XX_X.gfield .gfield_description {border: 1px solid red}

Required Field Indicator (Asterisk)

example: required field indicator (span) – applies to all forms
1body .gform_wrapper .gform_body .gform_fields .gfield .gfield_label .gfield_required {color: red}

example: required field indicator (span) – applies just to form ID #1
1body #gform_wrapper_1 .gform_body .gform_fields .gfield .gfield_label .gfield_required {color: red}

example: required field indicator (span) – applies just to specific indicator (based on the unique parent element ID – replace 「XX_X」 with your actual element ID)
1body .gform_wrapper .gform_body .gform_fields  #field_XX_X.gfield .gfield_label .gfield_required {color: red}

Extending the Dropbox Add-On

Extending the Dropbox Add-On

The Dropbox Add-On provides hooks that can be used to modify the default functionality or extend it. For more information, review the Dropbox category.
Looking for information about what properties the Dropbox Upload field uses in the Field Object or what format it』s value is stored in the Entry Object and how you can access it? Then take a look at the GF_Field_Dropbox article.
Because the Dropbox Add-On is built using the Add-On Framework, it also inherits any hooks available in the framework methods it uses such as:

gform_short_slug_field_value for changing the Dropbox Upload field value before it is used to upload the files to Dropbox.
gform_short_slug_error for performing a custom action when the add-on experiences an error processing a feed.

File Upload

File Upload

SummaryCommon SettingsGeneral SettingsNotesMerge TagsUsageModifiers

Summary

The File Upload field allows users to upload a file with their form submission. You may limit which filetypes a user may upload via the properties tab. It is available under the Advanced Fields section within the form editor.

File Upload field as displayed in the Field Library

File Upload field as displayed in the Form editor

Common Settings

This field uses only common field settings for the Appearance and Advanced settings. For a description of each of the common field settings, refer to this article. Below you will find description of specialty settings that are particular to this field.

General Settings

SettingsDescriptionAllowed file extensionsEnter the allowed file extensions for file uploads. This will limit what type of files a user may upload. See note 1.Enable Multi-File UploadIf checked, this option allows the user to upload multiple files. If unchecked (default state), the upload will accept only a single file. See note 2.Maximum File SizeUse this to specify the maximum size in megabytes allowed for each of the files.

Notes

1. See this article for important notes on WordPress permitted file types.2. Once an entry has been submitted using this field, this option will no longer be editable. That is, you cannot switch a file upload field from from single file to multi-file once an entry with a file has been submitted.

Merge Tags

For more information on the use of merge tags, refer to these articles.

Usage

{Field Name:2:modifier}

Modifiers

ModifiersDescription:downloadDenotes that the link created for the download should force the download when accessed.

Entry Date Merge Tags

Entry Date Merge Tags

SummarySinceImportantDefault UsageModifiers:time:format:human:diff:raw:timestamp

Summary
The entry date merge tags can be used in notifications, confirmations, and with some add-ons to output the date and/or time the entry was created, updated, and paid. They cannot be used in field settings.
Since
Support for these merge tags was added in Gravity Forms 2.5. They were previously only available when using selected third party add-ons from certified developers.
Important
The date_created, date_updated, and payment_date are stored in the entry and database using UTC in the YYYY-MM-DD HH:MM:SS format. The values will be formatted for output using the timezone, date, and/or time formats from the WordPress General Settings screen.
For the examples below the value stored in the entry for specified property is 2021-04-21 10:30:15 UTC, the timezone is set to Europe/London, the date format is set to F j, Y, and the time format is set to g:i a.
Default Usage
Outputs the specified date.

Merge Tag
Output

{date_created}
April 21, 2021

{date_updated}
April 21, 2021

{payment_date}
April 21, 2021

Modifiers
:time
Adds at [time] to the output.

Merge Tag
Output

{date_created:time}
April 21, 2021 at 11:30 am

{date_updated:time}
April 21, 2021 at 11:30 am

{payment_date:time}
April 21, 2021 at 11:30 am

:format
Define a custom format for the output using the WordPress and PHP date/time formatting characters.
The format must be defined after :format, with a colon, like this :format:m/d/Y.
If you want to use a colon in your output, it must be escaped with a backslash, like this :.

Merge Tag
Output

{date_created:format:m/d/Y}
04/21/2021

{date_created:format:Y-m-d}
2021-04-21

{date_created:format:d/m/Y at H:i:s}
21/04/2021 at 11:30:15

{date_updated:format:m/d/Y}
04/21/2021

{date_updated:format:Y-m-d}
2021-04-21

{date_updated:format:d/m/Y at H:i:s}
21/04/2021 at 11:30:15

{payment_date:format:m/d/Y}
04/21/2021

{payment_date:format:Y-m-d}
2021-04-21

{payment_date:format:d/m/Y at H:i:s}
21/04/2021 at 11:30:15

:human
If the entry is less than a day old, it will output a relative vale using the [time] ago format. If you want to customize the format, use the :diff and :format modifiers instead.

Merge Tag
Output

{date_created:human}
15 mins ago

{date_updated:human}
15 mins ago

{payment_date:human}
15 mins ago

If the entry is more than a day old, it will output the date using the default date format. If the :time modifier is also used, it will output [date] at [time] using the default date and time formats.

Merge Tag
Output

{date_created:human}
April 21, 2021

{date_created:human:time}
April 21, 2021 at 11:30 am

{date_updated:human}
April 21, 2021

{date_updated:human:time}
April 21, 2021 at 11:30 am

{payment_date:human}
April 21, 2021

{payment_date:human:time}
April 21, 2021 at 11:30 am

:diff
Outputs how long ago the entry was created, updated, or paid.
The default format is %s ago, where %s is replaced by the time difference in seconds, minutes, hours, days, weeks, months, or years.

Merge Tag
Output

{date_created:diff}
1 second ago

{date_created:diff:format:%s has passed since the form was submitted}
5 hours has passed since the form was submitted

{date_updated:diff}
1 day ago

{date_updated:diff:format:%s has passed since the entry was updated}
3 days has passed since the entry was updated

{payment_date:diff}
1 week ago

{payment_date:diff:format:payment was completed %s ago}
payment was completed 1 month ago

Using the :time and :human modifiers with this modifier is not supported.
:raw
Outputs the value as it is stored in the entry and database. This value is also available using the Entry Merge Tag.

Merge Tag
Output

{date_created:raw}
2021-04-21 10:30:15

{date_updated:raw}
2021-04-21 10:30:15

{payment_date:raw}
2021-04-21 10:30:15

This modifier cannot be used with other modifiers.
:timestamp
Outputs the value as a Unix timestamp; the number of seconds since the Unix epoch on January 1st, 1970 at UTC.

Merge Tag
Output

{date_created:timestamp}
1619001015

{date_updated:timestamp}
1619001015

{payment_date:timestamp}
1619001015

This modifier cannot be used with other modifiers.

Accessibility Warning Showing on Field

Accessibility Warning Showing on Field

SummaryDescriptionAdvice Regarding Specific FieldsMultiselectGoogle reCAPTCHA V2DatepickerSubmit/Next Page ButtonIntroduced InFurther InformationExample Screenshots

Summary

This article provides information regarding accessibility warning messages you may receive for a particular field on your form. The message is presented in the Field Settings pane of the Form Editor. See screenshots at bottom for some examples.

Description

To ensure your form can be completed by all your visitors. it is important to try and limit your form to using fields that work for everyone. People who use assistive technology for example, may find some form fields have hard to navigate, or some fields are hard to understand when read back by a screen reader or voice recognition software.

If your forms must comply with accessibility guidelines like WCAG, section 508 or the ADA, then please be aware that some form fields with accessibility issues can』t be used. From Gravity Forms 2.5 onwards we present a warning message for the most common of those, and have listed some alternatives here.

Advice Regarding Specific Fields

Multiselect

The Multiselect field is difficult for people using assistive technology like a screen reader or voice recognition software, as they are not able to properly select multiple options. The better choice is using checkboxes.

A warning will be displayed in the Form Editor when Field Label Visibility is marked as hidden.

Google reCAPTCHA V2

The Google Support website has a page is dedicated to the accessibility of reCAPTCHA V2 through the use of an audio challenge. The can present other challenges for your visitors though.

Firstly, this is not an option for deafblind users. Secondly, reCAPTCHA only offers an English audio challenge and expects an English answer to it, which makes it harder for non-native English speakers to understand the challenge or increases the likelihood of typing the answer with a spelling mistake.

There is also a cognitive and cultural accessibility issue. Not everyone understands the visual challenges.If you have a form that is vital for your visitor to fill out, don』t put the burden of proving they are human on them.

An alternative could be to use a third-party reCAPTCHA V3 add-on. If you choose V3, also consider the privacy impact for your users and whether you need to comply with your GDPR policy as well.

Support for reCAPTCHA V3 will be added in a future update of Gravity Forms.

Datepicker

The date field provides the option of displaying a datepicker, but note this datepicker is not keyboard or screen reader accessible at the moment. Therefore we provide an accessible alternative of having the date input fields be text only.

Hints on what the exact date format your field expects is given by placeholders and by additional text, connected to the input field with aria-describedby. Then the date format is announced and visible.

For more info, this external article has a good discussion of accessible datepickers.

Submit/Next Page Button

The presentation of the submit (and next page) buttons can be controlled by conditional logic. The best accessibility choice is to use a visibly disabled button. This is a well known form pattern, people know what it means.

Completely hiding the submit button can have a negative impact on the accessibility of a form for a few reasons, mostly cognitive:

Visitors do not see the submit button at first. This is unexpected behavior, which can discourage visitors that are not that web savvy, and increase anxiety around the task of trying to complete the form.You send the visitor on a quest: what do I need to fill out to get this form submitted?Blind visitors do not get informed when the button later (conditionally) appears and the form can be submitted.For accessibility it』s always best to stick to form conventions and give the visitor all the information they need.

Introduced In

These warning messages were added in Gravity Forms 2.5. The warning messages contain a link to this article.

Further Information

Refer to the Accessibility area of our documentation site for more helpful advice on improving your form』s accessibility.

Example Screenshots

These images show a few examples of the type of warning you may see.

Enabling the Gravity Forms Toolbar Menu

Enabling the Gravity Forms Toolbar Menu

Enabling the toolbar menu itemAccessing the toolbar menu itemCapabilitiesHelp! I don』t see the toolbar!

The Gravity Forms toolbar menu enables quick access to your most recent common actions. This article shows you how to enable it.

Enabling the toolbar menu item

First, access your Gravity Forms settings page. This done by hovering over Forms on the left side admin menu, and clicking on Settings.

Once you have accessed the Settings page, locate the option labeled Toolbar Menu and turn it on.

After the Toolbar Menu option is set, save your settings by scrolling down and clicking the Save Settings button.

Accessing the toolbar menu item

After enabling the Gravity Forms toolbar menu, you should immediately see the new menu item labeled Forms. Hovering over it will provide a listing of the most recent forms accessed, as well as links to view all forms or create a new form.

By hovering over one of the forms listed, additional items will appear. From here, you can do things such as access the form editor, view entries, change settings, and preview the form.

Capabilities

Which capabilities are enabled for your user role will determine what items will appear in the menu.

Menu ItemUser Capability RequiredNew Formgravityforms_create_formAll Formsgravityforms_edit_forms

These are the submenu items for the individual forms.

Menu ItemUser Capability RequiredEditgravityforms_edit_formsEntriesgravityforms_view_entriesSettingsgravityforms_edit_formsPreviewPreview – gravityforms_edit_forms or gravityforms_create_form or gravityforms_preview_forms

See the Role Management article for more information about the plugin capabilities and how they can be managed.

Help! I don』t see the toolbar!

If you don』t see the admin toolbar at all, you may have it disabled in your main WordPress settings. To enable it, perform the following:

Access your user profile within the WordPress admin dashboard. To do so, hover over Users on the left side admin menu, and click on My Profile.Within this page, you should see an option labeled Toolbar. Ensure the checkbox is enabled. If not, enable it and save your changes.

If you still don』t see the toolbar, you may have a theme or plugin that is interfering with it. Try enabling a default theme such as Twenty Fifteen and disabling other plugins.

Form Confirmation CSS Selectors

Form Confirmation CSS Selectors

Inline Confirmation Message

Inline Confirmation Message
Displays on same page upon successful completion of the form

example: inline confirmation message (div) – applies to all forms
body .gform_confirmation_wrapper .gform_confirmation_message {border: 1px solid red;}

example: inline confirmation message (div) – applies to form id 1
body #gform_confirmation_wrapper_1 .gform_confirmation_message {color: black;}

FAQ About Gravity Forms Language Translation Files

FAQ About Gravity Forms Language Translation Files

IntroductionFrequently Asked Questions?What has changed for Gravity Forms language files? What triggers a language file download? Can I download language files manually?What locale translation files are managed by Gravity Forms?What other locale translation files are available?Where are the language files stored now? What about if the WordPress user has their own selected locale?

Introduction

Language files provide translations of many of the most common Gravity Forms text and UI strings into additional languages. The way language translation files are accessed, loaded and stored has changed with Gravity Forms 2.5. This article provides information about how they are handled now.

Frequently Asked Questions?

What has changed for Gravity Forms language files?

Previously, all the core translation files were included in the Gravity Forms files package with each download. From Gravity Forms 2.5 though, language files are now hosted by the TranslationsPress service, and are downloaded as required during a few key events based on the languages specified in your WordPress admin. This provides a reduction in the overall size of the core file package, and it has also has changed where the files are stored.

What triggers a language file download?

Gravity Forms will trigger the download and installation of appropriate language files on the following events:

The installation of the Gravity Forms core plugin or a Gravity Forms add-on.The update of the Gravity Forms core plugin or a Gravity Forms add-on.When the site language is changed on the WordPress My Site → Settings page.

There are also a few conditions that can stop the download of the language file, such as if the installed translation last updated date is the same as the available version, or the translation language/locale is not found.

Can I download language files manually?

Language files can be downloaded for manual installation from the Translations page, which is accessible from the Help menu on the Gravity Forms site.

What locale translation files are managed by Gravity Forms?

There are a certain list of core locales that are updated and reviewed directly by Gravity Forms teams. These are generally checked for updates and updated monthly.

Brazilian (pt_BR)Dutch (nl_NL)French (fr_FR)German (de_DE)Hebrew (he_IL)Hindi (hi_HI)Italian (it_IT)Japanese (ja)Portuguese (pt_PT)Russian (ru_RU)Spanish (es_ES)Swedish (sv_SE)Turkish (tr_TR)

What other locale translation files are available?

With customers all over the world, there are many other language translations for Gravity Forms that have been authored and reviewed by volunteer contributors. A full list of these can be found on the Translations page on our website, noted under the manual download menu. Note that these are unofficial translations. Although as much care is taken as possible, Gravity Forms cannot guarantee the accuracy, speed or coverage of these updates. We do log all feedback received through our support channels, and provide it back to the contributors responsible.

To volunteer as a translation contributor, please see the Translation page.

Where are the language files stored now?

The translations are stored in WP_LANG_DIR/plugins/, where WP_LANG_DIR is your WordPress language directory. For example, /wp-content/languages/plugins/.

They can also be stored in WP_LANG_DIR/gravityforms/, and files here will be loaded before those in the default location mentioned above.

What about if the WordPress user has their own selected locale?

Support for the user selected locale was added in Gravity Forms v2.5.6. The user locale will be used first if set, and the default locale otherwise.