Displaying a Form Within a Modal/Popup/Lightbox

Displaying a Form Within a Modal/Popup/Lightbox

IntroductionObtain the Popup Maker pluginEmbed your Form

Note: This tutorial is provided as a suggestion only. We do not support third party solutions. If you have any troulbe using Popup Maker, please contact with its author.

Introduction

Sometimes you may want to display your form within a box that will display over the current page. This is especially handy when encouraging newsletter signups on your site. In this article, we will show you how to embed any forms made with Gravity Forms into a popup window in just a few steps using a third-party plugin.

Obtain the Popup Maker plugin

The easiest way to create a popup window and embed Gravity Forms into it is to do so using the Popup Maker plugin. Simply download and install the Popup Maker plugin either from within your WordPress admin dashboard or manually.

Embed your Form

To embed your form, it』s as simple as creating a new popup, and embedding your form just as you would any other post or page. To do so, simply click the Add Form button.

When embedding your form, ensure that AJAX is enabled to avoid the page refreshing. To do so, either use the Enable AJAX checkbox when adding a form using the button, or add ajax=」true」 to your Gravity Forms embed shortcode.

¿Need more help creating your popup? Please contact the Popup Maker author for further assistance and tips.

Display a message on the login form when the user is pending activation

Display a message on the login form when the user is pending activation

This example shows how the WordPress authenticate filter can be used to check if the user attempting to login is still pending activation so a custom message can be displayed instead of the standard unknown username or email message.

add_filter( 'authenticate', function ( $user_or_error, $username_or_email ) {
// Abort if the user has already been authenticated or the UR add-on is not active.
if ( $user_or_error instanceof WP_User || ! function_exists( 'gf_user_registration' ) ) {
return $user_or_error;
}

// Abort if authentication failed for an unsupported reason.
if ( is_wp_error( $user_or_error ) && ! in_array( $user_or_error->get_error_code(), array(
'invalid_username',
'invalid_email',
) ) ) {
return $user_or_error;
}

add_filter( 'gform_user_registration_pending_activation_expiration', 'authenticate_pending_activation_expiration' );
$key = strpos( $username_or_email, '@' ) ? 'user_email' : 'user_login';
$is_pending = gf_user_registration()->pending_activation_exists( $key, $username_or_email );
remove_filter( 'gform_user_registration_pending_activation_expiration', 'authenticate_pending_activation_expiration' );

// If there isn't a pending activation return the original error.
if ( ! $is_pending ) {
return $user_or_error;
}

$custom_error_message = 'Account is pending activation.';

// If the UR login form is being used add the error to the first field.
if ( isset( $_POST['gform_submit'] ) && absint( $_POST['gform_submit'] ) === 0 ) {
$field = GFAPI::get_field( gf_user_registration()->login_form_object(), 1 );
$field->failed_validation = true;
$field->validation_message = $custom_error_message;
}

return new WP_Error( 'pending_activation', $custom_error_message );
}, 30, 2 );

// Callback for the gform_user_registration_pending_activation_expiration hook.
// Prevents the pending activation being deleted by the pending_activation_exists() check if it is a few days old.
function authenticate_pending_activation_expiration() {
return YEAR_IN_SECONDS;
}

This code snippet is compatible with both the standard WordPress login form and the login form included with the User Registration Add-On.

PHP based code snippets like this can be added to the theme functions.php file or a custom functions plugin.

Disabling Mobile Keyboard Input on Datepicker Fields

Disabling Mobile Keyboard Input on Datepicker Fields

This quick block of Javascript will allow you to disable keyboard input within Date fields. This snippet is helpful if you need to avoid the virtual keyboard from appearing within the datepicker.

Disabling Automatic Scrolling On Form Confirmations

Disabling Automatic Scrolling On Form Confirmations

Use the gform_confirmation_anchor FilterDisabling Automatic Scrolling On a Specific FormDisabling Automatic Scrolling On All Forms

When a form is submitted, the default behavior of Gravity Forms is to scroll to the confirmation message. In the vast majority of cases, this is the desired behavior, but in a few scenarios, you may want to disable this functionality.
Use the gform_confirmation_anchor Filter
Gravity Forms makes it incredibly easy to remove this functionality by providing an easy to use filter.
This filter will be used either within its own plugin (ideally) or within your theme』s functions.php file.
Note: Placing modifications within your own plugin is recommended simply because it makes your changes immune to theme updates. If placed within your theme, your changes could be overwritten by theme updates.
Disabling Automatic Scrolling On a Specific Form
To disable automatic scrolling on a specific form, use the gform_confirmation_anchor filter like so, replacing # with the form ID:
add_filter( 'gform_confirmation_anchor_#', '__return_false' );

Disabling Automatic Scrolling On All Forms
Disabling automatic scrolling on all forms is just as easy as disabling it on a specific form. Use the filter like the following:
add_filter( 'gform_confirmation_anchor', '__return_false' );

CSS Visual Guide and Design Overview

CSS Visual Guide and Design Overview

Element Relationships (HTML and PNG)Element NamingConfigurable ClassesForm Wrapper ClassesTheme & Markup ClassesLabel Position ClassesField Size ClassesCustom ClassesCSS Ready ClassesCSS Targeting Examples

