Themify Post Type Builder - WordPress Plugin

Guide to Setting Up Themify Post Type Builder for Structured WordPress Content

Themify Post Type Builder is not for yet another decorative page. It is for cases where standard WordPress posts and pages are no longer enough: a property catalog, movie database, restaurant directory, expert listing, portfolio with custom fields, real estate listings, or an extended product profile all need their own structure. In this guide, we will walk through how to plan that structure, create a post type, fields, taxonomies, output templates, and result checks without editing the WordPress core.

This guide is written for a site owner, webmaster, or content manager who already has the plugin ZIP archive and wants to understand what to do after installation. It does not cover purchasing, licensing, or activation workarounds. The focus is on a working data model, safe configuration, a practical example, troubleshooting, and choosing comparable solutions.

A key PTB advantage is that it combines several jobs in one workflow: it registers custom post types, adds custom fields, connects them to taxonomies, helps build archive and single post templates, and then outputs finished entries through a template or shortcode. That is why setup works best when you think in a sequence rather than clicking through screens: data structure - content entry - template - output - verification.

When the plugin actually solves the problem, and when it is better not to overcomplicate the site

Custom post types are useful when content repeats in the same pattern and needs to be sorted, filtered, or displayed in dedicated blocks. If a site has ten similar pages such as "Property," "Movie," "Expert," "Service," or "Project," and each one manually repeats fields like "Address," "Price," "Rating," "Date," "Gallery," or "Link," a regular page turns into a poorly managed copy of a spreadsheet. PTB lets you move that repeated data into fields and give the editor a clear form to fill out.

A strong use case for Themify Post Type Builder is a directory where every card should have the same fields but different values. A real estate listing stores an address, price, area, property type, number of rooms, map, and gallery. A movie stores genre, director, rating, release date, and trailer. A restaurant stores cuisine, neighborhood, average check, map, and business hours. In every case, the goal is not just to make it look good, but to preserve the data structure.

The plugin may be excessive if you only need one landing page, one icon block, or a one-time list that will never grow. In those cases, regular editor blocks, a page template, or a builder are simpler. PTB starts to shine when content will keep expanding: the editor adds new entries, the administrator updates the template once, and the entire archive automatically gets the new structure.

Who this approach works well for

PTB is especially convenient for small teams that do not have a full-time developer but do have a clear directory structure in mind. A webmaster can configure the fields and templates, while a content manager fills in entries through the WordPress admin panel. For an agency, it is a fast way to build a repeatable content model on client sites without creating a separate plugin for every directory.

PTB can also help developers, but more as a prototyping and handoff tool for the content model. The documentation includes PHP export for those who understand code and want to move post type or field registration into a child theme or standalone plugin. For a typical site owner, it is safer to use PTB's built-in import and export tools, because inserting generated PHP requires understanding the consequences.

Where you should think twice

If the project requires complex data relationships, bulk migration, custom SQL queries, external service integration, or strict role-based permissions, a visual builder alone may not be enough. In those cases, PTB can still be useful for the basic model, but the architecture should be planned with a developer. Be especially careful with directories that contain thousands of entries and many filters based on meta fields: WordPress can store that data, but performance depends on the theme, queries, cache, hosting, and filter structure.

Practical rule: if the data will be updated often and needs to appear in multiple parts of the site, build the structure with a post type and fields. If the block is a one-off and will not scale, do not turn it into a separate content model.

How the "post type - fields - template - output" chain works

In WordPress, a post type defines what is being stored: blog posts, pages, WooCommerce products, or custom items. Taxonomies group entries: categories, tags, genres, neighborhoods, property types. Meta fields add individual values inside an entry: price, address, rating, file, link, phone number, date, gallery. Themify Post Type Builder brings these parts together inside the Post Type Builder interface so the user can assemble the structure without manually calling WordPress functions.

Most errors happen not because custom post types are a bad idea, but because the structure was not planned well. If you create a post type first, then casually change its label, then rename the slug, add a taxonomy after the content is already filled in, and only then start building the template, you can end up with confusing links, empty archives, and mismatched fields. That is why it helps to sketch a simple map before the first click.

Three levels of setup

