GravityKit GravityMath - WordPress Plugin

Guide to GravityKit GravityMath: Gravity Forms entry calculations, reporting, and result validation

GravityKit GravityMath is not about describing yet another form. It is built for working with data already collected through Gravity Forms: calculating totals, averages, counts of matching entries, metrics for visible GravityView rows, or calculations inside an individual entry. In this guide, we will break down how to think about these calculations, where to place the shortcode, when to use the Calculation field in GravityView, how to validate the result, and which mistakes most often break a formula.

The core idea behind the plugin is simple: WordPress receives Gravity Forms entries, and GravityMath turns numeric fields, merge tags, filters, and mathematical functions into output values. In practice, though, setup rarely comes down to a single example. You need to choose the right scope, avoid mixing up the form ID and the View ID, decide how money values should be formatted, exclude hidden or irrelevant entries, and understand in advance where the formula is supposed to run - in an entry, in a form, in a visible list, or in a Custom Content field.

This guide is written for site owners, WordPress administrators, developers who do not want to build a separate reporting module, and specialists already using Gravity Forms for applications, orders, questionnaires, ratings, tabular reports, or internal workflows. We are not covering purchasing, licensing, or activation bypasses. This is strictly the working side of the plugin: preparation, installation, formulas, use cases, troubleshooting, and deciding when it is time to start testing.

What the plugin actually solves and where it fits in the Gravity Forms ecosystem

Gravity Forms can already handle calculations inside the form itself: for example, adding fields before submission, recalculating a price, or showing a total in a Number or Product field. That is useful when the user enters data and immediately sees the result inside the form. GravityKit GravityMath addresses a different layer of the problem - calculations based on existing entries, with results displayed in WordPress content, GravityView, or after form submission.

According to the official documentation, GravityMath revolves around the [gravitymath] shortcode. It can perform pure math without Gravity Forms, calculate data from a single entry, process all entries in a form, work with entries inside GravityView, and apply filters. In practice, that makes the plugin a bridge between your submission database and a clear number on the page: how many applications passed review, what the average course score is, what the total donation volume is, how many hours tasks took, or what the current total is after filtering a list.

It is important not to confuse GravityMath with a standard Gravity Forms calculation field. A regular calculation field is useful before or during form submission. GravityMath becomes useful after entries already exist, or when the result needs to appear outside the form: in a blog post, on a reporting page, in a widget, in GravityView, in a notification, or in a confirmation message. So the right question is not "can the plugin calculate," but "which layer of data do I need to calculate."

Common use cases where GravityMath is especially useful

The strongest use cases appear when a form has effectively become a small database. For example, a site collects training applications and needs to show the average score for a group. A project directory stores budget, status, and manager, while leadership needs a total for completed projects. A nonprofit collects volunteer submissions and wants to display the number of confirmed hours. An internal portal receives employee reports, and the department page should show a total or average based on a specific filter.

• Form-level summary metrics. Useful for totals, averages, minimums, maximums, and counts based on a numeric field.
• Calculations inside GravityView. Helpful when a View already displays a table, list, or cards and you need a total next to all or visible rows.
• Post-submission calculators. The plugin does not work inside the form as an interactive field, but it can display a calculation in the confirmation after submission.
• Calculations across multiple forms. Nested shortcodes let you build a single formula from data stored in different forms, if the entry structure allows it.
• Pure math in content. Sometimes you just need to display a formula on a page without referencing Gravity Forms, and the shortcode supports that.

When the plugin may not be a good fit

If you need a live calculation while the user is filling out the form, start by checking Gravity Forms' built-in calculations or dedicated add-ons for advanced in-form logic. GravityMath can be used in the confirmation after submission, but it is not a replacement for an interactive calculation field inside the form. If you need complex conditional logic inside the formula before submission, a more advanced formula editor with highlighting and conditional expressions, Gravity Forms Advanced Calculations by Gravity Wiz is likely a better fit. If the task is not about numbers but about charts, graphs, or visual analytics, GravityCharts is the more relevant option.

Another limitation involves precision. GravityMath documentation specifically warns that mathematical precision is based on PHP float behavior, so results with long decimal tails should not be treated like an accounting system with absolute precision. For reporting numbers, averages, rounding, and user-facing calculators, this is usually fine. For legally significant financial calculations, tax obligations, or payment documents, the business logic needs separate verification.

