Themify Builder Pro - WordPress Plugin

Guide to Using and Configuring Themify Builder Pro

Themify Builder Pro is not a typical single-page builder. It is a WordPress layer for creating reusable site templates: the header, footer, single post page, archive, search results, product page, cart, and other standard layouts. This guide focuses on the practical workflow rather than marketing copy: how to prepare the site, create a Pro Theme, configure display conditions, output dynamic fields, and confirm that a template is actually being applied where it should.

The main challenge with tools like this is that they operate across multiple WordPress layers at once. The user sees a visual editor, but behind it are post types, display conditions, WooCommerce, custom fields, caching, multilingual plugins, and the active theme. A useful Themify Builder Pro guide should explain not only "where to click," but also why a specific setting changes the result on the live site.

This material is intended for site owners, webmasters, small agency developers, and content teams that already understand the basics of the WordPress admin area. It will help you safely test the plugin on a live project or a staging copy, build your first template, and stay oriented when the template does not appear, a dynamic field is empty, WooCommerce modules are missing, or a condition change affects pages you did not intend to touch.

What Problem the Template Builder Solves

A standard visual editor helps you design a single page. Themify Builder Pro solves a different problem: it lets you define a rule for an entire page type and design something once that WordPress will then output repeatedly. For example, you can create a unified blog post template, a category archive template, a separate header for the store section, or a WooCommerce product card layout. After that, new posts and products inherit the design without manually copying blocks.

This approach is especially useful when a site is built around recurring content rather than a handful of static pages. A real estate catalog, movie database, multi-category blog, online store with product cards, or a site with authors and custom fields all need more than just a polished homepage. They need a predictable template system. If every new post requires manually inserting the same structure, the site quickly becomes difficult to maintain.

In Themify Builder Pro, three layers matter most. The first is the Pro Theme, a set of related templates that can be activated, deactivated, imported, and exported as a complete design system. The second is the Pro Template, an individual template for the header, footer, post, archive, page, product, or another output type. The third is the display conditions, which determine exactly where that template should run.

Compared with a classic WordPress theme, Builder Pro does not replace the entire theme outright. It takes over the areas you design through Pro Templates and uses the Themify Builder visual editor to assemble the layout. That is why it is important to understand before rollout which part of the design is already controlled by the theme, which part will be replaced by the Pro Theme, and which part will remain in standard WordPress or WooCommerce settings.

The practical value of this separation becomes obvious during site maintenance. You change the header once and it updates across every relevant page. A category archive can be redesigned without editing theme files. A post template can pull in the title, author, image, and custom fields from the post itself. If the design does not work, you can deactivate the Pro Theme or change the display conditions without manually rewriting PHP templates.

Key point: Themify Builder Pro works best when your design needs to repeat according to clear rules. If you only need to style one landing page, regular Themify Builder or the WordPress block editor is often enough.

The plugin should not be treated as a magical replacement for site architecture. It will not fix a messy category structure, invent post types, or turn poorly prepared images into a clean design. What it does provide is a clear template management layer when the content is already organized and the user understands which page types need their own layouts.

Who Themify Builder Pro Is For, and When Another Approach Makes More Sense

Themify Builder Pro is usually chosen by users who want visual control over the whole theme without constantly editing files like single.php, archive.php, header.php, and WooCommerce templates. It fits especially well on projects that already use Themify products, where the team is comfortable with the Themify visual editor and wants reusable design without building a separate custom theme from scratch.

A good fit is any site with several types of repeatable content. For example, an education project might have articles, courses, and instructor pages. A store might have a catalog page, product pages, cart, and checkout. An agency might have a portfolio, case studies, and service archives. In each case, it is more efficient to build the template once and then work with content rather than duplicate layouts.

The plugin also suits a webmaster who wants to give the client a safer editing system. Instead of granting access to theme files, you can prepare the templates in advance and explain which fields in the post control the output. The client adds the title, image, price, specs, or text, and the template places that data into the correct structure automatically.

There are also cases where Themify Builder Pro may be unnecessary. If the site is fully built on a WordPress block theme and the team already uses the Site Editor, adding a second template layer may confuse administrators. If the project requires complex logic, custom queries, integrations with external APIs, and strict code-level control, a child theme or custom plugin may be more reliable. If the team is already deeply invested in Elementor Pro, Beaver Themer, Bricks, or Divi, switching to Themify only makes sense when there is a clear reason, not just because it is "another builder."

Sites with heavy traffic and lots of dynamic blocks also need extra scrutiny. A visual builder helps you assemble layouts faster, but every added animation, map, slider, video background, expensive query, or third-party widget affects performance. If the project is sensitive to Core Web Vitals, test more than just appearance. Check page weight, request count, lazy loading, and cache behavior as well.

When Themify Builder Pro Is Usually a Good Fit

Situation	Why It Fits	What to Check in Advance
Blog, magazine, or knowledge base	You can create a unified post template, archives, and search layout.	Category structure, author output, images, and metadata.
Catalog with custom fields	Dynamic content pulls values from meta fields.	Exact field names, empty values, and fallback behavior.
WooCommerce store	It includes templates and modules for product pages, archives, cart, and checkout.	Published products, categories, and payment and shipping settings.
Multilingual site	The documentation covers WPML and Polylang support for templates.	How the selected language plugin handles the tbp_template type.

The decision to implement it should be based on the actual workflow, not a feature list. Define which templates need to exist, what data they should display, who will edit them, and how you will roll back if needed. If those answers are clear, Builder Pro can speed up the work. If they are not, start with a content map rather than the plugin installation.

What to Check Before Installing It on a WordPress Site

Before installing Themify Builder Pro, do not mix up three different questions: technical compatibility, content structure, and change safety. The plugin works as a template layer, so a mistake in display conditions can affect not one page, but an entire site section. The best way to avoid unnecessary risk is to create a short rollout plan first and test it on a site copy.

