Custom Post Type UI registers WordPress post types without touching code

What it does, and what it explicitly does not do

Custom Post Type UI, usually shortened to CPTUI, provides an easy to use interface to create and administer custom post types and taxonomies for WordPress.

The important sentence is the second one in the description, because it is the thing people discover too late. CPTUI does NOT handle display of registered post types or taxonomies in your current theme, and its goal is to simply register them for use.

So the plugin sits in one half of the job. Registering a custom post type means telling WordPress that a new kind of content exists, what it is called, how it behaves in the admin, what its URL looks like and what capabilities it needs. That is a block of PHP that a developer writes and adds to a theme or a plugin. The plugin replaces that block with a form.

Rendering the content, meaning the single-post template, the archive page, the navigation entries and the styling, is not included, and that part still needs a developer or a theme that already handles custom post types generically.

The distinction decides when the plugin is the right tool. If you are adding a post type that a capable theme already knows how to display, the plugin removes the only tedious part. If you need bespoke templates, you are using it for the registration and writing the display yourself, which is still a reasonable split.

The core developers listed are Michael Beckwith, John Hawkins and Brad Williams, along with WebDevStudios as the sponsoring organisation. The plugin is GPL v2 or later.

Two ways to install, and both end at the same menu

The installation section gives two routes, and both are short enough to reproduce from memory.

The manual route is three steps. Upload the Custom Post Type UI folder to the plugins directory in your WordPress installation, activate the plugin, and then go to the CPTUI Menu.

The admin installer route is four steps. Visit the Add New plugin screen and search for custom post type ui, click the Install Now button, activate the plugin, and go to the CPTUI Menu.

The final step being identical in both routes is the point, because the plugin has no separate onboarding. You are dropped straight into the screen where you create a post type, and the instructions end with the claim that you can now easily start creating custom post types and taxonomies in WordPress.

The manual route is worth knowing about beyond emergencies, because the plugin directory on a server is a normal directory and some hosts make it awkward to install from the admin, and some site owners prefer to version the plugin folder alongside the rest of the site code.

Note that the plugin does not create content of its own and does not require a separate database table for its settings as far as the documentation indicates. The post types and taxonomies it creates are registered with WordPress itself, which is what makes them usable by anything else in the stack.

The support model is the Help and Support section, and the guidance is to check the FAQs there first and then open a new thread on the support forums for Custom Post Type UI if none of those answer the question. So there is a forum rather than only the issue tracker, and the FAQ is the first place to look.

The build pipeline is a modern WordPress plugin build

The package file describes the development setup, and it is a standard modern WordPress plugin toolchain.

The scripts are where the structure of the project shows. The build script is a composite that runs buildjs, then dashicons, then uglify, then styles. The buildjs step is `wp-scripts build --config webpack.config.js`, so the JavaScript is bundled with the WordPress scripts package rather than with a bespoke configuration. The watch script starts wp-scripts in watch mode with the same webpack config, and there is a start script and a dev script that both run wp-scripts start.

The styles are compiled from Sass in two passes, `styles:compile` produces the readable stylesheet from `src/scss/cptui-styles.scss` and `styles:compress` produces the minified version, with the styles script running both.

The dashicons step copies `src/js/dashicons.json` into a `src/vanilla-icon-picker` directory, which tells you the plugin ships its own icon picker rather than depending on a WordPress core one, and the uglify step minifies `build/cptui.js` with a source map.

The release script is the one that explains how a build becomes a distributable plugin. It creates a release-build/custom-post-type-ui directory and copies into it the build output, the classes, external, images and inc directories, readme.txt, LICENSE, the main plugin file, the WPML configuration file and the Wordfence vendor file. So the shipped artefact is a directory with the plugin file at its root and the PHP source beside it, which is the classic WordPress plugin layout.

Linting is split three ways, with a CSS lint over the scss files, a JavaScript lint over `src/js/**`, and a PHP lint that runs phpcs against the whole tree with the phpcs.xml.dist standard while ignoring the build, node_modules and vendor directories.

The repository layout shows a plugin that has absorbed a lot of history

The top-level entries tell you what kind of codebase this is, and the presence of both a src/ directory and several legacy PHP directories is the interesting part.