Element Relationships (HTML and PNG)

We』ve put together a visual guide to the Gravity Forms CSS hierarchy to illustrate the structure of a form and the CSS class relationship.

You can access it on a few formats here:

View Visual CSS Guide (HTML Version) | Download Guide (png)

Element Naming

Gravity Forms are structured so that every element can be targeted and manipulated via CSS. Most elements share reusable class names to affect styling, and many elements have unique ID』s that you can use to target specific elements within the form. By using CSS inheritance, you can effectively style every element in your form.

All element ID』s are based on the unique form ID and then a field ID.For example:

#gform_wrapper_xx where 「xx」 is the form ID, or#field_xx_yyy where 「xx」 is the form ID and 「yyy」 is the field ID.

Configurable Classes

Form Wrapper Classes

Theme & Markup Classes

There are 2 classes applied to the form wrapper based on whether or not legacy mode is enabled for a form. The class .gravity-theme is applied to all forms that do no have legacy mode enabled. The class .gform_legacy_markup_wrapper is applied to all forms that have legacy mode enabled.

Label Position Classes

There are 3 label classes that are applied to the form wrapper based on the individual form settings, .top_label, .left_label and .right_label.

Other elements change positions, widths, etc. based on inheritance from these label classes.

Field Size Classes

For many of the individual fields, there are classes of .small, .medium and .large which are defined in the form admin by changing the field size setting.

Custom Classes

Finally, for most of the fields, the user can define additional class names with the Custom CSS Class setting in order to apply additional custom styles or to target elements for other types of manipulation.

CSS Ready Classes

Using Ready Classes, you can easily create more advanced alternative layouts for the fields in your forms. Essentially, Ready Classes are class names that you can add to the parent element surrounding each field to take advantage of pre-defined styles included in the default form stylesheet.

Note that the column and inline ready classes were deprecated with the improvements made to the form editor in Gravity Forms 2.5.

CSS Targeting Examples

This article contains a few basic usage examples for targeting each element, one that would be generic for all forms and then one (or two) that would be specific to a unique form ID. If you』re styling a specific form, you would simply view your source, find the form ID and replace the ID in these examples with your own.

Deprecation of the Rocketgenius Namespace for Gravity Forms 2.5

Deprecation of the Rocketgenius Namespace for Gravity Forms 2.5

SummaryAffected AreasAdditional updatesMoving Forward

Summary

The top-level Rocketgenius namespace is being replaced with Gravity_Forms. These changes may break third party add-ons using the old namespace, even though they may have tested fine in previous beta releases of Gravity Forms 2.5

These namespaces were introduced in Gravity Forms 2.5, and none of them existed in any previous release of Gravity Forms. As such, this change has the potential to affect beta testers only.

Affected Areas

Add-ons which are extending any class which previously had a Rocketgenius namespace will need to update those class references to Gravity_Forms.

These include:

RocketgeniusGravity_FormsSettings is now Gravity_FormsGravity_FormsSettingsSettingsRocketgeniusGravity_FormsFields, are all now Gravity_FormsGravity_FormsFieldsRocketgeniusGravity_FormsTranslationsPress_Updater is now Gravity_FormsGravity_FormsTranslationsPress_Updater

Additionally, if developers solutions are requiring any of the class files referenced above in their own add-ons, they』ll need to update those references, as well.

Additional updates

