Custom Post Type UI Extended - WordPress Plugin

Guide to Setting Up and Using Custom Post Type UI Extended

Custom Post Type UI Extended is not really about registering a new post type - it is about the next step: displaying structured content you have already created on WordPress pages without hand-building a separate template every time. In this guide, we will walk through how to prepare the site, where to find the settings, how to choose a block or shortcode, how to verify the result on the front end, and what to do if the output is empty, too wide, filtered the wrong way, or conflicting with your theme.

This guide is written for site owners, editors, webmasters, and developers who already understand why the site uses separate post types: projects, courses, products, events, team members, testimonials, directory entries, or other content entities. The goal here is not to repeat the plugin description, but to show the working logic: post type -> display settings -> block or shortcode -> result check -> careful refinement.

Custom Post Type UI Extended is especially useful when content is already organized into distinct entities, but the team does not want to write a separate theme template every time. That said, the plugin does not replace a well-planned data architecture, fix bad slugs, or design your site cards for you. Its strength is different: it gives editors a controlled way to show posts, choose a layout, limit the number of items, enable the image, title, excerpt, date, term filtering, and then save that output as part of a page.

Next, we will cover the full workflow: preparation before installation, the initial check, block configuration, shortcode usage, a project directory scenario, WooCommerce and Easy Digital Downloads nuances, WordPress Multisite settings, troubleshooting, and safe refinements through filters, CSS, or theme templates.

What Problem the Plugin Solves After You Create Post Types

The core Custom Post Type UI plugin registers post types and taxonomies. That is an important part of the job, but it does not answer the editor's question: "How do I display these posts cleanly in the middle of a page, in a homepage section, on a landing page, or inside a blog post?" Custom Post Type UI Extended fills that gap between data structure and a visible front-end content block.

The official product page describes two main output methods: a block for the WordPress editor and a shortcode builder. The documentation also makes it clear that after activation, the plugin does nothing on its own: you have to choose where the content should appear and configure the display settings. That is an important expectation to set. If someone activates the plugin and does not immediately see changes on the site, that is normal behavior, not an error.

In practice, it works like this: you have already created a post type such as "Projects," "Courses," or "Speakers"; added a few entries; maybe assigned categories or custom taxonomies; and then inserted a Custom Post Type UI Extended block or generated a shortcode on the target page. In the settings, you choose the post type, layout, number of items, sorting, whether to show the image, title, excerpt, link, and terms. After saving the page, visitors see a clean list, grid, cards, slider, or another available display format instead of raw admin-side posts.

When It Is Better Than a Manual Theme Template

A custom theme template is a great option when the entire site is being built specifically for a project and the team has a developer. But on many sites, the task is simpler: show a few items in the right place on a page, quickly change the order, limit the number of posts, create a separate block for a specific category, or display one selected item. In those cases, a block or shortcode is faster and safer because the editor works through the WordPress interface instead of editing theme files.

Custom Post Type UI Extended is also useful when you want to test a hypothesis. For example, a marketer may want to see whether "Case Studies" belong on a service page, or an editor may want to add "Upcoming Events" inside a long article. Instead of creating a new template, you can insert a block, configure the query, and review the result. If the idea does not work, the block is easy to remove or disable without changing the site structure.

Where the Plugin Does Not Replace Full Development

There is a flip side, though. If you need a complex directory with multi-level filters, custom search, member areas, access permissions, advanced sorting logic, relationships between items, and separate templates for different states, Custom Post Type UI Extended alone may not be enough. It does a good job of displaying data, but it does not turn WordPress into a specialized directory platform without proper architecture work.

Another limit is the data structure itself. If the post type has no featured images, taxonomies are not configured, posts are unpublished, or the titles are inconsistent, any layout will look weaker. That is why plugin setup should start not with choosing a nice-looking grid, but with reviewing the posts themselves.

Who Custom Post Type UI Extended Is Best For, and When Another Approach Makes More Sense

This plugin works best on sites that already have, or plan to have, clearly defined sets of similar content. That does not necessarily mean a large portal. Even a small service business website can benefit if "Case Studies," "Team," "Jobs," "Events," or "Testimonials" live in separate post types instead of being scattered manually across different pages.