Dependency on Themify Builder or a Themify Theme

The official documentation states that Builder Pro requires either an active Themify theme or the free Themify Builder plugin. If the site uses a third-party theme, the usual approach is to install and activate the free Themify Builder first, then add Builder Pro. This matters because without the base editor, the user may not see the expected visual interface and assume the Pro plugin was installed incorrectly.

If the site is already running a Themify theme, the separate free Builder may not be necessary because the editor is already part of the theme framework. But with a third-party theme, it is better to confirm in advance that it will not conflict with the areas you want to replace: the header, footer, archive, single post, or WooCommerce pages. Not every theme hands over control of the header and footer to a third-party builder in a predictable way.

Site Copy and Rollback Checkpoint

For a production site, using a staging copy is safer. Visual templates can change the header, footer, navigation, product card, and archives. If the display conditions are too broad, visitors will see the new design in places you did not intend. So before installing anything, create a backup and define how quickly you can return to the previous theme output or disable the Pro Theme.

A minimal checkpoint includes a list of pages to verify: the homepage, a standard post, a category archive, a search page, a 404 page, a product page, the cart, and checkout if the site uses WooCommerce. For each page type, open the public version before making changes, note the key elements, and compare them again after enabling the templates.

Content and Fields That Will Be Output Dynamically

If you plan to output custom fields, prepare them before building the template. Builder Pro documentation describes working with ACF, Pods, Toolset, Meta Box, PTB, and manually created custom fields. But the builder itself will not guess which field represents the price, address, area, or product material. You need exact field names, clear test entries, and at least one example with an empty value so you can verify the fallback behavior.

For WooCommerce, you need published products and categories. The documentation specifically notes that the Product Single and Product Archive template types only appear when WooCommerce is active. That is not an interface bug. If the store plugin is disabled, Builder Pro should not show pieces that only apply to products.

User Roles and Editorial Workflow

Site templates usually should not be editable by everyone on the team. If a content manager gets access to Pro Templates without understanding display conditions, they may accidentally change the global post template instead of a single page. Before rollout, decide who creates Pro Themes, who edits content, who checks the public site, and who is responsible for rollback.

On a simple project, it may be enough to agree that only the administrator changes templates while editors work with standard posts and products. On an agency project, it is better to keep a small change log: which template was modified, which condition was added, and which pages were checked. This becomes especially useful when the site has caching, multilingual behavior, or several post types.

Practical rule of thumb: if you cannot name at least three pages where you will verify the result, postpone the installation and map out your templates first.

Installation, Pro Theme, and the First Validation Pass

Installing Themify Builder Pro has two parts: preparing the base editor and activating the Pro plugin itself. This guide does not cover purchasing, payment, or entering license details. We assume the ZIP archive has already been obtained legally and that the user's task is to connect the product to WordPress correctly and confirm that it works.

Basic Installation Order

If the site uses a Themify theme, make sure the theme is active and the visual Builder is available. If the site uses another theme, install the free Themify Builder from the WordPress repository or through the standard plugin uploader. Then install the Builder Pro ZIP archive through Plugins -> Add New -> Upload Plugin and activate it.

After activation, confirm that the admin panel now includes Themify sections related to Pro Themes and Pro Templates. Do not start by editing the site header right away. First, create a separate test Pro Theme so all future templates are tied to one set. The documentation emphasizes that you need an active Pro Theme before creating Pro Templates, otherwise the template will not be attached to the correct design system.

Creating the First Pro Theme

Go to WP Admin -> Themify -> Pro Themes and add a new theme. Name it so its purpose will still be obvious a few months later, for example Blog system redesign, Shop templates test, or Client catalog theme. Avoid generic names like New Theme if multiple people work on the site.

Next, you can choose a blank theme or import a preset. A blank theme is better for a careful rollout on an existing site because you only add the templates you actually need. A preset gets you a ready-made visual set faster, but it requires more careful review of which templates and demo data are imported along with it.

Once the Pro Theme is active, create your first low-risk template. The safest candidate is a separate static page or a test post, not the site-wide header. That lets you see how the Pro Theme -> Pro Template -> Display Conditions chain behaves without affecting the entire site.

A First Pro Template Without Risking the Whole Site

Go to WP Admin -> Themify -> Pro Templates and click Add New. Enter a clear name, keep the active Pro Theme selected in the related theme field, choose the template type, and set the display condition. For an initial test, choosing the Page type and enabling the template for one pre-created page is a practical option.

After publishing, Builder Pro will usually send you to the public side of the site for visual template editing. This uses the familiar Themify Builder. Add a simple block: a heading, text, image, or dynamic element if it is supported for the selected template type. Save it, then open the page as a guest or in another browser.

How to Tell Whether the Installation Worked Properly

• The admin panel shows the Pro Themes and Pro Templates sections.
• The created Pro Theme is active, and the template is linked to it specifically.
• The test page loads with the new template, while other pages remain unchanged.
• When you change the display condition, the result changes only for the selected page type.
• When you disable the test template, the site returns to the normal theme output.

If all of those checks pass, you can move on to more sensitive areas: the header, footer, post template, archive, or WooCommerce. If the template does not appear even in the first test, do not keep creating second and third templates in a row. First verify the active Pro Theme, the dependency on the base Builder, the selected template type, and the display condition.

Configuring Display Conditions Without Unwanted Overlap

Display conditions are one of the most important mechanisms in Themify Builder Pro. They determine where the template will be used: across the entire site, on archives, on single posts, on specific pages, on categories, on products, or on excluded sections. A mistake in conditions usually does not look like a technical failure. It looks like, "Why did the wrong page change?"

The documentation describes the logic of Include and Exclude. Include adds the area where the template applies, while Exclude removes part of that already selected area. For example, you can include a header across the whole site but exclude one landing page. Or create a separate template for all product archives but keep it from applying to one specific category. It is a powerful system, but it needs structure.