Changing the fully-qualified namespace for the new Settings class from RocketgeniusGravity_Forms to Gravity_FormsGravity_FormsSettings, because the Settings class file is in the settings subdirectory (thus, it now has the same namespace as the adjacent Fields class in the same directory.Renaming class files for Checkbox_And_Select and Text_And_Select to class-checkbox-and-select.php and class-text-and-select.php, respectively.Renaming the class file for TranslationsPress_Updater from class-t15s-updater.php to class-translationspress-updater.php, and updating associated require statements for that class file.

Moving Forward

This namespace update reflects the newly established standard for current and future Gravity Forms product development. Our expectation is that these namespaces will not change again. Any new classes which get added to Gravity Forms core or official Gravity Forms add-ons, will include the Gravity_Forms top-level namespace only.

Deprecation of the Gravity Forms Credit Card Field

Deprecation of the Gravity Forms Credit Card Field

NoticeDetailHow to Change Your Payment Collection MethodMore Help Needed?

Notice
The Gravity Forms Credit Card Field has been deprecated in the Stripe Add-On from version 3.4. Forms that are currently using this field will continue to work, however, it is not possible to add the field to new forms.
We recommend you migrate any solutions using this field so they use an alternative Stripe payment collection method.
Detail
This field displays inputs for the credit card details. Gravity Forms turns the field values into a token in the browser just before submission. It then passes the token along to Stripe』s servers for processing with a script that has been deprecated by Stripe. The last 4 digits of the card number are later stored in the entry details.
With this payment method, you (the website admin/owner) takes on the burden of the safe storage, handling and transmission of sensitive payment data. The Gravity Forms Credit Card field collection method is not SCA capable, and will complicate attempts to obtain PCI compliance.
This approach is considered the least secure option for Stripe Add-on payment collection, and is discouraged by Stripe.
Gravity Forms and Stripe recommend you migrate your solution away from the Gravity Forms Credit Card field to either of the other Stripe payment collection methods.
Deprecation will not affect existing forms already using this field.
How to Change Your Payment Collection Method
The payment option is contained within Stripe Add-On settings − refer to this article for details.
BE AWARE of the implications:
1. You are modifying a payment gateway. Test extensively! Try on a development sandbox first, or duplicate your form and test on a hidden page. Care is needed, and make sure you have a fallback plan. Nothing hurts more than a problem with the page that collects money!
1. Removing the credit card field will result in you losing any saved entry data already collected for that field. It holds only partial digits of the payment method, but be conscious of this.
1. If you choose to upgrade to Stripe Checkout, don』t forget to configure the Checkout options within your Stripe dashboard. This is handled outside of Gravity Forms.
More Help Needed?
If you have any additional questions, please contact our Support Team who will be happy to help.
List of relevant links:
Download official Stripe Add-On
Stripe Add-On Change Log
About Stripe Payment Collection methods
Support of SCA
About SCA
Stripe Security and PCI Compliance Validation

Deprecated Gravity Forms Database Tables

Deprecated Gravity Forms Database Tables

The following database tables have been deprecated as of Gravity Forms 2.3, and should not be utilized by any custom code or third-party plug-ins etc.

wp_rg_form
wp_rg_form_meta
wp_rg_form_view
wp_rg_incomplete_submissions
wp_rg_lead
wp_rg_lead_detail
wp_rg_lead_detail_long
wp_rg_lead_meta
wp_rg_lead_notes

For more detail on the Gravity Forms 2.3 upgrade process, refer to this article.

Deleting Cached Entry Data

Deleting Cached Entry Data

This snippet will allow the cached entry data for products to be deleted when viewing an entry. Note that the cached data should only be removed if absolutely necessary, as it will impact performance.
add_action( 'gform_entry_detail_content_before', function ( $form, $entry ) {
GFFormsModel::refresh_product_cache( $form, $entry );
}, 10, 2 );

Delete Entry Data after Submission

Delete Entry Data after Submission

By default, Gravity Forms was designed to record all data submitted to it, so there isn』t an override to stop Gravity Forms from storing entry data upon submission. The reason for this is the entry must be saved so the data is available when notifications are sent and feed based add-ons, like PayPal and User Registration, are processed.
That said, Gravity Forms 2.4 did introduce Personal Data Settings which include the ablity to enable automatic deletion of entries after a specified number of days.
Bear in mind when entries are deleted, files associated with the entry are also deleted. If you want to keep the files, use the gform_field_types_delete_files filter.
There are also a number of third-party add-ons which can be used to delete entries either as the form submission ends or at a scheduled date/time:

Gravity Flow
Entry Automation by ForGravity
Gravity Perks – Disable Entry Creation by Gravity Wiz
Gravity Forms Encrypted Fields by PluginOwl
Gravity Forms Utility by Gravity+
Wider Gravity Forms Stop Entries by Jonny Allbut

If you would prefer not to use one of the above solutions you can use custom code in the theme functions.php file or a custom functionality plugin that will wait until the data is recorded, and then go in and remove the entry that was just created. To do so, you would use the following code which works with Gravity Forms 1.8 and newer:
// Target submissions from form ID 1.
// Change gform_after_submission_1 to reflect your target form ID, or use gform_after_submission to target all forms.
add_action( 'gform_after_submission_1', 'remove_form_entry' );
function remove_form_entry( $entry ) {
GFAPI::delete_entry( $entry['id'] );
}

The following code is applicable to Gravity Forms 1.7 and earlier only.
add_action('gform_after_submission_1', 'remove_form_entry', 10, 2);
function remove_form_entry($entry, $form){
global $wpdb;

$lead_id = $entry['id'];
$lead_table = RGFormsModel::get_lead_table_name();
$lead_notes_table = RGFormsModel::get_lead_notes_table_name();
$lead_detail_table = RGFormsModel::get_lead_details_table_name();
$lead_detail_long_table = RGFormsModel::get_lead_details_long_table_name();

//Delete from detail long
$sql = $wpdb->prepare(" DELETE FROM $lead_detail_long_table
WHERE lead_detail_id IN(
SELECT id FROM $lead_detail_table WHERE lead_id=%d
)", $lead_id);
$wpdb->query($sql);

//Delete from lead details
$sql = $wpdb->prepare("DELETE FROM $lead_detail_table WHERE lead_id=%d", $lead_id);
$wpdb->query($sql);

//Delete from lead notes
$sql = $wpdb->prepare("DELETE FROM $lead_notes_table WHERE lead_id=%d", $lead_id);
$wpdb->query($sql);

//Delete from lead
$sql = $wpdb->prepare("DELETE FROM $lead_table WHERE id=%d", $lead_id);
$wpdb->query($sql);

}

The expected behavior would be that the entry would not exist in the Gravity Forms database tables after submission. If you are having issues with this script, please read up on our gform_after_submission hook.