Good-Fit Scenarios

• An editorial site with repeatable content blocks. You can insert curated sets of posts by post type or terms directly into articles and pages.
• A portfolio or project directory. A grid, cards, a featured item, and list views help present work results without custom-developing every block.
• A site with courses, events, or a content library. Taxonomy-based output and sorting make it easier to build themed collections.
• A multisite network. Network-wide post types and taxonomies are useful when the same structure needs to be reused across multiple sites.
• A team without a full-time developer. The block and shortcode give editors a controlled way to change content output without editing PHP.

When to Be More Careful

Custom Post Type UI Extended may be unnecessary if the site has only one occasional custom post type and it appears in just one template. In that case, it may be simpler to build a theme template once or use the capabilities of your current page builder. The plugin also should not become a way to hide a messy data model. If post types were created without a plan, it is better to clean up the slugs, taxonomies, permissions, archives, and fields first.

You should also take a closer look at projects where content needs to be displayed from custom fields. The plugin itself works with posts, taxonomies, layouts, and display templates, but more complex field-driven output often requires ACF, Meta Box, Pods, a custom theme, or additional development. If a card needs to display dozens of fields with conditions, comparisons, and calculations, Custom Post Type UI Extended can be part of the solution, but not the only layer.

Practical rule: if the task sounds like "display published items of a specific type in a chosen layout," this plugin is a strong fit. If the task sounds like "build a data system with relationships, filters, custom roles, and non-standard business logic," start with architecture and choose a broader toolset.

What to Check Before Installation and First Launch

Before installing the plugin, it is important to understand exactly what you plan to display. The plugin does not create content out of thin air: it takes published posts from the selected post type and displays them according to the rules you set. That means your preparation should be just as practical as it would be before launching any visible content block on a live site.

Review Your Post Types and Taxonomies

Start with the list of post types. For each one, answer these questions: are there published items, are featured images being used, do you need categories or tags, is there an archive, should the posts appear in the main blog feed, RSS, or standard WordPress archives? Pluginize documentation includes separate settings that can add a post type to the main blog feed, standard category and tag archives, RSS, AMP scenarios, and Divi Builder support. Those options should not be enabled "just in case." They change how WordPress queries behave, so only enable them when you understand the expected outcome.

Minimum Data Needed for Clear Output

• The post type has several published entries, not just drafts.
• The posts have completed titles and short descriptions or excerpts if the chosen layout displays them.
• The posts have featured images if you plan to use a grid, cards, slider, or a featured block with an image.
• Taxonomies are assigned meaningfully if term-based filtering will be used.
• Access permissions do not hide posts from visitors if the block is meant to be public.

Assess Your Theme and Site Styles

Custom Post Type UI Extended output depends on the plugin markup and your theme styles. If the theme aggressively overrides cards, lists, images, or grids, the result may differ from what you expect. That does not automatically mean the plugin is at fault. In practice, the usual approach is to test the output on a dedicated page with a small number of items first, then check the container width, image sizes, spacing, headings, buttons, and mobile behavior.

If the site uses caching, minification, or script bundling, do not turn on every optimization at once for the test page. First, get the output working correctly without extra optimization, then enable caching and test again. That makes it much easier to tell whether the issue comes from the display settings, the theme, cache, or a third-party script.

Do Not Mix Testing with a Live Production Page

The best way to handle the first launch is to create a private or non-public test page, insert the block, select the post type, and save it. Then open that page as a normal visitor. If the result makes sense and the styles hold up, move the block to the live page. This is especially important for the homepage, landing pages, and service pages where a broken grid or empty block is immediately visible to visitors.

Installation and the Initial Post-Activation Check

Custom Post Type UI Extended is distributed as a ZIP file, so the standard WordPress plugin directory search is not the primary installation method. Pluginize documentation describes installation either by uploading the ZIP through the WordPress admin or by manually uploading the plugin folder to the plugins directory. In a normal production workflow, the admin upload method is safer because it reduces the chance of mistakes with folders, permissions, or archive structure.

Installing Through the WordPress Admin

