MainWP Custom Post Types - WordPress Plugin

MainWP Custom Post Types Guide: Centralized Post Type Management Across WordPress Sites

MainWP Custom Post Types is not designed to create a polished WordPress menu or move an entire site structure with one click. Its practical purpose is more specific: it lets a MainWP Dashboard owner create, search, edit, change the status of, and delete posts from an existing custom post type across connected Child Sites. This guide explains the essential requirement - a matching CPT - then walks through setting up a safe working environment, publishing content to a site group, verifying the outcome, and diagnosing common failures by symptom.

In this context, a custom post type, or CPT, is a separate kind of WordPress content: portfolio items, testimonials, job listings, movies, case studies, real estate listings, or WooCommerce products, for example. This content can have its own admin label, archive, taxonomies, meta fields, and display template. MainWP Custom Post Types does not alter that model. Instead, it adds a centralized operational point: one Dashboard selects target sites and sends content operations to the matching post type on those sites.

That is why it is more useful to think of the extension as a discipline tool for a network of WordPress projects. First, you standardize the content structure. Then, you create and maintain posts from MainWP. This order reduces the chance that one site receives a post with the wrong type, another receives an incomplete set of fields, and a third never receives the post in the intended section at all.

Not a New Content Type, but a Bridge Between Matching CPTs

The most important distinction is often lost in short product descriptions. MainWP Custom Post Types does not register a custom post type on Child Sites. It does not create a project entity there, add testimonial fields, build a single-post template, or determine which plugin powers a catalog. Those decisions must already be in place before remote management is enabled.

The extension expects the Dashboard and the selected Child Site to recognize the same type. MainWP's official documentation refers to this as a Matching CPT. For practical use, three foundations must match: the technical slug, the plural label, and the singular label. In a movie example, these would be movies, Movies, and Movie. If one project uses portfolio and another uses projects, both sections may look like portfolios to a person, but the extension treats them as different entities.

This rule explains nearly every action that follows. When MainWP detects a match on the Dashboard, it adds a MainWP icon next to the corresponding WordPress menu item. When you create a post, a metabox for selecting Child Sites becomes available. When searching in Manage Posts, a post-type filter becomes available. In other words, the input is a familiar CPT post, the controlling rule is structure matching, the state change is delivery to selected sites, and the visible outcome is a post of the correct type in their admin areas and public-facing sites.

What Must Match and What Can Differ

It is best to record the technical key and base labels in a project table before the first large-scale publication. Different descriptions, images, authors, or category selections do not invalidate the mechanism. However, different required meta fields, role permissions, or save behavior can make the same delivery incomplete on some sites. In MainWP, that is not a reason to blindly "fix" the post: first determine how that CPT was created and extended on the specific site.

Practical takeaway: standardize one post type across a small group of sites first, then scale publication. A menu item that looks the same is not a substitute for verifying the slug and labels.

Create a Post Type Profile for a Repeatable Workflow

Once a network contains more than two sites, relying on an editor's memory is no longer enough. Today, they may remember that "Projects" are configured the same way across three storefronts, but next month one site may receive a different plugin, an additional field, or a changed template. MainWP Custom Post Types cannot warn you about every organizational shift because some of them involve themes and meta fields. For that reason, create a short profile for every managed post type. Its purpose is not reporting. It lets you answer a practical question before every publication: which sites form a safe group, and what outcome counts as correct on them?

Do not store passwords, connection keys, or other secrets in the profile. Technical and editorial details are enough: the human-readable type name, slug, Singular Label, Plural Label, registration owner, required fields, allowed taxonomies, links to test pages, and the responsible role. It is also useful to note whether the historical collection was created locally or through MainWP. This directly relates to the Bulk Edit limitation.

Minimum Profile for the case_study Type

The profile helps keep different problem layers separate. If a "Client" field disappears from a card, you can immediately see whether it is a standard CPT meta field, a Pods component, a field from another extension, or part of the template. If the type itself cannot be found, check its three identifiers. If a post does not appear on one site, check that recipient's connection and state. That kind of routing is more useful than generic advice to "reinstall the plugin."

How to Build Safe Recipient Groups

Do not group sites only by brand or language. A MainWP Custom Post Types group should be consistent from the perspective of the specific content type. Three sites may have different logos and color schemes but the same event registration, the same fields, and the same display order - that is a strong group. Conversely, four storefronts that look identical but have different slug values or required fields should be separated.

For larger networks, three group classifications are useful. A "verified" group contains sites that passed complete testing and can receive normal publications. A "conditional" group has a matching CPT but requires a manual check of one specific field or template. An "excluded" group receives no publications until the discrepancy is resolved. You can record these classifications in a MainWP note, project documentation, or a task system. The important point is not to replace this classification with editorial guesswork at publication time.

When a site moves from a conditional group to a verified group, repeat the acceptance flow: draft, publication, search, admin-area review, public page review, edit, and Trash. If the project changed its theme or CPT registration source in the meantime, the old test result should no longer be considered sufficient.

Who Saves Time With This Extension and Who Gains an Extra Layer