Start with a Broad Rule, Then Add Exceptions

A good practice is to define the base area first and then add exceptions only when needed. If you are creating a global header, it makes sense to start with Include -> Entire Site. If a campaign landing page needs its own header, exclude that page and create a separate template with a narrower condition.

What does not work well is starting with a dozen narrow conditions and no overall logic. A month later, it will be hard to understand why the template works on one page and not another. On larger sites, use a simple naming convention such as Header - global, Header - shop, Single - blog posts, Archive - product categories. The name should reflect the scope, not just the design.

Priority and Conflicts Between Multiple Templates

In practice, several templates may sometimes match the same page. For example, one header might be enabled for the entire site, while another is enabled for the archive of a specific category. The official product page notes that template priority can be managed when multiple conditions overlap. Use that intentionally. Priority should not be a way to hide chaotic rules. It should help in rare overlap scenarios.

If you see an unexpected template on a page, do not fix it immediately by adding yet another exclusion. First build the chain: which Pro Templates could possibly apply to this page, what conditions each one has, which template is active, and whether there is a narrower rule in place. Only then should you change the condition or the priority.

Examples of Working Conditions

For a blog, a typical setup might look like this: a global header for the whole site, a separate single post template for all posts, a separate category archive template, and an exclusion for the blog homepage if that page needs an editorial layout. For a store: a general header, a shop header for products and product archives, Product Single for the product page, Product Archive for the catalog, and separate Cart/Checkout templates only after WooCommerce has been verified.

For custom post types created through PTB, Pods, ACF, or another plugin, first make sure the post type is public and has test content. Then create a single template for that type and an archive template if the archive is actually used on the site. Not every custom post type has a public archive, so verify the real URL instead of relying only on the type appearing in the admin panel.

Quick check after saving: open the page where the template should apply, a page in a neighboring section, and the page you explicitly excluded. If all three results match expectations, the condition is configured cleanly.

Dynamic Content, ACF, Pods, and PTB in Templates

Dynamic content is the main reason to use Builder Pro on catalogs, knowledge bases, portfolios, and stores. Instead of manually entering the same blocks in every item, the template pulls data from the post: title, image, author, taxonomy, custom fields, PTB fields, ACF data, Pods data, or values from other tools. The user edits the content, while the design stays consistent.

The official documentation gives several representative examples: outputting a custom field value in a Text module, using the Featured Image as a background, displaying the author avatar through the Image module, linking FitText with Post Title and Post Permalink, embedding Image Pro into an archive layout, and using a dynamic value as a CSS class. These scenarios show that dynamic behavior applies not just to text, but also to images, links, captions, classes, and display logic.

How to Prepare Fields Before Building the Template

First, decide which data belongs to content and which belongs to design. A property's price, address, area, material, rating, course duration, author name, and event date belong to content. Button color, spacing, card grid, and image size belong to design. If you mix them together, editors will start changing the visual layer just to edit data, and the template loses its value.

Create one test entry with a complete set of fields and a second entry with some fields left blank. This matters because the Builder Pro documentation describes the ability to hide a row, module, or subrow when a custom field is empty, or to show a fallback value instead. If you only test a fully completed entry, you will not see how the template behaves when data is missing.

The Custom Field -> Dynamic Switch -> Output Chain

Inside the module, look for the Dynamic switch. If it is available for that field, enable it, choose the data source, and enter the custom field name when using the Custom Field option. If the value is a shortcode, enable Enable Shortcodes only for that specific field. The documentation explicitly warns against enabling shortcode parsing for ordinary values that do not contain shortcodes.

After saving, open one entry where the field is filled and another where it is empty. For the empty field, verify whether the module, row, or subrow disappears or whether fallback text appears. This is not a minor detail. On a real site, an empty spec should not leave behind a visual gap, double spacing, an extra divider, or a heading with no value.

Dynamic Images and Backgrounds

One useful scenario is using a post's Featured Image as the background for a row, column, or module. That approach works well for the hero section of a single post, a catalog card, or an archive item. But it requires discipline around images. If authors upload images that are too small or inconsistent in proportion, the template will look uneven.

For a template like this, define image requirements ahead of time: minimum width, a safe zone without important content near the edges, consistent orientation, and a fallback background when no image exists. After publishing, test several posts with different images. If one image crops badly, the issue may not be Builder Pro at all. It may be the source media.

Dynamic CSS Classes as a Safe Way to Add Variants

The documentation describes the ability to inject a custom field value into the CSS class field of a row or column. This is useful for small visual variants. For example, a real estate listing might have a property_status field with values like featured or sold, and the template then adds that class to the card. The appearance can then be styled with CSS.

This approach is only safe when the values are controlled. Do not allow editors to enter arbitrary class names if they do not understand CSS. It is better to use a select field in ACF, PTB, or Pods where the allowed values are predefined. That way the template does not end up with random spaces, non-Latin characters, HTML, or conflicting classes.

Below is an example of a small CSS adjustment. It can be added to a child theme, the standard Additional CSS area, or a safe code snippets plugin. The code does not depend on Builder Pro internals and does not modify plugin files. It only styles the card when the template is already outputting a controlled class.

.listing-card.featured {
  border: 2px solid #4f8cff;
  box-shadow: 0 10px 30px rgba(79, 140, 255, 0.18);
}

.listing-card.sold {
  opacity: 0.72;
}

.listing-card.sold .listing-status {
  background: #444;
  color: #fff;
}

The validation is simple: assign a test entry the value that should produce the featured class, open the public page, and confirm that the card gets the border. Then change the field to sold and verify the alternative visual state. Rollback is straightforward: remove the CSS or reset the field to an empty value.

WooCommerce Templates: Product, Archive, Cart, and Checkout