1. Open Plugins and go to the add new plugin screen.
2. Click Upload Plugin, select the Custom Post Type UI Extended ZIP file, and start the installation.
3. After the upload completes, activate the plugin from the plugins list screen.
4. If the site runs on WordPress Multisite, decide in advance whether you need regular activation for a single site or network-wide activation.
5. Create a test page and check whether the block or shortcode builder elements appear in the editor.

After activation, do not expect blocks to appear automatically on the front end. The documentation explicitly says the plugin starts working when you choose a display location. So the first check is not "did the site change," but "can I insert the block or shortcode and choose the correct post type."

Initial Check Without Risking the Site

Open the test page, add the Custom Post Type UI Extended block, and choose a simple layout. For the first check, it is best to use a post type with 3 to 5 published items that already have featured images. Do not start with a rare combination of multiple taxonomies, custom sorting, a slider, and hidden fields. First confirm the basic output, then make the setup more advanced.

Quick takeaway: if the block can be inserted, the post type can be selected, the page can be saved, and the correct posts are visible on the front end, the core installation is successful. From there, you can move on to layouts, sorting, terms, and visual refinements.

Configuring the Block in the Editor: From Post Type Selection to a Finished Page Block

The Custom Post Type UI Extended block is the main path for modern WordPress pages. Unlike the older shortcode approach, the block is easier to edit later: the settings remain visible in the interface, they are easier to change, and you can evaluate the result in the editor before publishing. Pluginize documentation describes fields such as Post Type, Layout, Title, available layouts, and the global Shortcode ID attribute.

Selecting the Post Type and Layout

The first decision is which post type to display. It can be a type created through Custom Post Type UI, but Pluginize also notes that the shortcode builder can work with other post type data, including WooCommerce and Easy Digital Downloads scenarios. In the block interface, the available options depend on the plugin version, installed extensions, and the specific layout.

The second decision is the layout. The documentation lists several options: default, List, Single Post Type, Taxonomy List, Post Slider, Post Cards, Featured Plus, Grid, Grid with Overlay, Woo Product, and EDD Download. Do not choose a layout just because the name sounds right. Start with the task.

This table has one practical limitation: it does not replace testing. On a real site, the same layout can look very different depending on the theme, container width, images, CSS, and neighboring blocks.

The Settings Worth Adjusting First

Start with the settings that have the biggest impact on the result: Posts per page, choosing specific posts, sorting, Order, Order By, and whether to show the featured image, title, excerpt, and link. If the layout supports taxonomy-based filtering, start with one taxonomy and one term. Only after that should you add multiple terms and more complex conditions.

A Practical Configuration Sequence

1. Select one post type and the simplest layout.
2. Set a small number of items so the order is easy to inspect.
3. Turn the featured image, title, excerpt, and read button on or off.
4. Set sorting by date, title, or ID if the chosen layout supports it.
5. Add term-based filtering if the block should not display all posts.
6. Save the page and check the front-end result while logged out of the admin.

Do not change ten settings at once. If the block turns out empty after saving, it becomes much harder to tell whether the cause is the post type, publication status, selected term, sorting, post count, or theme styling.

Shortcode ID and Fine-Tuning a Specific Block Instance

The documentation explains that Shortcode ID is used to keep output instances unique, especially where pagination is involved. This prevents clicking into the next page inside the block from sending a visitor to a different WordPress archive page. A second practical use is targeted CSS or JavaScript customization for a single display instance. If there are multiple blocks on one page, a unique ID helps avoid changing them all at once.

Editors usually do not need to change this attribute manually. But for developers, it is useful to know that the plugin adds a unique identifier to the wrapper. That is why, for targeted adjustments, it is best to inspect the block HTML in the browser first and make sure the CSS rule applies only to the intended instance.

The Shortcode Builder: When It Still Makes Sense

The block is more convenient for most new pages, but the shortcode builder remains an important tool. It is useful in places where the editor, theme, or older content works better with shortcodes: the Classic Editor, widget areas, a text block inside a page builder, a template insertion in an older landing page, or legacy content that was historically built with shortcodes.

Pluginize documentation describes the shortcode builder as the main feature of the older approach: the user selects parameters and a layout, and the plugin generates code to insert. In this scenario, you should not be afraid of the shortcode itself, but you also should not treat it like a black box. Save the original page, copy the generated code into a separate note, and keep track of exactly what you changed.