The most natural use case is an agency or team maintaining several independent WordPress sites with the same content model. These might be regional sites within one network, partner directories, franchise sites, a set of storefronts featuring the same projects, multilingual sites maintained by separate editors, or a group of client sites with a standardized case-study collection. In each case, the value is not the number of buttons. It is that an editor does not need to open ten admin areas to perform the same operation.

The extension can also suit a WooCommerce network owner when the task is limited to the product type. MainWP documentation specifically states that installing WooCommerce on the Dashboard is sufficient to support products, after which the extension adds Products support. That does not mean an identical product will automatically be presented identically across all storefronts. Pricing, inventory, attributes, taxes, shipping, and third-party fields require a separate verification model.

Signs That the Tool Is a Good Fit

• Several connected sites genuinely have the same CPT with aligned slug values and labels.
• A content operation repeats: publishing a new case study, changing the status of a job listing, correcting a property card, or cleaning up outdated posts.
• The editor has a clear list of sites where the material may be sent, rather than a need to publish anywhere.
• The team is ready to test a post on one Child Site before expanding the scope.
• Public templates have been checked: the post is not merely saved in the admin area, but appears in the required archive, query, or theme block.

When It Makes More Sense to Stop

If each site registers similar content in its own way and has its own required-field set, centralization will create more errors than value. Be particularly careful with types created by a theme: changing the theme or using different child themes can easily change available fields and display behavior. For a one-time publication on a single site, the extension can also be excessive. The standard WordPress editor will be simpler and more transparent.

Do not use MainWP Custom Post Types as a way to synchronize all data between sites. It is not a migration system, backup system, or bidirectional replication tool. It works best when an editor intentionally creates or updates a post and chooses the recipients. If you need complex transfers of inventory, translations, orders, or relationships between posts, first determine the source of truth and evaluate a specialized solution for that task.

Five Product Mechanics to Understand Before Daily Use

The extension does not have a long list of switches, but it does have several connected mechanics. Once you understand them through the chain of "setting location - input - action - outcome - verification - symptom - fix - limitation," daily work becomes more predictable.

1. Matching Models Make the Type Available

Where it is configured: in the CPT registration source on the Dashboard and Child Sites. User input: aligned slug, Singular Label, and Plural Label values when creating the type through a supported tool. What the product changes: MainWP recognizes the Dashboard type as eligible for remote operations and adds its own route to it. Visible outcome: the required CPT becomes available in the extension area and receives a MainWP indicator in the menu.

Verification: open the type on the Dashboard and create a test post without sending it. Failure symptom: the required section is not visible or the expected metabox is missing. Fix: compare all three identifiers and the registration source exactly. Limitation: matching these parameters does not guarantee matching complex fields or theme output, so it is the entry point to the workflow rather than a final guarantee.

2. The Recipient Selection Metabox Limits the Scope

Where it is located: on the Add New screen for the managed CPT. Input: the editor selects specific Child Sites. Action: the extension sends the content operation only to the selected recipients. Outcome: a test case study appears on two permitted sites and does not appear on an excluded third site.

Verification: search for one unique phrase through Manage Posts using post-type and site filters. Failure symptom: content was sent to the wrong site or did not appear on one recipient. Fix: narrow the test to one site, verify the connection, then repeat the action only for the undelivered recipient. Limitation: site selection does not understand editorial suitability and cannot replace the team's publication rules.

3. Filtering Connects Content With Proof of Delivery

Where it is located: Sites > Content Operations > Manage Posts. Input: type, status, keyword, date range, and a set of Child Sites. Action: MainWP builds a working set of matching posts. Outcome: the editor sees not the entire site collection, but the specific operation that can be opened, edited, or moved to Trash.

Verification: a unique title returns only the expected rows. Failure symptom: the results are empty or filled with unrelated content. Fix: remove unnecessary filters, check the Post Type and selected sites, and compare the results with the Child Site's direct admin area. Limitation: search proves that a post exists and can be managed, but does not replace checking the public template.

4. Post Origin Limits Bulk Edit

Where it applies: when bulk-editing the CPT itself. Input: the user selects posts created through the Dashboard and the required Child Sites. Action: the extension applies a supported bulk change. Outcome: a consistent group of recent posts can be maintained faster.

Verification: on a test post published through MainWP, the required operation is available and produces the expected status. Failure symptom: an old post is found, but Bulk Edit is unavailable. Fix: use targeted Edit or plan future posts through the Dashboard. Limitation: you cannot treat historically created local content as new centralized content solely to make it eligible for a bulk operation.

5. Trash Provides a Controlled Return Point

Where it is located: in the row actions in Manage Posts. Input: select a post or group and choose Trash. Action: the post moves to Trash instead of disappearing permanently. Outcome: the team can verify that unrelated material was not affected and restore the test if necessary.

Verification: filter by Trash status and open the public listing. Failure symptom: an editor attempts permanent deletion immediately. Fix: separate test-data cleanup from the decision to permanently delete. Limitation: permanent deletion is allowed only for posts already in Trash, so the workflow is necessarily two-step.

Preparation Map: Connections, Roles, and Content Structure

Installing the extension itself takes less time than preparing the network. MainWP consists of a Dashboard on a separate WordPress site and MainWP Child on every managed site. Before working with CPTs, make sure Child Sites are actually connected, not merely running an active plugin. An active but unconnected MainWP Child displays its own notice, and an isolated site will not receive a publication from the Dashboard.

