Author 诗语

rgempty()

DescriptionUsageParametersExamplesChecking for an empty array.Source Code

Description
Checks if an array or key within an array is empty.
Usage
rgempty( $name, $array );

Parameters

$name string
The array or key to be checked.

$array array
If checking if a key within an array is empty, this parameter contains your array. Default is $_POST.

Examples
Checking for an empty array.
// This would return _true_.
$name = array();
rgempty( $name );

// This would return _false_.
$name = array( 'something' );
rgempty( $name );

// This would return _true_ as the key assigned to _$name_ doesn't exist.
$name = 'empty_key';
$array = array(
'key1' => 'value1',
'key2' => 'value2',
'empty_key' => ''
);
rgempty( $name, $array );

Source Code
This function is located in gravityforms.php

Setting up a PayPal Checkout Compatible Form

PrerequisitesIntroductionCreate Your FormSummaryNotes

Prerequisites
See the Using the PayPal Checkout Add-On article.
Introduction
The next step in integrating the PayPal Checkout Add-On is to create the form you are going to use. This can include existing forms. To be compatible with the PayPal Checkout Add-On, your Gravity Form must contain:

One or more Product fields
The PayPal Field

Create Your Form

From the left-hand navigation menu of your WordPress admin dashboard, hover over Forms and click on New Form.
Enter a Form Title and Form Description. Click Create Form. Alternatively you can hover over Forms and click on Forms to choose an existing form from the list.
Add fields for capturing customer billing and/or delivery information. We included the Name, Address and Email fields to get basic information from customers, however, they are not required to use the add-on.

Add Pricing fields to your form and configure them as needed. In this example Product, Shipping, and Total fields serve as the Pricing fields.

Add the PayPal Field – Expand the Pricing Fields section and add the PayPal Field to your form. When using multiple add-ons, such as the Stripe Card field, conditional logic should be used to show/hide the field depending on the payment processor selected in another field such a Drop Down field. See the Setting Up Conditional Payments In Gravity Forms article for an example. Note: The PayPal Field is not compatible with the Gravity Forms Credit Card field.

If your form does not look exactly like the images above, don』t panic. Every form will vary depending on which fields were selected and what order they were added to the form. As long as you have pricing fields of some sort and the PayPal Field, your form is valid for integration.
Summary
Now that you have created your form visit the Configuring a Feed for the PayPal Checkout Add-On article for the next step in the integration process. This is a critical step. If the form does not have an active PayPal Checkout feed the PayPal Checkout will NOT process the form submission.
If you need help with creating forms, visit Creating a Form for more information.
Notes

When using Page fields to create a multi-page form, the PayPal Field should be located on the last page of the form.
If you delete the PayPal Field from your form, the PayPal Checkout feeds will automatically deactivate to prevent them from running during form submission, which as the field is missing, would cause a validation error due to PayPal being unable to capture the payment details.

Security Warning: merge tags as HTML attribute values

If your form confirmation is using a merge tag as a value for an HTML attribute, you may see the following warning:
Your confirmation message appears to contain a merge tag as the value for an HTML attribute. Depending on the attribute and field type, this might be a security risk.
Example:
Link
This can result in a Cross Site Scripting (XSS) vulnerability for most field types. The following field types are safe to use as values for HTML attributes: Calculation, Email, File Upload, Time.
Regardless of the field type, if you decide to continue, please ensure you enable confirmation sanitization using the gform_sanitize_confirmation_message filter. This will remove all potentially dangerous scripts and tags from your confirmation.

How to Set the Default Properties for a New Field

IntroductionThe SetDefaultValues_{$type} functionUsing get_form_editor_inline_script_on_page_render()Setting the default ChoicesSetting the default Inputs

