Toolset Module Manager - WordPress Plugin

Toolset Module Manager Guide: moving modules, importing them, and verifying the result

Toolset Module Manager is useful not as a typical "install it and forget it" plugin, but as a working tool for reusing solutions you build with Toolset. In this guide, we'll walk through how to prepare a site, create a module from Toolset elements, import that package into another WordPress site, verify the result, and avoid confusing a structure transfer with an actual content migration.

This guide is intended for webmasters, developers, and site owners who already work with Toolset Types, Views, Blocks, Forms, or the older Views/CRED stack and want to move repeatable solutions between projects. For example, a directory of specialists, testimonials, a portfolio, a filtered listing, a card template, or a ready-made WooCommerce block.

One important detail: Module Manager belongs to Toolset's legacy feature set. That means it should be used carefully, on a test copy, with a backup in place, and with a clear understanding of its limits. What follows is not a promotional rewrite of the product page, but a practical guide: what gets transferred, what does not, where to find the relevant menu, which checks to run after import, and when a different migration method is the better choice.

What problem module-based transfer solves in Toolset

A standard WordPress migration moves the entire site: files, database, uploads, settings, users, and posts. Toolset Module Manager solves a different problem. It helps you take the structure of a feature built in Toolset and move it to another site without manually recreating every setting.

By structure, we mean the elements that define how the feature works: a post type, custom field groups, taxonomies, views, output templates, forms, and related Toolset settings. If you have already built something like a "Client Testimonials" block or a "Portfolio with filters," Module Manager lets you package the necessary parts into a module, export a ZIP file, and reuse that package in another project.

This is especially useful in agency work. Different clients may have different copy, images, and posts, but the underlying logic repeats: a portfolio post type, fields like "Client," "Year," and "Link," a card template, an archive with a category filter, and a form for submitting a request. Instead of rebuilding post types, fields, and views from scratch each time, you can prepare a base module and import it as a starting configuration.

But this is also where the biggest trap appears. Module Manager is not a full site cloning tool. It transfers Toolset elements, but it should not be treated as a replacement for Duplicator, WP Migrate, the built-in WordPress export, or a manual database migration. The official documentation clearly separates transferring structures from transferring posts and their values. So when planning a move, decide in advance what exactly you are transferring: a feature framework, content, the full site, or just one specific configuration.

Practical rule: if you need to move "how a section is built," look at Module Manager. If you need to move "all actual posts, files, and URLs," use content migration tools or a full-site migration tool.

What usually makes sense to package into a module

The best candidates for Toolset Module Manager are repeatable features that can be separated from the specific content. This is more than just a group of fields. It is a complete workflow where the elements depend on each other and need to be moved together.

• Portfolio cards with a post type, fields, archive, filter, and output template.
• Testimonials with custom fields, a list view, and a single-item template.
• A property directory with taxonomies, search filters, and a results page.
• A simple messaging or inquiry system built with Toolset, as long as it does not depend on nonstandard custom code.
• Ready-made Toolset library modules that you can import, review with demo data, and then adapt to your own site.

If a feature depends on third-party theme code, a complex external service integration, or custom database tables, Module Manager may transfer only part of the picture. In that case, document the dependencies separately and verify that the imported module actually works without missing components.

What is included in a module, and what needs to be transferred separately

This is the most important section for understanding the plugin: the boundary between settings and data. In Toolset Module Manager, a module is a portable package of Toolset settings and elements. It can create the required post types, fields, views, and templates on another site, but it does not replace the transfer of the actual posts themselves.

The official documentation gives a simple example: if you transfer a "Consultants" post type, the module transfers the definition of that post type. The actual consultant entries, their field values, and taxonomy terms are not included in that transfer. For posts and related values, you need a separate method: the built-in WordPress export/import tool, a migration plugin, a database transfer, or another reliable tool.

The logic of "framework first, content second"

A safe order usually looks like this: transfer the structure first, then import or create the content, and only after that verify the output. This order reduces the risk of having posts appear on the site before the required post types, fields, and templates exist. If you import posts before the structure is ready, WordPress may store some of the data, but editors will have a harder time working with it, and the output templates will not magically appear on their own.