Start with a small matrix: list site names on the left, then required post types and mandatory fields across the top. For every site, document the technical slug, singular and plural labels, responsible plugin or code, public-facing template, and a test post. This is not bureaucracy. The matrix immediately exposes risky groups: for example, three sites use case_study, while the fourth uses cases; two have a "Timeline" field, the third requires it, and the fourth does not have it.

Check Permissions and Connectivity Before Content Operations

The Dashboard and all selected Child Sites require administrator access for initial setup. Use MainWP's Test Connection mechanism before investigating publication failures. A successful test confirms that the Dashboard can reach the specific site; that is different from a site being accessible in a normal browser. If the test fails, CPT operations will not begin, and changing labels will not fix the issue.

When connecting MainWP Child, the system supports an administrator password, a Unique Security ID, or both methods. Do not disable every authentication method. This is also the point to separate responsibilities for a content team: editors do not need credentials for every Child Site, while the Dashboard administrator should control which sites are available for publishing at all.

Why Create a Restore Point Before You Start

This is not about a dramatic failure scenario. It is about normal reversibility. Bulk publishing or status changes can affect several sites. Create a backup or a confirmed restore point according to your infrastructure rules, then test one example. This is especially useful when the CPT is tied to a catalog, repeating fields, or complex taxonomies. Verify one targeted post first, then apply a bulk action - it is safer than trying to quickly correct the same error in several admin areas.

Classic Editor as a Required Dependency

MainWP's official documentation requires Classic Editor on the Dashboard and all Child Sites for MainWP Custom Post Types. This is not a cosmetic recommendation: the extension relies on the legacy WordPress editing screen and metaboxes, including site selection. Do not try to "compensate" for the missing dependency with a theme switch or Block Editor setting. Install and activate Classic Editor on a small test group, open an existing post of the required CPT, and make sure the expected screen and metaboxes are available.

If editors in your organization are used to blocks, agree on this limitation in advance. Classic Editor can allow editor selection when configured appropriately, but this particular workflow needs a predictable classic editing screen. Do not promise users that the extension will manage every block field or any third-party builder interface without separate testing.

Field, Taxonomy, and Template Compatibility: What MainWP Does Not Standardize

Matching CPT is often mistaken for complete compatibility. In practice, it solves type recognition, but every CPT has a second layer around it: meta fields, taxonomies, media, roles, templates, and display settings. This layer should not be dramatized, but it must be separated from the MainWP mechanism. The extension can deliver a project post; how it appears in a card depends on the template reading that type on a particular Child Site.

Required Fields Should Not Be a Surprise

Suppose one real estate directory requires a "City" field, while another requires both "City" and "Area." Both systems may use property and identical labels. A title-only test may succeed, but the public block on the second site will remain empty or display incorrectly. The solution is not to modify MainWP. Record the minimum fields for the consistent group in the type profile, and do not send material to sites where that minimum differs.

Check fields from external components one at a time. On a test post, fill in one field, save it, open the post on the Child Site, and then review the public card. This tells you whether the required value is transferred, remains in the expected location, and requires an additional editor action. Do not enter a large set of metadata before confirming basic delivery, or it will be difficult to identify which field caused the discrepancy.

Taxonomies Need Their Own Rules

A category, service area, city, genre, or tag often controls more than the admin filter; it can also affect public display. Compare taxonomy technical identifiers and terms across recipients. If the "Analytics" term is missing from one site, the centrally created post may arrive without the expected classification. If the term exists but has a different slug, URLs and queries may behave differently. For the first publication, use a term that has been explicitly verified on every site in the group.

Do not replace term verification with a simple comparison of visible names. An editor should open the specific Child Site and confirm that the term can be assigned to this CPT, appears in the archive, and has no separate role restriction. When in doubt, publish a draft without risky classification on one test site and resolve the structural difference first.

The Theme Determines What Visitors See

On some sites, the CPT is registered by the theme; on others, it is registered by a standalone plugin. That may be acceptable for MainWP if the required indicators match. For ongoing maintenance, however, the difference matters: changing a theme can alter the type, templates, and fields. Do not establish a MainWP workflow for a group where one site depends on a theme without a documented update plan. It is more sensible to move registration into a supported project plugin or document the theme as part of the required conditions.

You can verify public display through three locations: the direct single post, the CPT archive, and a specific home-page block or section where visitors are expected to find the content. If the single post opens but the card is absent from the archive, the cause is usually filtering, taxonomy, or the template. If the card appears in the archive but its link returns an error, check registration and permalinks. This split is faster than changing the theme, cache, and MainWP at the same time.

Post Statuses and Lifecycle in a Centralized Editorial Workflow

The value of MainWP Custom Post Types becomes more visible when a post moves through a complete lifecycle rather than a single publication moment. A hypothetical case study may start as a draft, be released to a selected site group, be updated later, removed from publication, and eventually moved to Trash. The clearer each stage is, the lower the risk that a technical test becomes visible to visitors or that an outdated card disappears without a way back.

A Draft as a Technical Check