Introduction
Historically it』s been possible to set the default properties for a new field by using the gform_editor_js_set_default_values hook to echo a custom case into the switch statement within the SetDefaultValues() function in js.php, however, it』s also been possible to define your own SetDefaultValues_{$type} function instead. In this article we will show how you can use that function in your new field which extends the GF_Field class.
The SetDefaultValues_{$type} function
Here』s what a basic SetDefaultValues_ function would look like, the function name ends with your field type, in this case the field type is simple. The function is passed the field object so you can set the default values of any of the properties, in this case we are setting the field label.
123function SetDefaultValues_simple(field) {    field.label = 'The Default Field Label Goes Here';}
See the Field Object article for the standard field properties.
Using get_form_editor_inline_script_on_page_render()
The GF_Field class includes the get_form_editor_inline_script_on_page_render() method which can be used to include scripts in the form editor. In this example we are assigning the value returned by the get_form_editor_field_title() method as the default label for new fields of this type.
1234567public function get_form_editor_inline_script_on_page_render() {     // set the default field label for the field    $script = sprintf( "function SetDefaultValues_%s(field) {field.label = '%s';}", $this->type, $this->get_form_editor_field_title() ) . PHP_EOL;     return $script;}
Setting the default Choices
You can use the Choice() function when defining the fields default choices.
1new Choice(text, value, price)
The value and price properties are optional, if a value is not specified the text will be assigned to the choice value.
Here』s an example showing how that can be used with the SetDefaultValues_ function.
1234function SetDefaultValues_simple(field) {    field.label = 'The Default Field Label Goes Here';    field.choices = [new Choice('Your First Choice'), new Choice('Your Second Choice'), new Choice('Your Third Choice')];}
Setting the default Inputs
You can use the Input() function when defining the fields default inputs.
1new Input(id, label)
The id is a string in the format {field_id}.{input_number}, starting with the input_number of 1. For example, the first input of field 5 would be 5.1. We also recommend skipping ids ending in zero, so you would skip 5.10, 5.20 etc.
Here』s an example showing how that can be used with the SetDefaultValues_ function.
1234function SetDefaultValues_simple(field) {    field.label = 'The Default Field Label Goes Here';    field.inputs = [new Input(field.id + '.1', 'Your First Choice'), new Input(field.id + '.2', 'Your Second Choice'), new Input(field.id + '.3', 'Your Third Choice')];}

Save and Continue Link CSS Selectors

ContainerAdditional InfoExamples

Container
The Save and Continue link is contained within the form footer.
Additional Info
For more information on the Save and Continue functionality, refer to the Save And Continue user guide article.
Examples

example: the form Save and Continue link – applies to all forms
body .gform_wrapper .gform_footer a.gform_save_link {border: 1px solid red}

example: the form Save and Continue link – applies just to form ID #1
body #gform_wrapper_1 .gform_footer a.gform_save_link {border: 1px solid red}

example: the form Save and Continue link – applies just to form ID #1 and save link in the first page of a multipage form
body #gform_wrapper_1 .gform_footer a#gform_save_1_2_link {border: 1px solid red}

Send Notifications on Payment Events

By default Gravity Forms only sends notifications for the form submission event, however, it is possible to define you own custom events.

Note: The ability to assign notifications to be sent on payment events is now a built-in feature of Gravity Forms Authorize.net Add-On 2.1.4+, Gravity Forms PayPal Standard Add-On 2.6+, and Gravity Forms Stripe Add-On 2.0+ when running Gravity Forms 1.9.12+. For those running these versions the following code snippets are no longer required.
The first step is to list the event in the event drop down on the edit notification page. You can do this using the gform_notification_events filter.
12345678910111213141516171819202122232425add_filter( 'gform_notification_events', function ( $notification_events, $form ) {    $has_stripe_feed            = function_exists( 'gf_stripe' ) ? gf_stripe()->get_feeds( $form['id'] ) : false;    $has_paypal_feed            = function_exists( 'gf_paypal' ) ? gf_paypal()->get_feeds( $form['id'] ) : false;    $has_paypalpaymentspro_feed = function_exists( 'gf_paypalpaymentspro' ) ? gf_paypalpaymentspro()->get_feeds( $form['id'] ) : false;    $has_authorizenet_feed      = function_exists( 'gf_authorizenet' ) ? gf_authorizenet()->get_feeds( $form['id'] ) : false;     if ( $has_stripe_feed || $has_paypal_feed || $has_paypalpaymentspro_feed || $has_authorizenet_feed ) {        $payment_events = array(            'complete_payment'          => __( 'Payment Completed', 'gravityforms' ),            'refund_payment'            => __( 'Payment Refunded', 'gravityforms' ),            'fail_payment'              => __( 'Payment Failed', 'gravityforms' ),            'add_pending_payment'       => __( 'Payment Pending', 'gravityforms' ),            'void_authorization'        => __( 'Authorization Voided', 'gravityforms' ),            'create_subscription'       => __( 'Subscription Created', 'gravityforms' ),            'cancel_subscription'       => __( 'Subscription Canceled', 'gravityforms' ),            'expire_subscription'       => __( 'Subscription Expired', 'gravityforms' ),            'add_subscription_payment'  => __( 'Subscription Payment Added', 'gravityforms' ),            'fail_subscription_payment' => __( 'Subscription Payment Failed', 'gravityforms' ),        );         return array_merge( $notification_events, $payment_events );    }     return $notification_events;}, 10, 2 );

Once you have added the events to the drop down you can then go and edit your notifications (or create new notifications) and assign them to your new events.
The events drop down only appears on the edit notification page when multiple notification events exist for the form, it will appear between the notification name and send to settings.
Assigning a notification to a custom event will prevent it being sent during submission. You will need to manually trigger the sending of the event notifications at the appropriate time. For payment related events we can use the gform_post_payment_action action hook and the GFAPI::send_notifications method.
1234add_action( 'gform_post_payment_action', function ( $entry, $action ) {    $form = GFAPI::get_form( $entry['form_id'] );    GFAPI::send_notifications( $form, $entry, rgar( $action, 'type' ) );}, 10, 2 );
The above code snippets should be placed in the functions.php file of your active theme.

Note: These snippets will only work if the form has a payment feed using the Stripe, PayPal Standard (min v2.0) or Authorize.net (v2.0) add-ons. Support has been added for PayPal Payments Pro (v2.0) add-on which is currently in development. The legacy PayPal Pro add-on and earlier versions of the previously mentioned add-ons are not supported.

rgexplode()

DescriptionUsageParametersExampleSource Code

Description
Explodes a string into an array of strings.
Usage
1rgexplode( $sep, $string, $count ),
Parameters

$sep string
The separator between items. Commonly, a comma is used.

$string string
The string of values to be placed within an array.

$count string
Determines the maximum number of items to be placed within the array.

Example
12345// Gets the first 5 values and places them into an array.$sep = ',';$string = 'item1,item2,item3,item4,item5,item6,item7,item8,item9';$count = 5;$items = rgexplode( $sep, $string, $count );
Source Code
This function is located in gravityforms.php

Setting Up A Sample Poll Form

ScenarioCreate Your FormImmediate ResultsNext Steps

Scenario

In this example, we will set up a Poll Form asking what the user』s favorite video game genre is.

Create Your Form

After installing and activating the Polls Add-On, you can add a Poll field to your form.

In your WordPress admin dashboard, go to New Form under the Forms navigation or choose an existing form from Edit Forms.Click on the Poll field under the Advanced Fields toolbox to add a Poll field to your form.Under Poll Question type 「What is your favorite game genre?」Configure your Poll Type as a Radio ButtonFor the Choices we will add FPS, RTS, and RPG.Let』s setup another Poll field with a Poll Question of 「What is your favorite game system and Choices of 「Xbox, Playstation, and Computer」. For both fields we will check the Enable 「other」 choice option to allow the user to add their own unique choice.Update your form.

Immediate Results

By default, the Poll results are displayed upon submission of the form. You can adjust how these results are displayed in the Poll Settings.

Let』s leave the settings as they are for now and click preview and submit the form. Your results should look something like the image below depending on your choices.

Next Steps

Now that your form is has been created and your results are displaying properly you can Add the Poll to your Site and View the Poll Results. Both of these topics are reviewed in the Using the Polls Add-On article.

Gravity Forms Security Whitepaper

OverviewExecutive SummaryAn Overview of Gravity FormsThe Gravity Forms Leadership TeamThe Gravity Forms Release CycleVersion Numbering and Security ReleasesVersion Backwards CompatibilityGravity Forms and Security2013 OWASP Top 10A1 – InjectionA2 – Broken Authentication and Session ManagementA3 – Cross Site Scripting (XSS)A4 – Insecure Direct Object ReferenceA5 – Security MisconfigurationA6 – Sensitive Data ExposureA7 – Missing Function Level Access ControlA8 – Cross Site Request Forgery (CSRF)A9 – Using Components with Known VulnerabilitiesA10 – Unvalidated Redirects and ForwardsFurther Security Risks and ConcernsXXE (XML eXternal Entity) processing attacksSSRF (Server Side Request Forgery) AttacksAppendixCore WordPress APIsDatabase APIHTTP APIPermissions and current user API

Learn more about Gravity Forms software security in this free white paper which is forked from the original security white paper for WordPress.
Overview
This document is an analysis and explanation of the Gravity Forms software development and its related security processes, as well as an examination of the inherent security built directly into the software. Decision makers evaluating Gravity Forms as a form design and management system or web application framework should use this document in their analysis and decision-making, and for developers to refer to it to familiarize themselves with the security components and best practices of the software.
The information in this document is up-to-date for the latest stable release of the software, Gravity Forms 1.9.4 at time of publication, but should be considered relevant also to the most recent versions of the software as backwards compatibility is a strong focus for the Gravity Forms development team. Specific security measures and changes will be noted as they have been added to the core software in specific releases. It is strongly encouraged to always be running the latest stable version of Gravity Forms to ensure the most secure experience possible.
Executive Summary
Gravity Forms is a dynamic open-source form management system which is used to power websites and web applications. It currently powers more than 1.5 million websites on the Internet. The usability and extensibility make it a popular and secure choice for websites of all sizes.
Since its inception in 2007, Gravity Forms has undergone continual hardening so its software can address and mitigate common security threats, including the Top 10 list identified by The Open Web Application Security Project (OWASP) as common security vulnerabilities, which are discussed in this document.
The Gravity Forms Development Team, in collaboration with the Gravity Forms Leadership Team, works to identify and resolve security issues in the software available for purchase at gravityforms.com, as well as recommending and documenting security best practices for third-party add-on and theme authors.
Site developers and administrators should pay particular attention to the correct use of the WordPress and Gravity Forms APIs and underlying server configuration which have been the source of common vulnerabilities, as well as ensuring all users employ strong passwords to access Gravity Forms.
An Overview of Gravity Forms
Gravity Forms is a commercial open source form management system (FMS). It is licensed under the General Public License (GPLv2 or later).
The Gravity Forms Leadership Team
Gravity Forms is developed by Rocketgenius Inc., run by a leadership team, and led by its co-founders Carl Hancock, Kevin Flahaut and Alex Cancado. The team governs all aspects of the project, including development, gravityforms.com, and community initiatives.
The Leadership Team has final authority on technical decisions, and lead architecture discussions and implementation efforts.
The Gravity Forms Release Cycle
Each Gravity Forms release cycle is led by one or more of the Gravity Forms developers. A release cycle usually lasts around 1 month from the initial scoping meeting to launch of the version.
A release cycle follows the following pattern:

Phase 1: Planning and securing team leads. This is done via chat using HipChat and Trello. The release lead discusses features for the next release of Gravity Forms. Gravity Forms developers get involved with that discussion. The release lead will identify tasks for each of the developers.
Phase 2: Development work begins. Regular chats are scheduled to ensure the development keeps moving forward.
Phase 3: Beta. Betas are released, and beta-testers are asked to start reporting bugs. No more commits for new enhancements or feature requests are carried out from this phase on. Third-party add-on and theme authors are encouraged to test their code against the upcoming changes.
Phase 4: Launch. Gravity Forms version is launched and made available on the Gravity Forms downloads page. Soon after it is made available to installations for automatic and background updates.

Version Numbering and Security Releases
A major Gravity Forms version is dictated by the first two sequences. For example, 3.5 is a major release, as is 1.6, 1.7, or 2.0. There isn』t a 「Gravity Forms 3」 or 「Gravity Forms 4」 and each major release is referred to by its numbering, e.g., 「Gravity Forms 1.9.」
Major releases may add new user features and developer APIs. Though typically in the software world, a 「major」 version means you can break backwards compatibility, Gravity Forms strives to never break backwards compatibility. Backwards compatibility is one of the project』s most important philosophies, with the aim of making updates much easier on users and developers alike.
A minor Gravity Forms version is dictated by the third sequence. Version 1.9.3 is a minor release, as is 1.9.3.1. A minor release is reserved for fixing security vulnerabilities and addressing critical bugs only. Since new versions of Gravity Forms are released so frequently — the aim is every 1 month for a major release, and minor releases happen as needed — there is only a need for major and minor releases.
Version Backwards Compatibility
The Gravity Forms team has a strong commitment to backwards compatibility. This commitment means that whenever possible add-ons, themes, plugins, and custom code continues to function when Gravity Forms is updated, encouraging site owners to keep their Gravity Forms version updated to the latest secure release.
Gravity Forms and Security
The Gravity Forms Development Team often collaborates with security specialists to address issues in common dependencies, such as resolving the issues file upload field in versions up to 1.8.19
The Gravity Forms Leadership Team believes in Responsible Disclosure by alerting the development team immediately of any potential vulnerabilities. Potential security vulnerabilities can be signaled to the development team directly via the email address: [email protected]. The Development Team communicates amongst itself via a private email list, and HipChat and works on a walled-off, private repository for tracking, testing, and fixing bugs and security problems.
Each security report is acknowledged upon receipt, and the team works to verify the vulnerability and determine its severity. If confirmed, the development team then plans for a patch to fix the problem which can be committed to an upcoming release of the Gravity Forms software or it can be pushed as an immediate security release, depending on the severity of the issue.
For every release, an announcement is published by the Gravity Forms Leadership Team to the Gravity Forms blog listing the changes. Details of the vulnerability will be made available to trusted parties on request. Credit for the responsible disclosure of a vulnerability is given in the announcement to encourage and reinforce continued responsible reporting in the future.
Administrators of the Gravity Forms software see a notification on their site dashboard to upgrade when a new release is available. If administrators have automatic background updates enabled, Gravity Forms will be updated automatically.
Starting with version 1.9, Gravity Forms introduced automated background updates for all minor releases, such as 1.9.3 and 1.9.4. The Gravity Forms development team can identify, fix, and push out automated security enhancements for Gravity Forms without the site owner needing to do anything on their end, and the security update will install automatically. This is enabled by default on all new installations from version 1.9.2 onward.
Individual site owners can opt to remove automatic background updates through a simple change in the Gravity Forms settings or WordPress configuration file, but keeping the functionality is strongly recommended by the development team, as well as running the latest stable release of Gravity Forms.
2013 OWASP Top 10
The Open Web Application Security Project (OWASP) is an online community dedicated to web application security. The OWASP Top 10 list focuses on identifying the most serious application security risks for a broad array of organizations. The Top 10 items are selected and prioritized in combination with consensus estimates of exploitability, detectability, and impact estimates.
The following sections discuss the APIs, resources, and policies that Gravity Forms uses to strengthen the core software and 3rd party plugins and themes against these potential risks.
A1 – Injection
There is a set of functions and APIs available in WordPress which Gravity Forms developers use in making sure unauthorized code cannot be injected, and help them validate and sanitize data. Best practices and documentation are available on how to use these APIs to protect, validate, or sanitize input and output data in HTML, URLs, HTTP headers, and when interacting with the database and filesystem. Administrators and Form Editors can also further restrict the types of file which can be uploaded via filters and settings.
A2 – Broken Authentication and Session Management
WordPress core software manages user accounts and authentication and details such as the user ID, name, and password are managed on the server-side, as well as the authentication cookies. Passwords are protected in the database using standard salting and stretching techniques. Existing sessions are destroyed upon logout for versions of WordPress after 4.0.
Gravity Forms utilizes WordPress authentication for session management alongside a simple implementation of OAuth 1 with HMAC-SHA1 signatures which is used by external clients for session-less connections to the Gravity Forms API.
A3 – Cross Site Scripting (XSS)
WordPress provides a range of functions which help Gravity Forms developers ensure that user-supplied data is safe. Trusted users, that is Administrators on a single WordPress installation, and site administrators in WordPress Multisite and users with the permission to edit forms, can publish unfiltered HTML or JavaScript as they need to, such as inside a form confirmation or field label. Untrusted users and user-submitted content is filtered by default to remove dangerous entities by escaping output and stripping tags as appropriate depending on the context.
A4 – Insecure Direct Object Reference
Gravity Forms often provides direct object reference, such as unique numeric identifiers of forms or entries. While these identifiers disclose direct system information, Gravity Forms』 rich permissions and access control system prevent unauthorized requests.
A5 – Security Misconfiguration
The majority of the WordPress and Gravity Forms security configuration operations are limited to a single authorized administrator. Default settings for Gravity Forms are continually evaluated at the development team level, and the Gravity Forms development team provides documentation and best practices to tighten security for server configuration for running Gravity Forms on a WordPress site.
A6 – Sensitive Data Exposure
WordPress user account passwords are salted and hashed based on the Portable PHP Password Hashing Framework. WordPress』 permission system is used to control access to private information such as entry details. Gravity Forms provides functions to help developers enforce authorization and also encourages the use of these functions throughout the documentation including examples of best practices.
A7 – Missing Function Level Access Control
Gravity Forms checks for proper authorization and permissions for any function level access requests prior to the action being executed. Access or visualization of administrative URLs, menus, and pages without proper authentication is tightly integrated with the authentication system to prevent access from unauthorized users.
A8 – Cross Site Request Forgery (CSRF)
WordPress uses cryptographic tokens, called nonces, to validate intent of action requests from authorized users to protect against potential CSRF threats. WordPress provides an API for the generation of these tokens to create and verify unique and temporary tokens, and the token is limited to a specific user, a specific action, a specific object, and a specific time period, which can be added to forms and URLs as needed. Additionally, all nonces are invalidated upon logout.
Gravity Forms utilizes this WordPress API to protect against potential CSRF threats.
A9 – Using Components with Known Vulnerabilities
The Gravity Forms development team closely monitors the few included libraries and frameworks Gravity Forms integrates with for core functionality.
If necessary, the development team may decide to fork or replace critical external components.
A10 – Unvalidated Redirects and Forwards
WordPress』 internal access control and authentication system will protect against attempts to direct users to unwanted destinations or automatic redirects. This functionality is also made available to plugin developers via an API, wp_safe_redirect().
Gravity Forms utilizes wp_safe_redirect().
Further Security Risks and Concerns
XXE (XML eXternal Entity) processing attacks
When processing XML, WordPress and Gravity Forms disable the loading of custom XML entities to prevent both External Entity and Entity Expansion attacks. Beyond PHP』s core functionality, Gravity Forms does not provide additional secure XML processing APIs for add-on authors.
SSRF (Server Side Request Forgery) Attacks
HTTP requests issued by WordPress are filtered to prevent access to loopback and private IP addresses. Additionally, access is only allowed to certain standard HTTP ports.
Gravity Forms uses the WordPress HTTP API for all HTTP requests.
Appendix
Core WordPress APIs
The WordPress Core Application Programming Interface (API) is comprised of several individual APIs, each one covering the functions involved in, and use of, a given set of functionality. Together, these form the project interface which allows plugins and themes to interact with, alter, and extend WordPress core functionality safely and securely.
While each WordPress API provides best practices and standardized ways to interact with and extend WordPress core software, the following WordPress APIs are the most pertinent to enforcing and hardening WordPress security:
Database API
The Database API, added in WordPress 0.71, provides the correct method for accessing data as named values which are stored in the database layer.
Gravity Forms always utilizes the Database API to access the database layer.
HTTP API
The HTTP API, added in WordPress 2.728 and extended further in WordPress 2.8, standardizes the HTTP requests for WordPress. The API handles cookies, gzip encoding and decoding, chunk decoding (if HTTP 1.1), and various other HTTP protocol implementations. The API standardizes requests, tests each method prior to sending, and, based on your server configuration, uses the appropriate method to make the request.
Gravity Forms utilizes the HTTP API for all HTTP requests.
Permissions and current user API
The permissions and current user API is a set of functions which helps verify the current user』s permissions and authority to perform any task or operation being requested, and can protect further against unauthorized users accessing or performing functions beyond their permitted capabilities.
Gravity Forms utilizes the permissions and user API to protect against unauthorized access.

Set Tabindex

Having an issue where pressing tab on your keyboard brings your user to another form on your page? That is because Gravity Forms assumes its tabindex values, and you can have overlap. You need to change the tabindex on your forms so that they work as expected.
There are multiple ways to set your tabindex in Gravity Forms.
Embed Code
In your embed code in Gravity Forms, you can set the initial tabindex value of the first field. Gravity Forms will then auto-increment the value from that starting number.
[gravityform id="1" title="false" description="false" tabindex="10"]

Using this code, you can expect the first form element to be later in the tab order. If you have used tabindex one through nine, then the first element would be the tenth tab selection.
Widget
Forms that are in widgets have a control option for tabindex. Change the number based on where you want it to appear in order. If you change it to a number higher than the number of fields on any other form, then it you will notice that it will only tab over to your widget based form after all other form fields.
Code
We have a filter called gform_tabindex that allows you to set the tabindex of all forms or a single form using PHP.
add_filter( 'gform_tabindex', 'change_tabindex' , 10, 2 );
function change_tabindex( $tabindex, $form ) {
return 10;
}

Similar to the embed code version, except this would set all forms to have a starting tabindex of ten.