Here is a simple example: the source site has a "Testimonials" post type, a "Client Details" field group, a "Testimonials List" view, and a card template. Module Manager transfers the framework. Then you import the real testimonials through WordPress or another tool. After that, you open the page where the view is inserted and verify that the cards are visible, the fields render correctly, the filters work, and no empty gaps appear.

What to check in the module package

Before exporting, it helps to create a short dependency checklist. That protects you from the situation where the module imports successfully, but part of the result is missing because a related template or field was not included in the package.

The short takeaway from this section is simple: Module Manager transfers a working framework, but it does not remove the need to verify data. The better you define the contents of the module before export, the fewer surprises you will face after import.

Who Toolset Module Manager is a good fit for, and who should choose another route

This plugin is especially useful where Toolset-based solutions repeat across projects. If you run a single site and do not plan to move elements between projects, Module Manager may be unnecessary. But if you manage multiple client sites, a test environment, a library of ready-made solutions, or standard repeatable sections, the time savings become noticeable.

Good use cases

Toolset Module Manager is worth considering if you build feature sets that can be adapted without rewriting the logic. For example, an agency might maintain a library of standard blocks: team members, testimonials, property listings, a document base, or a portfolio. Each block can be configured on a test site, verified, exported, and then imported into a new project as a starting point.

A second strong use case is learning and prototyping. Ready-made Toolset modules can be imported so you can inspect the structure and see which post types, fields, and views make up the solution, then break it down as a learning example. That is more useful than reading an abstract description because the user can see a live chain of "post type - fields - view - result."

A third scenario is carefully moving individual elements between staging and production. If you do not want to migrate the whole site but you do want to bring over a specific set of Toolset settings, a module export can be faster and cleaner than a full migration.

When the tool may not be the right fit

There are cases where Module Manager should not be your starting point. If you need to move all posts, media files, users, URLs, and site settings, choose a full-site migration tool. If the project is built not on Toolset but on ACF, Pods, CPT UI, or custom code, Module Manager will not serve as a universal packaging tool for every WordPress structure.

You should also take the plugin's legacy status into account. Toolset support has explicitly noted that Module Manager is not an actively developed component and is not guaranteed to work with every newer Types and Blocks combination. That does not mean you cannot use it, but it does mean the workflow should be cautious: a test copy, a backup, compatibility checks, and a rollback plan.

What to check before installing it on a WordPress site

Preparation matters more than the installation itself. Module Manager works inside the Toolset ecosystem, so the result depends not only on the plugin alone, but also on the Toolset component versions, server settings, enabled modules, and the overall state of the site.

Source site and target site

You need the plugin on both sites if you are creating your own module on one site and importing it into another. On the source site, you build the module and export the ZIP file. On the target site, you import that ZIP file and verify the elements it creates.

Before you begin, compare the environments of the two sites. Ideally, they should use the same core Toolset plugins, or at least a compatible set. If the module contains Views, Forms, or elements that depend on a specific Toolset component, that component must also be installed and activated on the target site. Otherwise, the import may complete only partially, or the result may be incomplete.

Server requirements and library access

For the Toolset ecosystem itself, the usual WordPress requirements matter: PHP, MySQL, available memory, and enabled PHP features. For the Toolset module library, there is also a specific requirement for allow_url_fopen. If the library does not load from the admin panel, that is one of the first settings worth discussing with your hosting provider.

You should also check file upload limits. Module import uses a ZIP file, so very small values for upload_max_filesize, post_max_size, or max_execution_time can interfere with the upload. There is no need to change server settings blindly right away. First, check the size of the ZIP, try the import on a test copy, and see whether you get an upload error or a timeout.

Backup and test copy

Before importing a module, create a backup of the database and files. This is especially important if the site already contains similar post types, fields, or views. Importing creates Toolset elements, and if names, slugs, or assignments overlap, the admin panel can quickly become confusing.

Best order for a production project: first import the module into a staging site, review the list of created elements, insert the view into a test page, verify that the output is correct, and only then repeat the process on the live site.

Installation and an initial menu check

Module Manager is installed like a standard WordPress plugin from a ZIP archive. Toolset's official support materials mention that it should be found in the legacy or utility plugin section of your Toolset account. This guide does not cover purchasing it, registering a license, or getting paid access. What matters here is that you already have the archive and can install it safely on the site.

Basic installation flow

