ACPT - WordPress Plugin

ACPT Guide: How to Build Content Structure, Fields, and Output in WordPress

ACPT becomes useful not when you just need to add one more setting in WordPress, but when your site needs its own data model: separate post types, taxonomies, meta fields, forms, dynamic blocks, configuration export, and a clear way to verify that all of it actually works. In this guide, we will look at ACPT as a practical content modeling tool, not just a polished "create custom post type" button.

This guide is written for site owners, editors, developers, and small studios that need to understand not only what to click, but why a specific setting affects the admin panel, public URLs, the block editor, the REST API, SEO plugins, caching, and future project maintenance. We will go from preparation and installation to a hands-on specialist directory example, result verification, troubleshooting, and choosing comparable alternatives.

This article does not cover purchasing instructions, license bypasses, or working with someone else's keys. The focus is on using an already installed plugin safely: what to enable after activation, which settings not to touch without a reason, how not to lose data when deleting a definition, and how to tell whether the problem is in permalinks, cache, a slug, permissions, or a theme conflict.

What ACPT Solves in a Real WordPress Project

A standard WordPress post works well for a blog, news, and simple publications. But as soon as a site starts storing different kinds of entities, a single post is no longer enough. A course has an instructor, duration, and format. A real estate listing has an address, price, gallery, area, and a relationship to an agent. A book has an author, genre, cover image, rating, and an external link. You can put all of that into plain text, but then the editor loses structure, filters become fragile, and template output turns into manual markup.

The main job of ACPT is to turn those entities into a manageable WordPress structure. The plugin provides an interface for registering custom post types, taxonomies, meta field groups, option pages, forms, and dynamic blocks. The official documentation separately describes panels for custom post types, taxonomies, field groups, the meta fields manager, forms, dynamic blocks, tools, the REST API, and integrations. That matters because the product is not limited to a single "create CPT" action. It covers a large part of the full cycle: define the structure, fill in the data, display the result, and move the configuration elsewhere.

For an editor, that means less arbitrary text and more clearly defined fields. For a developer, it means fewer one-off PHP snippets for every new project. For a site owner, it means a more stable model that can be explained to a new employee or contractor. At the same time, ACPT does not replace the core rules of WordPress: the slug should be clean, permalinks need to be checked, post type visibility should match the use case, and site output still depends on the theme, blocks, templates, or page builder integration.

When the plugin makes sense

ACPT is worth considering if the site needs directories, knowledge bases, portfolios, events, listings, specialists, testimonials, documents, service cards, private reference databases, front-end content submission forms, or structured settings pages. It is especially useful when the same set of fields is repeated many times and should be editable without copying HTML.

The product is also appealing for studios building similar projects and wanting to move a structure from one site to another. ACPT's export/import tools export ACPT settings, not the actual posts. That does not replace content migration, but it is a convenient way to move the data model itself: post types, taxonomies, field groups, and related definitions.

When ACPT should not be your starting point

If you only need one extra block on a page, a simple contact form, or a couple of fields in a theme, ACPT may be more than you need. If the whole site is already built on another dynamic data system such as ACF, Meta Box, Pods, Toolset, or JetEngine, migrating just for the interface is rarely worth it without a separate reason. If the team does not understand the difference between a post type, taxonomy, and meta field, it is better to design the structure on paper first. Otherwise, you may end up with a polished admin UI built on a poor data model.

Practical rule: create a new post type only when the entity has its own lifecycle, its own admin navigation, its own fields, its own URL, or a separate display scenario. If the content differs only by category, a taxonomy or regular posts are often enough.

Who ACPT Is For and Where It May Fall Short

ACPT is designed for several user levels. A beginner gets visual wizards and can build a basic post type without code. An editor gets a cleaner content entry form. A developer gets an API, functions, a REST dashboard, settings export, and a faster way to assemble a project skeleton. An agency gets repeatability: a well-designed model can be moved to the next site and extended.

That said, ACPT should not be treated as a magical substitute for design decisions. The plugin helps you register a structure, but it does not make architecture choices for you. For example, "Genre" in a book catalog is better as a taxonomy because it is easy to filter and group by. "ISBN" is better as a text field. "Author" could be either a separate post type or a taxonomy, depending on whether the author needs a dedicated page, photo, biography, relationships, and extra fields.

For the site owner

