How to Create a Custom Post Type in WordPress: A Complete Developer’s Guide

Introduction to Custom Post Types

WordPress began as a blogging platform, but it has evolved into a full-featured content management system (CMS) that powers over 40% of the web. At its core, WordPress organizes content into two default content types: posts (for blog entries, often displayed in reverse chronological order) and pages (for static, hierarchical content like “About Us” or “Contact”). While these two types suffice for a basic blog or brochure site, they quickly become limiting when you need to manage distinct content structures—such as portfolios, testimonials, events, or products—each with unique fields and display requirements.

This is where custom post types (CPTs) come in. A custom post type allows you to define a new content type tailored to your specific needs, complete with its own set of attributes, custom fields, taxonomies, and admin interface. By creating a CPT, you can logically separate different kinds of content, give each its own editing screen, and control how it appears on the front end. For developers, mastering CPTs is essential for building anything beyond a simple blog—from membership sites and e-commerce stores to directories and project management tools.

In this guide, you will learn exactly how to create a custom post type in WordPress using best practices, including both code-based methods and plugin alternatives. We will start with the fundamentals: what a CPT is, when to use one instead of a plugin, and real-world examples that demonstrate their power.

What Is a Custom Post Type?

In WordPress, a “post type” is a classification for different types of content. The platform ships with several built-in post types:

• Post – blog entries, typically listed in reverse chronological order.
• Page – static, hierarchical content (e.g., About, Contact).
• Attachment – media files uploaded to the Media Library.
• Revision – saved drafts and past versions of posts/pages.
• Navigation Menu – menu items stored in the database.

A custom post type is any additional post type you register yourself. It behaves similarly to the built-in “post” type, but you control its name, labels, icon, supported features (like excerpts, thumbnails, or custom fields), and how it integrates with taxonomies (tags, categories, or custom ones). For example, you might register a “Portfolio” CPT that supports a featured image, a custom field for “client name,” and a custom taxonomy for “project type.”

Technically, all content in WordPress is stored in the same database table (wp_posts), distinguished by the post_type column. When you register a CPT, WordPress adds a new entry to the wp_post_types table (in the options API) and creates admin menu items, rewrite rules, and template hierarchy hooks. This means you can create a dedicated editing experience for your custom content without hacking core files.

Key characteristics of a custom post type include:

• Unique slug – e.g., portfolio, event, testimonial.
• Custom labels – singular/plural names, menu name, “Add New” text, etc.
• Public visibility – whether it appears on the front end and in search results.
• Supported features – title, editor, thumbnail, excerpts, custom fields, comments, revisions, etc.
• Taxonomy associations – built-in categories/tags or custom taxonomies.
• Hierarchical or flat – like pages (parent-child) or posts (flat).
• Rewrite rules – custom URL structure (e.g., /portfolio/project-name/).

When to Use a Custom Post Type Instead of a Plugin

One of the first decisions a WordPress developer faces is whether to create a custom post type manually (via code in a theme or plugin) or to use a plugin like Custom Post Type UI or Toolset. Both approaches have valid use cases, and the right choice depends on the project’s scope, longevity, and your role.

Use a custom post type via code when:

• You are building a custom theme or plugin for a client and want full control over the implementation.
• The CPT is central to the site’s functionality (e.g., a real estate listings CPT for a property site).
• You need to avoid plugin bloat and dependency on third-party tools that may not be maintained.
• You are comfortable with PHP and the WordPress coding standards.
• The site will be maintained by developers who can update code if needed.

Use a plugin when:

• You are a non-developer or a beginner who wants a graphical interface to set up CPTs quickly.
• The project is small, temporary, or requires frequent changes to CPT settings.
• You need advanced features like custom fields and taxonomies managed through a UI (many CPT plugins bundle these).
• You are prototyping and may later migrate to code.
• The client is non-technical and prefers to manage content types through a plugin dashboard.

Here is a quick comparison table to help you decide:

Factor	Code-Based CPT	Plugin-Based CPT
Performance	Minimal overhead; runs only when needed.	Slightly more overhead due to plugin loading.
Control	Complete control over labels, capabilities, and rewrite rules.	Limited to plugin options; may not support all arguments.
Portability	Easy to move between themes (if placed in a plugin).	Dependent on the plugin being active.
Learning Curve	Requires PHP and hook knowledge.	Minimal; point-and-click interface.
Maintenance	You maintain updates; no third-party dependency.	Plugin updates may break or change settings.
Best For	Custom themes, client sites, complex projects.	Quick builds, non-developers, prototypes.

For professional development, the recommended approach is to register CPTs in a site-specific plugin (not in functions.php of a theme). This ensures that the CPT persists even if the user switches themes. However, for the purposes of this guide, we will focus on the code method, as it gives you the deepest understanding of how to create a custom post type in WordPress.

Real-World Examples of Custom Post Types

To illustrate the versatility of CPTs, here are common real-world use cases where a custom post type dramatically improves content management:

• Portfolio – A designer or agency needs to showcase projects with a featured image, project URL, client name, and a custom taxonomy for “skills” or “industry.” A “Portfolio” CPT keeps these entries separate from blog posts and allows a dedicated archive page (e.g., /portfolio/).
• Testimonials – A business wants to display customer quotes with a rating, photo, and attribution. A “Testimonial” CPT can support a custom meta box for the rating and a shortcode to display a rotating carousel.
• Events – A conference or community site needs to list upcoming events with dates, locations, speakers, and registration links. An “Event” CPT can use custom date fields, a custom taxonomy for “event type” (workshop, keynote), and a calendar view.
• Products – For a simple online store (without WooCommerce), a “Product” CPT can include fields for price, SKU, and stock status, with a custom taxonomy for “brand” or “category.”
• Job Listings – A company website needs to post job openings with location, department, and application deadline. A “Job” CPT can use custom fields for salary range and a taxonomy for “job type” (full-time, contract).
• Recipes – A food blog can separate recipes from regular posts, with custom fields for ingredients, cooking time, and difficulty level, plus a taxonomy for “cuisine.”
• Staff / Team Members – An organization wants to display team bios with photo, job title, email, and social links. A “Staff” CPT can support a custom meta box for contact info and a hierarchical taxonomy for “department.”

Each of these examples shares a common pattern: the content has a distinct structure that does not fit neatly into a standard blog post or page. By creating a dedicated CPT, you gain a cleaner admin interface, better separation of concerns, and the ability to display content in unique ways (e.g., a grid layout for portfolios, a list with filters for events).

Moreover, CPTs integrate seamlessly with the WordPress template hierarchy. For a CPT called “portfolio,” you can create a single-portfolio.php file for individual entries and an archive-portfolio.php file for the listing page. This gives you complete control over front-end presentation without touching other templates.

In summary, custom post types are the foundation of advanced WordPress development. They allow you to model any kind of content your project demands, while keeping the admin area organized and the codebase maintainable. Now that you understand the “what,” “when,” and “why,” you are ready to dive into the actual code. In the next sections, we will walk through the step-by-step process of registering a CPT, configuring its arguments, and adding custom fields and taxonomies—all using best practices that will serve you for years to come.

Prerequisites Before You Start

Before you dive into the mechanics of how to create a custom post type in WordPress, it is essential to prepare your development environment and ensure you have the foundational knowledge required. Custom post types are a powerful feature, but they require precise coding practices to avoid breaking your site, losing data, or creating security vulnerabilities. This section outlines the essential tools, environment, and knowledge you must have in place before writing a single line of code.

Setting Up a Local or Staging WordPress Site

Never develop custom post types—or any custom code—on a live production website. A single syntax error in your functions.php file or a misplaced comma in your registration array can trigger a white screen of death, rendering your entire site inaccessible. Always use a local development environment or a staging site.

Local Development Environments run directly on your computer. They allow you to test code instantly without an internet connection. Popular options include:

• Local by Flywheel – Free, user-friendly, and includes built-in SSL support. Ideal for beginners and professionals.
• XAMPP – Cross-platform, open-source stack including Apache, MySQL, PHP, and phpMyAdmin. More manual configuration required.
• MAMP – Similar to XAMPP but with a macOS-friendly interface. Also available for Windows.
• DesktopServer – Paid tool with powerful portability features for moving sites between environments.
• Docker – Advanced container-based setup for developers who need exact replicas of production server configurations.

Staging Sites are exact copies of your live site hosted on a private server or subdomain. Most managed WordPress hosts (e.g., WP Engine, Kinsta, SiteGround) provide one-click staging environments. If you do not have a staging option, you can manually create one by:

1. Exporting your live database via phpMyAdmin or a plugin like UpdraftPlus.
2. Copying all live files via FTP.
3. Importing the database into a new database on the staging server.
4. Updating the wp-config.php file to point to the new database.
5. Using a search-and-replace tool (like the Better Search Replace plugin) to update all URLs from the live domain to the staging domain.

Minimum requirements for your local or staging site:

Component	Recommended Version	Notes
WordPress	6.0 or higher	Older versions may lack features or security patches.
PHP	8.0 or higher	PHP 7.4 is acceptable but reaching end-of-life.
MySQL / MariaDB	MySQL 8.0 or MariaDB 10.4+	Ensure your environment supports utf8mb4 character set.
Web Server	Apache or Nginx	Apache with mod_rewrite is most common for WordPress.

Once your environment is ready, install a fresh copy of WordPress or clone an existing site. Verify that you can log in to the admin dashboard, create test posts, and view the frontend. This confirms your environment is stable before you begin coding your custom post type.