There is custom-post-type-ui.php, the main plugin file that WordPress loads, and readme.txt, which is the plugin directory listing format rather than the README.md you see on GitHub. Then there are classes/, inc/, external/ and images/, which are the directories copied into the release build. That is the older style of WordPress plugin organisation, and the presence of both it and a modern src/ directory with a webpack build and an SCSS entry point suggests a codebase partway through being modernised rather than one that started that way.

Alongside those, the modern tooling files: composer.json for the PHP dependencies, package.json and package-lock.json for the JavaScript, webpack.config.js, phpcs.xml.dist for the PHP coding standard, .editorconfig and .gitattributes, a .nvmrc pinning the Node version used for the build, and .github/ for the workflows.

Two files are worth calling out because they say something about who the plugin serves. There is wpml-config.xml, which tells WordPress Machine Translation which strings to expose for translation, which is what you need if the plugin has to be localised. And there is wordfence-vendor.txt, which is the file that tells the Wordfence security plugin that this plugin's code should be excluded from its malware scanning, because a plugin that registers custom post types trips rules written for ordinary plugins.

The release script copying both of those files is a small but telling detail. It means the plugin is aware of the two common external integrations that break when a plugin is not configured for them, localisation and security scanning.

There is also a CHANGELOG.md, which the README points to for the full list of changes, and a CODE_OF_CONDUCT.md.

The release history tells you about the maintenance rhythm

The version history is short in its listing but the gaps in it are informative.

The recent releases are 1.19.3 from 2026-08-19, then 1.13.5 from 2023-03-27 and 1.13.4 from 2022-12-16. So there is a long stretch between the 1.13.x line and the 1.19.3 release, and the versions in between are not among the most recent tags listed.

That pattern is common in WordPress plugins and it has a practical consequence for you as an adopter. The version you get depends on the channel you install from and when you install it. The admin installer serves whatever is in the WordPress plugin directory at that moment, and the repository's own release history shows both a slow line and a recent jump.

The last push was on 2026-08-27 and the package file version is 1.19.3, which matches the most recent release tag, so the repository is in step with its own published version.

The import and export functionality is called out separately as amended from an original contribution by Ben Allfree, with a link to his WordPress.org support profile. That is worth noting for a different reason. An admin screen that lets you create a post type is only useful at scale if you can move the configurations between sites, and the import and export feature is what makes a set of post type definitions portable. When a team builds out several sites from one template, that feature is the difference between a repeatable setup and a manual re-entry.

There is also an outside contributors note thanking brandondove, which is a small acknowledgement typical of a plugin with a long public history.

Where this sits against writing the registration yourself

The comparison is with a few lines of PHP in a theme's functions file, and it is closer than it might look.

Registering a post type by hand is a call to register_post_type with a set of arguments, and registering a taxonomy is a call to register_taxonomy. That is genuinely not much code. The argument is that the plugin turns a set of arguments you would have to look up into a labelled form, and it makes the result editable by someone who does not write code.

That second benefit is the real one. A site owner who wants to add a post type for a section that did not exist at build time, for instance a documentation category or an event type, can do it in the admin rather than raising a ticket. The plugin is the difference between a content model fixed at deploy time and one the site can evolve.

The cost is the usual one. You now have a dependency that must be installed, kept updated and configured, and a layer between you and WordPress's own registration function. And the display half is still yours, so you have not avoided the theme work.

Against the alternative of a full custom plugin built for your site, the plugin wins on generality and loses on specificity, since a bespoke plugin can do exactly the registration you need and nothing else, and can integrate with your theme's display code directly.

There is also a middle path worth naming, and it is common in practice. Use the plugin for the registration, keep the display in your theme, and treat the plugin's stored configuration as the source of truth for what content types exist. That gives the site owner the ability to add types and gives you a single place to look when you write the templates.

What the plugin deliberately does not try to be is a page builder or a front-end framework. It registers and administers, and it says so.

Editorial conclusion

Adopt Custom Post Type UI if you need post types and taxonomies in WordPress and want a site owner to be able to manage them without a developer, since the form covers the registration options a plugin normally hard-codes. Skip it if you need the custom types rendered in your theme, because the plugin explicitly does not handle display, and if your project demands a strict dependency and licensing review, since the plugin is GPL v2 or later and carries a Wordfence vendor file. Verify first which WordPress version and PHP version you are on, that the plugin directory on your server is writable, and that you have read the changelog, since the version line has a long gap and the release you get depends on which channel you install from.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. WebDevStudios/custom-post-type-ui on GitHub