A site owner will benefit from ACPT if they want to hand work off to a content manager and reduce the risk of mistakes. Instead of saying "put the image on the right, the rating at the top, and the link at the end," you can create fields such as "Photo," "Rating," "Author Website," plus an output template. In that setup, the editor fills out the form, and the site places the data where it belongs.

For the developer and studio

For a developer, ACPT can save time on routine registration of post types, fields, and taxonomies. But the developer still needs to understand the WordPress API, REST behavior, permalinks, user permissions, caching, and theme output. If the project requires complex queries, custom tables, or high traffic, you need to evaluate in advance how the data will be stored and how often it will be queried.

Limitations worth knowing up front

The free ACPT Lite version on WordPress.org shows the basic feature set and is useful for an initial interface check. The official product page and documentation describe a broader feature set in ACPT, including advanced fields, forms, dynamic blocks, WooCommerce product data, integrations, and the API. So before designing a live site, make sure the features you need are actually available in your installed version.

The second limitation is output. Creating a post type and fields is easier than building a polished public-facing template. ACPT offers dynamic blocks, forms, builder integrations, and APIs, but the result still depends on the theme, the editor, the selected output method, and data quality. If you are building a complex directory, budget separate time for templates, filters, SEO, and testing.

What to Check Before Installation and First Run

Before installing ACPT, check not just the WordPress version but the overall state of the project. The plugin works with definitions that affect the admin panel, URLs, editor fields, the REST API, and sometimes public output. On a test site, that is a safe experiment. On a live site, any structural change should be made with a backup and a clear rollback plan.

Technical compatibility

The official ACPT v2 documentation lists minimum requirements for WordPress, PHP, MySQL, and memory. It also specifically notes that the error_log function must be available, because troubleshooting becomes much harder without an error log. For a production setup, what matters is not just that "the plugin activates," but that the server can write errors, the admin panel is not blocking AJAX requests, and the database does not have corrupted tables.

Check the block editor separately. If the new post type needs to work with Gutenberg, the REST API, blocks, or dynamic tags, the show_in_rest setting is critical. WordPress itself ties custom post type and taxonomy availability in the REST API to the show_in_rest parameter. ACPT documentation explicitly asks you to pay close attention to that parameter when creating a custom post type.

Backup and testing environment

Before the first serious change, back up both files and the database. It is better to test the structure on a staging site or a temporary copy. Do not start on a live directory if you have not yet decided which slugs, fields, and taxonomies are permanent. Once a post type slug is created, it is usually harder to change than an admin label, and changing a URL can affect SEO and internal links.

A map of the future structure

Before installation, it helps to list the project entities in four columns: post types, taxonomies, meta fields, and output method. For example, for a specialist directory:

That map only seems unnecessary on a very small site. In a real project, it prevents the most expensive mistakes: overly generic slugs, the wrong field types, duplicated taxonomies, missing REST support for the block editor, and unclear output logic.

Installing ACPT and Checking the Admin Panel

Installation works like any other WordPress plugin: upload the ZIP file or install the Lite version from the repository, activate it under Plugins, then go to ACPT settings. If you are using Pro features, do not pass license data into third-party tools or paste keys into prompts for generators. During site setup, the key should stay inside the admin panel and the owner's account.

First review after activation

After activation, check whether the ACPT menu item appears in the left-side WordPress menu. Then open the custom post types panel. ACPT documentation describes automatic synchronization of already registered post types during installation, as well as manual synchronization from the dashboard. The list may include native WordPress posts and pages marked as Native. That is normal: ACPT sees the existing types, but native elements cannot be deleted like the plugin's own definitions.

Next, open Settings. In general settings, check the language, interface theme, records per page, admin menu, logs, and beta versions. Beta versions should not be enabled on a live site without a reason. Logs, on the other hand, are useful during setup and troubleshooting, but on a mature project they should be managed so you do not keep unnecessary data forever.

Content settings

In the content settings section, ACPT lets you enable and disable functional modules. According to the documentation, custom post types, taxonomies, option pages, and meta fields are enabled by default. Forms and dynamic blocks are off by default and must be enabled manually. That is a good model: do not enable forms and blocks "just in case" if the project only uses post types and fields for now.

Danger zone and data deletion