Understanding WordPress Theme vs. Plugin Location

One of the most common mistakes when learning how to create a custom post type in WordPress is placing the code in the wrong location. You have two primary options: your theme’s functions.php file or a custom plugin. Each has distinct advantages and drawbacks.

Option 1: Theme’s functions.php file

This is the simplest method for beginners. You add your custom post type registration code directly to your active theme’s functions.php file. However, this approach has significant limitations:

• Theme dependency: If you switch themes, your custom post types disappear along with any content associated with them. While the data remains in the database, the admin interface and frontend templates become inaccessible.
• Update vulnerability: If you use a parent theme and update it, your changes to functions.php are overwritten. You must use a child theme to preserve customizations.
• Clutter: As you add more custom post types and related code (taxonomies, meta boxes, shortcodes), your functions.php file becomes bloated and difficult to maintain.

Option 2: Custom plugin

This is the professional, recommended approach. You create a dedicated plugin that registers your custom post type. Benefits include:

• Theme independence: The custom post type persists even if you change themes completely.
• Portability: You can export the plugin and use it on multiple sites.
• Maintainability: All custom post type code lives in one organized location, separate from theme presentation logic.
• Version control: Easier to track changes and collaborate with a team.

How to create a basic custom plugin:

1. Navigate to /wp-content/plugins/ on your server via FTP or file manager.
2. Create a new folder, e.g., custom-post-types.
3. Inside that folder, create a PHP file with the same name: custom-post-types.php.
4. Add the plugin header at the top of the file:

<?php
/**
 * Plugin Name: Custom Post Types
 * Description: Registers custom post types for this site.
 * Version: 1.0.0
 * Author: Your Name
 */

5. Save the file and go to your WordPress admin dashboard > Plugins. You will see your new plugin listed. Activate it.

When to use a child theme instead of a plugin: If your custom post type is tightly coupled with your theme’s design (e.g., a portfolio post type that uses specific theme templates and CSS), you may place the registration code in your child theme’s functions.php. However, even in this scenario, a plugin is still preferable because you can later move the design templates into the plugin using template hierarchy overrides. For maximum flexibility and best practices, always use a custom plugin.

Required PHP and WordPress Version Compatibility

When you learn how to create a custom post type in WordPress, you must write code that is compatible with the versions of PHP and WordPress running on your server. Using deprecated functions or modern syntax on an older environment will cause fatal errors.

PHP Version Requirements

Related reading: WordPress Development: A Comprehensive Guide to Building Custom Websites

WordPress core currently supports PHP 7.4 and above, but the official recommendation is PHP 8.0 or higher for performance and security. When writing custom post type registration code, be aware of the following:

• Array syntax: Use short array syntax [] instead of array() for cleaner code. This is supported in PHP 5.4+.
• Type declarations: You can add type hints to function parameters and return values in PHP 7.0+.
• Named arguments: Avoid using named arguments (PHP 8.0+) if you need to support older environments.
• Null coalescing operator: ?? is safe for PHP 7.0+.
• Match expression: match is only available in PHP 8.0+. Use switch for backward compatibility.

WordPress Version Requirements

The register_post_type() function has been available since WordPress 3.0. However, many advanced features and parameters were added in later versions. Key compatibility points include:

Feature	Minimum WordPress Version	Notes
show_in_rest parameter	4.7	Required for block editor (Gutenberg) compatibility.
template parameter	5.0	Pre-defines block editor layout for new posts.
template_lock parameter	5.0	Locks the block editor template to prevent user modifications.
supports array with ‘custom-fields’	3.0	Always supported but behaves differently in block editor.
capability_type parameter	3.0	Works across all modern versions.

How to check your environment:

1. In your WordPress admin dashboard, go to Tools > Site Health.
2. Click the “Info” tab.
3. Expand the “Server” section to see your PHP version.
4. Expand the “WordPress” section to see your WordPress version.

Best practices for version-safe code:

• Use function_exists() checks when calling plugin-specific functions that might not be available.
• Prefix all your functions and variables with a unique identifier (e.g., myprefix_register_book_post_type()) to avoid conflicts with other plugins or themes.
• Wrap your registration code in an action hook that fires after WordPress core is fully loaded:

add_action( 'init', 'myprefix_register_book_post_type' );

• Test on multiple PHP versions if possible. Use tools like PHP_CodeSniffer with WordPress coding standards to catch compatibility issues.

By ensuring your environment is properly set up, your code is placed in the correct location, and your PHP and WordPress versions are compatible, you eliminate the most common pitfalls that plague developers when they first attempt to create a custom post type in WordPress. With these prerequisites in place, you are ready to proceed confidently to the actual registration code.

Step 1: Choosing a Custom Post Type Name and Labels

The first and most critical decision when building a custom post type is selecting its internal name (slug) and the labels that will appear throughout the WordPress admin interface. This step sets the foundation for how your content type behaves programmatically and how users interact with it. A poorly chosen slug can cause conflicts with existing WordPress functions, while vague labels confuse editors and site administrators. Let’s break down both components with precision.

Related reading: WordPress Multisite: When and How to Use It

Best Practices for Slug Naming (No Spaces, No Hyphens)

The slug is the machine-readable identifier for your custom post type. It is used in database queries, URL structures, template hierarchy, and function parameters. WordPress imposes strict rules: slugs must be lowercase, contain no spaces, and use only letters, numbers, and underscores. Hyphens are technically allowed but strongly discouraged for reasons we will explain.

Related reading: The Future of WordPress: What’s Next in 2026?

Why avoid hyphens? WordPress uses the slug to generate function names and hooks. For example, a post type with slug my-products will be referenced as my_products in many internal contexts due to PHP’s variable naming conventions. This inconsistency between the slug (with hyphens) and the function prefix (with underscores) creates confusion and potential bugs when you register meta boxes, taxonomies, or rewrite rules. Always use underscores to match PHP conventions.

Key naming rules:

• Maximum 20 characters – WordPress database column post_type is limited to 20 characters. Longer slugs will be truncated silently.
• No reserved names – Avoid post, page, attachment, revision, nav_menu_item, custom_css, customize_changeset, oembed_cache, user_request, wp_block, wp_template, and wp_global_styles. These are core WordPress post types.
• Prefix for plugins – If your custom post type belongs to a plugin, prefix the slug with a unique identifier (e.g., myplugin_product). This prevents collisions with other plugins or themes.
• Singular, not plural – Use singular form (product rather than products). WordPress handles pluralization through labels.

Common mistakes table:

Incorrect Slug	Issue	Correct Slug
my-products	Hyphen causes PHP naming inconsistency	my_products or myproduct
Products	Uppercase not allowed	product
post	Reserved core post type	custom_post
a_very_long_product_type_name	Exceeds 20 characters	product_type

How to Define $labels Array for Admin Menus

Once you have chosen a slug, you must define the $labels array. This array controls every human-readable string that appears in the WordPress admin dashboard: menu items, submenu names, update messages, and contextual prompts. WordPress uses these labels to make your custom post type feel native to the interface.

The register_post_type() function accepts a labels parameter. You build this as an associative array with specific keys. While you can technically omit many keys and WordPress will generate defaults based on your name and singular_name, defining all relevant labels improves user experience dramatically.

Essential labels you should always define:

• name – General plural name (e.g., “Products”). Used in menu titles and bulk actions.
• singular_name – Singular form (e.g., “Product”). Used for add-new buttons and edit screens.
• add_new – Text for the “Add New” button. Defaults to “Add New” if omitted.
• add_new_item – Title for the new item creation screen (e.g., “Add New Product”).
• edit_item – Title for the edit screen (e.g., “Edit Product”).
• new_item – Text for “New Product” in the admin menu.
• view_item – Link text to view the item on the front end.
• search_items – Text for the search button (e.g., “Search Products”).
• not_found – Message when no items exist (e.g., “No products found.”).
• not_found_in_trash – Message when trash is empty (e.g., “No products found in Trash.”).
• all_items – Text for the “All Items” submenu link.
• menu_name – Text that appears in the admin sidebar menu. Often matches name.

Additional labels for advanced contexts:

• item_published – Shown after publishing (e.g., “Product published.”).
• item_published_privately – For private visibility.
• item_reverted_to_draft – When reverting to draft.
• item_scheduled – For scheduled content.
• item_updated – Shown after updating an existing item.

When you define these labels, WordPress automatically uses them in admin screens, contextual help tabs, and update messages. This eliminates the need for custom string replacements and ensures consistency across the backend.

Example: Creating a ‘Product’ Post Type Labels

Let’s walk through a complete example for a custom post type that manages products in an e-commerce site. The slug will be product (singular, no hyphens, under 20 characters). Below is the $labels array you would pass to register_post_type():