The first level is content registration. This is where you define names, the slug, supported WordPress features, and taxonomy relationships. The second level is input fields. These define what the editor fills in on each entry: text, number, date, image, map, rating, file, phone number, gallery, link, and other field types. The third level is output. Here, the archive template controls the list of entries, while the single template controls the page for an individual entry.

PTB creates archive and single templates for the selected post type. The template loads standard post elements and connected fields. The user drags modules into place, sets text before and after the value, chooses the grid, and controls the order of elements. As a result, one template change can update the output of every entry of that type.

Why the template matters more than a pretty card

In PTB, a template is not just presentation. It determines which data the visitor actually sees. If the "Price" field exists in the admin panel but its module is not added to the template, it will never appear on the site. If the "Neighborhood" taxonomy exists but is not used in the archive or filter, the visitor will not be able to narrow the list quickly. After adding each field, mentally walk through the full path: where the editor enters the value, where the template outputs it, and how the visitor checks the result.

What to check before installation and first activation

Before installation, do not start by uploading the ZIP archive. First, make sure the site has a backup, that you still have admin access, and that you have a staging environment if the site already gets traffic. PTB changes the content structure, not just a widget, so it is safer to test a new model on a copy of the site or at least during a low-traffic period.

Check the theme and builder that will be used to display the content. Official Themify materials show PTB closely tied to Builder Pro and dynamic content, but PTB itself can still work with a standard WordPress theme for basic templates. If you plan to design dynamic templates visually through Builder Pro, you need a compatible Themify theme or Themify Builder, because Builder Pro has its own requirements.

Quick checklist before installation

• Create a backup of files and the database, or work on a staging copy.
• Write down the future slugs for post types and taxonomies in Latin characters, with no spaces and no conflicts with existing URLs.
• Decide which fields are required, which can remain optional, and which are better handled as taxonomies.
• Check whether you need a Google Maps API key if the structure will include a map field or Map View.
• Confirm whether you need Classic Editor only for the shortcode generator. In the block editor, the shortcode can be typed manually.
• If you expect many filters, decide in advance which parameters should become taxonomies and which should remain meta fields.

How to avoid slug mistakes

The post type slug becomes part of the permalink structure. WordPress recommends avoiding overly generic identifiers because they can conflict with other plugins or the theme. PTB documentation specifically warns that the slug must be unique, lowercase, contain no spaces, and use English characters. Do not use reserved names such as post, page, menu, author, order, and similar values.

If the site is already indexed, do not change the slug after publishing dozens of entries unless you have a redirect plan. In multilingual setups with WPML, the developer warns that renaming the slug after multilingual entries have been added can cause unpleasant issues with translation relationships. It is much safer to approve the slug before large-scale content entry begins.

Installation and initial checks in the admin panel

Installing Themify Post Type Builder works like installing a standard WordPress plugin from a ZIP archive: Plugins, Add New, Upload Plugin, upload the file, Install Now, and Activate Plugin. If the browser automatically extracted the archive, download the ZIP again or save the file as an archive. That is a common detail that official Themify documentation specifically mentions for some browsers.

After activation, a Post Type Builder item appears in the admin panel. Do not start creating fields right away. First open the plugin settings and review the language, Google Maps, and custom CSS sections. If you are not using a map, you do not need an API key. If the site is multilingual, check the site language and future translation model before you create required labels.

Initial check after activation

1. Open Post Type Builder and confirm that the post types, taxonomies, templates, and import sections are available.
2. Go to Post Type Builder - Settings and review which options are actually needed for your use case.
3. If a map is planned, prepare the Google Maps key first and create the map field only after that.
4. If you use the block editor, save an example of a manual shortcode in advance, because the documentation ties the shortcode generator to Classic Editor.
5. If the site is already live, create one test post type and one test entry first instead of moving the whole catalog at once.

Result check: after activating the plugin, there should be no blank screen, no PHP errors in the admin panel, and no missing WordPress menu items. If an error appears immediately, deactivate the plugin normally and check the error log or a conflict with the current theme.

Setting up the structure: post type, fields, and taxonomies without chaos