Feature map: shortcode, scope, filters, and the Calculation field

GravityMath has several working surfaces. The first is the [gravitymath] shortcode, which you can place in a post, page, block, widget, confirmation, notification, or GravityView Custom Content field. The second is the Calculation field in GravityView, which adds a calculated value to a specific entry and provides formatting options. The third is a set of utility hooks that a developer can use for targeted behavior changes when that is truly necessary.

To avoid confusion, it helps to separate calculations by data scope from the start. In the documentation, this is called scope. If no scope is specified, the shortcode evaluates a pure formula. If entry is specified, it uses values from a single entry. If form is specified, it processes all entries in the selected form. If view is specified, the calculation runs against the entries in the selected View. If visible is specified, the result is tied to the currently visible entries in the current View, although that mode comes with its own limitations.

Pure formula with no form data

The simplest version looks like a regular expression inside the shortcode. For example, the formula can add numbers, round a result, or use avg(), sum(), sqrt(), round(), ceil(), floor(), min(), max(), PI, or E. This mode is useful for static calculations, but in real projects it is more often used as a test: if a pure formula works but a data-driven formula does not, the problem is not the math itself, but the merge tag, scope, ID, or filter.

[gravitymath] ( 1200 + 350 ) / 2 [/gravitymath]

A pure formula does not require a form ID or entry ID. But that does not mean you can mix plain text with the formula inside the shortcode. The documentation is clear: the formula itself should contain math, not arbitrary text. Labels are better placed outside the shortcode, for example Total: [gravitymath] ... [/gravitymath].

Single-entry calculation

The scope="entry" mode is used when the formula pulls values from one specific entry. Outside a Custom Content field, you usually need the entry ID. Inside a GravityView row, you can omit id if the calculation refers to the current entry and is placed in a Custom Content field. This is a convenient way to display, for example, a commission for one application, an average score for a questionnaire, or a final price based on stored fields.

[gravitymath scope="entry" id="123"] {Number:5} * 0.15 [/gravitymath]

Make sure the merge tag points to a field from the same entry. If the field has been renamed, removed, or assigned a different ID, the friendly name inside curly braces will not save the formula. It is safer to pull merge tags directly from the Gravity Forms or GravityView interface rather than typing them from memory.

Calculation across all form entries

The scope="form" mode works with a form ID and lets you aggregate values across all matching entries. Fields use modifiers such as :sum, :avg, :min, :max, and :count. This is the mode most often used for a stats page: total amount, average score, number of submissions, minimum, or maximum based on a numeric field.

[gravitymath scope="form" id="9"] {Donation Amount:5:sum} [/gravitymath]

If you need to calculate only part of the dataset rather than all entries, use the filter parameter. It works with scope="form" and scope="view". In a filter, field IDs and actual saved values matter. For choice fields with separate labels and values, GravityMath looks for the value, not the visible label. That is one of the main reasons a formula can appear empty even when it looks correct.

Calculation inside GravityView

When you work with a View, there are more nuances. If the shortcode is meant to calculate across all entries in a specific View, use scope="view", the View ID, and, when enhanced security is enabled, the View secret. If the shortcode should calculate only the visible entries, use scope="visible". The documentation specifically notes that scope="visible" does not work with the DataTables layout, so this mode needs to be tested in the exact layout where it will be published.

View mode is especially useful when a visitor or administrator filters a list and the total should reflect the current selection. For example, an application table shows only confirmed events, and the top of the page should display the total hours. In that scenario, the formula becomes part of the reporting interface rather than just a number in an individual entry.

What to check before installation and first use

Preparing for GravityMath is not a long technical ritual. It is a data check. If forms are filled inconsistently, numeric fields use different formats, choice fields store unexpected values, and nobody knows the entry IDs, the plugin may install just fine, but the formulas will return empty or confusing results. That is why it is worth doing a quick audit before installation.

Check which data is actually numeric

For totals and averages, it is best to use Number, Product, Price, or other fields that Gravity Forms and GravityMath can safely interpret as numbers. A text field where users type things like "about 10," "10 hours," "10.5," or "$10" may look understandable to a person, but calculations need a predictable format. If a field stores a price, GravityMath documentation recommends using the :price modifier to convert the currency string into a numeric format.

Practical check: open several Gravity Forms entries and compare the actual values stored in the fields. If some users enter a period, others a comma, and others add units, normalize the form first or create a separate numeric field.