$labels = array(
    'name'                  => _x( 'Products', 'Post Type General Name', 'textdomain' ),
    'singular_name'         => _x( 'Product', 'Post Type Singular Name', 'textdomain' ),
    'menu_name'             => __( 'Products', 'textdomain' ),
    'name_admin_bar'        => __( 'Product', 'textdomain' ),
    'archives'              => __( 'Product Archives', 'textdomain' ),
    'attributes'            => __( 'Product Attributes', 'textdomain' ),
    'parent_item_colon'     => __( 'Parent Product:', 'textdomain' ),
    'all_items'             => __( 'All Products', 'textdomain' ),
    'add_new_item'          => __( 'Add New Product', 'textdomain' ),
    'add_new'               => __( 'Add New', 'textdomain' ),
    'new_item'              => __( 'New Product', 'textdomain' ),
    'edit_item'             => __( 'Edit Product', 'textdomain' ),
    'update_item'           => __( 'Update Product', 'textdomain' ),
    'view_item'             => __( 'View Product', 'textdomain' ),
    'view_items'            => __( 'View Products', 'textdomain' ),
    'search_items'          => __( 'Search Product', 'textdomain' ),
    'not_found'             => __( 'Not found', 'textdomain' ),
    'not_found_in_trash'    => __( 'Not found in Trash', 'textdomain' ),
    'featured_image'        => __( 'Featured Image', 'textdomain' ),
    'set_featured_image'    => __( 'Set featured image', 'textdomain' ),
    'remove_featured_image' => __( 'Remove featured image', 'textdomain' ),
    'use_featured_image'    => __( 'Use as featured image', 'textdomain' ),
    'insert_into_item'      => __( 'Insert into product', 'textdomain' ),
    'uploaded_to_this_item' => __( 'Uploaded to this product', 'textdomain' ),
    'items_list'            => __( 'Products list', 'textdomain' ),
    'items_list_navigation' => __( 'Products list navigation', 'textdomain' ),
    'filter_items_list'     => __( 'Filter products list', 'textdomain' ),
);

Explanation of key choices:

• Internationalization – Each string is wrapped in _x() or __() with a textdomain. This makes your custom post type translation-ready. The _x() function adds context for translators.
• Consistent capitalization – “Product” is capitalized consistently across all labels. This matches WordPress core conventions where menu items use title case.
• Contextual precision – add_new_item says “Add New Product” rather than just “Add New”. This eliminates ambiguity when multiple post types exist.
• Featured image labels – These are often overlooked but critical for product-oriented sites where images are primary content.

How these labels appear in the admin:

• The left sidebar menu shows “Products” (from menu_name).
• Clicking “Add New” opens a screen titled “Add New Product” (from add_new_item).
• The “All Products” page shows “Products list” as the heading (from items_list).
• When no products exist, users see “Not found” (from not_found).
• After publishing, the admin notice reads “Product published.” (from item_published if defined).

Testing your labels: After registering the post type, navigate through every admin screen. Check the menu, the list table, the edit screen, and the publish notice area. If any string seems out of place (e.g., “Post” appears instead of “Product”), you likely missed a label key. Use the all_items and add_new_item keys as your minimum set for a functional interface, but define all keys for a polished experience.

Remember that labels are not just cosmetic. They affect accessibility (screen readers announce these strings), user workflow efficiency, and multi-language support. Investing time in precise, descriptive labels reduces support requests and training needs for content editors.

Step 2: Registering the Custom Post Type with register_post_type()

Once you have planned your custom post type and chosen a unique slug, the next step is to bring it to life using WordPress’s core function: register_post_type(). This function tells WordPress to recognize your new content type, adding it to the admin dashboard and making it available for queries, templates, and custom fields. While the function itself is straightforward, the power lies in the array of parameters you pass to it. These parameters control everything from visibility and menu placement to editing capabilities and URL structure.

Typically, you will place this registration call inside a function hooked to the init action. This ensures it runs early enough for WordPress to handle the new post type correctly. A minimal example looks like this:

function mytheme_register_book_post_type() {
    $args = array(
        'labels'  => array(
            'name'          => 'Books',
            'singular_name' => 'Book',
        ),
        'public'  => true,
    );
    register_post_type( 'book', $args );
}
add_action( 'init', 'mytheme_register_book_post_type' );

This registers a post type with the slug book, but it uses only the bare essentials. For a production-ready custom post type, you need to understand and configure the critical parameters that govern its behavior. Below, we break down the most important ones.

The Essential $args Parameters Explained

The $args array is the heart of register_post_type(). While there are over 40 possible parameters, a handful determine the core experience for both users and search engines. Here are the ones you must know:

Parameter	Type	Default	Purpose
public	boolean	false	Controls whether the post type is visible in the admin area and on the front end. Setting true is the most common choice for content types like portfolios or events.
show_in_menu	boolean or string	Value of public	Determines if the post type appears in the admin menu. Use true for a top-level menu item, or set it to a parent slug (e.g., 'edit.php') to nest it under Posts.
menu_icon	string	Pin icon	Accepts a Dashicons class (e.g., 'dashicons-book-alt') or a custom image URL. This replaces the default pin icon in the admin menu.
menu_position	integer	null	Sets the order in the admin menu. For example, 5 places it below Posts, 10 below Media, and 20 below Pages.
has_archive	boolean	false	Enables a post type archive page (e.g., /books/). Set to true to allow listing all items of that type.
supports	array	array('title', 'editor')	Defines which meta boxes appear in the post editor. This is crucial for controlling the editing experience.
rewrite	array or boolean	true	Configures URL permalinks for single and archive views. Set to false to disable pretty URLs entirely.

Important distinction: The public parameter is a shortcut that sets several other parameters at once, including publicly_queryable, show_ui, show_in_nav_menus, and show_in_admin_bar. If you need granular control, set public to false and configure each of these individually. For example, you might want a post type that appears in the admin but is not queryable on the front end (e.g., for internal data).

Another essential parameter is labels. While not listed in the table above, it deserves special mention. The labels array customizes all the text strings that WordPress uses for your post type, such as “Add New Book,” “Search Books,” and “All Books.” A complete labels array ensures your post type feels native and professional.

How to Set Supports (Title, Editor, Thumbnail, etc.)

The supports parameter defines which editing features are available in the WordPress block editor (or classic editor). By default, WordPress only enables the title and editor fields. To add featured images, excerpts, custom fields, or other meta boxes, you must explicitly list them in an array.

Here is a comprehensive list of the most commonly used support values:

• title – The post title field. Almost always required for content types.
• editor – The main content editor (block or classic).
• thumbnail – Enables the featured image meta box (often called “post thumbnail”).
• excerpt – Adds a textarea for a manual excerpt, used in archive views and feeds.
• custom-fields – Shows the custom fields meta box, useful for developers adding arbitrary metadata.
• comments – Enables the comments meta box for user discussion.
• trackbacks – Allows pingbacks and trackbacks.
• revisions – Stores post revisions, enabling users to revert to previous versions.
• author – Adds an author dropdown to assign ownership to another user.
• page-attributes – Provides the Page Attributes meta box for parent/child relationships and template selection (useful for hierarchical post types).
• post-formats – Adds support for Post Formats (standard, aside, gallery, etc.) if your theme supports them.

Example usage with a portfolio post type:

'supports' => array(
    'title',
    'editor',
    'thumbnail',
    'excerpt',
    'revisions',
    'custom-fields',
),

This configuration gives editors everything they need to create rich portfolio entries: a title, body content, a featured image, a short excerpt for listing pages, revision history, and the ability to add custom fields for extra data like project date or client name.

Pro tip: If you need additional meta boxes beyond these defaults, consider using Advanced Custom Fields (ACF) or the WordPress Meta Box API. However, always start with the built-in supports array—it reduces plugin dependencies and keeps your code lightweight.

Enabling Custom Rewrite Slugs for SEO-Friendly URLs

By default, the URL structure for a custom post type is based on its slug. For a post type registered as book, a single entry might appear at example.com/book/name-of-book/. The archive page (if enabled) would be at example.com/book/. While this works, you often want more control over the URL for branding, hierarchy, or SEO reasons. This is where the rewrite parameter comes in.

The rewrite parameter accepts either a boolean or an array. Setting it to false disables pretty permalinks entirely, forcing URLs like ?post_type=book&p=123. For most sites, you will want an array with the following keys:

Related reading: How to Optimize WordPress for High Traffic: A Comprehensive Guide

Array Key	Type	Description
slug	string	The URL prefix for the post type. Defaults to the post type slug. Change it to something like 'library' to make books appear at /library/name-of-book/.
with_front	boolean	Whether the URL should include the front base from your permalink settings (e.g., /blog/ if your permalink structure starts with /blog/). Set to false to ignore the front base.
feeds	boolean	Enables RSS feeds for the post type archive. Useful for podcasting or news sites.
pages	boolean	Enables pagination for the archive (e.g., /library/page/2/).
ep_mask	int	Sets the endpoint mask for advanced URL rewriting. Rarely needed unless you are adding custom endpoints.

Example configuration that creates an SEO-friendly URL structure:

'rewrite' => array(
    'slug'       => 'books',
    'with_front' => false,
    'feeds'      => true,
    'pages'      => true,
),

With this setup, a book titled “The Great Gatsby” would have the URL example.com/books/the-great-gatsby/, and the archive would be at example.com/books/. The with_front set to false ensures that if your permalink structure includes a category base like /blog/, it is not prepended to your book URLs.

SEO considerations: Custom rewrite slugs allow you to create logical, keyword-rich URL structures. For example, a “property” post type might use slug => 'real-estate/properties' to create a hierarchical URL like /real-estate/properties/123-main-street/. This helps search engines understand content relationships and can improve click-through rates from search results. However, always choose a slug that is stable—changing it later requires 301 redirects to avoid broken links.

After adding or modifying the rewrite parameter, you must flush WordPress’s rewrite rules. You can do this by visiting Settings > Permalinks and clicking “Save Changes” (no changes needed). Alternatively, call flush_rewrite_rules() in your theme’s activation hook, but never on every page load as it is resource-intensive.

Related reading: Home