The first draft is suitable for confirming Matching CPT, site selection, and field availability. It should not contain real client data if that publication has not yet been approved. Give it a unique title and record which recipients are selected. After creating it, find it through Manage Posts. If the draft already looks wrong, do not try to solve the problem by publishing it: a structural issue does not improve after a status change.

Publication as an Editorial Decision

Moving to published status means the material is ready in terms of content and intended for the selected storefronts. Before making that change, verify more than the MainWP area; confirm the suitability of every recipient. Sites with different localization, legal text, or image display may require separate editorial preparation. In such cases, splitting publications is better than using a centralized action as a context-free broadcast.

Unpublishing and Trash

When a case study, job listing, or property becomes outdated, first decide whether it should be removed from the public site, retained as archived material, or deleted. Those are three different editorial goals. Use status filters to ensure that exactly the intended set is changing. Trash is suitable for tests and obvious duplicates because it provides time to recheck links, archives, and neighboring posts. Reserve permanent deletion for approved cleanup, not as the first response to an unclear outcome.

Team Workflow: Separate Structure, Publishing, and Outcome Verification

MainWP Custom Post Types has a useful characteristic: the same workflow can be divided among different roles without sharing passwords for every individual storefront. But it works only when the team does not blend responsibilities. A developer or technical administrator is responsible for CPT registration, fields, templates, and Child Site connections. An editor is responsible for content and an intentional choice of recipients. A content manager or site owner verifies the public outcome. MainWP connects these roles, but it does not make them interchangeable.

This separation is especially useful in an agency. An editor should not change a type's slug just to make its menu name look "better." A technical specialist should not publish unapproved text simply because they know how to connect sites. And a reviewer should not consider their work complete after seeing a green connection indicator if the public card appears without an image or does not land in the correct category.

Handing a New CPT Over to the Editorial Team

1. The technical owner registers or confirms the CPT on the Dashboard and the selected test group of Child Sites.
2. They document the three identifiers, registration source, required fields, taxonomies, and public verification URLs in the type profile.
3. An editor creates a neutral draft with a unique title and selects one Child Site.
4. The technical owner confirms that the post was created with the correct type and is available through Manage Posts.
5. The reviewer opens the public page, archive, and expected site block, if one exists.
6. After a successful single-site test, the team repeats it for a consistent group and documents the permitted recipient set.

This order may seem slower than simply clicking Publish and checking afterward. In reality, it reduces unclear situations. If a problem appears after step two, the technical owner handles it. If the text is unsuitable for a particular market, it is an editorial task. If the post was created but is not visible in a grid, the template needs to be checked. As a result, there is no need to change three unrelated layers at the same time.

Minimum Naming and Search Rules

A unique test title is a small but powerful tool. It should make the post easy to find through the keyword field without accidental matches. Adding a short task marker to the title can help, but do not leave it on a published client-facing card. After verification, rename the post with a normal editorial title or remove the test through Trash.

For recurring publications, agree on one internal-note format: which CPT was used, which Child Sites were selected, what status is expected, and which public page was checked. This does not need to be added to the post text or shown to visitors. An internal note prevents a situation where another editor sees a similar card a week later and does not understand where it came from or why Bulk Edit is available or unavailable for it.

How to Keep Centralization From Becoming Added Risk

A central dashboard increases the power of an action, which means it requires narrower selection. Do not combine sites with different editorial rules in one publication merely because they can all be checked. Do not use one shared title for a marketing campaign if one site must display a legal clarification, another needs a different language, and a third requires a different image set. In this situation, create separate posts or keep the local workflow.

If the team frequently produces similar materials, create a verified set of draft templates outside the actual publishing mechanism: approved text structure, image requirements, permitted taxonomies, and verification points. Then use MainWP Custom Post Types for its intended purpose: deliver one finished post to an already verified group. This allows centralized management to speed up the operation rather than conceal the absence of a content standard.

Testing Plan Before Updating MainWP, a Theme, or the CPT Source

Updating the Dashboard, Child plugin, theme, or component that registers a CPT can change the working environment. This does not mean every update is dangerous, but it does mean that an old test should not be treated as permanent. The extension's changelog has included fixes related to publishing and loading CPT categories, so after significant updates it is useful to run a short regression check in one test environment.

A Six-Point Test

1. Open the Dashboard and confirm that the required CPT is still visible as managed.
2. Open one Child Site and check that MainWP Child, Classic Editor, and the type registration source are active.
3. Compare the slug, Singular Label, and Plural Label with the type profile if the CPT source was updated.
4. Create or update a safe test draft on one recipient through Child Site selection.
5. Find it in Manage Posts using type, status, and keyword filters.
6. Check the admin area and public page, then remove the test through Trash or leave it as a draft according to project rules.

Do not skip the public-facing step. A theme update may leave MainWP delivery untouched while changing an archive query. Conversely, a MainWP update may leave the card's appearance unchanged while affecting creation or filtering. Separate checks reveal where to investigate more quickly.

What to Do When the Outcome Is Unclear After an Update

First, stop broad bulk operations. Take one post with a unique title and one verified Child Site. If the CPT itself disappears, compare registration. If the post is not delivered, check Child and the connection. If it is delivered but invisible to visitors, review the template and taxonomies. If everything works on one site but not another, do not apply a network-wide "general fix": compare the two sites' profiles line by line.

