Gravity SMTP 2.3.3 can use a single license key constant shared with Gravity Forms core. On multisite or managed hosting, centralizing the key can simplify updates but may expose it through lower-privilege settings pages, debug output, support bundles, deployment logs, configuration repositories, or copied staging environments.
Use this for WordPress multisite, agency fleets, container deployments, infrastructure-as-code repositories, managed hosts, staging clones, and teams with delegated site administrators.
Quick answer
Define the shared key in the narrowest protected environment layer supported by the deployment, not in a theme, public repository, or database copied to clients. Test network administrator, site administrator, editor, support role, command-line, REST, debug log, Site Health export, support bundle, and failed-update screens. Confirm both Gravity Forms and Gravity SMTP can validate updates while no unauthorized role can recover the value. Document rotation so replacing the shared key does not leave one plugin on an old cached value.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Network admin | License status | Status visible, key protected |
| Site admin | Direct settings URL | No secret exposure |
| Support bundle | Export diagnostics | Value redacted |
| Rotation | Replace constant | Both plugins refresh |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Choose one protected secret source | Record hosting model, multisite state, configuration source, file permissions, deployment logs, secret manager, Gravity Forms and SMTP versions, license screens, and role matrix. | Both plugins read the intended shared constant and show valid update status. |
| Map every role and output surface | Search protected configuration, database options, generated support bundles, Site Health exports, PHP error output, shell history, build artifacts, backups, and repositories for the test key marker. | No lower-privilege page, response, log, export, repository, or support bundle reveals the full value. |
| Verify both plugin update paths | Test network admin, site admin, custom support role, editor, unauthenticated request, WP-CLI, REST, and a failed license validation on a cloned staging domain. | Rotation updates both plugins without lingering cached or database copies. |
| Rotate a marked test value | Rotate to a marked replacement, clear only relevant caches, and compare both plugins' update status, scheduled checks, remote validation, and old-key references. | Staging, local, backup, and disaster-recovery environments follow the documented license handling policy. |
What to check first
- Record hosting model, multisite state, configuration source, file permissions, deployment logs, secret manager, Gravity Forms and SMTP versions, license screens, and role matrix.
- Search protected configuration, database options, generated support bundles, Site Health exports, PHP error output, shell history, build artifacts, backups, and repositories for the test key marker.
- Test network admin, site admin, custom support role, editor, unauthenticated request, WP-CLI, REST, and a failed license validation on a cloned staging domain.
- Rotate to a marked replacement, clear only relevant caches, and compare both plugins' update status, scheduled checks, remote validation, and old-key references.
- Verify staging and local environments use environment-specific policy and cannot send production keys in screenshots, tickets, telemetry, or vendor support uploads.
Field notes
- Write the pass condition before changing anything. A repeatable synthetic fixture makes the before and after comparison useful.
- Keep exact versions and UTC timestamps because scheduled jobs, caches, retries, and background processing can change the evidence.
- Check the public experience and the stored server-side result. Admin previews and isolated API calls do not prove the whole workflow.
- Repeat the test after the relevant cache, queue, scheduled action, webhook, and observation window has finished.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
# Keep the real value in a protected environment source.
define( 'GF_LICENSE_KEY', getenv( 'GRAVITY_LICENSE_KEY' ) );
# Never print the environment value during health checks.
wp plugin status gravityforms gravitysmtp
Why this usually happens
- A masked field still embeds the full value in page source or an API response.
- Site administrators inherit a diagnostic capability intended only for network administrators.
- Deployment tooling prints configuration values during substitution or failure.
- A staging clone continues using the production key after the constant moves out of the database.
Decision rule
Centralize the key only when both plugins work, unauthorized users and exports cannot reveal it, staging follows a written policy, and rotation replaces all old references predictably.
Production verification checklist
- Both plugins read the intended shared constant and show valid update status.
- No lower-privilege page, response, log, export, repository, or support bundle reveals the full value.
- Rotation updates both plugins without lingering cached or database copies.
- Staging, local, backup, and disaster-recovery environments follow the documented license handling policy.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Choose one protected secret source
- Map every role and output surface
- Verify both plugin update paths
- Rotate a marked test value
- Remove old copies and logs
Mistakes to avoid
- Changing production before recording exact versions, UTC time, the affected fixture, current behavior, and a tested rollback point.
- Accepting one successful admin screen while the public page, stored record, API response, accessibility tree, queue, email, or downstream system remains unchecked.
- Testing only as an administrator instead of the role, browser, device, locale, network state, and failure path that a real customer reaches.
- Leaving broad credentials, debug logs, temporary filters, synthetic records, or recovery code active after verification.
Questions teams ask during testing
Should I test this on production?
Use production for read-only evidence first. Reproduce the change on staging with a current data shape, theme, extensions, cache, and browser mix. If a production canary is necessary, make it reversible, identifiable, monitored, and unable to charge a customer or expose personal data.
How do I rule out a cache artifact?
Record the origin response, purge only affected paths, and repeat in private and normal sessions. Compare stored data and server logs with the visible page. A cache hit is useful evidence only when you know which version it contains.
What belongs in the evidence packet?
Keep UTC time, exact versions, fixture ID, role, browser, expected result, actual result, relevant response or log lines, change made, rollback point, owner, and final verification. Redact passwords, tokens, personal data, and private URLs.
When is the test complete?
Close it when the main path and important failure branches pass, records reconcile across systems, accessibility and mobile checks are complete, temporary changes are removed, and monitoring covers the next update or business cycle.
What to tell the client or owner
Give the owner a short packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key evidence, change made, rollback point, unresolved risk, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP audit WordPress secrets.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references