The setup process should start with the model itself. In PTB, you can add a post type quickly, but the right outcome depends on what data you store as a field and what you store as a taxonomy. A field is suitable for a unique value inside an entry: price, area, phone number, date, address, link, file, image. A taxonomy is suitable for repeatable classification: genre, neighborhood, property type, cuisine, expert category, difficulty level. A taxonomy can then be used in archives, links, filters, and grouping.

Creating a post type

Open WP-admin - Post Type Builder - Post Types - Add New. Fill in the singular and plural names. For a property directory, you might use "Property" and "Properties"; for movies, "Movie" and "Movies." It is best to make the slug short and clear from the beginning: property, movie, restaurant, expert. Even if the site uses another language on the front end, readable localized titles are fine, but the system slug should remain stable and safe.

In the support block, enable only what the editor will actually need. A title and featured image are usually necessary in most cases. Main content is needed if the entry will contain a full description. An excerpt is useful for archive cards. Comments, author, and other features should be enabled only when there is a clear reason, otherwise the editing form becomes noisy.

What to do with advanced settings

Official Themify documentation says advanced settings can usually be left at their defaults. That is a reasonable starting position. Change them only when you understand the impact: archive behavior, public visibility, menu visibility, URL behavior, and REST support can affect output, the editor, integrations, and search. After changing these settings, save WordPress permalinks via Settings - Permalinks if the site starts showing URL errors.

Adding meta fields

Custom fields are added in Meta Box Builder. PTB supports many types: text, multiline text, radio, checkbox, select, image, link button, video, rating, map, date, slider, gallery, progress bar, icon, audio, file, email, telephone, number, accordion. Choose the field type based not on how it looks, but on how the editor will enter the data and how the visitor will read it.

If a field may have many possible values, do not use a long set of radio buttons. For a large list of options, Select is better because it keeps the editing form more compact. Checkbox works better for several independent options. For values you plan to sort by, use a numeric field or date field rather than plain text. For an address with a map, use a map field only if you truly plan to show a map or Map View.

Taxonomies and their connection to the post type

Taxonomies are created separately: Post Type Builder - Taxonomies - Add New. After creating them, you need to attach them to the correct post type. If you forgot to do that at first, you can go back and edit the post type. It is best to create taxonomies before large-scale content entry so editors do not start typing repeatable values into plain text fields.

For a real estate directory, taxonomies may include property type, city, neighborhood, room count, or status. For movies, genre, director, actor, or audience rating. For a restaurant, cuisine, neighborhood, or venue format. Do not turn every attribute into a taxonomy. If the value is unique to each entry or rarely repeated, it should be a field. If the value creates a grouping and makes filtering easier, it should be a taxonomy.

PTB templates: how to output fields so visitors can actually see them

After creating the post type and fields, PTB prompts you to move on to templates. The archive template controls the entry list: card grid, number of posts, sort order, pagination, masonry, and other archive options. The single template controls the page for one entry. Themify documentation notes that one template is assigned to one post type, and once a template is created, you cannot simply reassign it to another type. If you assigned it incorrectly, it is safer to create a new template than to try repairing the old one.

Archive template

The archive template is used in post type archives, taxonomy pages, and when outputting entries through the [ptb] shortcode. This is where you define the overall look of the cards. For a property directory, it usually makes sense to show the featured image, title, neighborhood, price, short specs, and a link to the detail page. For movies, poster, title, genre, rating, date, and a short description. For a restaurant, photo, cuisine, neighborhood, average check, and a button to continue.

Do not overload the card. If you output every field in the archive, the card becomes heavy and hard to scan. Leave 4-6 key attributes that help the visitor choose an entry. The remaining details are better shown in the single template.

Single template

The single template is for the full detail page. Here you can show a gallery, map, video, specs block, related entries, text description, and extra fields. In Template Builder, modules are dragged into a grid, and common settings let you add text before and after the value, choose an HTML tag, and enable inline output if elements should appear on one line.

Start by building a logical order: title, main image, short specs, main text, additional media, map, related items, or a call-to-action button. Only then move on to styling. If you start with appearance, it is easy to forget to output an important field.

Multiple archive templates

