WordPress add_post_type_support Example: Enable CPT Features Safely

Last reviewed: May 1, 2026

Custom post types often start with the wrong feature set: missing excerpts, no featured images, or hidden revisions even though the editorial workflow clearly needs them. add_post_type_support() is the focused way to extend a post type after registration without rebuilding the whole definition array.

This guide shows how to enable core features for a custom post type safely and deliberately.

Add support after the post type exists

<?php
add_action( 'init', 'vulnwp_enable_case_study_features', 20 );

function vulnwp_enable_case_study_features() {
	add_post_type_support( 'case_study', array( 'excerpt', 'thumbnail', 'revisions' ) );
}

The later priority matters if the post type is registered earlier on the same hook. The feature support can only be added once the post type exists.

Use it to match the actual editorial model

Do not enable every feature just because WordPress allows it. A case study might need excerpts and thumbnails, while an internal log post type may need neither.

Remember that thumbnails still depend on theme support

Even if the post type supports thumbnail, the active theme still needs featured-image support for the UI and rendering flow to make sense.

Prefer this helper when the post type is owned elsewhere

If a plugin registers the post type and the theme needs to extend the editing experience, add_post_type_support() is often cleaner than copying the original registration logic into another layer.

Production checklist

• Run the support change only after the post type is registered.
• Enable features that map to a real editorial need.
• Confirm theme support when enabling thumbnails.
• Retest the edit screen after adding revisions, excerpts, or author support.
• Document feature changes when the post type belongs to a third-party plugin.
• Review whether REST/editor exposure should change alongside the new features.

Common mistakes

• Calling the helper before the post type exists. The change then never lands.
• Turning on every feature by default. Editorial clutter increases without benefit.
• Assuming thumbnail support is enough by itself. Theme support still matters.
• Extending a third-party post type without documentation. Future maintainers need that context.
• Ignoring the effect on editor UI and revision storage. Features change workflow, not just code.

Related reading

If the post type itself still needs to be registered, pair this with the custom post type guide. If the newly enabled thumbnail feature drives theme media output, continue with the add_image_size article.

References and further reading

• WordPress Code Reference: add_post_type_support()
• WordPress Code Reference: register_post_type()
• WordPress Code Reference: add_theme_support()