When to Choose a Block vs. a Shortcode

• Choose the block if the page is edited in the block editor and the team will update the display settings regularly.
• Choose the shortcode if you need to insert the output in a place where blocks are unavailable or inconvenient.
• Keep the existing shortcode if it already works and there is no urgent reason to migrate older content to blocks.
• Move to a theme template if the same output should be part of the site's global layout and should not depend on manual placement on a page.

How to Work Safely with a Shortcode

A shortcode is manageable as long as its parameters are understandable. Problems start when a page contains one long string with many attributes and nobody remembers which one controls the query, which one controls the layout, and which one identifies the specific instance. For important blocks, use a simple workflow: generate the shortcode through the interface, save the page as a draft or test page, check the result, and only then move it to the live page.

Maintenance tip: if the page matters, save a short shortcode description next to the task in your project management system: which post type is being displayed, which layout is selected, which terms are used, and where to verify the result. That is much faster than trying to decode the attributes from memory a month later.

Display Layouts: Grids, Lists, Cards, Sliders, and Single Posts

The most common layout mistake is choosing the most visually rich option before the purpose of the block is clear. A grid with images may look impressive, but a simple list may be better for a short document index. A slider can feel dynamic, but on a page with important links it may hide content. A featured block works well for one strong highlight, but it is poor as a catalog format.

Default and List for Low-Key Output

Default and List work well on pages where content should be readable rather than competing with the rest of the design. For example, a list of related materials inside an article, a group of documents, a lineup of talks, or a compact news block. In the settings, pay attention to the number of items, excerpt, order, and taxonomies. If the list becomes too long, it is usually better to limit the number of entries and link to an archive or a dedicated page.

Grid, Grid with Overlay, and Post Cards for Visual Collections

Visual layouts work best when each post has a strong featured image. If the images vary in size, are too dark, or contain tiny text, the grid will feel uneven. Before publishing, check not only desktop but also mobile. Sometimes cards look good in a wide column but turn into a long repetitive strip on smaller screens.

Grid with Overlay deserves extra attention to contrast. If the title sits on top of the image, check readability on both light and dark thumbnails. Some themes will need additional CSS for a text background or consistent card height. Start with the plugin settings, and only add CSS once you are sure the base layout is the right one.

Post Slider for a Short Highlight Block

A slider is best used as a small accent, not as the primary way to navigate important content. The documentation points to settings such as selecting specific posts, height, title display, markers, and autoplay. Real-world testing matters even more here because the slider depends on scripts, image heights, and the theme. If the slider stops moving after site optimization, the first thing to do is temporarily disable script bundling or check the browser console.

Woo Product and EDD Download

Layouts for WooCommerce and Easy Digital Downloads are available only when the corresponding plugins are installed. That is logical: Custom Post Type UI Extended should not show product or download settings if the site has no such data source. For these blocks, what matters most is not testing checkout or payment, but checking card visibility, image output, title, sorting, and the link to the individual item page.

Practical Example: Showing a Project Catalog on a Service Page

Let us walk through a concrete scenario. Suppose an agency website has a "Projects" post type. Each project has a title, featured image, short description, and an "Industry" taxonomy. On a service page, you want to show four relevant projects in a grid so visitors can see examples of work and click through to the full details.

Goal

Create a "Projects Related to This Service" block on the service page. The block should display only published projects from the right industry, along with the featured image, title, short text, and link. The editor should be able to change the number of projects or the term without a developer.

Preparation

• The "Projects" post type is already registered and visible in the admin panel.
• At least four published projects with featured images have been added.
• Each project has the taxonomy term assigned that matches the service.
• The service page opens in the WordPress block editor.
• You have already confirmed on a test page that the Custom Post Type UI Extended block can be inserted and display posts.

Setup Steps

1. Open the service page in the editor and add the Custom Post Type UI Extended block where the project selection should appear.
2. In the Post Type field, choose the project post type.
3. In the Layout field, choose a visual layout: for a catalog, Grid or Post Cards usually works best.
4. Enter a block heading, for example "Projects for This Type of Work."
5. Enable the featured image, title, excerpt, and link if those options are available in the selected layout.
6. Set the number of posts, such as four or six, so the block does not become too large.
7. In the taxonomy filter, select the term that matches the service page.
8. Save the page and open it in a separate window as a normal visitor.