PTB allows you to create additional archive templates for the same post type and select them through the template attribute in the [ptb] shortcode. This is useful when the same directory is needed in several formats: a full grid on the archive page, a compact block on the homepage, a "new listings" selection in a sidebar, or a text-only list for a reference section.

Do not create a new post type just because you want a different list layout. If the data is the same, use an additional archive template. A new post type is needed only when the data model itself changes.

Shortcodes, archives, and checking the output on a page

PTB can output entries through the [ptb] shortcode. The shortcode generator is available in Classic Editor, and in the block editor the shortcode can be entered manually through a shortcode block or a plain text block if your theme processes it correctly. Themify documentation lists the main attributes: type, orderby, order, pagination, style, masonry, offset, posts_per_page, logic, template, and taxonomy parameters.

A minimal working example for a property list might look like this:

[ptb type="property" orderby="date" order="desc" pagination="1" posts_per_page="9" style="grid3" logic="or"]

If you need to output a single entry, the documentation shows a version with post_id and type:

[ptb post_id="820" type="movie" template="New Movie Template"]

Do not copy these examples without replacing the slug. The type value must match the slug of your post type. If the template attribute is used, the template name must match an additional archive template that actually exists in PTB.

Why the shortcode may show nothing

The most common causes usually have nothing to do with the plugin being broken. Instead, the conditions for output are missing. Themify documentation says that if the generator button does not show the expected post type, you should check whether archive support is enabled for that post type and whether a PTB Template has been created. In a manual shortcode, also verify the slug, the presence of published entries, the selected taxonomies, and the AND or OR logic.

With AND logic, an entry must match all selected taxonomy conditions at the same time. That is useful for a precise filter, but it can also unexpectedly narrow the result set to zero. With OR, matching one condition is enough. If the output is empty, temporarily remove the extra taxonomy attributes and test a basic shortcode with only type.

Quick check after publishing

• Open the page in incognito mode to see the result as a regular visitor.
• Make sure the entries are published and not left in draft status.
• Confirm that the cards are using the intended archive template.
• Check pagination if there are more entries than the value set in posts_per_page.
• Open one card and make sure the single template outputs all important fields.

Practical example: a real estate property directory

Let us walk through a concrete scenario, because it clearly shows how Themify Post Type Builder works. The goal is to build a real estate directory with archive cards, a detailed property page, taxonomies for filtering, and fields the editor can fill in without manual layout work.

Goal and preparation

You need a separate "Properties" section where each entry stores the price, address, area, number of rooms, gallery, map, and property type. On the archive page, the visitor sees a grid of cards with the photo, price, neighborhood, and short specs. On the single page, they see the full description, gallery, and map. For testing, creating 3-5 entries is enough to verify the grid, sorting, and empty fields.

Setup steps

1. Create a post type with the singular name "Property," the plural name "Properties," and the slug property.
2. Enable support for title, main content, excerpt, and featured image if those are needed on the card and detail page.
3. Create the taxonomies "Property Type," "Neighborhood," and "Rooms" and attach them to the property post type.
4. Add fields in Meta Box Builder: price as a number or formatted text, address as text, area as a number, gallery as a gallery, and map as a map.
5. Build the archive template: photo, title, neighborhood, price, area, room count, and a link to the single page.
6. Build the single template: photo or gallery, title, specs, description, map, and a related properties block if your structure includes one.
7. Create several test entries and fill the fields with different values.
8. Output the list on a page with the shortcode [ptb type="property" posts_per_page="9" style="grid3" pagination="1"].

Expected result

The archive page should display property cards in the selected grid. If an entry opens separately, the single page should use the PTB template rather than the theme's default post template. If the map is not displaying, first check the map field, the address in the entry, and the API key instead of rebuilding the entire template.

A detail people often miss

If you created a field but did not add it to the template, the visitor will not see it. If you created a taxonomy but did not attach it to the post type, the editor will not see it in the entry form. If you changed the slug after creating entries, check permalinks and old URLs. With a structure like this, discipline matters: one structural change should be followed by one result check.

Search, maps, relations, and front-end submissions as extensions of the core model

The work does not end with the basic "post type - fields - template" setup. PTB includes additional capabilities and add-ons for more advanced scenarios: property maps, advanced search, relationships between post types, and front-end submission forms. Do not enable them just in case. Add each mode only when it solves a specific problem for the visitor or editor.