ACPT settings include options that control deletion of definitions, posts, and metadata. They should not be enabled automatically. For example, deleting posts when deleting a custom post type definition can lead to content loss, and deleting metadata when deleting a field can remove values editors have already entered. If you are experimenting on staging, these switches can help clean up tests. On a live site, it is safer to export settings first, create a backup, and only then remove definitions.

Quick post-install check: ACPT is visible in the menu, existing post types are synchronized, settings open without errors, logs are enabled during setup, cache behaves as expected, and forms and dynamic blocks are enabled only if the project needs them.

Creating a Post Type and Taxonomy Without Making a Mess of URLs

A custom post type in ACPT is created with a three-step wizard: basic data, labels, and settings. That sequence matches WordPress logic: first you define the machine name and core properties, then the admin labels, then the behavior of the post type in the menu, public-facing site, REST API, and other places.

Basic step: slug, labels, and editor support

The post name field defines the slug. ACPT documentation notes that the plugin sanitizes the slug automatically, but that does not remove the need for a thoughtful project-level choice. Do not use overly generic values like product, item, type, or category if they could conflict with the theme, WooCommerce, taxonomies, or future site sections. WordPress Developer Resources recommends avoiding identifiers that are too generic and keeping the post type identifier length limit in mind.

Singular label and plural label are visible in the admin panel. Here you can use names that make sense to the editor: "Specialist" and "Specialists," "Course" and "Courses," "Listing" and "Listings." Pick an icon so the menu item does not blend in with standard posts. In supports, enable only what you actually need: title, editor, thumbnail, excerpt, comments, and other capabilities should match the content workflow.

Labels step: when defaults are enough

Labels control interface text: add, search, no items found, edit, and similar actions. For an internal project, the defaults are often enough. For a client site, it is worth going through this step and cleaning up the labels, otherwise the editor may see a mix of English and another language in the interface.

Settings step: visibility, menu, and REST API

The third step determines whether the post type will be public and whether it will appear in the admin panel, menus, navigation, admin bar, and REST API. If the type is only for technical data storage, visibility can be limited. If it is a full directory with dedicated pages, public output and rewrite settings should be planned from the start. For the block editor, REST integrations, and some dynamic scenarios, enable show_in_rest when it matches the use case.

After creating the post type, check whether the new item appears in the left-side WordPress menu. Create one test entry, publish it, open the permalink, and verify the public page. If the page returns a 404, first resave permalinks in WordPress settings. That is a standard check after registering new rewrite rules.

Taxonomies and reserved terms

A taxonomy in ACPT is also created with a three-step wizard. First you define the slug, singular label, and plural label, then labels, then settings. ACPT documentation specifically warns about WordPress reserved terms: some reserved words can lead to 404 errors with no clear hint. So for taxonomies, choose narrow, domain-specific slugs such as specialty, book_genre, event_type, property_city, not type, name, term, or category.

After creating the taxonomy, attach it to the required post type. Then create several terms, assign them to a test entry, and confirm they are visible in the admin panel. If the taxonomy needs to be available in filters or REST, check the corresponding settings during the settings step.

Meta Fields, Groups, and the Logic of Content Entry

Meta fields are the most practical part of ACPT because they are what turn ordinary text into a structured content card. In ACPT, field groups act as containers for fields and can be assigned to different WordPress objects: custom post types, taxonomies, users, option pages, or attachments. Inside the group, you create meta boxes, and inside those, individual fields.

How to design a field group

Do not start by choosing the prettiest field types. Start with the question: what data does the editor need to enter, and how will the site use it afterward? A specialist directory may need a photo, title, city, experience, specialization, website, rating, and short bio. A book directory may need a cover image, author, publication year, genre, external URL, rating, and gallery. A property database may need address, map, area, price, status, gallery, and an agent relationship.

In ACPT, the meta fields manager provides the actions Add meta box, Delete all, and Save. A meta box has operations such as copy, duplicate, delete, and collapse. Fields have toggles for showing in the admin list, filtering, quick edit, and required status. Use those toggles intentionally. A "City" field is useful in the list view and can be made filterable. A long description or HTML field is better left out of the list table, otherwise the admin panel becomes noisy.

Choosing the right field type

ACPT documentation lists a wide range of field types: address, audio, barcode, color, country, currency, date, editor, email, embed, file, gallery, HTML, icon, image, number, phone, QR Code, select, checkbox, radio, rating, repeater, relational, table, textarea, text, time, toggle, URL, video, weight, and others. The choice affects not only the interface, but also value validation, future output, and editor usability.