The WooCommerce scenario in Themify Builder Pro requires extra care. In a normal post, a template mistake may only affect how an article looks. In a store, a mistake affects the product page, catalog, cart, or checkout, which means it can affect sales. That is why store templates should be rolled out in stages: first visual validation, then functional validation, then a test order or at least a full cart flow without payment if payments are disabled on the staging copy.

The Builder Pro documentation describes the Product Single, Product Archive, Cart, and Checkout types. It also states that WooCommerce must be installed and active, and that published products and categories are required for product templates. If Product Single or Product Archive is missing from the template type list, the first thing to check is WooCommerce status, not Themify.

Product Pages and Product Modules

For Product Single, the important modules are the ones tied to the current product: Product Title, Product Image, Product Price, Add To Cart, Product Description, Product Rating, Product Meta, Related Products, Upsell Products, and the other elements listed in the documentation. These modules should output data from the current product rather than static text. If a user accidentally replaces the price with a regular text block, the template loses its dynamic behavior.

Start with a minimal product page: image, title, price, short description, add-to-cart button, and description and review tabs if they are used. First confirm the core purchase flow, then add decorative elements, sliders, animations, and extra sections. In a store, a beautiful layout is worse than useless if the add-to-cart button is hidden, inaccessible on mobile, or broken by product variations.

Product Archives and the Catalog

Product Archive applies to the shop page, product categories, and tags. A common question here is whether to use one template for all archives or several different ones. The documentation suggests a two-template approach if you want to style the shop page separately from category or tag archives. That makes sense when the main catalog page includes a marketing block, while categories should stay more compact.

In the archive, do not check only the first few products. Open the second page of pagination, an empty category, a category with long names, and products without images. If you use Advanced Products or a similar module, test sorting, filters, AJAX behavior, and the "no results" state. Any catalog module should behave predictably with different product counts.

Cart and Checkout

Cart and Checkout templates are best handled only after the product page and archive are already working. These pages include important WooCommerce logic: coupons, totals, shipping methods, payment blocks, notices, validation errors, and customer fields. Builder Pro provides modules for these areas, but visual customization must not break the form structure.

Validation after setup should include adding a product, changing quantity in the cart, removing a product, applying a coupon, checking notices, moving to checkout, and navigating back. If safe test payment methods are available on the staging copy, place a full test order. If not, at least confirm that checkout fields are visible, the submit button is available, errors are displayed clearly, and the cache is not serving an outdated cart.

Important for stores: do not cache the cart and checkout pages as if they were ordinary static pages. If the site uses a separate cache plugin or server-side cache, verify its WooCommerce exclusions.

Practical Example: A Catalog Template with Dynamic Fields

To keep the guide from staying too abstract, let's walk through a concrete scenario. The goal is to build a template for a catalog of items such as properties, studios, courses, or services. Each item has a title, image, price or range, short description, several attributes, and a status. The template should pull that data automatically and present all entries of the selected type in a consistent layout.

Target Outcome

After setup, the user should have a single item page with a large image, title, a set of attributes, description, contact block, and related items. When a new item is created, the editor fills in the fields in the admin panel, and the public page inherits the same design without manual layout assembly.

Preparing the Data

First create a custom post type through PTB, Pods, ACF paired with another solution, or custom development. The important part is that the type is public and has test entries. Add fields such as price, location, area, status, contact_note. These names are just examples. On a real site, use your own names, but document them clearly inside the project.

Create three test items. Fill the first one completely. In the second, leave one secondary field empty, such as contact_note. In the third, test a long title and an unusual image. That set will immediately show how the template behaves in a normal case, an incomplete-data case, and a problematic case.

Creating the Single Template

1. Open Themify -> Pro Templates and add a new template.
2. Select the single template type for the required post type, if it is available in the list.
3. In display conditions, apply it only to the selected post type or to one test entry if you want to start with the narrowest possible scope.
4. Publish the template and switch to visual editing.
5. Add a hero block with the Featured Image as the background, plus Post Title and a short text block.
6. Add a specs block where Text modules or appropriate elements pull values from custom fields through Dynamic.
7. For empty values, configure module hiding or fallback text if that option is available for your field.
8. Save the template and open all three test entries.

Validating the Result

Your validation should be specific. On the first entry, all fields should appear in the correct places. On the second, there should be no empty row or label without a value. On the third, the long title should not break the layout, and the image should still look acceptable. If the hero background crops out an important part of the image, that is a signal to adjust proportions or media requirements.

Then validate the archive scenario. Create an archive template, use Advanced Posts or another appropriate module, enable cards with dynamic fields, and open the archive page. The goal here is not just to see one attractive card, but a grid of several items with different data. If the cards have different heights, decide whether that is acceptable in the design or whether you need to limit text length.

A Common Detail That Causes Problems

The most common issue in this scenario is a field name mismatch. In the admin panel, the person sees a friendly label such as "Price," but in the template you need the technical custom field name, such as price or property_price. If you enter the visible label instead of the field name, the field may not display at all. That is why it is worth keeping a field list next to the task and checking it before setting up the dynamic module.

After working through an example like this, you gain more than just a first template. You gain a method. For any new content type, repeat the same chain: define the fields, create test entries, use a narrow condition, connect modules to dynamic data, validate complete and incomplete content, and only then expand the scope.

Import, Export, and Moving Templates Between Sites

Builder Pro lets you move not only individual templates, but entire Pro Themes. That is useful for agencies that build the design on a staging domain and then move it to the client site. But importing and exporting templates is not a substitute for full content migration. If the template expects custom fields, products, categories, images, or custom post types, those must exist on the destination site.

The official documentation explains that exporting a Pro Theme includes its related templates. That is convenient when you need to move a unified design system. Exporting a single Pro Template makes more sense if you only want one template, such as a new header or archive. In both cases, it is important to understand dependencies: a module may reference a menu, field, image, category, or plugin that does not exist on the second site.