Save a map of form, View, and field IDs

GravityMath relies on IDs. The form name helps a person, but the shortcode works through id, field ID, View ID, and sometimes the View secret. Before you start configuring anything, make yourself a simple map: application form - ID 9, amount field - ID 5, status field - ID 7, reporting View - ID 27. That will save more time than trying to fix a formula based on a vague "no result" message.

Check where the result will be published

The same calculation can be displayed in different places: on a regular WordPress page, in a Gravity Forms confirmation, in a notification, in a widget, in a GravityView Custom Content field, or in a dedicated Calculation field. The publication location affects whether the current entry is available, the order in which merge tags are processed, whether a secret is required, and how caching behaves. For example, a calculation that should change when a View is filtered should not be moved to a static page with no connection to that View.

Separate public numbers from administrative ones

If the result is visible to site visitors, the formula needs to be understandable and safe in meaning: it should not expose internal KPIs, personal data, hidden totals, or fields that are not meant to be public. GravityMath outputs a numeric result, but the act of publishing that result can still reveal sensitive information. That may be fine for an internal dashboard, but not for a public-facing applications page.

Installation and first validation without overcomplicating it

Installing GravityKit GravityMath does not require a special architecture. Like other WordPress plugins, it is added through the admin panel, activated, and then used wherever WordPress processes shortcodes or where GravityView supports the appropriate field. But right after activation, do not start with the most complex formula. It is more reliable to validate the chain in small steps.

Minimal path after activation

1. Make sure Gravity Forms is active if the calculation is supposed to use form data.
2. If the calculation is needed inside a View, confirm that GravityView is active and that the correct View is selected.
3. Create a test WordPress page that is not linked from the menu and insert a pure formula: [gravitymath] 2 * 300 [/gravitymath].
4. Open the page in preview mode and confirm that the shortcode outputs a number rather than the shortcode text itself.
5. Only after that, add a simple calculation based on one form or one entry.

If the shortcode appears as plain text at the first step, the issue is not the formula. It means the publication area is not processing shortcodes, or the block or widget is outputting text without executing the shortcode. In that case, first change the test location: a normal WordPress post or page with a block that supports shortcodes is usually a better place to start.

Your first calculation using form data

For the first test, use the simplest field and the smallest possible scope. For example, a form with ID 9 and a numeric field with ID 5. Do not add filters, nested shortcodes, or formatting until you see the baseline result. Once a simple total works, then add decimals, format, filter, and other parameters.

[gravitymath scope="form" id="9"] {Amount:5:sum} [/gravitymath]

After publishing, compare the result with a manual check based on a few entries. You do not need to recalculate hundreds of rows by hand. It is enough to create a temporary form with 3 to 5 test entries where the totals are known in advance. If the formula works on a small sample, move it to real data.

How to roll back testing safely

The best rollback strategy is not to uninstall the plugin immediately, but to remove the shortcode from the public page or temporarily replace it with static text while you diagnose the issue. If the calculation is inserted in GravityView, temporarily disable the Custom Content field or create a copy of the View for testing. If you used a snippet added through Code Snippets or a child theme, disable that specific snippet. This way, you do not break other forms or lose data.

Shortcode configuration: parameters, formatting, and entry filtering

In practice, GravityMath configuration starts with the shortcode. The plugin does not have a single universal control panel where you can click "best settings." The best settings come from choosing the right parameters in the formula: scope, id, filter, decimals, format, default_value, notices, and correct merge tags. A mistake in one parameter often changes the meaning of the result more than it changes the look of the page.

Choosing scope as the primary decision

Start by answering which rows should be included in the calculation. If you need one entry, use entry. If you need the whole form, use form. If you need a specific GravityView, use view. If you need the currently filtered list, check visible, but keep layout limitations in mind. Do not start with filters until the scope is selected.

Formatting the result

The decimals parameter controls the number of digits after the decimal point. If the result is meant to show a percentage or an average score, 1 to 2 decimal places are usually enough. For entry counts, use decimals="0". If you need the raw number without local formatting, you can use format="raw". That is useful when the result is passed to another shortcode or used inside a more complex formula.

For money values, do not stop at visually adding a currency symbol. First make sure the field returns a number rather than a string that includes currency formatting. In GravityMath documentation, pricing fields are paired with the :price modifier. If you skip that modifier where the field stores a value with a currency symbol, the formula may not receive the numeric value you expect.

