Custom field data that appears to have vanished — empty where content used to be, missing after an update or migration — is often still present in the database under a different key or format than the current site expects, which is why recovery starts with confirming whether the data is genuinely gone or just disconnected from where it’s supposed to display.
Check the database directly before assuming the data is gone
If you have database access, searching the wp_postmeta table directly for the affected post ID can reveal whether the field data still exists under its original meta key, even if it’s no longer displaying correctly on the edit screen. This is a genuinely useful first check before assuming permanent loss.
Custom field data loss recovery
Custom field data that looks gone — checked against the database before assuming it's lost.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| Custom field data appears missing and you want to know if it’s recoverable | This fix covers it |
| The field group itself is misconfigured, not showing correctly, separate from confirmed data loss | ACF field group repair & migration, a more general repair |
| You want a bulk import of field data from a supplied file, not recovery of existing data | Custom field bulk import from supplied file |
| You’re confident the data is genuinely, permanently gone and want a technical explanation rather than a recovery attempt | We’d confirm this plainly rather than promise a recovery that isn’t realistically possible |
What you are seeing
- Custom field values displaying as empty where content previously existed
- The apparent loss coinciding with a plugin update, migration, or field group change
- Some fields affected while others on the same content remain intact
- Uncertainty about whether the underlying data still exists somewhere in the database
Common causes
- A field key change disconnecting the display from data still stored under the original key
- A migration or import process not correctly mapping field data to its new environment
- A plugin update changing how a specific field type stores or retrieves its data
- Data genuinely deleted, whether by an update process, a manual action, or a database issue
- A serialized data structure corrupted by a partial import or a character encoding mismatch, leaving the raw data unreadable even though it technically still exists
What we do
- Investigate the database directly for the affected content and field
- Determine whether data still exists under a different key, format, or location
- Reconnect display to genuinely recovered data where found
- Check backups or logs for genuinely lost data with no live trace remaining
- Verify recovered data displays correctly and matches what’s expected
- Provide a written, honest summary of what was recovered and what, if anything, could not be
What is included
- A thorough investigation into whether field data is genuinely lost or merely disconnected
- Recovery and reconnection of data found to still exist
- An attempt to recover from backup for data with no live trace, where a suitable backup exists
- A written, honest summary of the outcome
Not included
- Guaranteeing recovery of data with genuinely no trace in any backup, log, or database location — that can’t be recreated from nothing
- Fixing an underlying, ongoing cause of continued data loss — a separate, related fix if that’s also needed
- General field group configuration repair unrelated to the specific data loss investigated
- Ongoing monitoring for future data integrity issues
Questions about this fix
How likely is it that my data is actually recoverable?
It depends heavily on the specific cause — data disconnected due to a key mismatch is often fully recoverable, while data genuinely deleted with no backup covering that period may not be; we investigate thoroughly before giving you a realistic answer either way.
Will you tell me honestly if the data can't be recovered?
Yes — we'd rather give you an accurate, if disappointing, answer than suggest false hope, since knowing definitively that something can't be recovered is still more useful than an open-ended, uncertain search.
Could this happen again after the fix?
If the underlying cause (a field key mismatch prone to recurring, for instance) isn't also addressed, yes — we'd flag this specifically if we find the fix should include preventing a repeat, not just recovering this instance.
What if only some of my affected content's data is recoverable?
We'd recover what's genuinely possible and give you a clear, itemised account of what was and wasn't recoverable, rather than an all-or-nothing outcome.
Should I check my own backups before contacting you about this?
If you have quick access to backup information, mentioning what's available (and from when) helps us investigate more efficiently, though we can also identify and check relevant backups ourselves as part of this fix.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.