1. Open the WordPress admin panel on a test copy of the site.
2. Go to Plugins > Add New and choose the ZIP upload option.
3. Install the Toolset Module Manager archive and click Activate.
4. Verify that the main Toolset components your module depends on are also active.
5. Open the Toolset menu and look for the Modules item or the Modules tab in the import/export area.

If the menu item does not appear, do not rush to reinstall all of Toolset. According to support discussions, the cause is often simple: the core Toolset plugin is installed, but the separate Toolset Module Manager plugin is not activated. Check the list of active plugins, refresh the admin page, and open the Toolset menu again.

Initial verification after activation

After installation, do not immediately import a large module. First, make sure the admin area is not showing critical errors, the Toolset menu opens properly, the Toolset > Modules page is available, and the Toolset > Import/Export section includes a modules tab. That is the basic check that confirms the plugin has actually connected to the interface.

At this stage, it is also useful to open the WordPress error log or the server log if the site is already showing warnings. Toolset documentation suggests using PHP and JavaScript diagnostics for more complex cases. In a normal scenario, it is enough to confirm that opening the modules page does not produce a white screen, a 500 error, an empty page, or a frozen interface.

Creating your own module on the source site

Exporting your own module starts with understanding which feature you want to reuse. Do not package everything indiscriminately. A module should be complete enough to create a working structure on another site, but narrow enough that it does not drag along unnecessary elements.

How to define the module boundaries

Think of a module as a folder for one feature. If it is a testimonials feature, it should include the post type, testimonial fields, the list view, and the card template. If it is a portfolio feature, you may need the post type, categories, project fields, archive, filter, single-post template, and the view inserted into a page.

A bad module is a random mix of three different features: a piece of a portfolio, half of an inquiry form, and an old template that is no longer used. That kind of ZIP is hard to maintain, and after import you will have to sort out which elements you actually need. A good module has a clear name, one purpose, and a defined list of dependencies.

Example of a name and description

The name should help you understand what is inside even months later. Instead of "New module," use something like "Portfolio cards with filters" or "Client testimonials list." In the description, note which elements are included and what result should appear after import. This is especially helpful if the module will be used by a team rather than one person.

Export sequence

In the standard workflow, export happens from Toolset > Modules. The documentation describes the process like this: add a new module, select the Toolset elements, drag them into the module area, and click Export. The result is a ZIP file that you should save locally or in your internal library.

1. Open the source site where the feature has already been built and verified.
2. Go to Toolset > Modules.
3. Click Add new and give the module a clear name.
4. Add only the related Toolset elements required for the chosen feature.
5. Click Export and save the resulting ZIP file.
6. Store a short note next to the archive: source, purpose, dependencies, and what is not included in the ZIP.

Adding elements to a module should not change the elements on the source site. You are simply defining what will be included in the export. That is part of what makes this approach convenient: you can assemble a package from working parts without disrupting the source site.

A quick ZIP check

After export, do not consider the module ready until it has been imported into a clean test copy. The minimum check is to create a separate test site, install the required Toolset components, import the ZIP, and confirm that the list of elements matches your expectations. If an extra template slipped into the module, or an important view was left out, it is better to catch that before sending the archive to a client or teammate.

Importing a ready-made module and configuring it afterward

Import is not the endpoint. It is the middle of the process. After uploading the ZIP to the target site, you need to see exactly what will be created, choose the elements to import, and then verify the relationships and the result on the public-facing side of the site.

Importing your own ZIP module

For import, the documentation points to Toolset > Import/Export and the Modules tab. There you select the ZIP file, start the import, and on the next screen you get a list of elements. Do not skip that list. It is there so you can understand which post types, fields, views, and templates will be added to the site.

1. Open the target site and confirm that the required Toolset components are active.
2. Go to Toolset > Import/Export.
3. Open the Modules tab.
4. Select the module ZIP file and click Import.
5. On the preview screen, review the elements and click Import selected items.
6. After the import finishes, open the created post types, fields, views, and templates to verify their assignments.

If you are importing a module into a site that already contains similar elements, watch the names carefully. In some cases, it is smarter to rename old test elements or remove unneeded duplicates on the staging copy first than to later guess which of two similar views was inserted into the page.

Importing from the Toolset module library

