The WordPress block editor became extremely slow on a site using Toolset Types, especially when editing posts with very large custom taxonomies (some with 1,000+ terms). Actions like opening the media library, selecting a featured image, or interacting with taxonomy fields caused long delays (30–60 seconds), making normal content editing impractical. Disabling Toolset Types restored performance, confirming the issue was related to how large taxonomies were rendered in the editor.
Solution:
The performance issue was resolved by changing large custom taxonomies from checkbox-style (category-like) inputs to tag-style (autocomplete) inputs. Checkbox-style taxonomy UIs attempt to load and render all terms in the editor, which becomes extremely slow with large term counts. Tag-style taxonomies use an autocomplete input instead, dramatically reducing the amount of data loaded in the editor. After switching most taxonomies to the tag-like format, editor performance improved significantly and editing became fast and usable again.
AJAX auto-update for Toolset View search filters (update results when inputs change) was not working on an archive page. The search worked only when using a Search button (non-AJAX submit), even though the View’s Custom Search settings and AJAX pagination settings appeared correct.
Solution:
The issue was caused by the theme deregistering WordPress’ jQuery using wp_deregister_script('jquery') and loading its own jQuery directly. This removed the jquery script handle that Toolset depends on. As a result, Toolset’s frontend.js was not initialized and AJAX events did not fire when filter inputs changed.
Fix: remove the deregister logic and restore the standard WordPress approach by using wp_enqueue_script('jquery'). After that, Toolset AJAX filtering worked normally.
The client was unable to save a Toolset Content Template on a new local/staging WordPress installation after importing older blog posts. The Content Template editor would not save changes, blocking further setup of archived content.
Solution:
The issue was caused by Toolset Blocks not being installed. While Toolset Types was active, the Blocks plugin—required for creating and saving Content Templates—was missing. After installing Toolset Blocks, the Content Template saved correctly and the issue was resolved.
The client wanted users to view, edit, and delete their own posts from a “My Account” page and expected the View/Browse link to go directly to a specific Content Template. Attempts to link directly to the Content Template using Toolset’s link options and View shortcodes did not work as expected.
Solution:
In Toolset, Content Templates cannot be linked to directly. A Content Template is applied automatically when a visitor opens a post’s permalink. The correct approach is to link to the post URL itself. When the post is opened, Toolset renders it using the assigned Content Template for that post type.
For edit and delete actions, Toolset Forms’ built-in edit and delete post links should be used, as they correctly handle post IDs and permissions.
The client could not create a new Toolset View or Content Template from the Toolset admin screens. When clicking Add New View or creating the first Content Template, WordPress showed “You have no permission to access this page” and redirected to the CT editor. This happened even when logged in as an admin and with default Toolset settings.
Solution:
After testing by deactivating plugins did not resolve the issue, the client reinstalled the website. Following the reinstall, the permission errors disappeared and Views / Content Templates could be created normally again.
The root cause was most likely a rogue plugin or corrupted permissions that had altered user capabilities in the original installation.
