The Gravity Forms short code: placing a form where people will find it

A form exists in the Gravity Forms admin and now it has to appear somewhere a visitor will actually reach. The block editor will insert it for you, but the block hides the settings, and the moment the form has to sit in a footer widget, a page builder module, a theme template, or inside another form's confirmation message, the block stops being an option. That is when the short code becomes the thing to learn, and the reason the query gets typed at all.

The short code is a small piece of text with a handful of named parameters. There are only eight of them, all optional except the form ID. Learning what each one does takes a few minutes and removes most of the guesswork about why a form looks wrong on one page and right on another.

What the short code is, and when the block is enough

Gravity Forms registers a WordPress short code called gravityform. WordPress expands it when the page loads and prints the form markup in its place. The minimum version is the form ID and nothing else:

[gravityform id="1"]

The official documentation gives a fuller example with most of the parameters in play:

[gravityform id="1" title="false" description="false" ajax="true" tabindex="49" field_values="check=First Choice,Second Choice" theme="orbital"]

If the page is a normal post or page in the block editor, the Gravity Forms block does the same job with a dropdown, and there is no reason to hand-write anything. The block writes the settings into block attributes rather than visible text, which is fine until you need to copy the same configuration to five pages or explain to someone else what is set.

The short code earns its place in the cases the block cannot reach. A classic text widget in a sidebar or footer. A page builder that accepts short codes inside a text module but has no Gravity Forms integration. A custom post template where the form has to render below the content. A confirmation message on another form. A custom email or a WooCommerce product description. In all of those the short code is the only route, and knowing the parameters is the difference between a form that fits and a form that has a stray heading and a broken tab order.

There is one more place worth knowing about inside the block editor itself. WordPress ships a Shortcode block, filed under the Widgets category in the block inserter. Paste the short code into that block and it behaves exactly as it would in the classic editor, which is the easiest way to use hand-written parameters on a page that is otherwise built with blocks.

The parameters, and what each one changes

Every parameter except id is optional, and the defaults are not always what a page needs. The table below lists what the current documentation states.

Two of these cause more trouble than the rest.

title and description

Both default to true, so a form dropped into a page that already has an H1 and an intro paragraph will print its title and description again. Setting title="false" description="false" is close to a habit worth forming, and it is why most hand-written short codes in the wild carry both.

tabindex

The default is 0, and 0 means something specific here: Gravity Forms leaves the tabindex attribute off the field markup entirely, so the browser works out the tab order from the document. That is usually the behaviour you want. Setting a starting number is for the case where two forms, or a form and other interactive elements, sit on one page and the keyboard order comes out wrong. Pick a starting number above anything else on the page and the form's fields follow each other in sequence.

The field_values parameter takes name and value pairs and only works on fields where Allow field to be populated dynamically has been switched on in the field settings, with a parameter name filled in. Field names are case sensitive, which accounts for a good share of the cases where a value silently fails to appear.

The short codes that arrive with add-ons

gravityform is not the only short code in play. Add-ons extend it with an action parameter, and the one people meet first belongs to the User Registration Add-On, which prints a login form:

[gravityform action="login" description="false" logged_in_message="Yay! You are logged in!" registration_link_text="Register for my super awesome site" forgot_password_text="Stop forgetting your password" theme="orbital" /]

Three details matter here. The short code does nothing unless the User Registration Add-On is installed, so a bare action="login" on a site without it prints nothing at all. The add-on is included with the Elite licence only, which puts a login form behind the $259 per year tier rather than the $59 one. And legacy markup is no longer supported on the login form, so styling is controlled through theme rather than through the older CSS classes.

The same pattern applies elsewhere. Other plugins can register their own actions on the gravityform short code, which is why a short code copied from a forum post sometimes does nothing on a site that looks identical. The first check is always whether the add-on that defines that action is actually present and active.

Where the short code can go, and where it will not run

WordPress expands short codes in post and page content, in widgets that run content through the short code parser, and anywhere a developer has called do_shortcode(). It does not expand them in places that print raw text. A short code pasted into a page title, a menu label, a category description, or a plain text email will appear on screen as literal square brackets.

Theme template files are the common sticking point. A short code written directly into a template file is text in a PHP file, not content, so nothing expands it. Wrapping it in do_shortcode() is the documented route, and it is a one-line change in the template. Some page builders parse short codes inside their own text modules and some do not, which is worth testing with any short code before assuming Gravity Forms is at fault.

One quieter constraint: a form can be embedded more than once on a page, but two copies of the same form on one page share field IDs and can confuse both the tab order and any JavaScript keyed to those IDs. If a page genuinely needs the same questions twice, duplicating the form so each copy has its own ID avoids that class of problem entirely.

When the form appears but does not behave

Four failures account for most of the time lost here, and the documentation names all four.