The Toolset Modules Library page provides ready-made modules for portfolios, testimonials, members, sliders, magazine blocks, real estate, WooCommerce, and other categories. The official page shows that many of these modules include not only structure but also a ready-to-use display pattern: a Bootstrap grid, cards, a slider, filters, responsive layout, or a demo result.

The ready-made library is useful as a starting point, but not as a final solution without review. After import, demo content should be replaced with your own, and the structure and design should be adapted to the site. Toolset also emphasizes that module elements can be edited: post types, fields, views, templates, and forms are not hard-coded.

Which settings to check immediately after import

• Post type names and slugs, to make sure they do not conflict with existing sections.
• Field group assignments, so the fields appear on the correct post type.
• Content selection in views, so they query the correct post type.
• Content templates, so single posts use the intended layout.
• The page where the view is inserted, if the module did not create it automatically.
• Any demo content that should be removed or replaced before publication.

Safe visual styling without editing the plugin

If the module works after import but looks out of place in the theme, do not edit Toolset files or the imported plugin directly. A safer approach is to add your own class to the page, block group, or container where the view is rendered, and then style it through Appearance > Customize > Additional CSS or a child theme.

The example below does not use internal Toolset classes and does not rely on undocumented APIs. It is just a standard CSS adjustment for a container you add around the module output yourself.

.client-portfolio-module {
  display: grid;
  gap: 24px;
}

.client-portfolio-module .portfolio-card {
  border: 1px solid #d8e4ea;
  border-radius: 8px;
  padding: 20px;
  background: #ffffff;
}

.client-portfolio-module .portfolio-card a {
  font-weight: 600;
  text-decoration: none;
}

The check is simple: add the class only on a test page, clear the cache, open the page in a regular browser window, and make sure the styles apply only to the intended block. If the result is not right, remove the class or the CSS snippet. That kind of rollback does not affect the module itself and will not interfere with future Toolset updates.

Practical example: moving a portfolio block between two sites

Let's look at a concrete scenario. An agency has a test site where it built a portfolio block: a "Projects" post type, "Client," "Industry," and "Gallery" fields, a "Project Category" taxonomy, a filtered list view, and a card template. The goal is to move that block to a new client site so an editor can fill it with real projects.

Goal

Create a ready-made framework for the portfolio section on the new site without manually recreating all Toolset settings. After the import, the editor should see the new post type, add several projects, open the portfolio page, and verify the filtered cards.

Preparation

• The portfolio block is already working on the test site and produces the expected result.
• The new site has the same core Toolset components installed that this block depends on.
• Toolset Module Manager is available on both sites.
• A backup of the new site was created before import.
• The new site does not already have a conflicting post type with the same slug, or you have already decided how to handle that conflict.

Steps

1. On the test site, open Toolset > Modules and create a module called "Portfolio base."
2. Add the post type, taxonomy, field groups, list view, and card template to the module.
3. Export the module and save the ZIP file next to a short description of its contents.
4. On the new site, open Toolset > Import/Export > Modules and upload the ZIP file.
5. On the element list screen, confirm that only portfolio-related parts are being imported, not unrelated test elements.
6. After import, open the created post type and manually add 2-3 test projects.
7. Create a "Portfolio" page or open an existing page and insert the required view.
8. Open the page on the public side of the site and verify the cards, filter, links, and responsive behavior.

Expected result

The new site now has the portfolio structure: the editor can create projects, fill in fields, assign categories, and see the result through the view. Demo data from the test site should not be treated as a required part of the transfer. If you need real projects, they must be imported separately or created manually.

A detail that often causes confusion

If the page opens but the list is empty, that does not automatically mean the import failed. The structure may have been transferred correctly, but the new site may not yet have any posts of the required type. Check the admin area: was the post type created, were test posts added, were the required categories assigned, and is the view querying the correct post type?

How to verify the result after import

Verification should follow a sequence. First the admin area, then the data, then the public-facing side of the site, and finally access permissions and cache. If you check only one page, it is easy to miss a problem in a single-post template or form.

Admin panel check

• Open the list of post types and make sure the required type appears in the menu or is available through Toolset.
• Open the field group and verify that it is attached to the correct post type.
• Create a test post and fill in every field used in the template.
• Open the view and verify the content selection, filters, sorting, and output template.
• Open the content template and confirm that it is assigned to the correct post type.

Public-side check