Checking the Result

Only projects with the selected term should appear on the live page. If unrelated projects are visible, check the term assignments on the posts themselves. If the block is empty, check the publication status, selected post type, term, item count, and whether access restrictions are hiding the content. If the cards are present but look uneven, review the featured images and theme styles.

Important nuance: if you select terms from multiple taxonomies, the behavior may be stricter than the editor expects. Pluginize documentation describes a filter that changes the condition relationship from AND to OR. Use that approach only if you clearly want the block to show posts matching any selected term rather than only full matches.

How to Roll Back Without Losing Content

If the block does not work for the page, do not delete the post type or the projects themselves. First remove or disable the block on the service page. The content will remain in the admin panel, and you can try a different layout, a different term, or a theme-template-based output. That is much safer than immediately changing the post type structure.

Practical Use Cases Across Different Types of Sites

After the first successful block, the next question is usually: where else can Custom Post Type UI Extended be used so it does not become a random showcase? A good scenario starts with an editorial goal. Not "add a block because it exists," but "help the visitor move from the current content to relevant items." Below are several proven models you can adapt without inventing capabilities the plugin does not have.

A Service Page with Relevant Case Studies

For service pages, it makes more sense to show a selection of projects by industry, technology, or job type rather than the entire project archive. In this scenario, the taxonomy becomes the main control mechanism. The editor assigns the term to projects, and the block on the service page pulls only that term. If each project has a featured image and a short excerpt, Grid or Post Cards tends to work well. If there are only a few case studies, it is better to show 3 to 4 strong cards than stretch the block with empty or repetitive items.

Checking the result here has two parts. The first is technical: the cards render, the links open, and the images do not crop important details. The second is editorial: each project genuinely supports the service it is paired with. If the block looks like a random mix, the term setup may be technically correct but the editorial goal is still not being met.

An Education Site with Course or Lesson Collections

For courses, lessons, webinars, and knowledge base materials, a list or grid with a limited number of items works well. For example, a topic page can show the latest lessons in that area, while an article can display related resources from the same section. It is important not to overload the page: if the block serves as navigation, it does not need to show twenty items. In most cases, 4 to 6 precise cards plus a link to the full archive is much more useful.

If the content is organized through multiple taxonomies, define in advance what each one means. A term like "Marketing" may describe the topic, while a term like "Beginner" may describe the difficulty level. If you select both terms, the result can become very narrow. On education sites, that is often a good thing: the visitor gets a focused selection. But if the block goes empty, first check whether there are any published posts matching both criteria.

A Directory of Experts, Listings, or Services

For directories, decide whether visitors need a visual overview or a quick list. A grid works well for experts, real estate listings, portfolios, showcase products, and image-based cards. A list is better for documents, job openings, knowledge base questions, and compact content items. Custom Post Type UI Extended can support both approaches, but the quality of the result depends on consistent data.

If some posts have no featured images, the grid will look uneven. If some posts have very long titles, the cards will jump in height. If posts have no excerpt, a layout that expects one will feel empty. Before publishing a directory, it is worth reviewing 10 to 15 entries and bringing them to one editorial standard: short title, consistent image style, concise excerpt, and an assigned taxonomy.

Internal Blocks Inside Long Articles

In long-form content, the plugin can act as a navigation bridge. For example, an article about choosing equipment might show related reviews; a guide to a service might show relevant case studies; a knowledge base article might show related instructions. Here, it is usually better not to use heavy sliders or oversized cards if they interrupt reading. A compact list or a calm three-item grid often works better.

Check not only the block itself, but also the rhythm of the page. If a visitor is reading an article, the block should help them continue the journey, not suddenly switch them into directory mode. That is why the block heading should explain the connection: "Related Guides," "Case Studies for This Task," or "Resources for the Next Step." In the plugin settings, that may just be a standard title field, but the editorial wording has a major effect on how the block is perceived.

A Working Process for Editors and Developers