With these three areas—essential parameters, supports, and rewrite rules—you have a solid foundation for registering a custom post type that is functional, user-friendly, and optimized for search engines. The next step is to create the template files that display your content on the front end, but that journey begins with a well-configured register_post_type() call.

Step 3: Adding the Code to Your Theme or Plugin

Once you have written the PHP code to register your custom post type, the next critical decision is where to place that code. WordPress offers two primary locations: your theme’s functions.php file or a dedicated plugin file. Each approach has distinct advantages and trade-offs regarding portability, maintenance, and future-proofing. This section will walk you through both methods, emphasizing best practices to avoid losing your work during theme updates and to keep your site stable while testing.

Using a Child Theme to Prevent Update Loss

Placing custom post type registration code directly into your active theme’s functions.php file is the quickest method. However, this approach carries a significant risk: if you update the parent theme—or switch to a different theme entirely—all your custom post type code will be lost. To avoid this, you must use a child theme.

A child theme inherits all the functionality and styling of its parent while allowing you to safely add custom code without being overwritten during updates. Here’s how to implement your custom post type code in a child theme:

1. Create a child theme folder. Navigate to /wp-content/themes/ and create a new folder, for example yourtheme-child.
2. Create a style.css file inside that folder with the required header:
   

   /*
   Theme Name: Your Theme Child
   Template: yourtheme
   */

   
   Replace yourtheme with the exact folder name of your parent theme.

3. Create a functions.php file in the child theme folder. This file will hold your custom post type registration code.
4. Add the registration code inside the child theme’s functions.php. Use the standard add_action( 'init', 'your_cpt_register_function' ); pattern. For example:
   

   function create_book_cpt() {
       $args = array(
           'public' => true,
           'label'  => 'Books',
           'supports' => array( 'title', 'editor', 'thumbnail' ),
       );
       register_post_type( 'book', $args );
   }
   add_action( 'init', 'create_book_cpt' );

5. Activate the child theme from the WordPress admin under Appearance > Themes.

Why this matters: When the parent theme updates, your child theme’s functions.php remains untouched. Your custom post type will continue to work seamlessly. Additionally, if you ever switch to a different child theme built on the same parent, your code remains intact as long as you reuse the same child theme folder.

Key considerations for child theme placement:

• Portability: The custom post type is tied to the child theme. If you switch to a completely different theme family, you must migrate the code.
• Site-specific logic: Ideal when your custom post type is closely related to the theme’s design (e.g., a “Portfolio” post type that uses theme templates).
• Simplicity: No extra files to manage beyond the child theme itself.

Creating a Simple Custom Post Type Plugin

For maximum portability and independence from your theme, placing your custom post type registration code inside a dedicated plugin is the recommended approach. A plugin remains active regardless of which theme you use, ensuring your custom content types persist even during major site redesigns.

Here is a step-by-step guide to creating a minimal plugin for a custom post type:

1. Create a plugin folder. In /wp-content/plugins/, create a new folder, such as custom-post-types.
2. Create the main plugin file. Inside that folder, create a file named custom-post-types.php.
3. Add the plugin header. This is required for WordPress to recognize the plugin. Use the following:
   

   <?php
   /**
    * Plugin Name: Custom Post Types
    * Description: Registers custom post types for this site.
    * Version: 1.0
    * Author: Your Name
    */

4. Insert your custom post type registration code below the header. For a clean structure, wrap it in a function and hook it to init. Example:
   

   function register_movie_cpt() {
       $labels = array(
           'name'               => 'Movies',
           'singular_name'      => 'Movie',
           'add_new'            => 'Add New Movie',
           'edit_item'          => 'Edit Movie',
           'view_item'          => 'View Movie',
           'search_items'       => 'Search Movies',
           'not_found'          => 'No movies found',
       );
       $args = array(
           'labels'    => $labels,
           'public'    => true,
           'has_archive' => true,
           'supports'  => array( 'title', 'editor', 'thumbnail', 'excerpt' ),
           'menu_icon' => 'dashicons-video-alt3',
       );
       register_post_type( 'movie', $args );
   }
   add_action( 'init', 'register_movie_cpt' );

5. Save and activate the plugin. Go to Plugins > Installed Plugins in your WordPress admin, find “Custom Post Types,” and click Activate.

Advantages of the plugin method:

• Theme-independent: Change themes freely without losing your custom post types.
• Reusable: Deploy the same plugin across multiple sites by simply copying the folder.
• Easier debugging: If a theme update causes issues, you can deactivate the plugin independently without affecting the entire theme.
• Clean separation: Keeps content logic separate from presentation logic, following WordPress best practices.

When to choose a plugin over a child theme:

Scenario	Recommended Location
Custom post type is content-focused (e.g., “Testimonials,” “Projects”)	Plugin
Custom post type requires specific theme templates (e.g., single-{cpt}.php)	Child theme
You plan to switch themes in the future	Plugin
You are developing for a client who may change themes	Plugin
You want the simplest possible setup	Child theme

Testing the Code Snippet Without Breaking Your Site

Before committing your custom post type code to a live production site, thorough testing in a safe environment is essential. A single syntax error in functions.php or a plugin file can trigger a white screen of death (WSOD) or make your admin dashboard inaccessible. Follow these proven testing steps to protect your site.

Step 1: Use a Staging or Local Environment
Always test new code on a staging site or a local WordPress installation (using tools like Local, XAMPP, or MAMP). This mirrors your live site without risk. If you must test on a live site, consider using a maintenance mode plugin to hide changes from visitors.

Step 2: Enable WordPress Debug Mode
Add the following lines to your wp-config.php file to catch errors without exposing them to users:

Related reading: How to Add a Link in WordPress: The Ultimate Internal Linking and SEO Architecture Guide

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );

This logs all errors to /wp-content/debug.log, which you can review after testing. Set WP_DEBUG_DISPLAY to true only if you are working in a local environment and want errors visible on screen.

Step 3: Test the Code Snippet in Isolation
Before adding the full registration code, test a minimal snippet. For example, add only the function name and a simple wp_die() to confirm the hook fires:

Related reading: How to Create a Custom WordPress Widget: A Step-by-Step Developer’s Guide

function test_cpt_hook() {
    wp_die( 'init hook works' );
}
add_action( 'init', 'test_cpt_hook' );

Load any frontend page. If you see the message “init hook works,” the hook is functioning. Remove this test code before proceeding.

Step 4: Add the Registration Code Incrementally
Start with the most basic register_post_type() call with minimal arguments. For instance:

function register_basic_cpt() {
    register_post_type( 'basic', array( 'public' => true, 'label' => 'Basics' ) );
}
add_action( 'init', 'register_basic_cpt' );

Visit your admin dashboard and confirm the new menu item appears under the “Basics” label. Then gradually add more arguments (supports, labels, rewrite rules) one at a time, checking for errors after each addition.

Step 5: Use a Fallback Mechanism
If you are editing functions.php directly and fear a lockout, add a conditional check at the top of the file to allow recovery. For example:

if ( isset( $_GET['disable_cpt'] ) ) {
    return;
}

If your site breaks after adding the code, you can append ?disable_cpt=1 to the admin URL to bypass the custom post type code temporarily. This trick works only if you have not yet caused a fatal error before the check runs—so place it as the very first line after the opening PHP tag.

Related reading: How to Backup Your WordPress Site (2026): Enterprise Guide

Step 6: Verify on Multiple Pages
After the code is in place, test the following:

• Admin dashboard loads without errors.
• Custom post type menu appears and is clickable.
• You can create, edit, and delete an entry of the new post type.
• Frontend single view and archive page (if enabled) render correctly.
• Search results include or exclude the custom post type as configured.

Step 7: Clear Permalinks
After activating a custom post type, always flush permalinks. Go to Settings > Permalinks and click “Save Changes” without modifying anything. This ensures the new rewrite rules are recognized and prevents 404 errors on your custom post type URLs.

Related reading: 10 Essential WordPress Plugins for Every Business Website

Common pitfalls to avoid:

• Duplicate names: Ensure your custom post type slug does not conflict with existing post types (e.g., post, page, attachment).
• Missing init hook: Never call register_post_type() outside of a hook; it must run during the init action.
• Syntax errors: A missing semicolon or unclosed bracket will break the entire site. Use a code editor with PHP syntax highlighting.
• Not backing up: Always export your database and files before adding new code to a live site.

By following these testing protocols, you can confidently add your custom post type registration code—whether in a child theme or a plugin—without risking the stability of your WordPress site. The extra minutes spent on careful testing will save hours of troubleshooting later.

Step 4: Flushing Rewrite Rules for Clean Permalinks

After you have successfully registered your custom post type, the next critical step is to ensure that the permalink structure for your new content type works correctly. Without this step, visitors (and search engines) who attempt to access a single post or archive page for your custom post type may encounter a frustrating 404 error. This occurs because WordPress stores its URL rewriting rules in the database, and these rules are not automatically updated when a new post type is registered. The process of updating these stored rules is known as “flushing rewrite rules.”

Understanding why this happens is essential. WordPress uses a sophisticated system to map human-readable URLs (like yoursite.com/movies/star-wars) to the underlying query parameters that load the correct content. When you register a custom post type, you are essentially adding a new set of URL patterns that WordPress must recognize. However, the database table that holds these rewrite rules is only rebuilt under specific circumstances, such as when you save your permalink settings or when a plugin or theme explicitly triggers a flush. If you simply register your post type and visit a URL, the old rules (which do not include your new post type) are still active, leading to a 404.