Keep a short record of the update outcome: what was updated, which CPT was tested, which site received the post, and which publication and public page passed verification. Editorial articles do not need version details or secrets, but they help in an operational log when connecting an environment change to a recurring symptom.

Install It at the Correct End of the Connection

MainWP has a common trap: Dashboard and Child perform different roles. Custom Post Types is a Dashboard extension. Install and activate it on the separate site that runs MainWP Dashboard, not on every managed project. Child Sites receive MainWP Child and their existing CPT registration. Uploading the extension ZIP file to Child Sites will not expand their content model and will only make troubleshooting more difficult.

1. Sign in as an administrator on the WordPress site that runs MainWP Dashboard.
2. Open MainWP > Add-ons > Manage Add-ons and find Custom Post Types in the available add-ons list.
3. Install and activate the add-on on the Dashboard. If ZIP upload is used, use the standard Plugins > Add New > Upload Plugin screen only on the Dashboard.
4. Confirm that MainWP Child is installed, active, and connected on every site in the test group.
5. Install Classic Editor on the Dashboard and every Child Site that will participate in the operation.
6. Open the add-on page and do not move straight to publishing: first check whether the expected registered type appears.

After activation, there is no need to look for a general "CPT settings" screen in the sense of a field builder. The extension's primary action appears where a custom type is already registered. The official path for creating a new post in current documentation is MainWP Dashboard > Add-ons > Administrative > Custom Post Type. MainWP may reorganize interface categories over time, so use the add-on name and registered-type list as your guide rather than old screenshots from random tutorials.

Post-installation checkpoint: if the add-on is active but the expected CPT is missing from its area, do not create a test post. Return to type matching on the Dashboard, dependencies, and site-list synchronization.

Configure a Matching CPT Without Risky Core Changes

MainWP documentation lists two ways to register a matching type on the Dashboard: code in functions.php and a third-party registration tool. The first method is suitable only when you maintain the theme code and fully understand the consequences. It is inconvenient for production sites because a type placed in a theme becomes dependent on that theme. The main goal of this guide is not to teach arbitrary PHP, but to achieve reliable matching, so it is safer to start with a clear registered configuration that can be reviewed and compared.

Custom Post Type UI or Pods can serve as supporting tools - both are specifically mentioned in MainWP documentation for CPT registration on the Dashboard. Custom Post Type UI is convenient when the focused task is registering types and taxonomies through the admin area. Pods is better suited when a type already has field groups and relationships. These tools do not replace MainWP Custom Post Types: they help describe the structure, while the MainWP extension manages publication across connected sites.

Recommended Configuration Order

1. On one Child Site, open the existing CPT and record its slug, Singular Label, and Plural Label from the registration source, not from a user-facing post title.
2. Determine what is responsible for the type on Child Sites: a dedicated plugin, a code module, or a theme. Do not remove that source for the sake of MainWP.
3. Create a Dashboard type with the same three identifiers, or connect the same source plugin to the Dashboard if that is appropriate for its purpose.
4. Match support for the title, editor, and required taxonomies. Do not add required fields "for appearance" when they do not exist in the actual Child Site structure.
5. Save the registration, refresh the CPT list in MainWP, and find the MainWP icon next to that type's menu item.
6. Run a one-Child-Site draft test, then open the post directly on the child site and check its type, title, text, and required fields.

What Not to Copy Mechanically

Do not transfer arbitrary theme templates, PHP snippets from an old forum, or settings from someone else's type to the Dashboard. Matching three identifiers is necessary for MainWP, but it does not justify copying business behavior. For example, a property type may require coordinates, deal status, and access restrictions. If the Dashboard lacks the component that makes these fields understandable, an editor may create a post that appears successful but is incomplete.

Likewise, do not use edits to the WordPress core, MainWP, or a theme as a "fix." Such changes disappear after an update and complicate maintenance. If registration is managed by your own code, make a reversible change in a supported plugin or child theme according to project rules, document it, and test it on a test site. If you are not confident, use the CPTUI or Pods admin interface and leave complex fields to their original owner.

Publishing Through Site Selection: Where the Extension Begins Its Work

Once the required type appears on the Dashboard as managed, the workflow looks much like adding a normal WordPress post. In Custom Post Types, choose the registered type and click Add New. Enter the title, content, and only the metadata that your test setup actually supports. Then use the Child Site selection metabox. This is the critical moment: do not assume the publication should go to every connected project. Select only sites whose structure has been verified and where the material is appropriate.

The apparently simple step of "selecting sites" is a boundary of responsibility. MainWP is responsible for sending the content operation to selected recipients. The editor is responsible for ensuring that CPT registration, access permissions, required fields, and the display template are current on every recipient. That is why the first run should use one Child Site, the second run a small consistent group, and only then the full set. This approach helps distinguish an issue in the material itself from a difference between sites.

What to Enter in the First Test

Use material that is easy to recognize: a unique title with an internal test marker, short text, one permitted image, and the minimum required fields. Do not add complex relationships, uncommon taxonomies, form integrations, or large media imports in the first test. The goal is not to test every WordPress capability at once. It is to prove the basic chain: Matching CPT is recognized, the Child Site is selected, the post is created with the correct type, and the public-facing site reads it correctly.