[gravitymath scope="form" id="9" decimals="2"] {Product Name (Price):28:price:sum} [/gravitymath]

Filters by value and date

The filter parameter lets you calculate only part of the entry set. The documentation describes a structure based on filter_N and op_N, where N corresponds to the field ID or meta key. Supported operations include is, isnot, contains, notcontains, lt, and gt. One important nuance: if a choice field uses separate values, the filter matches against the value, not the label.

[gravitymath scope="view" id="206" secret="abc123" filter="filter_1=approved&op_1=is"] {Amount:5:sum} [/gravitymath]

For dates, the documentation states support for the format configured in the form editor or the YYYY-MM-DD format. That is convenient for date-range reports, but it is not a full analytics system. If users type dates manually and the input is not validated, first make sure the entries are actually stored in a single consistent format.

Parameters for safe troubleshooting

The debug parameter helps expose errors, but it should not be left enabled on a public page. The notices parameter can display warnings to users if the formula returns no result or if the result may be inaccurate. During setup, that can be helpful. For final publication, it is better to think through a normal explanatory message next to the calculation.

Safe workflow: start with a test page using debug="true", validate the formula against real data, then disable debug and publish a short explanation for the user.

GravityView and the Calculation field: when to use the field and when to use a shortcode

One of the strengths of GravityKit GravityMath is how well it works alongside GravityView. But inside GravityView, there are two different approaches. The first is to place [gravitymath] in a Custom Content field or widget. The second is to add the dedicated Calculation field, which works at the level of the current entry and supports professional result formatting. These tools are not interchangeable.

When to choose the Calculation field

The Calculation field is the right choice when each View entry should have its own calculated value: commission, remaining balance, completion percentage, average score, tax, discount, or a total based on multiple fields in the same entry. The documentation makes it clear that this is an entry-scoped calculation. It uses values from the current entry and does not calculate totals across all rows in the View. In exchange, it offers settings for Number Format, Decimal Places, Show Thousands Separator, Prefix, and Suffix.

This approach reads well in a table or list: a calculated field appears next to the original fields and is formatted as a number, currency value, or percentage. For a site editor, that is simpler than inserting a shortcode into each row and manually managing the formatting.

When you need a shortcode in Custom Content

A shortcode is the right tool for a summary: a total across all rows, an average for visible entries, a counter of filtered submissions, a calculation across multiple forms, or a total in a report header. It is more flexible, but it requires more care. Inside a GravityView Custom Content field, merge tags are processed first and shortcodes run later. Because of that, formulas that reference another form can break: GravityView may replace the merge tags before GravityMath has a chance to process them.

The official documentation describes a workaround using tildes for cases where merge tags inside a Custom Content field need to be protected from early processing. The important idea is not to add code to every project, but to understand the cause: if a formula inside a View references another form, the merge tag processing order becomes critical.

/**
 * Allows ~Field:ID~ to be used inside a GravityMath shortcode.
 * Purpose: protect merge tags from another form from early GravityView processing.
 */
add_filter( 'gravityview/math/shortcode/before', function ( $formula ) {
    preg_match_all( '/~[^~]*?:(\d+(\.\d+)?|[a-z_]+)(:(.*?))?~/mi', $formula, $merge_tags, PREG_SET_ORDER );

    foreach ( $merge_tags as $merge_tag ) {
        $updated_merge_tag = str_replace( '~', '', $merge_tag[0] );
        $updated_merge_tag = sprintf( '{%s}', $updated_merge_tag );
        $formula = str_replace( $merge_tag[0], $updated_merge_tag, $formula );
    }

    return $formula;
} );

Add that kind of snippet only if this is your exact scenario: a GravityView Custom Content field, a calculation that references another form, and a conflict caused by processing order. The right place for it is a child theme or a trusted snippets plugin. After testing, disabling the snippet is easier than hunting for a change buried in the active theme files. Do not edit GravityMath, GravityView, or Gravity Forms plugin files directly.

How to choose between the two approaches

Keep one simple rule in mind. If the number belongs to the current View row, start with the Calculation field. If the number belongs to a set of rows, the current filter, another form, or the entire form, use a shortcode. If you need both, do not try to cram everything into a single visual block: show the row-level calculation in a column and place the summary total above or below the View.