There are two primary methods to flush rewrite rules: automatically, through code executed during theme activation, and manually, through the WordPress admin panel. Each method has its appropriate use cases, and choosing the right one is crucial for both developer experience and site performance.

Automatic Flush on Theme Activation

The most robust and recommended approach for a custom theme is to flush rewrite rules automatically when your theme is activated. This ensures that the moment a user activates your theme, all custom post types (and any custom taxonomies) are immediately recognized by the URL routing system. This method is particularly important if you are distributing a theme for others to use, as it prevents the initial confusion of broken links.

To implement this, you will hook into the after_switch_theme action. This action runs once, immediately after the theme is activated. Here is the standard pattern for doing this safely:

function mytheme_flush_rewrites_on_activation() {
    // Ensure your custom post type is registered before flushing.
    // If you have a dedicated function for registering post types,
    // call it here.
    mytheme_register_custom_post_types();

    // Then flush the rewrite rules.
    flush_rewrite_rules();
}
add_action( 'after_switch_theme', 'mytheme_flush_rewrites_on_activation' );

There is an important nuance here: you must ensure that your custom post type registration function is called before you call flush_rewrite_rules(). If you flush the rules without first registering the post type, WordPress will flush the old rules without knowing about your new URLs. The sequence is therefore:

1. Register the post type (typically by calling your registration function).
2. Call flush_rewrite_rules().

It is also worth noting that you should not call flush_rewrite_rules() on every page load, such as from init or wp_loaded. Doing so would cause a massive performance penalty because WordPress would be rebuilding the entire rewrite rule array on every request. The automatic flush on theme activation is a one-time event, making it safe and efficient.

If you are developing a plugin, the equivalent hook is register_activation_hook. The principle is identical: register your post types, then flush the rules. This ensures that when a site administrator activates your plugin, the URLs are immediately functional.

Manual Flush via Settings > Permalinks

For situations where automatic flushing is not possible or has already occurred, or if you are troubleshooting a 404 error after making changes to a post type’s rewrite slug or arguments, a manual flush is the simplest solution. This method requires no coding and can be performed by any WordPress administrator.

The manual process is deceptively simple:

1. Navigate to your WordPress admin dashboard.
2. Go to Settings > Permalinks.
3. At the bottom of the Permalinks settings page, click the Save Changes button.

You do not need to change any of the permalink structure options. Simply clicking the “Save Changes” button forces WordPress to regenerate and flush the rewrite rules database. This action effectively tells WordPress to re-examine all registered post types, taxonomies, and other rewrite rules, and rebuild the URL mapping from scratch. After doing this, your custom post type URLs should start working immediately.

This manual method is particularly useful during development. For example, if you change the rewrite argument of your custom post type (such as changing the slug from movies to films), the old rewrite rules will still map to the old slug. A manual flush will update the rules to recognize the new slug. It is also a common first step in debugging any unexpected 404 errors related to custom content types.

However, relying on this manual method for end users is not ideal. If you distribute a theme or plugin, you cannot expect every user to know that they must visit the Permalinks settings page. Therefore, the automatic flush on activation is the preferred method for a polished user experience.

Avoiding Performance Pitfalls with Repeated Flushing

While flushing rewrite rules is a necessary part of custom post type development, it is an operation that carries a significant performance cost. The rewrite rules are stored as a serialized array in the options table of your WordPress database. When you flush them, WordPress must:

• Query all registered post types, taxonomies, and other rewrite-contributing components.
• Build a comprehensive array of URL patterns and their corresponding query variables.
• Serialize that array and save it back to the database.

This process can be resource-intensive, especially on sites with many custom post types, taxonomies, or complex permalink structures. The most common performance pitfall is flushing rewrite rules on every page load. This is often done accidentally by developers who place flush_rewrite_rules() inside a function hooked to init or wp_loaded without a conditional check. The result is a site that runs slowly for every visitor, as the database is hammered with a rewrite rebuild on each request.

To avoid this, follow these best practices:

Practice	Why It Matters
Flush only on activation or deactivation	Ensures the flush happens exactly once, not on every page load.
Use a flag to track if flushing is needed	If you must flush outside of activation (e.g., after saving plugin settings), set a transient or option flag, then flush only when that flag is present.
Avoid flushing from init or wp_loaded	These hooks run on every request; flushing here is a performance disaster.
Test on a staging site first	If your site has many custom post types, a flush can cause a noticeable slowdown; test the impact before deploying to production.

Another common mistake is flushing rewrite rules inside a loop or a function that runs multiple times. For example, if you register three custom post types and flush after each registration, you are performing three expensive database writes instead of one. The correct approach is to register all post types first, then flush once at the end.

Finally, be aware that some caching plugins or hosting environments may cache the rewrite rules or the database queries involved. In such cases, a manual flush via the admin panel may appear to have no effect. If you are still seeing 404 errors after flushing, try clearing your site’s cache and any server-level cache (such as Redis or Varnish). Additionally, ensure that your web server’s .htaccess file (for Apache) or nginx.conf (for Nginx) is writable, as WordPress may need to update these files as part of the rewrite process.

By understanding when and how to flush rewrite rules—and equally important, when not to—you can ensure that your custom post type operates with clean, reliable permalinks without degrading site performance. This step, while often overlooked, is what transforms a technically correct post type registration into a fully functional, user-friendly content architecture.

Step 5: Customizing the Admin Interface

Once you have registered a custom post type in WordPress, the default admin interface is functional but often too generic for specialized content. The posts list table shows standard columns like Title, Date, and Author, and the edit screen provides only the default editor and publishing meta box. To make your custom post type truly useful for editors, site managers, or clients, you need to tailor these interfaces. This step covers three core customizations: adding custom admin columns, making those columns sortable, and building a simple meta box for storing additional metadata. Each technique uses WordPress hooks and is implemented in your theme’s functions.php file or a site-specific plugin.

Adding Custom Admin Columns with manage_edit-{post_type}_columns

The manage_edit-{post_type}_columns filter lets you add, remove, or reorder columns in the posts list table for your custom post type. Replace {post_type} with the actual slug of your post type (e.g., manage_edit-book_columns for a post type named book). This hook receives a single parameter: an associative array of column IDs and their display labels.

To add a column, append a new key-value pair to the array. To remove a default column, unset its key. Common columns to add include custom meta values, featured images, or taxonomy terms. Below is an example that adds a “Price” column and removes the “Author” column for a post type called product:

function custom_product_columns( $columns ) {
    // Remove the 'author' column
    unset( $columns['author'] );
    // Add a new 'price' column after the 'title' column
    $new_columns = array();
    foreach ( $columns as $key => $value ) {
        $new_columns[ $key ] = $value;
        if ( $key === 'title' ) {
            $new_columns['price'] = __( 'Price', 'textdomain' );
        }
    }
    return $new_columns;
}
add_filter( 'manage_edit-product_columns', 'custom_product_columns' );

Adding the column definition alone does not populate it with data. You must also use the manage_{post_type}_posts_custom_column action hook to output content for each row. This hook passes the column slug and the post ID. For the price example:

function custom_product_column_data( $column, $post_id ) {
    if ( $column === 'price' ) {
        $price = get_post_meta( $post_id, '_product_price', true );
        if ( $price ) {
            echo '$' . esc_html( $price );
        } else {
            echo '—';
        }
    }
}
add_action( 'manage_product_posts_custom_column', 'custom_product_column_data', 10, 2 );

Useful columns to consider for different content types:

• Featured Image: Display a small thumbnail using the_post_thumbnail( array( 50, 50 ) ).
• Custom Meta Value: Show a shortcode, SKU, rating, or location.
• Taxonomy Terms: List assigned categories or custom taxonomies with get_the_term_list().
• Post Status or Visibility: Indicate if a post is published, draft, or password-protected.
• Post ID: Helpful for debugging or referencing posts externally.

Making Columns Sortable with manage_edit-{post_type}_sortable_columns

Adding a custom column is only half the battle. Users expect to click column headers to sort data alphabetically, numerically, or by date. The manage_edit-{post_type}_sortable_columns filter lets you define which custom columns are clickable and sortable. This hook returns an array where the keys are column slugs and the values are the meta key (or query variable) used for sorting.

For the price column example, you would add:

function custom_product_sortable_columns( $columns ) {
    $columns['price'] = '_product_price';
    return $columns;
}
add_filter( 'manage_edit-product_sortable_columns', 'custom_product_sortable_columns' );

Declaring a column as sortable does not automatically make the sorting work correctly. You must also intercept the main query in the admin area to order by your custom meta key. Use the pre_get_posts action to modify the query when the sort order is set:

Related reading: TEST page

function custom_product_sortable_query( $query ) {
    if ( ! is_admin() || ! $query->is_main_query() ) {
        return;
    }
    $orderby = $query->get( 'orderby' );
    if ( $orderby === '_product_price' ) {
        $query->set( 'meta_key', '_product_price' );
        $query->set( 'orderby', 'meta_value_num' );
        // Use 'meta_value' for text, 'meta_value_num' for numeric values
    }
}
add_action( 'pre_get_posts', 'custom_product_sortable_query' );

Important considerations for sortable columns:

• Meta Key Existence: If some posts lack the meta key, they may not appear in sorted results. Consider using a default value when saving posts.
• Data Type: Use meta_value_num for integers and floats, meta_value for strings, and meta_value_datetime for dates stored in Unix timestamp format.
• Performance: Sorting by meta values can be slow on large sites. For high-traffic admin areas, consider storing sortable data in a dedicated database column or using a transient cache.
• Multiple Sortable Columns: You can declare multiple columns; each will use its own meta key and query modification logic.

