Bits of .NET

📝 The Post Type That Was Still There, Just Not Visible to Anyone

A custom post type that vanishes from the WordPress admin menu after a plugin or theme update almost always still exists in the database, with all its content completely intact – what actually broke is the register_post_type() call itself, most commonly because the update changed the exact ‘slug’ string the post type is registered under, or introduced a silent PHP error partway through the registration code that stops it from completing successfully, and WordPress simply has no admin menu entry to show for a post type it no longer knows is supposed to be registered.

🔎 The Problem

// Before the update:
register_post_type('"'"'event_listing'"'"', [
    '"'"'label'"'"' => '"'"'Events'"'"',
    '"'"'public'"'"' => true,
    '"'"'show_in_menu'"'"' => true,
    '"'"'supports'"'"' => ['"'"'title'"'"', '"'"'editor'"'"', '"'"'thumbnail'"'"'],
]);

// After a theme/plugin update that renamed the internal slug as part
// of a broader refactor:
register_post_type('"'"'listing_event'"'"', [   // Different slug!
    '"'"'label'"'"' => '"'"'Events'"'"',
    '"'"'public'"'"' => true,
    '"'"'show_in_menu'"'"' => true,
    '"'"'supports'"'"' => ['"'"'title'"'"', '"'"'editor'"'"', '"'"'thumbnail'"'"'],
]);

// Every existing event post in the database still has post_type =
// '"'"'event_listing'"'"' - but WordPress now only recognizes and shows an
// admin menu for '"'"'listing_event'"'"', which has zero posts, since nothing
// migrated the existing content'"'"'s post_type value to match. The old
// posts still exist, completely intact, just no longer associated with
// any registered, visible post type.

✅ Fix: Confirm the Registered Slug First, Then Decide How to Reconcile It

• Checking the wp_posts table directly (or via a quick WP_Query for any post type, filtered by the approximate date range the content was created) confirms whether the existing content’s actual post_type value in the database still matches what’s now being registered – this is the fastest way to tell a renamed-slug issue apart from a genuinely broken registration call.
• A one-time migration (a simple SQL UPDATE, or a small WP-CLI script) that updates every existing post’s post_type column from the old slug to the new one reconciles historical content with the new registration, once the new slug is confirmed to be the intentional, permanent one going forward.
• Enabling WP_DEBUG and WP_DEBUG_LOG temporarily and checking debug.log for a PHP error or warning around the theme/plugin’s functions.php is the direct way to catch the OTHER common cause – a fatal or caught-but-logged error partway through the file that stops register_post_type() from ever actually running at all, rather than a slug rename.

⚠️ Why the Content Being ‘Still There’ Is Easy to Miss

• The admin menu simply not showing an entry gives no direct indication of WHY – it looks identical whether the post type registration silently failed due to a PHP error, or succeeded perfectly under a different slug than before, so the two genuinely different root causes require actually checking rather than being distinguishable from the symptom alone.
• Panic that the content itself was deleted is a very natural first reaction to a post type disappearing from the admin menu entirely – checking the database directly, calmly, before assuming data loss, resolves this immediately in the far more common case where the content was never actually touched at all.