Practical example: a donation report with total, average donation, and status filtering

Let us walk through a concrete example. A site has a donation form in Gravity Forms. It includes an amount field, a review status field, and a submission date. The administrator wants to display three numbers on a private page: the total amount of approved donations, the average approved donation amount, and the number of approved entries. If GravityView is in use, a table of entries and a summary can be displayed side by side.

Goal

The goal is to build a clear report without exporting data into spreadsheets: total approved donations, average amount, and entry count. The result will be placed on a private WordPress page or inside a page with GravityView. Public visitors should not see internal details if the report is intended only for staff.

Preparation

Create or review the form. Assume the form ID is 9. The amount field is ID 5. The status field is ID 7, where the value for the approved status is approved. Do not rely on the visible label "Approved" if the choice field value is different in the settings. For testing, add 3 to 5 entries with easy-to-check values, such as 100, 200, 300, and one unapproved payment that should not be included in the total.

Setup steps

1. Create a private WordPress test page.
2. First insert a simple total calculation across all entries without a filter and make sure it works.
3. Add the status filter and verify that the unapproved entry is excluded from the result.
4. Then add a separate average formula using the :avg modifier.
5. For the counter, use :count on a specific form field rather than the global {entry_count} inside a filtered shortcode.

<p>Total approved donations:
[gravitymath scope="form" id="9" decimals="2" filter="filter_7=approved&op_7=is"] {Amount:5:sum} [/gravitymath]</p>

<p>Average donation amount:
[gravitymath scope="form" id="9" decimals="2" filter="filter_7=approved&op_7=is"] {Amount:5:avg} [/gravitymath]</p>

<p>Number of approved entries:
[gravitymath scope="form" id="9" decimals="0" filter="filter_7=approved&op_7=is"] {Amount:5:count} [/gravitymath]</p>

Result validation

Compare the calculation against a manual table built from your test entries. If there are three approved entries worth 100, 200, and 300, the total should be 600, the average should be 200, and the count should be 3. Then add an entry with a status that should not appear in the report and make sure all three numbers stay the same. After that, change that entry's status to approved and confirm that the totals update.

A nuance that often breaks the report

If the status field label is "Approved" but the value is "approved," the filter must use the value. If you put the label into the shortcode, the result may come back empty. Another common mistake is using {entry_count} together with filter. GravityMath documentation explains that the global merge tag {entry_count} ignores the filter because Gravity Forms processes it before GravityMath applies the filter. For a filtered counter, use :count on a form field.

Calculations involving time, dates, prices, and multiple forms

After the baseline scenario is working, more specific tasks usually follow: calculating durations, handling prices, combining data from two forms, displaying a total for a date range, or showing a result in a confirmation message. The key here is not to expand the formula chaotically. It is better to validate each new layer separately: first the field, then the modifier, then the filter, then the nesting.

Time and duration

GravityMath supports duration calculations in the hh:mm:ss format, including fast, slow, and average values, but the official product page also notes a limitation: date-plus-time values are not treated like regular durations. If your use case involves work hours, stage completion times, or sports results, confirm the field format and the expected result type before you build the formula.

For durations, a manual check on a small sample is especially important. Add together a few test values where the final total is obvious, and only then move the formula to live entries. If the result needs to be displayed as decimal hours, such as 4.5 hours, define the conversion rule explicitly rather than mixing different formats in one field.

Prices and product fields

When working with prices, make sure the formula is actually receiving a number. Gravity Forms Product fields and Total fields have their own storage and formatting logic. Gravity Forms documentation states that the Total field cannot be used inside regular calculation fields, and GravityMath documentation separately calls out the :price modifier for price values. If the formula looks correct but does not calculate, remove the currency symbol first and inspect the raw stored value.

Do not use GravityMath as a substitute for a payment system. It can display a calculated total, but payments, taxes, invoices, and accounting documents require separate business validation. The plugin is a much better fit for a storefront calculator, a rough estimate, or a report based on stored amounts than for legally critical payment recalculation.

Multiple forms in one calculation

Nested shortcodes let you build a total from different forms. The documentation shows an approach where the outer [gravitymath] shortcode adds the results of inner [gravitymath2] and [gravitymath3] shortcodes. The key rule is that you cannot nest a shortcode inside itself when it uses the same name, because the closing tag will stop processing. That is why nested calculations use different shortcode names.