Here is a quick reference table for common sortable column data types:

Related reading: How to Build a Fully Automated Automotive Marketplace with API Integration

Data Type	Meta Key Example	orderby Value	Notes
Integer (price, count)	_product_price	meta_value_num	Stored as number, sorts numerically
String (title, name)	_product_sku	meta_value	Sorts alphabetically
Date (timestamp)	_event_date	meta_value_num	Use Unix timestamp; sort chronologically
Date (formatted)	_release_date	meta_value	If stored as YYYY-MM-DD, sorts correctly as string

Building a Simple Meta Box for Additional Fields

Custom columns display data that you have already stored. To allow editors to input that data (like price, SKU, or event date), you need a custom meta box on the edit screen. A meta box groups custom fields into a visually distinct panel. WordPress provides the add_meta_box() function and the add_meta_boxes action hook to create them.

First, define the meta box using add_meta_box() inside a function hooked to add_meta_boxes_{post_type} (or the generic add_meta_boxes). The function requires a unique ID, a title, a callback to render the HTML, the screen (post type), and optional parameters for context and priority:

function add_product_details_meta_box() {
    add_meta_box(
        'product_details',
        __( 'Product Details', 'textdomain' ),
        'render_product_details_meta_box',
        'product',
        'normal',
        'default'
    );
}
add_action( 'add_meta_boxes_product', 'add_product_details_meta_box' );

Next, create the callback function that outputs the HTML for the meta box. This function receives the post object as a parameter. Inside, you retrieve existing meta values using get_post_meta() and output form fields. Always include a nonce field for security:

function render_product_details_meta_box( $post ) {
    // Add nonce for verification
    wp_nonce_field( 'product_details_save', 'product_details_nonce' );
    // Retrieve existing values
    $price = get_post_meta( $post->ID, '_product_price', true );
    $sku   = get_post_meta( $post->ID, '_product_sku', true );
    ?>
    

        
        <input type="number" step="0.01" name="product_price" id="product_price" value="" class="regular-text" />
    
    

        
        <input type="text" name="product_sku" id="product_sku" value="" class="regular-text" />
    
    <?php
}

Finally, save the meta box data using the save_post_{post_type} hook. This action runs every time a post is saved. Validate the nonce, check for autosaves, and then update the meta fields:

function save_product_details_meta( $post_id ) {
    // Check nonce
    if ( ! isset( $_POST['product_details_nonce'] ) || ! wp_verify_nonce( $_POST['product_details_nonce'], 'product_details_save' ) ) {
        return;
    }
    // Check autosave
    if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) {
        return;
    }
    // Check user permissions
    if ( ! current_user_can( 'edit_post', $post_id ) ) {
        return;
    }
    // Save price
    if ( isset( $_POST['product_price'] ) ) {
        $price = sanitize_text_field( $_POST['product_price'] );
        update_post_meta( $post_id, '_product_price', $price );
    }
    // Save SKU
    if ( isset( $_POST['product_sku'] ) ) {
        $sku = sanitize_text_field( $_POST['product_sku'] );
        update_post_meta( $post_id, '_product_sku', $sku );
    }
}
add_action( 'save_post_product', 'save_product_details_meta' );

Best practices for meta boxes:

• Context: Use normal for primary content fields, side for secondary data (like price or status), and advanced for fields that appear below the editor.
• Field Types: Use appropriate HTML input types: text, number, url, email, textarea, select, or checkbox.
• Sanitization: Always sanitize input with sanitize_text_field(), intval(), or wp_kses_post() depending on the data.
• User Experience: Group related fields, use clear labels, and provide placeholder text or descriptions for complex fields.
• Reusability: Consider creating a helper function to register multiple meta boxes or fields, especially for post types with many custom fields.

By implementing these three customizations—columns, sortable columns, and meta boxes—you transform the WordPress admin from a generic interface into a purpose-built tool for managing your custom content. Editors can see key information at a glance, sort data meaningfully, and input structured metadata without leaving the post editor. This step completes the functional layer of your custom post type, making it ready for real-world use.

Related reading: WordPress + React: Leveraging MERN Skills to Supercharge Elementor Websites

Step 6: Displaying Custom Post Types on the Front End

After registering a custom post type in WordPress, the next critical step is controlling how that content appears to visitors. By default, WordPress provides basic URLs for your custom post type, but the display relies entirely on template files. This step walks you through creating dedicated archive and single templates, using WP_Query for custom loops, and leveraging standard template tags for consistent output. Proper front-end display ensures your custom content is accessible, styled, and integrated into your theme seamlessly.

Creating archive-{post_type}.php and single-{post_type}.php

The WordPress template hierarchy provides a predictable system for loading templates based on the content type. For a custom post type named portfolio, the hierarchy looks for these files in order:

• Archive page: archive-portfolio.php → archive.php → index.php
• Single post page: single-portfolio.php → single.php → singular.php → index.php

Creating archive-portfolio.php gives you full control over the listing of all portfolio items. A minimal archive template might look like this:

<?php get_header(); ?>
<div class="portfolio-archive">
    <h1>Portfolio</h1>
    <?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?>
        <article id="post-<?php the_ID(); ?>" <?php post_class(); ?>>
            <h2><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></h2>
            <div class="entry-summary"><?php the_excerpt(); ?></div>
        </article>
    <?php endwhile; endif; ?>
    <?php the_posts_navigation(); ?>
</div>
<?php get_footer(); ?>

For the single post view, single-portfolio.php handles the full content display:

<?php get_header(); ?>
<?php while ( have_posts() ) : the_post(); ?>
    <article id="post-<?php the_ID(); ?>" <?php post_class(); ?>>
        <h1><?php the_title(); ?></h1>
        <div class="entry-content">
            <?php the_content(); ?>
        </div>
        <?php if ( has_post_thumbnail() ) : ?>
            <div class="post-thumbnail">
                <?php the_post_thumbnail( 'large' ); ?>
            </div>
        <?php endif; ?>
    </article>
<?php endwhile; ?>
<?php get_footer(); ?>

Key considerations when building these templates:

Related reading: How Much Does WordPress Cost ? The Complete Enterprise Pricing and Budget Blueprint

Element	Best Practice
Post classes	Use post_class() to add dynamic CSS classes for styling
Permalinks	Always use the_permalink() for correct URL generation
Pagination	Include the_posts_pagination() for archive pages
Custom fields	Use get_post_meta() or ACF functions inside the loop
Fallback templates	Test with archive.php and single.php if custom files don’t exist

Remember to flush permalinks after creating these files by visiting Settings → Permalinks and clicking “Save Changes.” This ensures your custom post type URLs resolve correctly.

Using WP_Query to Display Custom Post Types in Any Template

Sometimes you need to show custom post type entries outside their native archive—for example, on the homepage, in a sidebar, or within a page template. WP_Query gives you complete flexibility to create custom loops anywhere in your theme.

Basic syntax for querying a custom post type:

<?php
$portfolio_query = new WP_Query( array(
    'post_type'      => 'portfolio',
    'posts_per_page' => 6,
    'orderby'        => 'date',
    'order'          => 'DESC',
) );

if ( $portfolio_query->have_posts() ) :
    while ( $portfolio_query->have_posts() ) : $portfolio_query->the_post();
        // Display post content here
    endwhile;
    wp_reset_postdata();
endif;
?>

Common use cases for WP_Query with custom post types:

• Featured items on homepage: Query only posts marked as “featured” via a custom field.
• Related content: Show posts from the same taxonomy term on a single post page.
• Widget areas: Display recent testimonials or portfolio items in a sidebar.
• Page templates: Create a custom page template that lists all events or products.

Advanced query parameters to filter results:

Parameter	Example Value	Purpose
meta_key	'featured'	Filter by custom field value
tax_query	array( 'taxonomy' => 'portfolio_category', 'field' => 'slug', 'terms' => 'design' )	Filter by taxonomy term
posts_per_page	-1	Show all posts (use cautiously)
paged	get_query_var( 'paged' )	Support pagination in custom queries
post__not_in	array( 42 )	Exclude specific post IDs

Critical: Always call wp_reset_postdata() after a custom WP_Query loop. This restores the global $post variable to the current post in the main query, preventing conflicts with other loops on the same page.

Looping Through Custom Post Type Entries with Standard Tags

Once you have a query, use standard WordPress template tags to output content. These tags work identically for custom post types as they do for regular posts, making your code portable and familiar.

Related reading: How to Build a Custom WordPress Theme from Scratch: A Complete Step-by-Step Guide

Essential template tags for custom post type loops:

• the_title() – Displays the post title wrapped in an HTML tag of your choice.
• the_permalink() – Outputs the URL to the single post view.
• the_content() – Shows the full content, typically used on single pages.
• the_excerpt() – Displays a trimmed version of the content, ideal for archive listings.
• the_post_thumbnail() – Outputs the featured image at a specified size.
• the_terms() – Lists taxonomy terms (categories, tags, or custom taxonomies) linked to their archive pages.
• the_ID() – Prints the post ID, useful for CSS targeting or JavaScript.
• post_class() – Generates a string of CSS classes based on post properties.

A complete loop example combining these tags for a portfolio listing:

Related reading: Clean Code in Elementor: How to Maintain Performance While Using Page Builders

<?php
$portfolio_items = new WP_Query( array(
    'post_type'      => 'portfolio',
    'posts_per_page' => 9,
    'orderby'        => 'menu_order',
    'order'          => 'ASC',
) );