When to Move an Entire Pro Theme

Moving a full Pro Theme is a sensible choice when you are changing several site areas at once: header, footer, single, archive, and WooCommerce. That set is better kept together so you do not end up with a fragmented design. Before exporting, check that the Pro Theme does not contain outdated test templates, drafts, or temporary conditions that should never reach the client site.

After importing it onto the new site, do not activate everything immediately. First confirm that the required plugins are installed: Themify Builder, Builder Pro, WooCommerce for store templates, PTB, ACF, Pods, or other data sources. Then verify menus, widgets, images, custom fields, and post types. Only after that should you activate the Pro Theme or the individual templates.

When to Move a Single Template

An individual template is more convenient when you are updating one site area. For example, the live site may already have a stable header and footer, and you only want to replace the blog post template. In that case, exporting a single Pro Template reduces the risk of accidentally bringing over extra templates.

But an individual template is not self-contained if it depends on dynamic fields. Before importing it, verify the technical field names and the presence of test entries. If the template uses property_price but the destination site uses price_value, the layout may load correctly while the data stays empty.

Post-Migration Validation

• Open the Pro Templates list and verify the related Pro Theme and template types.
• Check the display conditions to make sure the template is not applying more broadly than expected.
• Open a public page for every template type.
• Validate dynamic fields on both a complete and an incomplete entry.
• Clear the cache if the site uses plugin-level, theme-level, or server-level caching.
• Compare the mobile layout and the main interactive elements.

Template migration works especially well when the team follows an internal standard: consistent field names, the same menu structure, the same post types, and clear Pro Theme names. If every project is built differently, importing is still useful, but it requires more manual verification.

Multilingual Templates, Translations, and Different Header Versions

Multilingual support in Builder Pro matters on sites where one design needs to work across several languages, but text, menus, conditions, and even individual templates may differ. Themify documentation separately covers WPML and Polylang scenarios. The general idea is that one template can be assigned across translations, while separate language-specific template versions can be created when needed.

For WPML, the documentation describes the ability to create templates in any language and assign them to the necessary pages or archives. If a template is assigned, translated versions of those assignments can also use that template. At the same time, you can create different templates for different languages when the structure or design needs to vary.

For Polylang, the documentation states that Builder Pro can automatically apply a template assignment to translated versions of pages, but if you want a different appearance in another language, the template itself needs to be translated. It also notes that in Polylang settings for custom post types and taxonomies, Templates tbp_template must be enabled so templates become translatable. This is a critical step, because without it, users may look for the translation option in the wrong place.

One Template for All Languages

One template works well when the structure is identical and the content comes from translated posts. For example, a single blog post may always include the same blocks: title, image, author, content, and related materials. In that scenario, the posts themselves are translated while the template remains shared. That is easier to maintain and reduces the risk of the design drifting between languages.

But you should still verify menus, buttons, static labels, and fallback text. If the template contains a manually entered phrase, it will not always become translated automatically. It is better to use dynamic data, translatable strings, or separate language templates in places where text is embedded directly into the design.

A Separate Template for a Specific Language

A separate template is needed when a language has a different header, menu, block order, legal notice, or CTA logic. For example, the French version of a site may need its own header for a local archive, while the English version uses a global one. In that case, create the translated template and validate its assignment on the relevant pages.

For Polylang, keep one limitation from the documentation in mind: the Themify Templates page in the admin panel may show templates in the default language, and changing the language from the top admin bar does not always switch that list. So when diagnosing an issue, do not rely on that one screen alone. Open the actual translated page and verify the public result.

What to Check After Translation

• The header menu matches the page language.
• Static labels in the template are translated or moved into a translatable layer.
• Display conditions do not assign the template to the wrong language.
• Dynamic fields pull values from the translated entry rather than the original one.
• Fallback text does not remain in the wrong language.
• The cache has been cleared after changing language conditions.

Multilingual behavior is best implemented only after the base single-language template already works. If you try to configure display conditions, dynamic fields, and language versions all at once, troubleshooting becomes much harder. First get a stable result in the default language, then add translations.

Performance, SEO, and Safe Cache Handling

Builder Pro does not automatically guarantee a fast site, and it does not automatically make a site slower either. The outcome depends on the theme, number of modules, images, animations, external scripts, WooCommerce, caching, and hosting. In its own materials, Themify describes performance techniques such as lazy loading, modular scripts, caching, minified and gzip-compressed scripts, WebP, and WooCommerce optimization. But those features still need to be tested in your specific project.

For SEO, what matters is not that the page was assembled with a visual builder, but that it outputs a clear structure, correct headings, accessible text, fast-loading images, and a stable layout. A post template should output the real post title, main content, metadata, image, and internal links in a way that gives search engines a meaningful page rather than a set of decorative blocks.

Images and Dynamic Backgrounds

If the template uses the Featured Image as a background, verify the size of the source images. Themify recommends uploading images in reasonable dimensions and setting dimensions where the module allows it. A hero background does not need a multi-megabyte camera original. An oversized background will slow down every item that uses the template.

In archive cards, do not output full-size images where a small card image is all you need. If the module lets you define width and height, use the actual render size. Then inspect the page in developer tools: the rendered size and intrinsic size should be close. If a thumbnail is loading a source image far larger than necessary, that is a problem with image preparation or module settings.

Cache and Dynamic Pages

Cache is useful for static pages and archives, but it requires caution on pages where data changes for the user: cart, checkout, account pages, forms, favorites, or dynamic notices. If the site uses Themify Cache, a third-party cache plugin, or server-side cache, do not enable multiple layers without understanding how they interact. Themify recommends avoiding double caching to reduce conflicts.

After changing a template, clear the cache and check the page as a guest. If the administrator sees the new design but a visitor sees the old one, the issue is most likely the cache, not Builder Pro conditions. For WooCommerce, specifically verify cart and checkout exclusions. For multilingual sites, confirm that the cache distinguishes between language URLs.