PTB Search for filtering by fields and taxonomies

PTB Search creates a search template for a specific post type and can search across meta fields, taxonomies, and standard post fields. This is useful for a property directory where the visitor needs to choose a neighborhood, price, type, and extra attributes. According to the documentation, the search template is inserted through a shortcode, and [ptb-search-results] can be used to control where the results appear.

If the search form is not updating anything, first check whether the correct post type is selected in the search template, whether the results block is placed nearby, and whether you forgot to output the entries themselves through [ptb] inside [ptb-search-results]. After major PTB Search changes, the developer explicitly noted that the results need either the placeholder shortcode or standard PTB output, so this check matters more than randomly switching themes.

Map View for entries with an address

Map View makes sense when each entry has a map field and a filled address. The documentation states that Map View requires PTB, the corresponding map field in the post type, and entries with addresses entered. After that, the map is configured through the editor button: choose the post type, map field, order, taxonomy logic, map type, dimensions, marker icon, scrollwheel, draggable behavior, and categories.

If the map does not appear, do not start with CSS. Check whether the map field exists in Meta Box Builder, whether the entry contains a valid address, whether the Google Maps API key is set in PTB settings, whether the map dimensions are correct, and whether the browser is blocking it. In some cases the map is present, but its container has zero height because of theme or tab settings.

Relation for connected post types

The Relation add-on lets you connect two post types. For example, a property can be connected to a neighborhood, or a movie can be connected to actors or directors as separate entities. One important detail from the documentation: after choosing the related post type in a Relation module, you cannot simply switch it to another one. You need to create a new Relation module to avoid conflicts. That is why it is better to think through the relationship before creating the field.

The Relation template controls the appearance of related entries. It is not just a list of links: it can be built through a template similar to a PTB Template. Use this mode when the relationships actually matter to the visitor. If you only need to separate entries by genre or neighborhood, a regular taxonomy is simpler.

Submissions for entry forms on the site

PTB Submissions allows users to submit entries from the public side of the site without admin access. The form is tied to the fields and taxonomies of the selected post type, and the administrator can manage submitted content in the admin panel. Form settings include a notification, success message, redirect, captcha, auto publish, and a one-time payment option. In a standard directory, it is better to start with manual moderation rather than turning on auto-publish immediately.

If you accept user-generated content, plan for spam, permissions, moderation, legal text, and attachment quality in advance. A submission form is not just a convenience feature, it is an inbound data channel. For testing, create a separate page, submit one entry as a regular visitor, and check the notification, status, fields, and how the entry looks after publication.

Builder Pro, WooCommerce, and dynamic field output

Official Themify materials also highlight the PTB and Builder Pro workflow. The idea is simple: PTB creates the fields and post types, while Builder Pro helps you visually assemble a dynamic template that pulls those field values in. This is especially useful when PTB's built-in Template Builder covers the structure, but you want more flexible visual control in a live editing workflow.

The WooCommerce scenario is also confirmed by official guidance: PTB can add extra fields to the product post type, and Builder Pro can then output them in product templates through dynamic content. The example with dimensions and materials shows a typical case: CSS is not the right tool for values that differ from one product to another, because those values should be stored as fields rather than drawn as static text.

When to bring in Builder Pro

Builder Pro makes sense when you need to design templates with dynamic values, live preview, display conditions, and more complex layouts. If you only need a simple list and a single page, start with PTB Template Builder. If you later need separate templates for categories, dynamic fields inside modules, WooCommerce pages, or visual editing with preview, then move to Builder Pro.

WooCommerce: where PTB helps and where it does not

PTB can add fields to products, such as dimensions, materials, documents, extra images, links, or technical specs. But it does not replace product logic: pricing, stock, variations, shipping, taxes, and checkout still belong to WooCommerce. Do not use PTB fields for anything that should affect price calculations or inventory management. Use them for extra information that needs to be shown in the product template.

Store check: if the value should affect purchasing, shipping, or stock availability, look for a native WooCommerce feature or a specialized extension. If the value only explains the product to the visitor, a PTB field is usually appropriate.

