An empty custom-post admin list does not prove the content was deleted. If it followed a WPML configuration change, preserve known post IDs and check language, status and post-type registration before recreating records or importing a backup over production.
Check the specific WPML repair
WPML 5.2.0 documents a fix for custom posts disappearing from admin lists after a wpml-config.xml file makes their type translatable. The changelog says affected sites are repaired on update. Match that sequence to your incident, then verify the supported update on a recoverable staging copy. Do not assume every empty post list is this defect.
A theme or integration may ship the configuration file, so the trigger may have been a theme update rather than a deliberate WPML settings change. Record the deployment time and changed package names. Preserve the current configuration before anyone edits translation preferences to see what happens.
Separate missing content from a missing view
Start with a known post ID from a private editorial record or a previously working edit link. With an authorized account, inspect whether the record still exists, which post type it belongs to, and its stored status. Check the admin language selector, status tabs and search filters. Compare the same view with a second authorized editor only when role differences are relevant.
If WP-CLI is available, these read-only checks can help an operator working in the correct WordPress installation:
wp post get 123 --fields=ID,post_type,post_status --format=json
wp post list --post_type=example_type --post_status=any --fields=ID,post_type,post_status --format=json
Replace the illustrative ID and type with the actual values. Consult wp post get and wp post list for supported arguments. These commands do not establish WPML translation relationships or rule out every filter. A negative result warrants investigation, not immediate deletion or recreation.
A missing admin row can result from a language or status filter even when the underlying post still exists. Explanatory diagram.
Inspect the configuration change
Find the custom post type's machine name and the configuration that changed its translation behavior. Compare the previous and deployed files using your normal version-control or backup tools. A display label such as “Projects” is not necessarily the registered type name used in configuration.
Confirm the plugin or theme that registers the type is active and loading without a new error. If that registration disappeared, changing a language filter cannot restore it. If the type exists and known records remain, inspect whether language assignment or list filtering explains their absence. Preserve private error logs without enabling public debug output.
Do not reset WPML, bulk-assign languages or import replacement posts to make the list look populated. Replacement records can receive new IDs and break relationships, forms, menus or external references. The absence of visible rows is not authorization to rewrite those relationships.
Verify recovery with stable identities
On staging, retain a small ledger of known source and translated IDs before applying the supported fix. After the update, reopen the admin list under each relevant language and status filter. Confirm the same records return rather than duplicate replacements appearing beside them.
Open one source and one translation through their ordinary editing paths. Check the relationship, a distinctive content marker and a field whose value is intentionally language-specific. Then verify the public URLs that should be public. A restored admin list alone does not establish that every translated route or template reads the correct record.
For a field value that remains stale after the list is repaired, use the WPML existing-field propagation guide. That is a different task from making a custom post type visible. If publication status changes unexpectedly, use the scheduled and restored translation status checks.
Preserve a useful handoff
Record the original trigger, package versions, affected type, representative IDs, configuration difference and the filters under which records disappear. Include what remained accessible before the update and what recovered afterward. Exclude unpublished titles and client details when sharing the report externally.
If known records genuinely cannot be found, pause bulk editing and ask the host or developer to investigate the backup and audit trail. HandL WP can trace the admin-list or translation failure with the preserved evidence. Recoverability and stable IDs matter more than quickly making an empty screen look busy.
Sources reviewed November 2, 2026. Examples and diagrams are diagnostic aids, not customer test results.