• Text works well for short strings that do not need special validation.
• Textarea is better for short descriptions without complex formatting.
• Editor is needed when the editor needs formatted text.
• Image and Gallery should be used for media that needs to be rendered as images.
• Select, Checkbox, and Radio are a good fit when the available choices are known in advance.
• Relational makes sense when you need to connect WordPress entities, such as a specialist and their services.
• Repeater is useful for repeatable blocks, but it should not be used where a separate post type would be the better model.

Conditional rendering, validation, and permissions

The field panel in ACPT is divided into the tabs basics, advanced options, conditional rendering, validation rules, and permissions. That lets you do more than simply add a field. You can control visibility conditions, required status, validation, and access. For example, a "Portfolio URL" field can be shown only for a specific kind of specialist, while an email field can be required only in a contact form.

Do not make every field required. Required is useful for data without which the card loses its meaning: title, city, primary status, core image. But if you make secondary fields required, editors will start filling them with junk just to get past save validation. It is better to leave a field empty and provide a clean fallback in the template.

Post-Install Settings: Cache, Services, Forms, Blocks, and Safe Disablement

Once the basic structure is clear, go back to settings. ACPT separates general settings, content settings, external services, performances, and the danger zone. This section is often skipped, but it is where you decide which modules are available, how cache behaves, and which external keys are needed for certain fields or forms.

Language, interface, and records per page

If several editors work on the same team, syncing the language with locale may be more convenient than selecting it manually. Skin and font affect only admin usability, but records per page affects how manageable large lists are. If you have hundreds of types, fields, or forms, do not set the number too high, or the admin panel will load more than it needs to.

Enable modules only when the project actually needs them

Custom post types, taxonomies, option pages, and meta fields are usually central to the core workflow. Enable forms and dynamic blocks only when they are genuinely part of the project. For example, if you want to display a front-end form for adding a new entry, enable the form builder. If you need to create your own Gutenberg block using ACPT fields and TWIG, enable dynamic blocks. If neither is part of the requirement, leave them off and reduce the potential conflict surface.

External services

ACPT settings let you connect a Google Maps API key for the address field, a Google Sheets API key for importing sheets into table fields, and Google reCAPTCHA or Cloudflare Turnstile for CAPTCHA in forms. Do not place those secrets in articles, notes, prompts, or external documents. Keep them in the admin panel and service account. If the form does not use CAPTCHA, do not connect keys in advance.

ACPT cache and metadata

In performances, you can manage ACPT's built-in cache: enabling cache, caching metadata, selecting the driver, viewing cache stats, and flushing it. According to ACPT documentation, cache is enabled by default, while cache for meta data is disabled by default. That is sensible because metadata often changes during setup, and extra caching can hide the real issue.

For a typical project, leave the basic cache enabled, but do not enable cache for meta data until you understand which fields appear on the front end and how often they change. If the site still shows an old value after a field is updated, clear ACPT cache first, then the optimization plugin cache, then hosting or CDN cache. Do not keep changing the field structure until you know which layer is serving stale data.

How to roll back a questionable setting safely

For every questionable setting, use a simple pattern: record the current state, change one parameter, save, test the admin panel and the public page, then either keep the change or revert it. Do not enable forms, dynamic blocks, cache for meta data, new permissions, and data deletion at the same time. If something breaks, you will not know which switch caused it.

Best setup order: enable the required module, create a test entity, verify saving, verify output, clear cache, repeat the check in another browser or user role. Only after that should you move the structure into live content.

Practical Example: A Specialist Directory with Profile Pages and Filtering

Let us walk through an example that shows how ACPT works in practice. The goal is to build a specialist directory in WordPress. Each specialist should have a dedicated profile page, photo, city, experience, specialization, website link, and short description. Specializations should group specialists, and the completed fields should be verified on the public page.

Goal and preparation

We need a specialist post type, a specialty taxonomy, and a field group called "Specialist Data." Before you begin, prepare a staging site, enable ACPT logs, make sure WordPress permalinks are working, and confirm that the theme can display a single template for the new post type or that you already have an output plan using a block, builder, or template.

Step 1. Create the custom post type

