CustomFields Pro can match CSV rows to existing WordPress posts using a business key: a saved reference such as a project code. Matching requires an explicitly chosen unique, supported native business-key field. First verify which real-world record each reference identifies; a plausible match is not enough to approve an update.
This hypothetical exercise produces a reconciliation record, tests reordered CSV columns and applies one reviewed staging update. It is a procedure to run, not a report of completed tests.
Confirm fit and prepare staging
Start with existing posts, populated reference values and a UTF-8 CSV. Use a stable reference, not a name that may change or repeat. Do not assume fuzzy matching, composite keys or arbitrary external storage support.
Use matching Free and Pro 1.1.2 packages with WordPress 6.5+ and PHP 7.4+. For a fresh installation, activate Free first, then Pro. Pro requires valid initial licence activation on each site and remains in private beta.
New activations support single-site WordPress; new multisite activation is unavailable, though existing confirmed per-site multisite connections retain activation. Back up your site and arrange authorized staging access using the installation and activation instructions. Test your host, theme and other plugins before production use.
CSV reviews support up to 500 rows, 32 columns and a 2 MiB file, with 1–10 supported fields per saved mapping. Missing or renamed required headers and duplicate headers stop staging.
For occasional corrections, manual reconciliation followed by WordPress-admin editing may suffice. Admin editing remains available in Free; the saved business-key update workflow requires Pro.
Record the baseline and map the key
The example uses five CSV rows and four staging posts. All references, IDs and notes are fictional; substitute verified IDs from your staging copy. project_reference and public_note are illustrative field names, not ready-made plugin fields. Confirm that both destination fields are supported.
Before any CSV preparation, record the saved reference and public-note values for posts 4101–4104 in WordPress admin. This baseline lets you check whether preparation or application changed them.
Keep the original CSV unchanged. Create a reconciliation sheet with one entry per incoming row, separating intended targets, actual observations and owner decisions. A hypothetical entry would begin:
- Source: pilot-original.csv, data row 1, reference PR-101.
- Intended post and evidence: 4101; the hypothetical owner's register and saved reference agree.
- Baseline reference and note: PR-101; “Contact the project team.”
- Proposed note: “Contact the project office.”
- Observed target/result: Not yet tested.
- Decision/owner: Await target verification; content owner.
This is a reader-created record, not a plugin-generated report. Verify post IDs in WordPress admin rather than inferring them from titles.
Choose an existing native post field group. Explicitly select its supported business-key field for matching, then map the incoming project_reference column to it. Separately map public_note to the supported update field.
Save the mapping when permitted and attempt preparation without approval. Record actual observations in your sheet. If processing stops before row review, record the blocking response—not invented row outcomes.
Decide which references can proceed
Use these cases to decide what the content owner must resolve. Keep actual workflow observations separate from the hypothetical decisions below.
TRY THE SCENARIOS
What should each reference allow you to do next?
Hypothetical fixtures: five CSV rows, four existing staging posts and supported fields. These are recommended editorial decisions, not observed plugin responses or a check of your file.
Unique intended destination
PR-101 belongs to post 4101. Verify the proposed target against the owner's evidence, then continue reviewing the note. A unique match does not establish that the proposed text is accurate or authorize application.
Duplicate incoming reference
Data rows 2 and 3 both use PR-202 for post 4102 but propose different notes. Obtain one authoritative source row from the owner, or exclude both pending resolution. Do not silently choose the first or last row.
Duplicate destination reference
Posts 4103 and 4104 both store PR-303. Hold the incoming row until the owner establishes its intended destination and authorizes an evidence-backed correction to the identifiers.
Unknown reference
PR-999 has no corresponding post in this fixture. Investigate a source typo, missing destination reference or genuinely new project. Keep the intended ID unresolved until evidence establishes the next action.
Compare all scenarios
| Situation | What happens |
|---|---|
| Unique intended destination | PR-101 belongs to post 4101. Verify the proposed target against the owner's evidence, then continue reviewing the note. A unique match does not establish that the proposed text is accurate or authorize application. |
| Duplicate incoming reference | Data rows 2 and 3 both use PR-202 for post 4102 but propose different notes. Obtain one authoritative source row from the owner, or exclude both pending resolution. Do not silently choose the first or last row. |
| Duplicate destination reference | Posts 4103 and 4104 both store PR-303. Hold the incoming row until the owner establishes its intended destination and authorizes an evidence-backed correction to the identifiers. |
| Unknown reference | PR-999 has no corresponding post in this fixture. Investigate a source typo, missing destination reference or genuinely new project. Keep the intended ID unresolved until evidence establishes the next action. |
Illustrative examples. Your selection is not saved or sent, and changes no store settings.
The plugin cannot establish real-world identity. Duplicate, ambiguous and unmatched references need owner resolution before those rows can proceed. Do not silently select a plausible destination or invent a replacement key. This workflow updates existing posts; do not assume unmatched rows create new ones.
Reorder the corrected file and review again
For the smallest pilot, obtain approval to include only PR-101 in a new CSV. Keep PR-202, PR-303 and PR-999 in an owner-assigned resolution queue. Excluding them makes the pilot input usable; it does not resolve their identities.
If the original file was blocked before you could save a mapping, establish the mapping using this clean file in the original column order.
Then reverse project_reference, public_note to public_note, project_reference, keeping both header names exactly unchanged. Reuse the saved mapping. Check that the reference still selects post 4101 and the note still reaches the intended field.
Mappings follow exact column names, so columns can move. Renaming a required header requires a corrected file or mapping.
Prepare a fresh before-and-after review of the corrected file. Inspect its full contents, target and proposed value. Search and pagination only change which rows you see; they do not exclude rows from the file under review.
Verify one update and limit the verdict
Before approval, reopen posts 4101–4104 and compare their saved references and notes with the baseline captured before the first preparation. Unapproved CSV preparation must not have changed them. Investigate any difference before approving.
Approve the exact reviewed change and follow background application. After completion, reopen the posts and verify:
- Post 4101 contains the exact approved note and retains PR-101.
- Posts 4102–4104 retain their baseline values.
- Relevant public output reflects the approved note where that field is displayed.
Update your reconciliation record with the verified target and saved results, not just a completion message. Preserve your backup and recovery plan; documented undo stops on later edits rather than overwriting them.
A go for this pilot only covers one clean match, exact-header mapping after reordering and one approved update. It does not validate excluded references or every future spreadsheet. Record hold if targets, field support or results remain uncertain.
Next, have the assigned owners resolve the excluded references and run a fresh review before extending the scope. If references cannot be made reliably unique, request verified post IDs or use separately reviewed manual edits.