On a live site, custom post type output often involves two people: the editor is responsible for meaning and content, while the developer handles templates, styles, and technical constraints. Custom Post Type UI Extended is useful because it can separate those roles, but only if the team agrees on the workflow in advance. Otherwise, the editor changes the layout, the developer adds CSS, then the theme gets updated, and nobody understands why the block looks different now.

What the Editor Should Define

The editor should describe the purpose of the block, not just its technical parameters. A good request sounds like this: "On the service page, show 4 projects from the 'Retail' industry, using cards with a featured image, title, short description, and link." A weak request sounds like this: "Make a nice CPT block." The more clearly the editor defines the post type, term, quantity, and placement, the fewer random revisions will be needed later.

After setup, the editor checks the meaning: are the right posts in the block, are the featured images strong enough, is the same project repeating on neighboring pages, and do any links lead to drafts or outdated content? That cannot be delegated fully to the developer, because the developer sees the layout but may not know the editorial priority.

What the Developer Should Check

The developer focuses on technical stability: output classes, container width, conflicts with theme styles, cache behavior, slider state, link accessibility, responsiveness, and overridden templates. If the appearance needs to change, first determine whether CSS is enough. If the HTML needs to change, use a theme template override. If the query needs to change, check the block settings first and only then move to filters.

The most common collaboration mistake is changing code to fix an editorial problem. For example, the block is empty because the posts do not have the required term, but the team starts looking for a theme conflict. Or the cards look weak because the featured images are inconsistent, and the developer writes complex CSS. The correct order is: data, block settings, front-end result, then styles and code.

Project-Level Documentation

If a block is important to a page, save a short internal note. It is enough to record: where the block appears, which post type is selected, which term is used, which layout is applied, whether there is custom CSS or a theme template, and how to verify the result after an update. That kind of note takes only a few lines but saves a lot of time when editors change, the theme is updated, or the site is migrated.

Mini Note Template

• Page: where the block is located and why it exists.
• Source: which post type and terms are used.
• Layout: which display option is selected and why.
• Constraint: how many items to show and which fields must be filled.
• Customizations: whether there is CSS, a filter, or a theme template.
• Verification: what to open after plugin, theme, or cache updates.

This workflow turns Custom Post Type UI Extended from "a plugin with a block" into a predictable part of the editorial process. That becomes especially clear on sites where the same post types are displayed on the homepage, service pages, articles, and archive sections.

WordPress Multisite Network Mode and Advanced Post Type Settings

One notable feature of Custom Post Type UI Extended is support for network-wide post types and taxonomies in WordPress Multisite. If you run a single site, you can skip this section, but for a network it is a major capability: a structure configured once can become available across multiple sites, reducing duplication and the risk of inconsistencies.

When Network-Wide Post Types Actually Make Sense

Network mode is appropriate when the group of sites is managed centrally and should share the same content model. For example, a company's regional sites may all use a "Locations" post type, an education network may use "Courses," and a media network may use "Experts." In that case, creating the same post type manually on each site quickly becomes a source of mistakes.

The documentation describes working through Network Admin: the user goes to the network admin area, selects CPTUI Extended items to add or edit post types and taxonomies, then saves the settings. A separate page shows the registered network-wide post types and taxonomies. The process is similar to a single-site setup, but the scope is much broader.

Which Settings to Enable Carefully

Advanced settings at the bottom of the post type screen can add that post type to the main blog feed, standard category and tag archives, RSS, and other compatible scenarios. On a single site, a mistake affects one site. At the network level, one checkbox can change output across the entire network. That is why Multisite should follow a two-step rule: first configure and test on a staging site or limited environment, then roll it out at the network level.

What to Check After a Network-Wide Change

• Open several sites in the network and make sure the post type appears where it should.
• Check the archives you added the post type to and confirm there are no unwanted entries.
• Check RSS if you enabled feed output.
• Compare editor permissions across sites so content does not become accessible to people who should not see it.
• Document the change in the project records, because network-level settings are harder to trace later.

The main risk of network mode is organizational, not technical. If different sites in the network operate under different rules, one shared content model can create friction. If the structure truly is shared, network mode saves time and reduces repeated configuration work.

Safe Customization: CSS, Classes, Templates, and the Term Filter

