Quick answer
A read-only Gravity Forms license field can be intentional when GF_LICENSE_KEY is defined in configuration. Identify the source of that constant before editing the database or reinstalling the plugin. Also check the installed build: the 3.1.1.2 notes document an exception for an expired GoDaddy starter license.
Distinguish editing from validation
First record the symptom precisely. Is the field disabled, does a replacement fail validation, or is the key valid but updates unavailable? Those are different problems. A locked input does not automatically mean that the license expired or that a browser script failed.
Record the Gravity Forms version and the status shown in settings without exposing the key. Capture a redacted screenshot if needed. Do not send the full configuration file to support because it may also contain database credentials and other unrelated secrets.
Find the configuration owner
Ask the site maintainer whether the license is defined in wp-config.php, supplied by a deployment process, or managed by the hosting provider. The important result is the source and responsible owner. A managed setting may be restored automatically after you manually change a local file.
Check staging and production separately. A migration can leave one environment with a host-provided key and another with an agency key. Do not assume that changing the database value on one site changes every environment or supersedes a configuration constant everywhere.
Apply the current precedence rules
The current documentation says that a configured license key can make the settings field read-only. The 3.1.1 release also describes checking the constant before the database value. Treat the visible UI as a consequence of that precedence, not a reason to remove safeguards from the page.
There is an important version-specific exception: 3.1.1.2 allows editing when GoDaddy defines an expired starter key. Check the exact installed build and hosting situation before advising that every constant-defined key is permanently uneditable. Do not generalize that exception to other hosting providers or every invalid key.
Choose an authorized correction
If the host manages the key, use its documented replacement or support process. If the deployment owns it, update the approved secret or configuration source through the normal release workflow. If the site should use the saved settings value instead, have the maintainer review how to remove the conflicting definition safely.
Do not use a public issue, command history, or source-control commit to transfer the replacement key. Avoid unnecessary copies and use the organization's existing secure method. Changing a license should not require exporting entries, deleting forms, or reinstalling the entire site.
- Record whether the constant exists, not its contents.
- Identify the owner before modifying a managed configuration.
- Check the exact build before applying a host-specific exception.
- Keep unrelated credentials out of evidence.
Verify the result at each layer
After the approved change, revisit the settings screen and record whether the field state now matches the intended configuration. Validate the key through the supported interface and check update availability. A visually editable field alone does not establish that the new license was accepted.
If validation still fails, examine the documented validation troubleshooting separately. Network access, account entitlement, and configuration precedence are different checks. Do not disable TLS verification or broaden security exceptions as a shortcut to a successful response.
Protect multisite and deployment behavior
For a multisite installation, ask which sites are meant to inherit the managed license and which are deliberately separate. Review the current vendor guidance for the installation and provisioning path before changing a network-level definition. A fix for one site can otherwise affect future sites created from the same template.
Repeat the check after the next normal deployment or configuration refresh. If the old behavior returns, the durable source was not corrected. Document that source so the next maintainer does not keep replacing a value that automation immediately restores.
Leave a minimal handover
Record the site, plugin build, configuration owner, change date, and resulting license status. Do not store the key in the maintenance note. Note any host-specific exception that influenced the decision.
The repair is complete when the intended configuration remains in control and supported updates are available as expected. If the account entitlement itself needs changing, hand that decision to the account owner instead of treating it as a technical reason to bypass licensing.
Illustrative diagnostic worksheet, not results from a customer site.When to bring in help
Contact WordPress maintenance support with the installed version, the visible license status, and whether the key is host-managed. Do not paste the license into email, screenshots, or chat. The person fixing the configuration needs to know its owner and precedence, not receive an unnecessary copy of the secret.
Related troubleshooting
Use a controlled Gravity Forms update checklist.
Helpful references
Gravity Forms 3.1.1 release notes. Gravity Forms WP Config options. Finding and entering a license key.