1. Open the custom post types panel in ACPT.
2. Click Register new Post Type.
3. In basic, set post name to specialist, singular label to "Specialist," and plural label to "Specialists."
4. Choose an icon that will make sense to the editor.
5. In supports, keep title, editor, and thumbnail if the profile page will use description and photo.
6. In the labels step, edit the labels or leave the default values for testing.
7. In settings, enable public output if profiles should have their own URLs, and enable show_in_rest if you plan to use the block editor or REST.
8. Save and confirm that the "Specialists" item appears in the admin panel.

Step 2. Create the taxonomy

In the taxonomies section, create specialty with the labels "Specialization" and "Specializations." Do not use the slug type or category, because those are too generic and may cause conflicts. After creation, associate the taxonomy with the specialist post type. Add test terms such as "Lawyer," "Marketer," and "Physician."

Step 3. Create the field group

Create a field group called "Specialist Data" and assign it to specialist. Inside it, add a meta box called "Profile." Then add these fields:

• City - text or select if the city list is fixed.
• Experience - number or text if you need phrasing like "10+ years."
• Profile Photo - image, if the featured image is not enough or you need separate logic.
• Website - URL, so you get a validated link.
• Rating - rating or number, if ratings are actually used on the site.
• Short Bio - textarea, so the editor does not paste in unnecessary markup.

The "City" field can be shown in the admin list and made filterable if a manager needs to find specialists quickly. "Website" should not be required because a specialist may not have an external site. Do not add "Rating" if the site has no actual rating policy, otherwise readers will see a number they have no reason to trust.

Step 4. Fill out a test entry

Create a test specialist, fill in title, editor, thumbnail, choose a specialization, and complete the meta fields. Save the entry. If a field does not save, check required status, validation rules, user permissions, and logs. If the change is visible in the admin panel but not on the site, the issue is almost always in the output template, cache, or field retrieval method.

Step 5. Verify the result

Open the specialist's public page. Check five things: the URL does not return a 404, the title matches, the photo loads, the meta fields appear in the right places, and the taxonomy is visible or available for filtering. Then open the post type archive if it is enabled. If you do not need the archive, do not make it public just to get a nicer-looking URL.

Forms, Dynamic Blocks, API, and Export: When to Enable Advanced Features

Once the basic model is in place, you can add ACPT's advanced capabilities. The important thing here is not to enable everything at once. Forms, dynamic blocks, custom APIs, export/import, and integrations solve different problems. If you mix them without a plan, the site becomes harder to maintain.

Form builder

Form builder in ACPT is enabled through content settings. Once enabled, a form is created in its own list and goes through the steps general settings, submission limits, CSS variables, and email settings. The documentation shows that after creation, a shortcode like [acpt_form id="..."] is generated and can be inserted into a page.

A form is useful when users need to add or update entries from the front end. For example, a specialist submits a request to add their profile, an editor reviews the entry, and then publishes it. Form builder provides groups such as standard fields, WordPress post fields, taxonomy fields, user fields, and ACPT fields. When you choose an action for post management, the available fields may change, so first decide what the form is supposed to do: create a post, update a user, collect a request, or work with a taxonomy.

For public forms, always configure submission limits, email notifications, and CAPTCHA if the form is available to outside users. For CAPTCHA, ACPT can use Google reCAPTCHA or Cloudflare Turnstile, but the keys belong in site settings, not in project documentation.

Dynamic blocks

Dynamic blocks are also enabled through content settings. The documentation describes block creation as a five-step wizard: general, supports, controls, callback, and style. In the callback step, you can use TWIG syntax and ACPT fields. This is a good option when you want to give the editor a block for displaying structured data directly in Gutenberg.

Do not use a dynamic block as a replacement for the entire site template. It works better for a repeatable component: a specialist card, a list of attributes, a gallery block, a related entity, or a compact table. For large single/archive templates, it is often easier to work at the theme, Site Editor, or builder level, especially when you need more complex SEO and responsive layouts.

Custom APIs

ACPT includes an API dashboard for operations involving custom post types, meta boxes and fields, taxonomies, WooCommerce product data, and filtering posts by query. The documentation describes both Basic authorization and API keys authentication, with API keys recommended as the preferred method. Do not enable the API just because it exists. It is meant for automation, external integrations, headless scenarios, or internal tools.