Import, export, Generate PHP, and safe enhancements

PTB includes import and export tools for moving post types, taxonomies, and templates between sites. This is useful for backing up the structure or reusing the model in another project. Official documentation says that during export you can save related taxonomies and templates together with the post type or separately. During import, PTB loads a JSON file created by the plugin.

There are also preset examples: Properties, Movies, and Restaurants. These are useful to import on a test site so you can understand how the fields and templates work. On a live site with real content, import the examples carefully so you do not clutter the admin panel or create unnecessary entries.

Generate PHP is only for people who understand code

The Generate PHP feature exports code that registers post types, taxonomies, and fields. Themify documentation explicitly notes that this feature is intended for developers. If you are not sure where to place the code or how it will affect the site, use PTB's regular import and export tools instead. Dropping PHP into functions.php without understanding it can break the site or duplicate registration.

Careful CSS through PTB settings

PTB settings include a Custom CSS tab. This is a safe place for small visual adjustments to the output if you already know your theme classes or have added your own container class through the template or builder. Do not use CSS to store data, and do not try to fake field values with CSS. CSS is for presentation only.

For example, if your theme wraps a directory card in the class ptb-directory-card, you can add a light spacing and emphasis adjustment. The class here is only an example: use only a selector that actually exists in your markup.

.ptb-directory-card {
  border: 1px solid #e5e7eb;
  border-radius: 8px;
  padding: 18px;
  background: #ffffff;
}

.ptb-directory-card .price {
  font-weight: 700;
  color: #1f7a4d;
}

After saving, open the directory page, clear the cache, and check the card on desktop and mobile. Rolling back is simple: remove this CSS from the Custom CSS tab. If the selector does not work, do not keep increasing specificity with random !important rules. First inspect the actual HTML in the browser inspector.

Multilingual setup, SEO, performance, and maintaining the structure

PTB supports multilingual labels for post types and taxonomies, and for multilingual content Themify documentation points to third-party plugins such as WPML or Polylang. With WPML, required labels and fields need to be filled in manually for each enabled language. If you enable languages after building the structure, the admin panel may show empty labels that you will then have to complete by hand.

From an SEO perspective, custom post types help only when they create clear pages with unique content, proper URLs, and solid internal navigation. Installing PTB alone will not improve site visibility. On the contrary, empty archives, duplicated templates, thin cards with no meaningful text, and sloppy filters can weaken the quality of the section. That is why, after setup, you should review not only the design but also the crawlable structure.

What to check for SEO

• The post type has a clear slug that does not conflict with existing pages.
• Archive pages are not empty and do not consist only of identical cards with no useful data.
• Single pages have a unique title, description, and filled key fields.
• Taxonomies are used intentionally and do not create dozens of thin pages with no content.
• The map, gallery, and slider do not block the main text or slow down the first screen unnecessarily.
• If an SEO plugin is used, check the title, description, schema, and sitemap settings for the new post type.

Performance and filters

A large directory with filters based on meta fields can put more load on the database than a standard blog. That is a general WordPress characteristic, not a PTB-specific flaw. If you have only a small number of entries, the difference may be negligible. If you have a large catalog, limit the number of filters, use taxonomies for repeatable categories, do not show too many cards on one page, and test cache behavior.

Do not enable maps, sliders, galleries, and video in the archive unless there is a real need. These elements are better left for the single page. In the archive, the visitor is choosing, not studying every detail at once.

How to validate the finished section before publishing

Validation should move from the admin panel to the public-facing site. Do not stop at "the page loads." With structured content, you need to check the input form, data saving, template, archive, single page, shortcode, filtering, empty values, and the mobile view.

Validation path

1. Create one entry with every field filled in and one entry with some optional fields left blank.
2. Open the entry list in the admin panel and make sure the editor understands which fields need to be filled.
3. Check the archive template: cards should be aligned cleanly, with no empty labels or awkward line breaks.
4. Open the single template: all required data should be visible, and blank optional fields should not leave behind junk text.
5. Test the shortcode on a separate page and compare its output to the archive.
6. If the Search add-on is installed, run a search using one field and one taxonomy separately, then together.
7. If a map is used, check the address, marker, container size, and mobile behavior.
8. If front-end submissions are enabled, submit a test entry as a guest or regular user if that matches your scenario.