SEO Structure in Templates

Do not output multiple visual headings as h1 if the main theme or the post already outputs an H1. In a post template, you usually want one main post title and then a normal H2/H3 hierarchy inside the content. If Builder Pro outputs Post Title, check which HTML tag it uses. If two H1 tags appear on the page, adjust the module or the theme structure.

For archives, Archive Title and Archive Description are useful when they are actually populated. That helps categories, product categories, and taxonomies feel like real landing pages rather than endless card grids. But do not duplicate the same SEO text across every archive. Let the description come from the current category or taxonomy when that fits the content model.

Validation After Optimization

• Open the public page as a guest after clearing the cache.
• Check whether dynamic fields disappeared because of aggressive script optimization.
• Make sure images are not loading at obviously excessive sizes.
• Test the mobile layout, especially the sticky header, menu, product page, and buttons.
• Compare the page before and after enabling heavy modules such as sliders, video, maps, and animations.

If a specific module stops working after optimization, roll back the last questionable setting rather than the entire template. For example, temporarily disable defer jQuery, minification, a third-party cache layer, or one specific module. That sequence will reveal the cause much faster than disabling every plugin at once.

Header, Footer, and Navigation as a Separate System

The header and footer are the most visible areas that users usually want to move into Builder Pro. But they also create the most confusion because the site may already have a header from the active theme, WordPress menus, mobile navigation, a Customizer logo, widgets, a WooCommerce cart icon, a search form, and separate sticky settings. Before replacing the header, you need to understand which elements should remain dynamic and which can be treated as static design.

The Builder Pro documentation lists Site modules that are especially important for headers and footers: Menu, Search Form, Site Logo, Site Tagline, Cart Icon, and others. These are not just decorative blocks. Menu should pull the real WordPress menu, Site Logo should display the site logo, Site Tagline should use the global settings, and Cart Icon should reflect the WooCommerce cart state when the store plugin is active. If you replace those elements with plain text or an image, the template may look polished but stop being manageable.

Where to Start with the Header

Start by mirroring the current structure: logo, primary menu, search, or a call-to-action button if one is genuinely needed. Do not immediately add a mega menu, transparent background, multiple rows, a complex sticky effect, and a separate mobile version. First build a simple header, apply it only to a test page or limited section, and confirm that the menu opens correctly, links go where they should, the logo is clickable, and the header height does not cover the content.

On a WooCommerce site, do not add the cart icon as a decorative icon only. Use the appropriate Site module if it is available in your template and WooCommerce is active. Then add a product to the cart and verify that the state changes. If the icon still looks empty, check whether the header is being cached too aggressively or whether the necessary WooCommerce script has been disabled.

Transparent and Sticky Headers

A transparent or sticky header needs separate validation because it depends not only on Builder Pro, but also on the first-screen background, spacing, the mobile menu, and browser behavior. If the header should be transparent on the homepage but standard on internal pages, do not try to solve that with one universal template and a pile of conditional CSS exclusions. Create a separate header template for the required section and assign a precise display condition.

Test that kind of header on a page with a large hero image, a standard post, an archive, a product page, and at a mobile width. Typical signs of misconfiguration include a white logo on a white background, a menu covering the heading, sticky mode activating immediately on load, a mobile button that does not open the menu, or a dropdown running off the edge of the screen. For each symptom, check the display condition and header settings first, then move on to CSS.

The Footer as a Navigation and Utility Zone

The footer is changed less often, but it can also be dynamic. It often needs menus, contact details, social links, a subscription form, widgets, copyright text, a language switcher, and links to utility pages. If all of that is entered as static text inside Builder, the administrator loses the familiar places where those items are managed. It is better to keep menus as WordPress menus, the form as the form provided by its plugin, and utility links as a dedicated navigation block.

If the footer contains the year, you do not necessarily need code to update it automatically. For most sites, that is a minor detail that is easy to check during routine maintenance. If automation is still required, use a documented mechanism from your theme, a shortcode, a block, or a safe snippet only when the source is confirmed. In this guide, we are not adding PHP for copyright output because there is no recently confirmed Builder Pro hook scenario that most users would actually need.

Header/footer check: open a page with long content, a store page, a search page, a 404 page, and the mobile menu. The header and footer should not just look good. They need to work: links, cart, search, language switching, and responsiveness all need separate validation.

How to Validate the Result After Every Template

Builder Pro can change large areas of a site, so a basic check like "the page opens" is not enough. You need a small validation protocol: what changed, where it should be visible, where it should not be visible, which data is pulled dynamically, how the mobile version looks, and how to roll back the change. This kind of protocol is especially useful when multiple people work on the site.

It helps to split validation into four levels. The first is administrative: the template is published, linked to the right Pro Theme, and the display conditions make sense. The second is visual: the public page looks the way it was intended to. The third is dynamic: data is coming from the current post, product, archive, or custom fields. The fourth is technical: cache, mobile layout, forms, buttons, WooCommerce, and language versions are all still working.

A Validation Table for a Single Post Template

For a single post, do not verify only one polished publication. Open a post with a short title, a long title, no image, a different author, multiple categories, and an empty extra field. If the template only works on the perfect post, it is not ready for a real site.

Minimum Validation for a Single Template

What to Check	Required Result	What to Fix if It Fails
Post Title and Featured Image	The title and image are pulled from the current post.	Check the module, the dynamic source, and whether the image exists.
Metadata and author	Author, categories, and date look clean and are not duplicated by the theme.	Remove the extra module or adjust the metadata output.
Empty custom fields	An empty field does not leave a label with no value.	Enable block hiding or add a fallback.
Mobile layout	The hero, menu, cards, and buttons do not overlap.	Adjust responsive spacing, column order, and image sizes.

Validating Archives and Search