[gravitymath]
  [gravitymath2 scope="form" id="12"] {Support Questions:2:count} * 100 [/gravitymath2]
  +
  [gravitymath3 scope="form" id="4"] {VIP Support Requests:4:count} * 200 [/gravitymath3]
[/gravitymath]

Before publishing a formula like this, test each inner shortcode on its own. If both inner results are correct but the outer total does not work, the problem is most likely in the nesting syntax, extra text, quotation marks, or closing tags. If one inner result is empty, fix that one first.

Calculation after form submission

GravityMath can be used in a Gravity Forms confirmation. That is useful when the user submits data and then sees a calculated result: a preliminary estimate, an eligibility result, a score total, an approximate timeline, or ROI. But that is not the same as an interactive calculation before submission. If the user needs to see the number while filling out the form, use Gravity Forms' built-in calculations or a dedicated extension for advanced in-form calculations.

How to validate the result: from test entries to publication

A calculation without validation is risky because it can look convincing. A number on the page feels like a fact until it turns out that the filter included the wrong entries, the price was treated as a string, {entry_count} counted every entry instead of the filtered subset, or the View secret did not match. That is why you need a short but systematic validation process after configuration.

Validate against a controlled sample

Create 3 to 5 entries with known values in advance. For totals, use simple numbers. For averages, use a set where the average is easy to verify. For a filter, add one entry that should definitely be excluded. For prices, include values with cents and check the rounding. For counts, use a field that actually exists in the form rather than a global counter.

After each change to the formula, write the expected result next to the test page. This is not formal documentation, just a practical way to preserve the logic. If someone later changes a choice value or a field ID, the test page will quickly reveal exactly what broke.

Validate in the real output location

Open the result in the same place where it will actually be used. A shortcode on a normal page, in a form confirmation, and in a GravityView Custom Content field can behave differently because of context, merge tags, and processing order. If the total is supposed to change after View filtering, test it right next to the View and in the exact layout you plan to use.

Validate access permissions and caching

If the page is private, log in using the role that will actually use it. If the site uses caching, make sure the number is not being frozen on a page where it needs to change. For public pages with totals that rarely change, caching may be fine. For internal reports based on current applications, caching should be configured carefully or the report page should be excluded entirely.

Validate meaning, not just syntax

A formula can be syntactically correct and still answer the wrong question. For example, the total across all form entries is not the same as the total across the entries currently published in a View. The average across all applications is not the same as the average across approved applications. The count of filled values is not always the same as the number of entries if the field can be empty. So the final check should answer one question: "Does this number help someone make the right decision?"

Common GravityMath issues and calm troubleshooting

Most problems with GravityKit GravityMath are not caused by installation, but by data context. The formula is almost correct, but the scope is wrong, the field belongs to a different form, the filter is checking the label instead of the value, the View requires a secret, or merge tags inside a Custom Content field were processed too early. Below is a practical symptom map.

The page shows the shortcode itself

Symptom: instead of a number, the user sees text like [gravitymath] 2 * 300 [/gravitymath]. A likely cause is that the output location does not execute shortcodes, the wrong block was selected, or the shortcode was placed in a template where the WordPress filter is not applied. Start by testing a pure formula on a standard test page. If it works there, the problem is the placement, not GravityMath.

How to fix it: use a Shortcode block, a supported editor area, or a GravityView Custom Content field if the calculation needs to live inside a View. If the shortcode has been inserted into a theme template, do not start adding random PHP code. It is better to move the calculation into a supported area or have a developer add shortcode handling cleanly.

The result is empty or zero

Symptom: the formula shows no error, but the number is empty, zero, or clearly lower than expected. Common causes include an incorrect form, View, or field ID, a non-numeric value, a filter that matched no entries, a field hidden by conditional logic, or a choice value that does not match what is specified in the shortcode. Start by removing the filter and testing a simple total based on a single field.

How to fix it: verify the IDs, copy the merge tag again from the interface, temporarily enable diagnostic output on a test page, and then restore the filter. If this is a price field, check the :price modifier. If it is a count, use :count on a specific field rather than {entry_count} for a filtered set.

The filter is not being applied

Symptom: the total matches the full form total even though the shortcode includes a filter. The cause may be an incorrect field ID, the wrong operator, a label used instead of a value, or a merge tag that is processed before the filter runs. The documentation explicitly states that {entry_count} inside a filtered shortcode returns the total number of entries, not the filtered number.

