Release guidance updated 28 October 2026 for 1.1.2. The edition split was introduced in 0.10.6; earlier instructions described 0.10.0. This remains a hypothetical staging procedure, not a claim that these tests ran on your installation.
Use CustomFields Pro’s change-request mode, not its supplied direct frontend edit form, when contributors need to propose corrections and revise returned entries before an authorized reviewer accepts them.
Pilot one explicitly targeted existing record with a text field and a choice field. Verify that unapproved proposals leave its saved values unchanged. The hypothetical walkthrough below is an acceptance test to run, not a report of proven results.
Decide whether the workflow fits
Choose the approach around your correction process:
- Infrequent corrections: an editor-managed request log and manual WordPress-admin edits may suffice; admin editing remains available in Free.
- Signed-in contributors need returned-entry revision: pilot Pro change requests with supported plain/choice fields.
- Uploads, references or complex nested/conditional fields are essential: this documented submission format is not a fit.
Anonymous correction access is not included. The supplied logged-in frontend edit/create forms are also Pro features, but they are separate from this proposal-and-review workflow.
Prepare staging and accounts
Use WordPress 6.5 or later and PHP 7.4 or later. Install Free first, then the compatible Pro companion; evaluate the matched 1.1.2 pair. For an existing pair, update Free before Pro without uninstalling.
Keep a database backup and test this beta workflow on staging with your theme and plugins. A successful pilot does not establish compatibility across other site configurations or hosting environments. Consult the 1.1.2 documentation for operating details and limits.
Prepare separate contributor and reviewer accounts. The reviewer needs the relevant WordPress content permissions; assignment does not override them. Check whether the contributor has broader direct-edit privileges elsewhere, too.
Do not depend on email. Notifications remain off until an administrator configures recipients and enables them; delivery uses the site’s mail service.
Name owners and configure one target
Write a responsibility map with a named person for each role:
- Contributor: supplies the correction’s basis and revises returned entries.
- Reviewer: verifies evidence, returns incomplete requests and owns the approval decision.
- Administrator: configures targets, fields and accounts, assigns the reviewer and investigates failures.
Agree what evidence a correction needs; keep it and any questions in a separate pilot log. Do not assume attachment support or a dedicated evidence field. Approval records a decision; it does not establish factual accuracy.
For this entirely hypothetical pilot, use an existing directory record called Harbor Studio:
- Visitor note: “Contact us before visiting.”
- Visit mode: “Appointment only”
- Configured visit-mode choices: “Appointment only” and “Drop-in”
Record its WordPress ID, saved values, field names, types and choices as your manual baseline.
Configure a signed-in submission form in change-request mode for that explicit existing target. Include the text and choice fields, assign the authorized reviewer, and place the form on a staging page using its documented shortcode. Do not substitute new-entry mode.
Run the correction lifecycle by actor
Use authorized WordPress-admin access for every saved-state check below. Page output alone is not proof of saved values.
Contributor: submit an incomplete proposal
Confirm the intended target, then propose:
- Visitor note: “Visit on open days.”
- Visit mode: “Drop-in”
Submit the request. The expected saved target remains “Contact us before visiting.” and “Appointment only”. Record the actual values after submission, including any unexpected change.
Reviewer: return it for clarification
Inspect the original and proposed values. In this example, “open days” is too vague to approve.
Return the entry. Record and share this question with the contributor: which days and hours have been confirmed, and by whom? Inspect the saved target again. Record its actual values after return; the expectation is still the original pair.
Contributor: revise the returned entry
Sign in as the original contributor. Confirm that they can follow their own status and revise the returned entry.
Assume, solely for this example, that the content owner confirms Saturday drop-in access from 10am–1pm. Change the note to “Drop in on Saturdays, 10am–1pm” and retain “Drop-in”.
Confirm that the revised entry is available to the assigned reviewer. Record the exact revision and whether both contributor access and reviewer access worked; do not assume a particular resubmission mechanism.
Reviewer: inspect and approve the revision
Compare the revision with its evidence and the target’s current values. Immediately before approval, record the saved target values. The unapproved revision should not already have replaced them.
Approve only the reviewed revision. After application, reopen the target and compare its saved values with the exact approved note and choice. Inspect their page display, too. Record both comparisons and investigate discrepancies rather than relying only on a completion message.
Test permissions and intervening changes
Test an assigned reviewer account that lacks the required content permissions. Record whether actions requiring those permissions are blocked; assignment alone must not authorize them.
Run two separate stale-request tests, each from a recorded baseline:
- Submit a proposal, then change a target value before review.
- Submit a separate proposal, then change a relevant field definition before review.
Review is documented as bound to original values and schema. Record each test’s observed handling and the resolution needed before approval. Do not predict automatic merging, rejection or rebasing. Keep the tests separate so you know which condition changed.
Record evidence and make the decision
Keep observations in your pilot log. Completing a checklist item means you recorded the evidence, not that the workflow passed.
Go only if targeting, revision and application meet expectations, unauthorized actions are denied, and both stale-request tests have safe resolutions. Unapproved proposals must leave the target unchanged.
Hold the workflow if any result is unresolved or required fields are unsupported. Use the manual request log while addressing those issues.
If Pro is deactivated, definitions and stored values remain and WordPress-admin editing continues, but supplied Pro workflows become unavailable. Name a manual fallback owner for outstanding corrections.
Next, select one staging record, record its ID and schedule the pilot with your named contributor, reviewer and administrator.