Archives are more complex than single pages because they output a list of items. Here you need to validate card count, pagination, empty results, long titles, missing images, and filters if they exist. If Advanced Posts or Advanced Products is being used, do not focus only on how the first row looks. Check how it behaves when the item count changes.

A Search template needs separate attention. A user may search for a term that returns many results, one result, or no results at all. A zero-results page should be clear and useful, not an empty grid. If the search form is located in the header, make sure the query goes to the search page rather than the homepage. Themify forum discussions include topics about live search and redirects, so that scenario should be part of manual validation.

Validating the WooCommerce Flow

For a store, validation should follow the customer journey: product category, product page, add to cart, cart, quantity change, coupon, checkout, required field errors. It is not enough to look at Product Single as a design layout. You need to make sure the real WooCommerce modules still work functionally.

If shipping fields, the payment block, or notices disappear after checkout customization, immediately return to the latest template version and check which modules were removed. Do not try to hide the problem with CSS. Checkout is a functional form, not a standard content section.

How to Record Results Without Unnecessary Bureaucracy

For a small site, a short task note is enough: which template was changed, which display conditions were used, which URLs were checked, and which issues remain. For an agency, it is better to build a repeatable checklist. That is not just process overhead. After several WordPress, WooCommerce, and Themify updates, those notes are often what tells you where to look when a template starts behaving differently.

Rollback rule: every template change should have a clear reverse step: deactivate the Pro Template, narrow the display condition, restore the previous Pro Theme, disable the questionable module, or remove the CSS adjustment.

Editorial Workflow for the Team and the Client

Builder Pro changes how responsibility is distributed across the site. The designer or webmaster builds the template system, the developer verifies dependencies and performance, the editor fills in posts and fields, and the client evaluates the public result. If those roles get blurred, the team will start editing the template for every new post, and the product will lose its main advantage: repeatability.

A good process starts with an agreement on which parts of the site are edited through templates and which are edited through content. For example, a listing page may have fixed zones: hero, specifications, description, gallery, and contact block. The editor should not move those zones around in every individual post. They fill in the fields, and the template decides where those values appear. If one specific post needs a unique layout, that is a reason to create a separate condition or another template, not to break the shared one.

Documenting Fields and Templates

Create a short internal table: the post type, its fields, where those fields are used, which template is responsible for the output, and what should happen if a field is empty. This matters especially for ACF, PTB, and Pods, where the visible field label and the technical field name may differ. The editor sees "Area," while the template expects property_area. Without documentation, small mismatches like that turn into long troubleshooting sessions.

Use clear names for Pro Templates. A bad name is Template 1. A good one is Single - Properties, Archive - Blog Category, Header - Shop, or Checkout - Clean Layout. The name should show the purpose, not just the visual style.

Permissions and Ownership

Not every editor needs access to Pro Templates. If someone is only responsible for articles, standard post fields and regular WordPress tools are enough. Access to templates should stay with the administrator, designer, or technical specialist. That is not about distrust. It protects the site, because one accidental include across the entire site can change far more than one mistake inside a single post.

If the client still needs to edit templates, give them a short training session on a staging copy. Show the difference between editing a page, editing a Pro Template, and editing a Pro Theme. Explain that saving inside a template affects every page that matches the condition. Then give the client a short result-validation checklist.

Working with Updates

Reviews and forum threads about visual builders often point to the same issue: updates can expose hidden conflicts, especially on sites with many modules, shortcodes, HTML inserts, cache layers, and third-party plugins. That is not a reason to avoid updates forever. It is a reason to update in a controlled way.

Update the staging copy first. Check the header, footer, single post, archive, WooCommerce flow, and pages with dynamic fields. If everything is stable, repeat the update on the live site during a maintenance window. After the update, clear the cache and run through the same short validation list again. If a problem appears, the rollback plan should already be technically prepared, not improvised after the failure.

This process turns Builder Pro from just a visual tool into part of a controlled site system. The more repeatable content and templates you have, the more discipline matters: naming, permissions, test entries, empty-field validation, cache handling, and a change log.

Why the Template Is Not Working and How to Find the Cause

Troubleshooting in Themify Builder Pro should start with one question: is the problem in the installation, the Pro Theme, display conditions, dynamic data, cache, or a conflict with another plugin? If you start changing the design immediately, you may make the situation worse. It is better to move from the simplest checks to the more complex ones and record exactly what has already been tested.

The Template Does Not Appear on the Intended Page

Symptom: the template was created and published, but the public page still looks the same as before. Possible causes include no active Pro Theme, the template being linked to a different Pro Theme, the wrong template type being selected, the display condition not including the current page, or the result being served from cache.

Check the active Pro Theme in Themify -> Pro Themes, then open the Pro Template settings and review the template type and display conditions. For the first test, use the narrowest possible condition for a single page. After saving, clear the cache and open the page as a guest. If the template appears, expand the condition gradually.

Extra Pages Changed Unexpectedly

Symptom: the new header, archive, or single template applies more broadly than planned. This is usually caused by an overly broad Include, a missing Exclude, or a conflict between multiple templates. Sometimes the user creates a template for Entire Site when they only meant to change one section.

First determine which template actually fired. Check its name, conditions, and priority. Then narrow the include rule or add an exclusion. Do not create a second template on top of the first until you understand the original rule. After fixing it, open three pages: the target page, a nearby page, and the excluded page.

The Dynamic Field Is Empty

Symptom: the template has space for the value, but nothing appears on the site. Common causes include an incorrect technical field name, the field being filled in on the wrong entry, the dynamic switch being off, the field not belonging to the current post type, the value actually being empty, or shortcode parsing being enabled where it is not needed.

Check the field name in ACF, PTB, Pods, or the other source. Open the specific entry where the template is being displayed and confirm that the field is filled in. Then inspect Dynamic, the source, and fallback behavior inside the module. If the field is empty only on some entries, configure module hiding or a fallback value.