If you need the API, create separate keys, restrict access by environment, do not store the secret key in public notes, and verify that the endpoint returns only the data an external system is supposed to receive. Test important requests on staging. If the JSON payload is invalid, ACPT documentation describes an error response, so the integration should handle more than just the successful case.

Export and import settings

Export data in ACPT supports JSON compressed, JSON, XML, and YAML. The documentation emphasizes that ACPT settings data is exported, not the posts themselves. Import data also loads definitions, not entries. That means moving the "framework" and moving the content are two different tasks. Use separate migration or integration tools for content, and use ACPT export/import for structure.

How to Verify the Result After Setup

Result verification should be its own stage, not a quick "looks fine" glance. ACPT affects several layers: admin navigation, post editing, meta field saving, public URL, template output, REST API, cache, and permissions. If you test only one layer, the error may surface later, after the editor has already filled out dozens of cards.

Admin panel checks

• The new post type is visible in the left menu only to the roles that actually need it.
• Labels are clear to the editor and do not mix random languages.
• Meta fields still save after updating the entry.
• Required fields are truly required, while optional fields can be left empty.
• Fields in the admin list do not overload the table and actually help locate entries.

Front-end checks

• The single URL opens without a 404.
• The archive URL is enabled only if users actually need it.
• Taxonomies do not conflict with existing pages and categories.
• Photos, galleries, URLs, rating, and repeater fields render in the expected format.
• Empty fields do not leave awkward labels such as "City:" with no value.

REST and block editor checks

If the post type or taxonomy needs to work in Gutenberg, the REST API, or an external integration, verify show_in_rest. WordPress documentation explains that when REST is enabled for a custom post type, a route appears in the wp/v2 namespace. The logic is similar for taxonomies. If the parameter is off, the block editor and external requests may not see the entity they need.

Cache checks

Change one field in a test entry and see how quickly the update appears on the site. If the front end still shows the old value, clear ACPT cache, then the site cache, then the CDN. If flushing ACPT fixes it, the issue is in the ACPT cache layer or metadata cache. If not, look for caching at the theme, builder, hosting, or template level.

Common ACPT Problems and How to Diagnose Them

Most ACPT problems are not caused by installation itself, but by the boundary between WordPress structure and public output. Below are symptoms frequently seen with custom post type plugins and confirmed by ACPT documentation, the WordPress API, or practical reviews.

A new entry opens with a 404 error

Symptom: the post type has been created, the profile is published in the admin panel, the permalink looks correct, but the public page does not open.

Possible cause: rewrite rules have not been rebuilt yet, or the slug conflicts with an existing page, taxonomy, or reserved term. For taxonomies, WordPress explicitly warns about reserved terms that can cause 404 errors without a clear hint.

What to check: resave permalinks in WordPress without changing the structure. Then review the post type and taxonomy slugs. Do not use generic words like type, name, term, taxonomy, or post.

How to fix it: early in the project, change the slug to something more specific and resave permalinks again. If the content is already published and indexed, plan redirects and check internal links.

Meta fields save, but do not appear on the site

Symptom: the editor can see completed fields in the admin panel, but the public template shows an empty area.

Possible cause: the theme template, block, or builder is not receiving the field, is using the wrong field name, does not support the selected data type, or is serving stale cache.

What to check: make sure the field group is assigned to the correct object, the field was actually saved, its name was not changed after setup, and the output method supports the chosen field type. Clear ACPT cache and any external cache.

How to fix it: simplify the test: output one text field first, then add image, gallery, repeater, or relational fields. That makes it easier to identify which field type or template is breaking the output.

A field does not save or is cleared after update

Symptom: the value is entered, but after Update it disappears or changes.

Possible cause: validation rules reject the value, the field is configured as required, the user does not have the needed permissions, cache is serving an old value, or there is a conflict with another plugin. ACPT changelogs have included fixes related to JSON, table fields, repeater visibility, media fields, and sanitization, so updates may matter.

What to check: enable logs, run a health check, temporarily remove complex validation rules on a test copy, and try saving both as an administrator and under the actual working role.

How to fix it: update the plugin during a safe maintenance window, simplify validation rules, check permissions, and roll the questionable field back to a simpler type if the data is critical.

The taxonomy exists, but is not connected to the post type

Symptom: the taxonomy is created, but the editor does not see it in the required post type, or the filter does not work.