Before clicking Publish, check four things: only the expected site is selected, the publication status is intentional, the title is unique enough for searching, and no confidential test text is included. After publishing, do not treat the form simply disappearing as proof of success. Open Manage Posts, locate the post by keyword, and inspect it directly on the Child Site.

WooCommerce Products Consideration

If the type is WooCommerce products, MainWP describes a separate path: WooCommerce must be installed on the Dashboard, after which the extension automatically adds Products support. Here, it is especially important not to infer full store compatibility from successful product creation alone. In a test product card, verify product type, price, catalog visibility, image, category, stock status, and public link. If specific fields are created by another plugin, test their behavior on one Child Site before working with a group of stores.

Do not use bulk publishing to discover whether the structure is suitable. A small test takes minutes, while correcting dozens of incomplete cards may affect menus, archives, caching, and search listings.

Manage Posts as the Center for Search, Statuses, and Cleanup

After publishing, the primary work screen is MainWP Dashboard > Sites > Content Operations > Manage Posts. The standard MainWP post-management area is designed for regular posts, while the active CPT extension adds support for custom types. In the search area, select the required Post Type, sites, and conditions, then click Show Posts. The results below the form are not merely a read-only list; they are the place for subsequent verification, viewing, editing, status changes, and moving posts to Trash.

Filters are useful for more than cleanup. The keyword field helps locate a test post by a unique phrase. The date range limits results to a recent operation. Status separates drafts from published posts or items already sent to Trash. Type selection prevents a similarly titled standard post from being mistaken for the target content. Before a bulk action, build a narrow set of results and make sure it contains no unrelated content.

Editing, Viewing, and Changing Status

For a particular row, use Edit, then recheck the target sites affected by the change. The View action helps confirm that the post truly opens on the public-facing site, but it does not replace reviewing the archive template or block where the content should be visible. When changing status, it is useful to inspect the list before and after the action so that a draft is not confused with a published post.

Deletion should be separated into two operations. First, move a post to Trash through Trash. WordPress allows permanent deletion only for posts already in Trash. This is a useful restriction because it leaves a window for verification and restoration. Even if content is clearly outdated, do not combine moving it to Trash and permanent deletion in the same initial bulk action.

The Bulk Edit Boundary

Official documentation specifically warns that Bulk Edit for CPT posts is unavailable if a post was not published through MainWP Dashboard. This is a logical but important origin boundary. Do not promise an editor that the extension can take an old locally created catalog and begin safely changing all of it in bulk without preparation. For those posts, first check available actions on a single row, confirm the creation source, and consider a possible process-migration plan.

Practical Example: One Case Study Catalog Across Three Sites

Imagine an agency with three sites: a main site, a regional storefront, and a specialized-service site. Each has a case_study CPT with the labels Case Studies and Case Study. The Dashboard registers it with the same values. On all three sites, a case study card requires a title, main text, image, and service-category taxonomy. A "Budget" field exists only on the main site, so it is not used as a required field in the first centralized publication.

Goal and Preparation

The goal is to create one new case study, show it on two sites, and leave the third untouched because its audience is not relevant to the service. Preparation includes checking the MainWP Child connection, Classic Editor, matching three CPT identifiers, and consistent availability of the required taxonomy. Before starting, the editor creates an identifiable test title, such as "Case Study: Form Analytics - MainWP Test," so the post can be found among existing content without being confused with client material.

Step 1: Confirm Structure, Not Just the Menu Appearance

On the first Child Site, open the type registration source or CPTUI/Pods settings. Record case_study, Case Study, and Case Studies. Repeat this on the second and third sites. Then open the menu item on the Dashboard. If MainWP shows it as available for management and the related indicator appears next to the menu, you can proceed to editing. If not, stop: publishing at this point would not prove that the workflow works, but would be a random experiment with mismatched structure.

Step 2: Create a Minimally Sufficient Card

In Custom Post Types, select the required type and click Add New. Enter the title, main text, image, and only one verified taxonomy. Save the material as a draft if the content approval process is not complete. If the purpose is strictly technical verification, use neutral test material without personal data, pricing, or confidential information.

Step 3: Select Recipients Intentionally

In the Select Sites metabox, select the main and regional sites. Do not select the third site. This deliberate exclusion is just as important as publication itself: afterward, you can confirm that the extension sent the action exactly where instructed. Click Publish only after reviewing the list again. If there is a risk of using the wrong group, work one site at a time instead of relying on remembered tags.

Step 4: Verify the Outcome in Two Layers

First, on the Dashboard open Manage Posts, set Post Type to case_study, enter the unique part of the title, select the two recipients, and click Show Posts. You should find two meaningful rows or results corresponding to the selected scope. Then go to the admin area of each Child Site. Confirm that the post has the correct type, was not created as a standard post, contains the title and text, has the required taxonomy, and has the correct status.

The second layer is public verification. Open the case study archive, list page, or theme block where the content should appear. Check not only the direct link to the single card, but also the place where a visitor would actually find it. If the third storefront was not supposed to change, perform the same search there. Its absence confirms that site selection worked as a constraint rather than a decorative field.