How to fix it: for filtered entry counts, use {Field:7:count} or another specific field modifier. For choice fields, verify the saved value. For multiple conditions, make sure the numbers in filter_N and op_N match the intended fields.

GravityView shows the wrong result in Custom Content

Symptom: the calculation inside the View works for the current entry, but breaks when the shortcode references another form. The reason is processing order. GravityView can replace merge tags before GravityMath runs, especially inside a Custom Content field. The official documentation provides a workaround for this case using tildes and the gravityview/math/shortcode/before filter.

How to fix it: first confirm that the task truly requires referencing another form. If it does, use the documented workaround in a child theme or Code Snippets after testing it on a copy of the View. If the calculation only applies to the current entry, it is usually simpler to switch to the Calculation field and avoid unnecessary complexity.

View mode requires a secret

Symptom: a shortcode with scope="view" does not return the expected result even though the View ID is correct. GravityMath documentation notes that when enhanced security is enabled for the View, the shortcode requires a secret attribute containing the same secret code used by the View. This is not there to make things harder, but to control access to View data.

How to fix it: check the View settings and add secret where required. Do not publish the secret in tutorials, screenshots, or public tips. If the calculation is public and includes sensitive data, reconsider the entire publication approach.

Decimal numbers look wrong

Symptom: the result has an excessively long decimal tail, rounds differently than expected, or a decimal formula is not valid. GravityMath documentation states that precision is based on PHP float behavior, and decimal fractions must include a leading zero: 0.5, not .5. For public output, use decimals together with readable formatting.

When rollback is the better choice: if the calculation is used for legally significant money amounts, taxes, or payment obligations, do not try to solve the problem with a rounding parameter alone. Pull the public result back, verify the business rules, and if necessary move the financial logic into a specialized process.

Safe improvements without editing plugin files

GravityMath does not require you to edit WordPress core, Gravity Forms, GravityView, or the plugin itself. If you need extra control, use only documented hooks and small reversible snippets. But there is no reason to add code for cosmetic purposes. In most cases, choosing the correct scope, filter, and formatting is enough.

When a precision snippet makes sense

GravityMath documentation describes the gravityview/math/precision filter, which limits or changes the precision threshold of the result. This is not a magic switch for financial accuracy. It is a technical control for number output. If you just want to reduce noise from long decimal tails, it is usually easier to use decimals. The filter makes sense when you need to change the precision limit consistently across calculations on the site.

// Example: limit GravityMath precision to 14 digits.
// Add only to a child theme or a trusted snippets plugin.
add_filter( 'gravityview/math/precision', function() {
    return 14;
} );

Validation after adding it is straightforward: open a test page with a formula that previously returned a long result and compare it to the expected output. To roll back, disable the snippet. Do not edit GravityMath files, because a plugin update will overwrite the changes and make maintenance harder.

When it is better to avoid code

If the task is simply rounding, use decimals. If you need to add a label like "Total:" or "Average:", use text around the shortcode or the Prefix and Suffix settings in the Calculation field. If you need to change the visual appearance of the block, add CSS to the page container rather than interfering with the calculation. Code should be added only when the problem is documented and cannot be solved through settings.

When GravityKit GravityMath is the right choice

GravityKit GravityMath is worth using when your forms already collect data and the site needs a clear calculation layer on top of those entries. That could be a report, a KPI block, a total inside GravityView, a post-submission calculation, an average, a filtered sum, or a metric for the current selection. The plugin fits especially well in projects where Gravity Forms and GravityView already function as a lightweight database.

Before publishing, run through one short final checklist: confirm the form and field IDs, choose the correct scope, test the formula on a small set of entries, make sure the filter uses the value rather than the label, verify access permissions, and remove debug output from any public page. If all of that checks out, you can download the latest version of GravityKit GravityMath and test the plugin on a staging copy or a safe test section of the site.

If what you actually need is a calculation before form submission, complex conditional formulas in the form editor, or visual charts, do not force one tool to handle every job. Use GravityMath for entry-based calculations and reports, built-in Gravity Forms calculations for simple live totals, Gravity Forms Advanced Calculations for advanced in-form logic, and GravityCharts for visual analytics. That keeps the stack easier to understand, and the results easier to validate and maintain.