Possible cause: the taxonomy is not associated with the correct object, or its settings limit how it appears in the admin panel. WordPress links a taxonomy to an object type at registration, and ACPT provides a separate workflow for association.

What to check: open the association settings in ACPT, make sure the correct custom post type is selected, and review show_ui, show_admin_column, and REST settings if the taxonomy is needed in blocks.

How to fix it: connect the taxonomy to the post type, save, resave the test entry, then check the list view and public output.

The form does not show the required fields

Symptom: form builder is open, but not all fields are available in the list, or some fields are not being submitted.

Possible cause: the wrong action is selected, the form is not configured for the correct post type, ACPT fields are not mapped, or CAPTCHA or validation rules are blocking submission.

What to check: review the form's general settings, submission limits, email settings, selected WordPress post fields, and ACPT fields. If CAPTCHA is connected, verify the keys in settings.

How to fix it: create a minimal form with title and one ACPT field, test submission, then add the remaining fields and validation one by one.

Strange errors appear after an update or migration

Symptom: the interface opens, but some panels behave inconsistently, old fields display incorrectly, import fails, or cache shows outdated objects.

Possible cause: incompatible old definitions, stale cache, database schema damage, or an import file from the wrong version. The import data documentation explicitly notes that a file from v1 will not work in v2.

What to check: open health check. It reviews plugin version, DB status, and cache. If the check fails, the documentation recommends running repair through Run health check and contacting support if the issue remains.

How to fix it: clear cache, verify the backup, do not import an old-format file into a live site, and repeat the migration on staging first.

SEO, Performance, and Security Tips for Working with Structure

ACPT creates the structure, but SEO and performance depend on how you use that structure. A post type with well-designed fields does not guarantee indexing, fast output, or a strong snippet. You still need good slugs, useful archives, unique titles, schema where needed, optimized images, and no duplicate content.

SEO and URLs

Choose a slug that reflects the entity and does not conflict with existing sections. If the specialist directory needs to be public, plan the URL structure before populating it: /specialists/name/ or a localized rewrite variant via settings. Do not change the slug after publication without redirects. For taxonomies, decide whether public term archives are actually useful. Sometimes a "City" term makes sense as a landing page, and sometimes it creates dozens of thin pages with no value.

Performance and fields

Do not output every field everywhere. Gallery, relational, repeater, and table fields can be useful, but if every archive loads heavy images and complex relationships, the page will slow down. For a card list, output only the title, thumbnail, a couple of short fields, and a link. Leave detailed galleries, tables, and relationships for the single page.

Form and API security

A public form should have submission limits, CAPTCHA when needed, clear moderation, and a minimal field set. Do not allow an external user to assign themselves a role, change internal fields, or publish a post without review. Treat API keys as secrets. If an external system reads data from ACPT, expose only the entities and fields it truly needs.

A small CSS snippet for safe form styling only

If an ACPT form is inserted via shortcode and the theme does a poor job separating the fields, you can add a small CSS snippet through Appearance - Customize - Additional CSS or through a safe snippet manager. This code does not change data, does not interfere with form submission, and is easy to roll back by removing the block.

.acpt-form {
  max-width: 760px;
  margin: 0 auto;
}

.acpt-form input,
.acpt-form textarea,
.acpt-form select {
  width: 100%;
  min-height: 44px;
}

.acpt-form button[type="submit"] {
  min-height: 44px;
  padding: 0 22px;
}

Test the form on a mobile screen, submit a test request, and make sure the button, fields, and messages do not overlap. If the theme already provides clean styling or the ACPT form uses its own CSS variables system, a separate snippet is not necessary.

When ACPT Is the Right Choice

ACPT is worth using if you want to turn WordPress into a more structured CMS without writing manual code for every data type over and over again. It works well for directories, reference databases, profile cards, portfolios, content hubs, internal panels, post submission forms, and projects where it matters to build a clean admin experience for editors quickly.

Before going live, verify three things: the data structure is thought through, the front-end output method is chosen and tested, and the troubleshooting path is clear. If you can explain why each custom post type, each taxonomy, and each meta field exists, ACPT can speed up your workflow. If the structure is still unclear, sketch the model first and test it on staging.

After setup and verification, you can proceed to downloading ACPT and use the file in your own test environment. Do not move the new framework directly to a live site without a backup, a permalink check, user permission checks, cache validation, and front-end output testing.