Step 5: Edit and Safely Remove the Test

Edit one short phrase through Edit and verify the update on both recipients. When the test is complete, move the post to Trash, find it with a status filter, and decide on permanent deletion only after an approved review. This gives the team a repeatable procedure rather than a one-time feeling that "something got published."

Common pitfall: if one of the two sites accepts the post and the other does not, do not repeat publication blindly. First compare Matching CPT, Classic Editor status, the Child Site connection, and required fields on the problematic recipient.

Why Content May Be Saved but Still Not Appear to Visitors

MainWP-side success and visitor-facing success are different verification layers. The extension may create a post of the correct type, while the theme or builder may not display that type in the intended location. The CPT may have a private archive, a custom query, a taxonomy exclusion, its own single-post template, or a cached listing. For that reason, after every important use case, verify the route "Dashboard post - Child Site post - public link - target listing."

Structural problems are especially often confused with display problems. If a post appears in Manage Posts and in the Child Site admin area but not on a catalog page, MainWP Custom Post Types has most likely completed its content task. The next step is to examine the CPT configuration, theme query, block, or plugin that builds the list. Do not change the slug to "fix" a storefront: doing so can easily break the match and existing links.

Permalinks and Archives

WordPress determines CPT URLs at registration time, including through the rewrite argument. If a post opens with an error after a registration change, first review how permalinks are configured in the project and carefully resave them using the standard WordPress screen. This action applies to the site where registration changed, not automatically to every Child Site. Do not replace it with random core code or change the URL structure of all projects without a redirect plan.

Fields, Media, and Taxonomies

Publishing a title and text alone does not prove that all meta fields match. If a card depends on custom fields created by ACF, Pods, or an industry-specific plugin, check their values and display on the specific post. For images, check the target site's Media Library and public template. For categories and taxonomies, verify that the required term exists and belongs to the same CPT. If terms are missing or do not match, do not conceal the issue by publishing again.

Verify the Outcome Before Entrusting the Workflow to Editors

Before handing the workflow over for daily use, run a short acceptance test. It should be reproducible rather than abstract. Choose one CPT, two Child Sites, one incomplete test item, and one published item. First, make sure the type is recognized on the Dashboard. Then create a draft on one site, publish a distinct example on two sites, find both through Manage Posts, edit one fragment, and confirm that the change is visible where expected.

• Structure verified: the slug, Singular Label, and Plural Label match on the test recipients.
• Path verified: the Dashboard sees the selected CPT and allows Add New to be opened.
• Delivery verified: the post is found when filtering by type and selected Child Sites.
• Outcome verified: the admin area and public display show the expected content and status.
• Rollback verified: the test post can be moved to Trash and restored if needed before permanent deletion.

Record the test outcome in a short team instruction: which sites belong to the consistent group, which type is approved for publishing, which fields are required, who confirms public display, and who should be notified about an error. This is particularly important for client sites where similar type sets look identical but belong to different themes or plugins.

Troubleshooting MainWP Custom Post Types: Symptoms, Causes, and Safe Actions

This is not a generic "clear the cache" list. MainWP Custom Post Types has a specific dependency chain: Child Site connection, active Classic Editor, matching CPT, site-selection metabox, publication, and public display. Start where the chain breaks. That saves time and prevents duplicate posts.

The Required Type Does Not Appear in MainWP Dashboard

Symptom: the add-on is active, but the expected section is missing from the Custom Post Types area, or the menu item has no MainWP management indicator.

Likely cause: the CPT is not registered on the Dashboard, one of the three required indicators differs, or the Dashboard has not yet received the current state after a structural change.

What to check: the registration source on the Dashboard and Child Site. Compare slug, Plural Label, and Singular Label exactly. Then make sure this is not a standard post or a type that exists only in the active theme on one Child Site.

How to fix it: register a genuinely matching type on the Dashboard through a supported source - the same required plugin, CPTUI, Pods, or approved project code. Then synchronize site status in MainWP and reopen the add-on page. If you are uncertain about registration, stop at the test site.

When to roll back: if the new registration conflicts with an existing menu, URL, or fields, remove only the test configuration, return to the documented matrix, and do not alter the working type on Child Sites just for one central dashboard.

Child Site Selection Is Missing From the Creation Screen

Symptom: an editor opens Add New for a CPT but cannot see the expected recipient-selection metabox.

Likely cause: the required Classic Editor is missing, a nonmatching CPT is in use, or the type was not recognized by the extension as managed.

What to check: Classic Editor activity on both the Dashboard and Child Sites. Then confirm that the open post belongs to the selected matching CPT rather than a similar standard type. Review Screen Options if your WordPress configuration allows metaboxes to be hidden.

How to fix it: activate Classic Editor on both sides of the workflow, return to Matching CPT verification, and reopen the add-new screen. Do not replace the metabox with a third-party script or try to send data directly to the database.

When to roll back: if switching to Classic Editor conflicts with a required editorial policy for the site, do not deploy the extension to that group. First agree on a separate safe workflow or keep local editing.

A Post Appears Only on Some Selected Sites