After validation, save an export of the PTB structure. It is not a replacement for a full backup, but it is a useful safety layer for reusing or restoring the content model.

Editor workflow after launching a PTB directory

After the initial Themify Post Type Builder setup, do not let the directory slip into a mode where everyone fills things out however they want. A custom post type is valuable precisely because repeated data becomes predictable. If one editor enters the price in the price field, another adds it to the main text, and a third leaves the field blank and manually inserts the price into the title, the directory turns back into a pile of disconnected pages within weeks. That is why PTB setup should end with a short editorial workflow.

The workflow does not need to be a large instruction manual. It is enough to explain which fields are required, which are filled only when data exists, which values must be selected from taxonomies, and which should never be invented manually. For example, in a real estate directory, "Neighborhood" and "Property Type" should be taxonomies so the filter works consistently. "Area" and "Price" should be fields so they can be displayed on the card and sorted or compared. "Short highlight" can be an excerpt because it is editorial text rather than a strict data point.

Quality checklist before publishing an entry

For each new listing, it helps if the editor runs through the same check every time. This saves admin time and reduces the risk of empty cards on the site. The most practical model is to check the entry in two places: the editing form and the public page. In the form, you verify the data. On the public page, you verify the output.

• The title is clear without extra context and does not include utility words like "test" or "new listing."
• All required fields are filled in using the proper format: a number in a numeric field, an address in the address field, a date in the date field.
• Repeatable categories are selected from taxonomies rather than typed manually into the description.
• A featured image is added if the archive template uses an image on the card.
• Fields shown in the archive do not contain text so long that it breaks the card grid.
• The single page opens correctly, the template does not show empty labels, and it does not leave technical placeholder values behind.
• If the entry is supposed to appear in search or on the map, it is tested through that specific search form or map view.

How to handle empty and questionable values

It is better to plan for empty fields in advance. In a real directory, not every entry will be filled perfectly: a property may not have a video, a restaurant may not have a map, a movie may not have a trailer, and an expert may not have a portfolio. If the template simply outputs the label "Video:" with no value, the visitor sees a technical flaw. That is why, while building the template, you should test both an entry with full data and an entry with optional fields left blank.

For required data, do not rely on the template. Make it clear to the editor that the entry should not be published until the field is filled in. For optional data, use more flexible output logic: do not show the label when the value is missing, or move rare media into a lower section of the page. If that kind of conditional logic is not available in your current PTB template, keep optional elements away from the first screen so empty gaps do not hurt the card.

How to maintain the structure as the directory grows

As the number of entries increases, the biggest risk is not design drift but uncontrolled growth of taxonomies and fields. If editors keep creating new terms like "downtown," "Downtown," "city center," and "Central District" for the same idea, the filter loses its meaning. Review the term list periodically and merge duplicates before they spread across hundreds of entries. For fields, check that you have not created two fields with the same meaning, such as area and square, or phone and contact_phone.

If the structure changes, do not delete the old field immediately. First determine where it is used: in entries, templates, shortcodes, search, Builder Pro modules, imports, or front-end submissions. Then create the new field, move test data into it, update the template, and only after verification decide what to do with the old field. This order is slower, but it is much safer for a live directory.

When to export the structure

PTB export is useful not only when moving a site. Export after every major structural change: adding a new post type, a new taxonomy, a new template, a search form, or Relation links. This makes it much easier to restore a working model if a template experiment goes wrong. A full backup still matters more, because a structure export does not replace files, media, or entries, but for a PTB administrator it is a convenient restore point.

Short takeaway: PTB helps you build the structure, but the quality of the directory is maintained by process. Assign an owner for the structure, document the data entry rules, and test new fields on sample entries before publishing.

Troubleshooting common Themify Post Type Builder issues

PTB problems usually show up as an empty archive, a shortcode that does not work, a missing field, a map with no markers, a broken template, or a conflict after an update. Below is a practical symptom-based troubleshooting path with no risky actions and no plugin file edits.

The shortcode outputs an empty list