Open the page with the view in a normal browser window where you are not logged in. That makes it easier to see what a visitor will actually get. Check not only that cards appear, but also links, images, filters, pagination, responsive behavior, and empty states. If the imported module includes a form, submit a test entry on the staging copy and verify where it appears.

Result check: a module can be considered working only after you create test data on the target site and see the expected output on the public-facing side.

Cache, theme, and block editor

If the site uses caching, clear the cache after the import and again after inserting the view into the page. If the theme heavily restyles blocks, check the appearance at multiple screen widths. If you use the block editor, confirm that the Toolset components are compatible with the current editor version and are not showing broken blocks. Recent Toolset release notes have specifically mentioned compatibility fixes for Views and Blocks in response to WordPress changes, so updating the components before a serious migration is usually smarter than importing into an outdated stack.

Workflow for a team or agency

If Toolset Module Manager is not a one-off tool for you but part of a repeatable development process, it is worth organizing a small module library. This does not need to be complicated. A shared naming convention, storage location for ZIP files, version notes, and verification on a test site are usually enough.

How to store modules

The official documentation notes that modules are ZIP files that you save yourself. They are not automatically stored in your Toolset account as a personal library. So the responsibility for keeping them organized falls on your team.

• Store each module alongside a text description: purpose, contents, dependencies, and date of internal verification.
• Use a clear filename such as portfolio-base-toolset-module.zip, not module-final-new.zip.
• Do not combine multiple unrelated features into one module.
• Note which elements are not included in the ZIP: actual posts, images, users, and content-filled pages.
• Test the module on a clean test site after every major change.

How not to break the live site

For a production site, it is best to follow a "staging first" rule. Import the module into a copy, verify the created elements, and then repeat the process on the live site during a low-traffic window. If a conflict appears after import, it is much easier to roll back the staging copy and fix the module than to untangle the mess on a live project.

For team workflows, it also helps to maintain a module changelog: what was added, what was renamed, which fields were removed, and which views depend on new settings. This is especially important if one specialist exports the module and another imports it into a client site.

Limits, compatibility, and careful workarounds

Module Manager should be treated as a specialized tool for the Toolset ecosystem, not as a universal WordPress module manager. That mindset helps you avoid the wrong expectations and choose the right approach for each task.

Legacy status

Toolset support has noted that Toolset Module Manager is not under active development and may not be guaranteed to work with the newest Types and Blocks combinations. So for new projects, it is worth deciding up front whether this path is truly necessary. If the goal is to reuse older Toolset-based solutions, the tool can still be useful. If the project is just starting and is being built on a new architecture, a more modern configuration management approach may be the better fit.

Coordinated Toolset updates

In its release notes, Toolset has repeatedly emphasized component compatibility with changes in WordPress, PHP, and the block editor. For Module Manager, that leads to a practical rule: do not randomly mix very old and very new components. If you update Toolset, update the related parts together and verify module imports on a copy of the site.

SEO, performance, and security

By itself, Module Manager should not directly improve SEO or speed up the site. It transfers structure. SEO depends on how post type URLs, templates, headings, filters, indexation, and content quality are configured. Performance depends on the complexity of the views, the queries, the number of fields, the theme, and caching. Security depends on which forms are exposed to visitors, which permissions were assigned to roles, and how plugins are updated.

So do not promise yourself an automatic ranking boost or perfect performance after import. Check indexable pages, empty archives, the speed of complex views, form access permissions, and admin access. Module Manager saves time when assembling structure, but the quality of the finished site is still your responsibility.

When Toolset Module Manager is a good choice

Toolset Module Manager is worth using when you understand its boundaries: it transfers modular Toolset structure, helps you reuse finished solutions, and speeds up building similar sections across different sites. It does not replace content migration, does not guarantee compatibility without testing, and does not remove the need for post-import configuration.

If your project is already built on Toolset and you want to carefully move a specific block with post types, fields, views, and templates, the tool can save a great deal of manual work. Start with a test copy, verify dependencies, import only the elements you need, create test posts, and review the result on the public-facing side of the site.

If, after reading this, you understand that what you need is specifically a Toolset structure transfer rather than a full site migration, you can get the Toolset Module Manager file and test it on a staging site. Proper verification matters more than speed: first the structure, then the data, then the public result, and only after that the decision to use it on the live project.