Symptom: the MainWP filter shows publication on one recipient, but the second has no post or returns a connection error.

Likely cause: the Dashboard connection to the Child Site is broken, MainWP Child is not connected, the CPT differs, or the target site is not ready to accept required fields.

What to check: run Test Connection for the problematic site, open its MainWP Child configuration, and confirm that it is connected. Then reduce the test to simple material: a title and text without complex fields. Compare the type registration with the working recipient.

How to fix it: restore the connection through MainWP > Sites > Manage Sites, correct Matching CPT or the required fields. After a successful local test, repeat the action only for the undelivered site. Do not repeat publication for the entire group, or duplicate posts may appear on sites where publication already succeeded.

When to roll back: if the initial operation created an incomplete card, move it to Trash on the affected site or restore from a return point according to your procedure, then begin again with a single-site test.

The Post Exists in the Admin Area but Is Missing From the Catalog

Symptom: Manage Posts finds the CPT, the direct post exists in the admin area, but visitors cannot see it in the archive, block, or case-study list.

Likely cause: this is usually a public-template or query issue, not a MainWP delivery issue. The archive may be disabled, a filter may expect a different taxonomy, or a cache may be showing an old listing.

What to check: the direct single-post link, publication status, assigned taxonomy, display settings in the theme, and cache within the project's normal maintenance procedure. If CPT registration changed recently, check permalink settings on the specific Child Site.

How to fix it: correct the public-query condition or assign a verified taxonomy, then recheck the list. Do not change Matching CPT or reinstall the extension while it has been proven that the post was already created with the correct type.

When to roll back: if a new template or display setting worsened the existing catalog, restore the previous theme configuration and isolate the test post. Theme work and MainWP work should have separate rollback points.

Bulk Edit Is Unavailable for Older Content

Symptom: older CPT posts are found by search, but the required bulk operation is unavailable or behaves differently from newer posts.

Likely cause: MainWP documentation limits Bulk Edit for posts that were not published through MainWP Dashboard.

What to check: the origin of one problematic post and whether it can be edited individually through Edit. Do not draw conclusions about an entire collection from one row without checking.

How to fix it: use targeted editing for existing local content, or plan a new workflow in which subsequent posts are created through the Dashboard. For large volumes, discuss migration separately, because MainWP Custom Post Types is not presented as a tool for safely converting the origin of old content.

When to roll back: do not attempt bulk "normalization" through statuses. If testing reveals a risk to older posts, cancel the operation before it affects the collection.

Changing a CPT Caused Strange URLs or 404 Errors

Symptom: the type is recognized, but a public link to a new or old post opens with an error.

Likely cause: type registration was changed, especially the rewrite rules, or the particular site needs the standard permalink refresh.

What to check: recent changes in the registration source, the original and current slug, permalink settings, and whether a conflicting URL exists. Do not combine this with MainWP connection troubleshooting if the post is already visible in the admin area.

How to fix it: restore the approved slug if it was changed incorrectly, save permalinks through the standard method on the affected site, and test both the old and new links. For a live project, prepare redirects according to its rules if the URL changed intentionally.

When to roll back: if the change was made only for the visible menu name, restore the previous technical registration and separate the presentation task from the data structure.

A Small Workflow Improvement Without Unverifiable Code

For this extension, a short operational card alongside the editorial workflow is more useful than an invented PHP snippet. The basis is simple: MainWP documentation describes exact matching of three parameters and the Bulk Edit limitation based on post origin. No general code snippet can safely guess the fields used by your theme, builder, or catalog plugin.

Create an internal-note template with five lines: "Type and slug," "Recipients," "Required fields," "Public verification location," and "Rollback action." Complete it before the first publication of a new content workflow. This is a reversible improvement: it changes nothing in the core, theme, or plugin, helps the editor remember site selection, and gives the administrator useful diagnostic details.

The test is simple: take a new test case study and ask another team member to publish it using only the card. If they can find the CPT, select the sites, identify the public verification location, and move the test to Trash without follow-up questions, the workflow has become more reliable. If the card does not help, do not add automation - clarify the specific gap in structure or permissions.

A Short Demonstration of the Mechanics Using Movies

MainWP has a focused demonstration video that shows the extension with the Movies type. It is useful as a visual companion to the Matching CPT and Child Site selection sections: it shows why one shared menu name alone does not guarantee that the workflow will work, and how remote publication relates to a specific type. The video predates current documentation, so its interface should not be used as the only guide to modern menu paths. Compare actions with current MainWP pages and use the video to understand the workflow.

When MainWP Custom Post Types Becomes a Strong Working Tool

The extension earns its place when your network already follows a consistent content discipline. You know which CPT exists on every site, why its three key identifiers match, who selects recipients, and where the public outcome is verified. In that situation, MainWP Custom Post Types removes the routine of signing in to several admin areas and gives the team a controlled route for publishing, searching, status management, and cleanup.

If types are created by different themes, fields and templates differ, and site connections have not been verified, fix the foundation first. Do not turn the extension into a magical compatibility layer. Prepare one consistent group, complete the workflow from this guide, and move to operational scale only after successful verification. Once the environment is ready, you can download the latest version of MainWP Custom Post Types and begin with a controlled test publication.