Custom Post Type UI Extended is not built only for editors. The official documentation includes developer-focused materials on template overrides, class additions, shortcode builder extensions, taxonomy condition logic changes, and filter usage. The key is to use those capabilities carefully: do not edit plugin files directly, do not break updates, and do not write code if a configuration setting can solve the problem.

Adding a CSS Class to Shortcode Output

The documentation describes the cptui_shortcode_classes filter, which lets you add a class to the output wrapper. This is useful if the theme needs its own class for a grid or if one output type should be styled separately. It is best to add that code through a child theme or a safe snippets plugin.

function site_cptui_add_layout_class( $classes, $shortcode ) {
    if ( 'default_shortcode' === $shortcode ) {
        $classes .= ' site-projects-strip';
    }

    return $classes;
}
add_filter( 'cptui_shortcode_classes', 'site_cptui_add_layout_class', 10, 2 );

After adding it, open the page with the output and inspect the HTML in the browser. The new class should appear only where you expect it. If the class is not added, check the shortcode type name and where the code was inserted. To roll it back, remove the snippet or disable it in your snippets management tool.

Changing Taxonomy Condition Logic from AND to OR

When the output uses terms from multiple taxonomies, the default logic can be strict: a post must match every selected condition. The official documentation shows the cptui_tax_query_relation filter, which returns OR. That is useful for collections like "show posts from any of the selected categories," but it can broaden the query more than you intended.

function site_cptui_use_any_selected_term() {
    return 'OR';
}
add_filter( 'cptui_tax_query_relation', 'site_cptui_use_any_selected_term' );

Before using this on a live page, test it on a staging page with a small set of posts. If the block starts showing too many items, restore the original logic by disabling the snippet. Do not use this code globally if other blocks on the site require strict condition matching.

Overriding a Template Without Editing the Plugin

For deeper customization, the documentation recommends copying templates from cptui-extended/templates/ into the cptui-extended folder inside the active theme. The file name must stay the same. This is similar to the WooCommerce approach: you edit the copy in the theme, not the plugin file. This method is appropriate when you need to change the HTML of a specific layout, add a field, rearrange elements, or inject theme-specific markup.

Be careful: a template override affects every instance that uses that template unless the copied file contains additional conditional logic. Before deploying it, check where else on the site the selected layout is already in use.

If you are not sure which file controls a specific layout, use the documentation that maps shortcode templates to template files. Do not guess the file name and do not edit the plugin source directly. For more complex changes, it is better to use a child theme, track changes in version control, and verify the output after updates.

How to Check the Result on the Site, in SEO, and in Performance

Displaying posts on a page is not only a visual task. A block can affect page length, image count, internal linking, indexation, speed, and cache behavior. Custom Post Type UI Extended does not promise automatic SEO gains, so what matters is checking the actual result.

Front-End Check

Open the page in a private window or another browser. See whether a normal visitor can view the block. Check the links in titles and buttons, image size, excerpts, post order, pagination, and behavior on mobile. If the block is displaying items from a restricted or internal post type, make sure you are not exposing content that should remain private.

Indexation and Duplicate Content Check

If the block displays the same posts on many pages, that is not automatically wrong, but it can create repetitive fragments. Use the block intentionally: show relevant case studies on a service page, topic-based resources inside an article, and a limited featured selection on the homepage. Do not turn every page into the same showcase of all posts. For SEO, context matters: the block should support the page topic, not act as a universal repeater.

Performance Check

The most obvious factor is images. A grid of 12 large cards with heavy thumbnails can slow down a page far more than the plugin itself. Limit the number of items, use optimized thumbnails, do not enable a slider unless it is necessary, and check the result after caching is turned on. If the page becomes noticeably heavier, first reduce the number of posts and check image sizes.

Post-Update Check

If you use template overrides or filters, review important pages after plugin updates. The changelog shows that the plugin has evolved in its blocks, layouts, templates, filters, compatibility, and fixes. For that reason, any working page - especially one using a custom template - should be part of your update checklist.

Why the Output Is Not Working and How to Diagnose the Issue

Troubleshooting is best done from simple to complex. Do not start by editing code if the block is empty: more often, the cause is the post status, selected type, terms, item count, or a layout mismatch with the available data. Below are typical symptoms specifically related to displaying custom post types through blocks, shortcodes, and layouts.