WooCommerce Modules or Template Types Are Missing

Symptom: when creating a template, Product Single, Product Archive, Cart, or Checkout is missing, or the expected product modules are not available in the editor. The first check is whether WooCommerce is active and whether published products and categories exist. Builder Pro documentation directly ties store-related types and modules to an active WooCommerce installation.

Activate WooCommerce, create a test product and category, then return to template creation. If the type appears, the issue was not Builder Pro. If the module exists but does not work on the public page, check whether you replaced the dynamic WooCommerce module with a normal text block or button block.

The Editor Freezes or the Public Site Shows an Old Version

Symptom: changes are saved, but the old version is still visible, the editor loads slowly, or some modules do not respond. The causes may include cache, script optimization, third-party plugin conflicts, oversized images, or server limits. Themify forum discussions include LiteSpeed, Advanced Post Module behavior, Firefox, mobile menu issues, update errors, and front-end editor freezes, so it is best to troubleshoot one layer at a time.

Clear the site, browser, and server cache if applicable. Temporarily disable aggressive minification, script combining, or defer jQuery if the issue appeared after optimization. Check the browser console for JavaScript errors. If the problem disappears when a third-party plugin is disabled, re-enable plugins one by one and document the conflict.

The Site Shows a Critical Error After an Update

Symptom: after installing or updating a theme or plugin, the admin panel becomes unavailable or the site shows a critical error. Themify recovery documentation recommends first checking whether wp-admin is accessible. If it is, the conflicting product can usually be reinstalled through the standard uploader. If it is not, recovery through file access should be handled by the site administrator or hosting specialist.

In normal Builder Pro work, it is better not to end up in emergency recovery at all. Before a major update, create a site copy, update in staging, validate key templates, and only then move the changes to production. If the error has already happened, do not blindly delete folders or edit WordPress core. Use a documented recovery process or involve a technical specialist.

The Multilingual Template Does Not Apply as Expected

Symptom: a translated page shows the shared template, the wrong header, or an outdated version. Check how your language plugin handles templates. For Polylang, Themify documentation points to the Templates tbp_template setting under custom post types and taxonomies. For WPML, verify that the template is assigned to the correct language and page.

Do not troubleshoot multilingual behavior only from the admin template list. Open the public URLs for all languages, clear the cache, and verify menus, static labels, and dynamic fields. If a language needs its own design, create a translated template instead of trying to hide half the blocks with conditions.

Questions About Builder Pro Setup and Limitations

Can You Use Themify Builder Pro with a Third-Party Theme?

Yes. The official documentation states that Builder Pro can be used with a third-party theme if the free Themify Builder plugin is installed. If a Themify theme is active, the separate base plugin may not be necessary because the editor is already built into the framework. In practice, you should still verify the header, footer, and archives because different themes hand off control of those areas differently.

Why Do You Need a Pro Theme Before a Pro Template?

A Pro Theme ties a group of templates into one system. Themify documentation emphasizes that you should create and activate a Pro Theme before creating Pro Templates so the templates are attached to a specific set. That makes design rollout, transfer, and deactivation more predictable.

How Do You Use Themify Builder Pro with Custom Fields?

First create the fields and test entries, then enable Dynamic in the module, choose the data source, and enter the technical field name if you are using Custom Field. After saving, validate one entry with the field filled in and another with an empty value. For empty values, configure block hiding or a fallback if that option is available.

Can You Build WooCommerce Templates Without WooCommerce?

No. It does not make practical sense. The documentation states that Product Single and Product Archive depend on active WooCommerce. If WooCommerce is not installed or is disabled, the related template types and modules may not appear. For testing, you also need at least one published product and one category.

What If the Administrator Sees the Template but Visitors Do Not?

First clear the cache and open the page in a private window. Check server-side cache, the cache plugin, Themify Cache, the CDN, and script optimization. If the administrator sees the new version while a guest sees the old one, the cause is often caching rather than the display condition itself.

Is Builder Pro Suitable for a Multilingual Site?

Themify documentation describes WPML and Polylang scenarios. You can use one shared template across translations or create separate templates for each language. For Polylang, it is important to enable Templates tbp_template in custom post types and taxonomies settings if templates need to be translatable.

Do You Need to Add CSS or PHP to Work with Builder Pro?

For basic use, no. The main scenarios are built visually. A small CSS adjustment can be useful for styling controlled classes or refining a card layout, but there is no need to edit WordPress core, modify plugin files, or invent internal hooks. If the exact extension point is not documented, stick with settings, CSS, or the official product documentation.

When Themify Builder Pro Is the Right Choice

Themify Builder Pro is worth using when you need a manageable WordPress template layer rather than just a page editor. It is especially useful for sites with repeatable content: blogs, catalogs, stores, knowledge bases, portfolios, custom post types, and multilingual projects. The main advantage appears when one template needs to serve dozens or hundreds of items automatically.

Before rollout, confirm the basics: an active Themify Builder or Themify theme, a staging copy of the site, a clear template map, prepared dynamic fields, a page list for validation, and a rollback path. After installation, do not try to replace the whole site at once. Start with one page, then configure the conditions, then move on to single templates, archives, WooCommerce, and multilingual behavior.

If you want the first practical step, create a Pro Theme, add one Pro Template for a test page, assign a narrow display condition, and validate the result as a guest. After that, move on to a more useful scenario: a post template, an archive, a product page, or a catalog with custom fields. When you are ready to repeat this workflow on your own site, you can download Themify Builder Pro and test it on a prepared project copy.

The product's strongest point is the combination of visual editing, display conditions, dynamic data, and Pro Themes. Its weak point is the need for discipline: without a template map, careful conditions, cache control, and empty-field validation, the site can become confusing instead of systematic. That is why Builder Pro works best as a template design system, not as a quick way to hide an unprepared content structure.