The form does not exist. The message reads "Oops! We could not locate your form." That is a form ID in the short code that has no matching form in the admin, which usually means a form was rebuilt, or the site was copied from staging where the IDs were different. The form list in the admin shows the real IDs.

AJAX submission does nothing. With ajax="true" the submit goes through JavaScript. If another script on the page throws an error before the handler runs, the button does nothing at all and the page gives no clue. The browser console is where that shows up, and the fastest test is to drop ajax and see whether a normal page-reload submit works.

Pre-filled values do not appear. Check the parameter name spelling against the field setting, case included, and confirm dynamic population is switched on for that field.

Styles do not apply. The styles parameter takes JSON. Invalid JSON is ignored silently rather than reported, so a missing quote or a trailing comma produces a form with no custom styling and no error message.

Chaining two forms, and why the confirmation type matters

One legitimately useful trick is putting a second form's short code inside the first form's confirmation, so a visitor finishes one form and the next appears in its place. The documented setup has a few conditions that are easy to miss.

The second form needs a Redirect or Page confirmation. With a Text confirmation on the second form, submitting it reloads the first form instead of showing a confirmation, which looks like the whole chain has failed. The documentation describes an AJAX-based workaround if a Text confirmation is genuinely required.

The first form's own page should leave ajax off or set it to false. Data carries across through field_values on the confirmation short code, and the receiving fields need dynamic population turned on with matching parameter names. Styling also leaks between the two, so setting theme explicitly on the second form's short code to match the first is part of the setup rather than a refinement.

It works, and it is worth knowing. It is also a good marker of where short codes stop being the right tool. Chaining forms is usually an attempt to model a process with several steps, and a process with several steps needs somewhere to record which step each person has reached. A short code puts the questions on the screen. It has nothing to say about the twelve people whose answers are now sitting in an entries list waiting for someone to act on them.

What the short code does not touch

Once the form renders correctly on the right page, the work shifts and none of it is a short code problem. Entries arrive in the Gravity Forms entries list and a notification email goes out. From there, whoever is handling the responses is reading an inbox, opening the entries list, and keeping track in their head or in a spreadsheet of who has been replied to and who has not.

That is where the cost sits on most sites, and it is worth knowing what the platform charges to reduce it. A Gravity Forms Basic licence is $59 per year for one site, Pro is $159 per year for three sites, and Elite is $259 per year for unlimited sites. Add-ons are split across those tiers: Dropbox, Slack, Stripe and Zapier come with Pro, while User Registration, Webhooks, Partial Entries and Conversational Forms are Elite only. Third-party add-ons are priced separately again. Gravity Wiz, whose perks cover a lot of the gaps people run into, charges $59 per year for one perk on one site, $169 per year for three perks on three sites, and $299 per year for everything on unlimited sites.

None of that buys an owner field, a status per response, or a record of what was sent to whom. Those are the things that stop two people replying to the same enquiry, and they are the reason some teams keep the WordPress form for the front end and move the handling elsewhere. A form tool with response management treats the submission as the start of a case rather than the end of one, giving each response an owner and a stage and keeping the reply on the same screen as the answers. The use cases page shows the shape that takes for applications, enquiries and event sign-ups.

What to change first

Rewrite the short codes you have with title="false" description="false" and an explicit theme, and confirm every form ID matches a form that still exists. Then look at what happens after submission: if the answer involves an inbox and a spreadsheet, the next fix is not a parameter. Give the responses an owner and a status in one place, which is what the demo shows without any setup.

Q1. Where do I find the form ID for the short code?

The form list in the Gravity Forms admin shows the ID for each form next to its name. The ID also appears in the URL when you open a form for editing. If the short code references an ID that does not exist, the page prints "Oops! We could not locate your form."

Q2. Why is my Gravity Forms short code showing as plain text on the page?

The short code is somewhere WordPress does not expand short codes, such as a theme template file, a page title, or a text field that prints raw output. In a template file, wrap it in do_shortcode(). In a page builder, check whether that module parses short codes at all.

Q3. Should I use ajax="true" or leave it off?

AJAX avoids a page reload, which is nicer when the form sits mid-page or inside a lightbox. It also means a JavaScript error elsewhere on the page can stop submission with no visible message. If a form has stopped submitting, removing ajax is a quick way to find out whether that is the cause.

Q4. Can I put two different forms on the same page with short codes?

Yes. Two short codes with different form IDs work on one page. Set tabindex on at least one of them so the keyboard order is predictable, and set theme on both so one form's styling does not affect the other. Embedding the same form twice is best avoided, since both copies share field IDs.

Q5. Does the short code work in a sidebar widget?

Yes, in a widget that runs its content through the short code parser, which covers the standard text and custom HTML widgets in most themes. Set title="false" so the form title does not duplicate the widget title, and keep sidebar forms short, since a long form in a narrow column is rarely completed.