The Block Is Inserted, but Nothing Is Visible on the Site

Symptom: the block exists in the editor, but the front-end page shows empty space or a message saying content was not found. Possible causes include no published posts in the selected type, an overly narrow term filter, an item count set to zero, a layout that requires a specific post, or visitor access restrictions.

Check the post type, post status, terms, item count, and page visibility. Then temporarily remove term filtering and switch to a simple layout. If posts appear, the problem was in the query condition. If they still do not appear, go back to the post type data and access permissions.

The Wrong Posts Are Being Displayed

Symptom: the block shows too many items or items from the wrong group. The cause is usually the wrong term, the wrong condition relationship, an old shortcode with forgotten attributes, or the fact that the editor changed the post taxonomies. Check each post in the admin panel and compare it with the block settings.

If the goal requires "any of the selected terms" logic rather than "all selected terms at once," look into the cptui_tax_query_relation filter. But do not enable it globally without testing: it changes the meaning of the query and may affect other blocks.

The Grid Looks Broken or the Cards Have Different Heights

Symptom: cards jump around, images are different sizes, text overlaps the button, or the mobile view becomes too long. Possible causes include inconsistent thumbnail formats, theme styles, overly long titles, or a poor layout choice for the current content.

Start by checking the featured images and title length. Then try a different layout. If the problem remains, add targeted CSS to the specific output instance using a unique class or ID. Roll back the CSS if it breaks other pages.

The Slider Stops Moving After Optimization Is Enabled

Symptom: the slider items are visible, but autoplay or navigation does not work. Possible causes include script conflicts, deferred loading, file bundling, or an error in the browser console. The changelog documentation mentions that the slider layout depends on jQuery, so script checks are especially important when the slider breaks.

Temporarily disable JavaScript bundling and deferred loading for the test page, clear the cache, and check the console. If the slider starts working again, create an exclusion in the optimization plugin or switch to a static layout if the slider is not critical.

The Custom Template Looks Different After an Update

Symptom: the block still works, but the template looks different, an element is missing, or a new warning appears during development. A likely cause is that the custom theme template has fallen behind the plugin template while the plugin updated the layout structure. The changelog shows that the plugin has changed templates and template versioning, so custom copies need to be reviewed from time to time.

Compare your file in the theme's cptui-extended folder with the current file from the plugin. Do not blindly overwrite your changes by copying the whole file. Bring over the needed changes carefully, check the page, and record exactly what you updated.

The Block Changes the Main Feed or Archives in an Unexpected Way

Symptom: the custom post type starts appearing in the blog, category, tag, or RSS feed even though the editor expected it to appear only in a separate page block. A likely cause is that the advanced settings for adding the post type to the main feed, archives, or RSS are enabled. Go back to the post type edit screen and review the extra checkboxes.

If the setting was enabled accidentally, turn it off and check the archives again after clearing cache. If it is needed but the output has become too broad, refine the taxonomy structure and explain to editors where this post type will now appear.

When Custom Post Type UI Extended Is the Right Choice

This plugin is a good fit when you already have structured content and a clear display goal: show a curated selection, grid, list, slider, single item, products, or downloads in a specific place on a page. It helps editors work through the interface and lets developers avoid building a separate template for every small content block.

Before using it on a live page, check three things: data quality, the selected layout, and the front-end result. If all three line up, you can move to final placement. If you have not installed the plugin yet and want to reproduce the workflow from this guide, you can get the Custom Post Type UI Extended file near the download section, install the ZIP archive on a test site, and verify the output with a small set of posts.

Do not use the plugin as a substitute for data architecture. It is excellent at displaying posts, but it should not be used to hide unclear post types, random taxonomies, or inconsistent cards. Define the structure first, choose the layout second, and only then refine the styling and templates.

Video on Extending and Customizing

The Pluginize product page includes a link to a walkthrough video about extending CPTUI Extended. It is worth watching after the basic setup, once you already understand the difference between the block, shortcode, template, and filters. The video addresses the intent of "how to extend Custom Post Type UI Extended" and is especially helpful for developers who need to work more deeply with templates and extension points.