if ( $portfolio_items->have_posts() ) : ?>
    <div class="portfolio-grid">
        <?php while ( $portfolio_items->have_posts() ) : $portfolio_items->the_post(); ?>
            <article id="post-<?php the_ID(); ?>" <?php post_class( 'portfolio-item' ); ?>>
                <?php if ( has_post_thumbnail() ) : ?>
                    <a href="<?php the_permalink(); ?>" class="portfolio-thumbnail">
                        <?php the_post_thumbnail( 'medium' ); ?>
                    </a>
                <?php endif; ?>
                <h3 class="portfolio-title">
                    <a href="<?php the_permalink(); ?>"><?php the_title(); ?></a>
                </h3>
                <div class="portfolio-excerpt">
                    <?php the_excerpt(); ?>
                </div>
                <div class="portfolio-meta">
                    <?php the_terms( get_the_ID(), 'portfolio_category', 'Category: ', ', ' ); ?>
                </div>
            </article>
        <?php endwhile; ?>
    </div>
    <?php
    // Pagination for custom query
    echo paginate_links( array(
        'total' => $portfolio_items->max_num_pages,
    ) );
    ?>
    <?php wp_reset_postdata(); ?>
<?php else : ?>
    <p>No portfolio items found.</p>
<?php endif; ?>

Styling considerations: Custom post types often benefit from distinct CSS classes. Use post_class() to add custom classes like portfolio-item, and target them in your theme’s stylesheet. For more granular control, wrap your output in semantic HTML5 elements (<article>, <section>, <figure>) and apply responsive grid systems or flexbox for layout.

Performance note: When using multiple WP_Query instances on a single page, each query executes a separate database call. Cache expensive queries with WordPress transients or object caching to reduce server load. For simple listings, consider using pre_get_posts to modify the main query instead of creating secondary loops.

By combining dedicated template files, flexible WP_Query usage, and standard template tags, you gain complete control over how your custom post type content is presented. This approach keeps your code maintainable, follows WordPress best practices, and ensures a consistent user experience across your site.

Step 7: Adding Taxonomies and Custom Fields

After registering your custom post type, the next logical step is to organize and enrich the content it stores. Taxonomies allow you to group and filter posts, while custom fields (post meta) let you attach arbitrary data to each entry. Without these two systems, a custom post type is little more than a renamed “post” — it lacks the structural depth that makes custom content types truly powerful. In this section, you will learn how to register new taxonomies, connect existing ones, and store extra data using both the built-in post meta system and the popular Advanced Custom Fields plugin.

Registering a Custom Taxonomy with register_taxonomy()

WordPress provides a function called register_taxonomy() that works almost identically to register_post_type(). It accepts three parameters: the taxonomy name (slug), the object type(s) it applies to, and an array of arguments. Below is a complete example that registers a “Genre” taxonomy for a “Book” custom post type:

function create_book_genre_taxonomy() {
    $labels = array(
        'name'              => __( 'Genres', 'textdomain' ),
        'singular_name'     => __( 'Genre', 'textdomain' ),
        'search_items'      => __( 'Search Genres', 'textdomain' ),
        'all_items'         => __( 'All Genres', 'textdomain' ),
        'parent_item'       => __( 'Parent Genre', 'textdomain' ),
        'parent_item_colon' => __( 'Parent Genre:', 'textdomain' ),
        'edit_item'         => __( 'Edit Genre', 'textdomain' ),
        'update_item'       => __( 'Update Genre', 'textdomain' ),
        'add_new_item'      => __( 'Add New Genre', 'textdomain' ),
        'new_item_name'     => __( 'New Genre Name', 'textdomain' ),
        'menu_name'         => __( 'Genres', 'textdomain' ),
    );
    $args = array(
        'hierarchical'      => true, // true = like categories, false = like tags
        'labels'            => $labels,
        'show_ui'           => true,
        'show_admin_column' => true,
        'query_var'         => true,
        'rewrite'           => array( 'slug' => 'genre' ),
        'show_in_rest'      => true, // enables Gutenberg and REST API support
    );
    register_taxonomy( 'genre', 'book', $args );
}
add_action( 'init', 'create_book_genre_taxonomy' );

Key arguments to understand:

• hierarchical: Set to true for a category-like structure (parent/child terms) or false for a tag-like structure (flat, non-hierarchical).
• show_admin_column: When true, the taxonomy terms appear as a column in the post type list table in the admin area.
• show_in_rest: Enables the taxonomy in the WordPress REST API and the block editor (Gutenberg). Always set this to true for modern development.
• rewrite: Controls the URL slug for taxonomy archive pages (e.g., /genre/fiction/).

Always call register_taxonomy() inside a function hooked to init, and make sure it runs after the custom post type is registered. If both registrations happen on the same hook, WordPress will still connect them correctly as long as the post type exists by the time the taxonomy is registered.

Connecting Existing Taxonomies to Your Custom Post Type

You do not always need to create a new taxonomy. Often, you want to reuse WordPress’s built-in taxonomies — categories and tags — with your custom post type. This is especially useful when your custom content type shares a common organizational scheme with regular posts. To attach an existing taxonomy, use register_taxonomy_for_object_type() or pass the taxonomy in the taxonomies argument during post type registration.

Related reading: WordPress vs. Custom Code: Which One Should You Choose?

Method 1: During post type registration

Add a taxonomies key to the $args array of register_post_type():

$args = array(
    'public'      => true,
    'label'       => 'Books',
    'taxonomies'  => array( 'category', 'post_tag' ),
    // ... other arguments
);
register_post_type( 'book', $args );

This immediately adds the category and tag meta boxes to the book editor screen and enables the taxonomy archive URLs for your post type.

Method 2: Using register_taxonomy_for_object_type()

If you already registered the post type and need to add a taxonomy later, use this function inside an init hook:

function add_categories_to_books() {
    register_taxonomy_for_object_type( 'category', 'book' );
    register_taxonomy_for_object_type( 'post_tag', 'book' );
}
add_action( 'init', 'add_categories_to_books' );

This approach is cleaner when you want to keep post type and taxonomy registrations separate, or when you are extending a post type registered by a plugin or theme.

Important considerations:

• When you reuse built-in taxonomies, the same term database table is shared across all post types. A category assigned to a “Book” post also appears in the category list for regular posts. If you need separate term sets, register a custom taxonomy instead.
• If you want the taxonomy to appear in the REST API for your custom post type, ensure both the post type and the taxonomy have show_in_rest set to true.
• For hierarchical taxonomies (like categories), you can still use wp_list_categories() and wp_dropdown_categories() with the taxonomy parameter set to 'category' to display terms filtered by your custom post type.

Storing Extra Data with Post Meta (Custom Fields)

Taxonomies group posts; custom fields store individual data points per post. WordPress stores this data in the wp_postmeta table as key-value pairs. You can add custom fields manually via the editor screen, programmatically with PHP, or through a plugin like Advanced Custom Fields (ACF). Each approach has its place depending on the project’s complexity and the client’s needs.

Manual meta boxes (code-based approach)

To create a simple meta box for a single text field (e.g., “ISBN Number” for a book post type), follow these steps:

1. Add the meta box using add_meta_box() inside the add_meta_boxes action hook.
2. Render the field in a callback function that outputs HTML.
3. Save the data using the save_post hook and update_post_meta().

function book_add_meta_boxes() {
    add_meta_box(
        'book_isbn',
        __( 'ISBN Number', 'textdomain' ),
        'book_isbn_meta_box_callback',
        'book',
        'side',
        'default'
    );
}
add_action( 'add_meta_boxes', 'book_add_meta_boxes' );

function book_isbn_meta_box_callback( $post ) {
    $value = get_post_meta( $post->ID, '_book_isbn', true );
    wp_nonce_field( 'book_isbn_nonce', 'book_isbn_nonce_field' );
    echo '<label for="book_isbn_field">' . __( 'ISBN', 'textdomain' ) . '</label> ';
    echo '<input type="text" id="book_isbn_field" name="book_isbn_field" value="' . esc_attr( $value ) . '" size="25" />';
}

function book_save_isbn_meta( $post_id ) {
    if ( ! isset( $_POST['book_isbn_nonce_field'] ) ) return;
    if ( ! wp_verify_nonce( $_POST['book_isbn_nonce_field'], 'book_isbn_nonce' ) ) return;
    if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) return;
    if ( ! current_user_can( 'edit_post', $post_id ) ) return;

    if ( isset( $_POST['book_isbn_field'] ) ) {
        update_post_meta( $post_id, '_book_isbn', sanitize_text_field( $_POST['book_isbn_field'] ) );
    }
}
add_action( 'save_post', 'book_save_isbn_meta' );

Notice the underscore prefix (_book_isbn) in the meta key. This hides the field from the default “Custom Fields” meta box in the admin, which is best practice for internal meta keys.

Using Advanced Custom Fields (ACF)

For projects with many fields — such as price, author, publisher, and publication date — writing manual meta boxes becomes tedious and error-prone. ACF provides a user-friendly interface for building field groups and returns data in a consistent format. To integrate ACF with your custom post type:

• Install the ACF plugin (free or pro).
• Create a new field group in Custom Fields > Add New.
• Set the location rule to “Post Type is equal to Book” (or your custom post type slug).
• Add fields (e.g., text, number, date picker, WYSIWYG editor).
• In your theme templates, retrieve values using get_field( 'field_name', $post_id ) or the the_field() function.

