A changed settings control needs both a persistence check and a real capture check. Test enabled and disabled forms independently.
Quick answer
Partial Entries 1.8.2 replaces the enabling control in form settings with a toggle switch. After updating, check that previously enabled and disabled forms retain their intended state, save and reopen the settings, then test actual capture in fresh synthetic sessions. The release note describes a control change; it does not establish that every existing form has a migration defect.
Create an inventory before changing settings
List the forms using partial capture and the forms deliberately excluded from it. Record each form identifier, enabled state, conditional capture rules, warning text, and the owner responsible for handling incomplete submissions. Include a form with sensitive information if one exists, but reproduce it using synthetic values. A mistaken enablement can matter as much as missing leads.
Capture a supported form export and a screenshot of the relevant settings. Keep those as comparison evidence, not as proof of the runtime behavior. Some form details or add-on settings may need separate documentation, so confirm what the export actually includes. Do not assume switching capture off deletes historical partial records; retention is a separate operation.
Check that the switch persists correctly
Update a staging copy and open an enabled form, a disabled form, and a newly created form. Record the initial switch state. Change one test form, save, navigate away, and reopen it. Verify the visible state and any dependent options. A switch that changes visually but fails to save is a different problem from a capture request blocked on the frontend.
Repeat using the actual administrative role that maintains forms. Test keyboard activation and visible focus if the team relies on them. If the setting unexpectedly resets, check for validation errors, permission failures, concurrent editor saves, and stale admin resources. Preserve the response and version details before manually rewriting plugin options.
Illustrative diagnostic worksheet. Values are examples, not measurements from a customer site.
Prove enabled and disabled behavior with fresh sessions
Use a fresh synthetic marker for each test and record the observation time. On an enabled form, enter enough data to satisfy the configured capture condition, then follow the documented partial-capture behavior and inspect the entries view. Record the partial identifier and fields present. Do not assume one keystroke or leaving the tab immediately is sufficient to trigger every configured capture path.
On a disabled form, repeat the same interaction and verify no new matching partial appears. Distinguish old records from records created during the test. Existing tabs may contain earlier configuration or tokens, so also reload the public form and test a new session. A stale page should not be your only evidence about whether the new setting is working.
Reconcile resumed and completed entries
Where the configured workflow supports resuming, reopen the partial through the intended mechanism and complete it once. Compare the partial and final identifiers and ensure downstream integrations handle the final submission correctly. Do not infer that a captured email address means the visitor agreed to marketing follow-up; follow the site approved notice and communication process.
Check the form URL through the cache and script-optimization layers actually used by the site. If capture works only without optimization, isolate the relevant exclusion and retest normal visitors. Preserve conditional logic, validation, and spam protections while making those changes. Keep the scope small enough to identify what restored capture.
Decide when the update is complete
Close the change after settings survive a fresh request, enabled forms capture under their intended conditions, disabled forms remain excluded, and a completed synthetic submission reconciles correctly. Remove synthetic records through the approved data-handling process and document any remaining uncertainty. Give the forms owner a short list of affected forms and the expected capture behavior so the next plugin update can use the same checks.
Working example
Use this as a read-only starting point or an evidence worksheet. Replace example identifiers with the approved staging fixture.
capture_check:
form: synthetic-test
configured_enabled: true
capture_condition: approved-test-rule
visitor_marker: unique-test-marker
partial_created: record-result
final_entry: reconcile-separately
Before closing the work
- Enabled forms capture under intended rules.
- Disabled forms produce no new partials.
- Completed submissions reconcile with their partial.
- Existing partial records are handled separately.
For help applying these checks to a live site, HandL WP WordPress support can review the affected configuration and verify the result. Continue with Partial Entries form-tag identifier checks when that adjacent issue matches your evidence.
Helpful references