Symptom: the page with the shortcode loads, but no entries appear. Possible causes include an incorrect type, no published entries, archive support turned off, no PTB Template, taxonomy conditions that are too restrictive, or an error in the name of the additional template.

Start by leaving only the basic shortcode [ptb type="your_slug"]. If the entries appear, the problem is in the extra attributes. Then add posts_per_page, style, template, and taxonomies one at a time. If nothing appears, check the post type slug and confirm that published entries actually exist.

The field is filled in in the admin panel, but it is not visible on the site

Symptom: the editor sees the field in the entry, the value is saved, but the visitor cannot see it. Usually the field was not added to the archive or single template. Open the required PTB template, add the field module, set the label through Text Before or Text After, and save.

If the field should be output through Builder Pro, check that the module has the dynamic switch enabled and that the correct PTB custom field is selected. For empty values, use a fallback or hide the block if that option is available in your template.

The map does not display or shows no markers

Symptom: the map container exists, but the map is blank, the markers are missing, or an error is visible. Check that the post type has a map field, that entries contain addresses, that the PTB settings include a Google Maps API key, and that Map View is configured to use the correct field. If the map is inside a tab or hidden block, verify the container height after that section is opened.

Rollback step: temporarily remove the map from the template and test regular fields only. If the cards still display, the issue is isolated to the map or API rather than the entire post type.

Search does not update the results

Symptom: the PTB Search form is visible, but the list does not change. Check whether the search template is attached to the correct post type, whether the form shortcode is inserted on the page, and whether a results block exists. For Builder-based pages, the documentation points to [ptb-search-results] as the place where results should appear.

Do not start by blaming cache. First confirm that the basic [ptb] shortcode outputs entries without search. Then test one filter. Only after that should you clear the cache and check for theme JavaScript conflicts.

Taxonomies do not appear in the entry or archive

Symptom: the taxonomy has been created, but it does not appear in the entry editing form or does not affect output. Check the Attach to setting in the taxonomy and the connection to the correct post type. If the taxonomy was created after the post type, go back to the post type settings and make sure the relationship was added.

If the taxonomy appears in the entry but is not visible on the site, add the corresponding module to the template. If it is used in a shortcode, verify the exact taxonomy parameter name and the term slug.

The template output changed after an update

Symptom: after updating the plugin or related Themify components, the cards look different, some elements disappeared, or an error appeared. Start by checking the changelog, and do not update a live directory without a copy. For major updates, the developer specifically recommends testing on a staging site.

If the issue has already occurred, do not edit plugin files. Export the current structure, disable cache, test with the default theme or a staging copy, compare the templates, and only then contact support with the exact symptom, the list of active extensions, and clear reproduction steps.

Themify video on PTB logic

The official Themify documentation includes a step-by-step video tutorial broken into planning, creation, templating, and adding a new entry. This format is especially useful for the intent behind "how to use Themify Post Type Builder" because it shows not only the final result but also the order of thinking: first the model, then the fields, then the template, and finally a test entry.

If you are reading this guide before your first setup, watch the video after the section on data structure. It will make it easier to connect terms such as Post Type, Meta Box, Taxonomy, Template, and Shortcode to the actual admin screens.

When Themify Post Type Builder is the right choice

Themify Post Type Builder is worth using when you want to turn WordPress from a collection of pages into a managed directory or reference section: post types define the entities, fields store the data, taxonomies handle grouping, templates control output, and shortcodes and add-ons help place the result where visitors need it. The plugin is especially logical for sites that already use Themify Builder or Builder Pro, because dynamic field output can be tied directly to visual templating.

Before you publish, do not rush to move the entire directory. Create a test structure, fill in several entries, and check the archive, single page, shortcode, filter, map, and mobile view. If the data model holds up in testing, you can move on to full content entry. If you are ready to try the plugin on your own site, you can download Themify Post Type Builder near the download block and begin with a safe test installation.

The main decision rule is simple: if you need a manageable content structure with fields and templates, PTB handles that without manual code registration. If the project requires complex development, custom queries, large volumes of data, or specialized access-control logic, use PTB as a fast prototype or one part of the solution, but do not treat it as a substitute for real architectural planning.