ACF also supports repeater fields, flexible content, and relationship fields, making it ideal for complex data structures. The plugin stores its data in the same wp_postmeta table, so you can still query posts by meta values using WP_Query with meta_key and meta_value parameters.

When to choose manual vs. ACF:

Criteria	Manual Meta Boxes	Advanced Custom Fields
Number of fields	1–3 simple fields	Any number, including complex fields
Client maintenance	Not suitable for non-developers	Client-friendly UI
Performance	No plugin overhead	Slight overhead from plugin
Flexibility	Full control over HTML and logic	Limited to ACF field types
Portability	No dependency	Requires plugin to be active

Regardless of which method you choose, always sanitize and validate user input when saving meta data. Use sanitize_text_field() for plain text, intval() for integers, and wp_kses_post() for HTML content. This prevents security vulnerabilities and ensures data integrity across your custom post type.

With taxonomies and custom fields in place, your custom post type now has both organizational structure and rich data storage. The next step is to display this information on the front end using template files and WordPress loops.

Troubleshooting Common Issues

Even with a solid understanding of how to create a custom post type in WordPress, implementation rarely goes perfectly on the first attempt. Whether you are a seasoned developer or just starting out, you will inevitably encounter a handful of recurring problems. These issues often stem from WordPress’s rewrite rules, capability checks, or theme conflicts. Below, we break down the most frequent obstacles and provide clear, actionable solutions to get your custom post types working correctly.

Why Your Custom Post Type Returns a 404 Error

One of the most frustrating issues when learning how to create a custom post type in WordPress is encountering a 404 error when trying to view a single post or archive page. This usually indicates that WordPress cannot find the correct URL structure for your new post type. The root cause is almost always related to permalink settings and rewrite rules.

Primary cause: Flushed rewrite rules. WordPress stores URL rewrite rules in the database. When you register a new custom post type, the rules for its slug (e.g., /projects/ or /portfolio/) are not automatically added. To fix this, you must flush the rewrite rules. The simplest method is:

1. Go to Settings > Permalinks in your WordPress admin dashboard.
2. Without making any changes, simply click Save Changes.
3. This action triggers a flush of the rewrite rules, which should resolve most 404 errors.

If the 404 persists, check these additional factors:

• Incorrect rewrite parameter: In your register_post_type() function, ensure the rewrite argument includes a unique slug. For example: 'rewrite' => array('slug' => 'your-slug'). Avoid using slugs that conflict with existing pages or taxonomies.
• Missing has_archive parameter: If you want an archive page (e.g., /projects/), set 'has_archive' => true. Without this, the archive URL will return a 404.
• Conflicting post type slug: If your slug matches a page slug (e.g., a page named “Projects” and a post type slug “projects”), WordPress will prioritize the page. Use a distinct slug like our-projects or portfolio-items.
• Custom permalink structure: If you use a custom permalink structure (e.g., /%postname%/), ensure your post type rewrite slug does not contain dynamic tags like %category% unless you have also registered the appropriate rewrite endpoints.

Table: Quick 404 Diagnostic Checklist

Step	Action	Expected Result
1	Flush permalinks (Settings > Permalinks > Save)	404 resolved for most cases
2	Verify rewrite slug is unique and not a page slug	No conflict with existing content
3	Check has_archive is set to true for archive pages	Archive URL loads correctly
4	Clear any caching plugins (e.g., W3 Total Cache, WP Rocket)	Updated rules take effect

Admin Menu Not Showing? Check show_in_menu and Capabilities

After registering a custom post type, you might find that it does not appear in the WordPress admin menu. This is a common stumbling block, especially when working with more advanced configurations. The issue usually lies in two specific parameters: show_in_menu and capability_type.

1. The show_in_menu parameter

By default, show_in_menu is set to true when public is true. However, if you explicitly set show_in_menu to false, the post type will be hidden from the admin menu entirely. If you want the post type to appear as a top-level menu item, use:

'show_in_menu' => true

If you want it as a submenu under an existing menu (e.g., under “Settings” or “Tools”), use the menu slug of the parent item:

'show_in_menu' => 'edit.php?post_type=page'

This will place your custom post type under the “Pages” menu. For a submenu under “Settings”, use 'options-general.php'. For “Tools”, use 'tools.php'.

Related reading: How to Add Alt Text to Images in WordPress: The Complete Image SEO and Accessibility Guide

2. Capabilities and user roles

WordPress uses capabilities to determine who can see and interact with admin menu items. If your custom post type uses a custom capability_type, you must ensure that the appropriate user roles have the corresponding capabilities. The most common mistake is using 'capability_type' => 'post' (which is the default) but then assigning custom capabilities without mapping them to roles.

To debug this, temporarily switch to an administrator account. If the menu appears for admins but not for editors or authors, the issue is capability-related. You have two solutions:

• Use the default capability_type: Set 'capability_type' => 'post' and rely on WordPress’s built-in post capabilities (edit_posts, publish_posts, etc.). This works for most projects.
• Map custom capabilities: If you need custom capabilities, use the capabilities parameter to map them to existing roles. For example, you can map 'edit_posts' to 'edit_others_posts' for editors. Alternatively, use a plugin like “User Role Editor” to assign capabilities to roles after registration.

3. The show_ui and show_in_nav_menus parameters

While less common, setting show_ui to false will hide the post type from the admin interface entirely, even if show_in_menu is true. Similarly, show_in_nav_menus controls visibility in the Appearance > Menus section. Ensure these are set to true if you want full admin access.

Resolving Template Conflicts with Plugin-Based Post Types

When you learn how to create a custom post type in WordPress, you often expect your theme’s template hierarchy to handle display automatically. However, conflicts arise when another plugin registers a post type with the same slug, or when your theme’s template files override your intended output. This is particularly common with popular plugins like “Custom Post Type UI,” “Toolset,” or “Advanced Custom Fields” that also generate post types.

Step 1: Identify the source of the template

WordPress follows a strict template hierarchy. For a single custom post type, it looks for single-{post_type}.php first, then single.php, then singular.php, and finally index.php. If your post type is not using the template you expect, check which file is actually loading. You can do this by adding a temporary debug line to your theme’s functions.php:

add_filter( 'template_include', function( $template ) {
    echo '<!-- Template: ' . basename( $template ) . ' -->';
    return $template;
});

View the page source to see which template file is being used. If it is index.php or a template from another plugin, you have a conflict.

Step 2: Resolve plugin-based template overrides

Some plugins, especially those that create custom post types for you, may include their own template files. For example, “Custom Post Type UI” does not include templates by default, but plugins like “The Events Calendar” or “WooCommerce” do. To override these, you must create a template file in your theme with the correct name. For a plugin-based post type with slug event, create single-event.php in your theme root. WordPress will prioritize this over the plugin’s template.

If the plugin uses a custom filter to load templates, you may need to use the template_include filter to force your theme’s file. Example:

Related reading: Why I Migrated a Client from Next.js to WordPress/Elementor (and why you might want to, too)

add_filter( 'template_include', 'my_plugin_template_override' );
function my_plugin_template_override( $template ) {
    if ( is_singular( 'event' ) ) {
        $new_template = locate_template( array( 'single-event.php' ) );
        if ( ! empty( $new_template ) ) {
            return $new_template;
        }
    }
    return $template;
}

Step 3: Avoid slug conflicts with other plugins

If two plugins register a post type with the same slug (e.g., both use portfolio), the one that runs later will overwrite the first, or both may break. To diagnose this, disable all non-essential plugins and re-enable them one by one. If the conflict is unavoidable, consider renaming your post type slug. You can do this by changing the rewrite slug in your registration code, but note that this will break existing URLs unless you set up redirects.

Table: Template Conflict Resolution Matrix

Related reading: wordpress website dubai

Symptom	Likely Cause	Solution
Page loads using index.php	No specific template file exists	Create single-{post_type}.php in theme
Page loads a plugin template	Plugin includes its own template	Use template_include filter to override
Archive shows wrong content	Theme’s archive.php or plugin conflict	Create archive-{post_type}.php in theme
Post type slug conflicts with page	Same slug used elsewhere	Rename post type slug or create redirect

Step 4: Check for theme-specific template parts

Many modern themes use template parts (e.g., template-parts/content.php) for displaying post content. If your custom post type is not rendering correctly, the theme may be using conditional checks like if ( 'post' === get_post_type() ). You may need to copy and modify the relevant template part to include your post type, or use a filter to adjust the loop.

For example, in a Genesis theme, you might need to use genesis_before_entry hooks to modify output. In block-based themes (FSE), you may need to create a custom block template for your post type.

Final note on debugging:

Always test template changes with a caching plugin disabled and in a staging environment. Use the WordPress Query Monitor plugin to see which template files are being loaded and to identify any PHP notices or errors. By systematically checking rewrite rules, admin menu parameters, and template hierarchy, you can resolve nearly any issue that arises when learning how to create a custom post type in WordPress. Remember that a clean, well-documented registration function and a thorough understanding of WordPress’s template hierarchy are your best defenses against these common problems.

Sources and further reading

• Post Types – WordPress Developer Resources
• Function Reference/register post type
• Post Type Arguments – WordPress Developer Resources
• Labels – WordPress Developer Resources
• Supports – WordPress Developer Resources
• Rewrite – WordPress Developer Resources
• Flush Rewrite Rules – WordPress Developer Resources
• Custom Post Types and Taxonomies – WordPress Developer Resources

Need help with this topic?

Send us your details and we will contact you.

Your Name

Phone Number

Email

Subject

Your Message

Δ