Types is a WordPress plugin that lets you quickly create custom post types, taxonomies and fields in your website through the WordPress admin screen instead of adding PHP code to your theme. Types User Guides include detailed documentation for setting up your custom content.
When you ask for help or report issues, make sure to tell us the versions of the Toolset plugins that you have installed and activated.
The customer created a custom post field for images but was unable to upload AVIF format files to the field, despite AVIF images being supported elsewhere in their WordPress media library. They requested a solution to enable AVIF uploads in Toolset's custom image field.
Solution:
A code snippet was provided to extend the valid image file types for Toolset, allowing AVIF images. The customer added this code to their theme’s functions.php file or within Toolset > Settings >
function allow_avif_in_toolset( $valid_extensions ) {
// Add AVIF to the list of valid extensions
$valid_extensions[] = 'avif';
return $valid_extensions;
}
add_filter( 'toolset_valid_image_extentions', 'allow_avif_in_toolset' );
This code successfully enabled the AVIF format in the custom image field, allowing the customer to upload AVIF images as intended.
The customer wanted to display the value of the "Date of birth" user field in a custom post type called "publication." They were looking for a way to do this through a function rather than a shortcode, as publications are added via a Toolset CRED form.
Solution:
To achieve this, the customer was advised to follow a three-step process:
1- Create a Custom Field:
They needed to create a custom field in their "publication" post type to store the user's date of birth. This field could be named birth-post-field.
2- Populate Existing Posts:
A custom function was provided to loop through existing posts and retrieve the date of birth from the user meta. The code snippet provided was:
function update_birth_field_for_existing_posts() {
// Replace 'your_custom_post_type' with your actual CPT slug
$custom_post_type = 'your_custom_post_type';
// Query to get all posts of the specified custom post type
$query_args = array(
'post_type' => $custom_post_type,
'posts_per_page' => -1, // Retrieve all posts
'post_status' => 'publish', // Only published posts
'fields' => 'ids' // We only need the post IDs
);
// Execute the query
$posts = get_posts($query_args);
// Loop through each post
foreach ($posts as $post_id) {
// Get the post author ID
$author_id = get_post_field('post_author', $post_id);
// Get the 'birth' custom field value for the author
$client_birth = get_user_meta($author_id, 'wpcf-birth', true);
// Check if the author has a 'birth' value
if (!empty($client_birth)) {
// Update the post meta with the user's birth value
update_post_meta($post_id, 'wpcf-birth-post-field', sanitize_text_field($client_birth));
}
}
// Remove the action after it runs to prevent it from running multiple times
remove_action('admin_init', 'update_birth_field_for_existing_posts');
}
// Hook the function to admin_init so it runs when any admin page is accessed
add_action('admin_init', 'update_birth_field_for_existing_posts');
This code should be added to the theme's functions.php file and executed once by accessing the WordPress admin dashboard.
3- Automatically Populate on New Posts:
Another function was provided to ensure that when new publications were created or edited through the CRED form, the user's date of birth would automatically populate in the custom field:
add_action('cred_save_data', 'my_save_user_birth_to_post', 10, 2);
function my_save_user_birth_to_post($post_id, $form_data) {
// Your Toolset form ID in here
if ($form_data['id']==ID) {
// Check if the user is logged in
if (is_user_logged_in()) {
// Get the current user ID
$current_user_id = get_current_user_id();
// Get the 'birth' custom field value for the current user
$clientBirth = get_user_meta($current_user_id, 'wpcf-birth', true);
// Check if the user has a 'birth' value
if (!empty($clientBirth)) {
// Save the user's 'birth' value to the post's 'wpcf-birth-post-field' custom field
update_post_meta($post_id, 'wpcf-birth-post-field', sanitize_text_field($clientBirth));
}
}
}
}
After implementing these steps, the customer would have a new custom field linked to the user's date of birth, ensuring that new posts or edits would sync the user's birthdate with the post field. They would also be able to utilize the post field in views.
The customer created a many-to-many relationship between posts and products using Toolset and WooCommerce. When a connected product is "trashed," the connection is not automatically deleted, resulting in empty product cells in the grid view. The customer wanted a way to either filter out intermediary posts with trashed children or automatically delete the connections when a product is trashed.
Solution:
We provided a custom function using the wp_trash_post hook to automatically disconnect any intermediary posts associated with a product when it is trashed. The function also initially moved the intermediary posts to the trash, but this behavior was corrected to ensure only the connections were deleted without affecting the original post status. The code was updated to handle multiple relationships and ensure the associated posts remain published even after a product is trashed.
Final code:
The function disconnects intermediary posts while ensuring that the associated posts remain published.
The customer confirmed that the final solution worked correctly after adding an additional check to maintain the post's published status:
add_action('wp_trash_post', 'delete_relationships_on_trashed_product', 101, 2);
function delete_relationships_on_trashed_product($post_id, $previous_status) {
// Get the post object based on the post ID
$post = get_post($post_id);
// Ensure we have a valid post object and that it is of type 'product'
if ($post && $post->post_type === 'product') {
// Define the relationship slugs to check
$relationship_slugs = ['post-product', 'post-product-2', 'post-product-3'];
// Loop through each relationship slug and handle the disconnection
foreach ($relationship_slugs as $relationship_slug) {
// Get all intermediary posts related to this product for the current relationship slug
$related_intermediary_posts = toolset_get_related_posts(
$post_id, // ID of the post to get relationships from
$relationship_slug, // Relationship slug
'child', // Role of $post_id in this relationship
-1, // Limit to get all related posts
0, // Offset
[], // Additional arguments
'post_id', // Return type, we want the post IDs
'parent' // We want to get the parent posts related to this child
);
// Loop through each intermediary post and delete the relationship
if (!empty($related_intermediary_posts)) {
foreach ($related_intermediary_posts as $intermediary_post_id) {
// Disconnect the intermediary post
$disconnect_result = toolset_disconnect_posts($relationship_slug, $intermediary_post_id, $post_id);
// After disconnecting, ensure the parent post remains published
// Get the parent post object
$parent_post = get_post($intermediary_post_id);
// Check if the post status is not 'publish' and update it to 'publish'
if ($parent_post && $parent_post->post_status !== 'publish') {
wp_update_post([
'ID' => $parent_post->ID,
'post_status' => 'publish'
]);
}
}
}
}
}
}
The customer experienced an issue where a numerical field was sorting incorrectly, treating numbers as strings. After fixing this, they reported a new issue: navigation problems when users are not logged in, but everything works fine when users are logged in.
Solution:
The initial sorting issue was resolved by changing the field type to a number. The new issue with navigation for logged-out users was split into a separate ticket to maintain a focus on one issue per ticket.
The customer has two custom post types: "Providers" and "Offers," where each "Offer" is linked to a "Provider." After editing some Offers, they noticed that these Offers were no longer visible to the original Providers in their front-end accounts and appeared under the customer's admin account instead. The original Providers could no longer edit their Offers without accessing the WordPress backend. The customer wanted to know how to make the Offers appear again in the original creators' front-end accounts and whether it was possible to edit Offers from other Providers without changing the Offer ownership.
Solution:
When editing the posts in the backend, the post author was being overwritten with the current user (the customer's admin account). To prevent this, it was suggested to go to Toolset > Post Types, edit the "Offer" custom post type, and enable the "Post author" option in the Supports section. This change would allow setting the post author when editing, ensuring the original author remains unchanged, and maintaining proper ownership visibility on the front end.
The customer reported an issue where, when opening a post for editing in two of their custom post types, they receive a message: "Missing script for creating a new template. Not able to create one." This message only appears when the editor section is disabled for those post types. The other two custom post types are functioning normally without this message.
Solution:
We attempted to recreate the issue on a fresh WordPress installation with Toolset, but we could not replicate the error, even with the editor disabled. We suggested that the issue might be caused by another plugin or a custom function in the theme. We recommended the customer test with all non-Toolset plugins disabled and a default theme. The customer found a workaround by enabling the editor and then hiding it in the Admin interface. The customer decided to monitor the situation and indicated they might open another ticket if further assistance is needed.
The customer is working on a website with two different types of listings—one created using another plugin and the other using Toolset. They wanted to know if it is possible for both custom post types (CPTs) to share the same fields and taxonomies, which are currently attached only to the custom post type created by the other plugin.
Solution:
We clarified that if the customer wants to have identical CPTs in both Toolset and another plugin, it might be best to convert the existing types and fields so that Toolset manages them, ensuring everything is centralized in one place. We provided a link to the relevant documentation for converting existing types and fields to Toolset control. Additionally, we mentioned that in some cases, it is possible to use custom fields in Toolset even if they are not managed by Toolset, but this would need to be checked on a case-by-case basis.
The customer reported that when opening any of their post types, the "Folders" box in the right-hand column generates an infinite loop, causing the rest of the page content to never load. This issue prevents the customer from making any changes to post types, and they have to close the tab to continue. Updating to the latest release of the plugins did not resolve the issue.
Solution:
We investigated the issue and found that it was caused by the plugin 'WP Media Folder.' By temporarily disabling this plugin, the issue could not be reproduced. We suggested configuring the 'WP Media Folder' plugin to prevent it from adding the 'Folder' option to the Toolset Post Type edit screen to resolve the issue.
Problem:
The customer wants to set a custom field as the featured image for an entire custom post type. They are looking for a solution to establish this custom field globally for each post, as they did not find an existing feature in the documentation that meets this requirement.
Solution:
We informed the customer that there is no built-in feature within Toolset to directly set a custom field as the featured image. However, we provided a workaround involving the following steps:
Use the save_post action hook to trigger a PHP function when a post is saved.
Use the get_post_meta function to retrieve the custom image field value.
Retrieve the remote image file using cURL.
Save the image into the WordPress media library using wp_insert_attachment.
Set the media ID as the post's featured image using set_post_thumbnail.
Additionally, we shared a link to a forum post where a colleague provided a working example of code that runs through all posts of a specific custom post type, assigning a given custom field as the featured image.
The customer wants to create a primary sort based on a custom field and a secondary sort based on the title (alphabetical). Despite trying various changes, the primary sort seems to override the secondary sort. The customer is unsure if the issue is related to caching or another problem.
Solution:
I initially suggested using the wpv_filter_query to modify the orderby parameter in the theme's functions.php file. This involved adding the following code, replacing '1234' with the post view's ID and 'custom-field' with the custom field slug:
The customer reported that the secondary sort was still not working. After further investigation and testing with a staging site, I identified that the issue was specific to the CPT Products.
I provided a workaround that involved modifying the orderby filter to include secondary sorting by title. The following code was added to the theme's functions.php file:
<?php
function func_orderby_title($orderby) {
global $WP_Views;
if ($WP_Views->current_view == 14670) {
$orderby = $orderby . ", wp_posts.post_title ASC";
}
return $orderby;
}
add_filter('posts_orderby', 'func_orderby_title');
?>
I tested the solution on the staging site and then replicated it on the live site, confirming that the sorting issue was resolved.
The customer wants to sort results based on the comments count.
Solution:
Upon further review, I identified that the comment_count field in the wp_posts table can be used directly for sorting. I provided a code snippet to add to the theme's functions.php file to sort by the comment_count field:
Problem:
The customer wants to have a different WooCommerce product archive template for each of their two categories. However, when attempting to add a filter to apply it to a category, they receive an error indicating that the filter cannot be applied.
Solution:
Taxonomy term filters are not supported on taxonomy archives, and the error received is expected behavior. For example, if on a taxonomy WordPress archive page (e.g., "my-tax"), the filter will not work on that page and will display a warning message.
As a workaround, the customer can create a view to display term archive page links:
Create a taxonomy view that lists terms of the custom taxonomy.
Display the term's archive page link with the shortcode [wpv-taxonomy-link].
Insert this taxonomy view into the taxonomy WordPress archive.
This allows users to click the links and be redirected to the corresponding term's archive page.
Problem:
The customer is trying to update Toolset Types from version 2.2.23 to 3.5.2 after purchasing a license, but they encounter an error message.
Solution:
If the website has very old versions of Toolset plugins, such as Types version 2, automatic updates won't work due to the significant version difference. A manual update is required:
Download the plugin from the Toolset account downloads page.
Upload the newer version of Types to the site via the WordPress admin area:
Navigate to WP Admin -> Plugins -> Add New Plugin -> Upload Plugin.
Confirm to overwrite the existing plugin version when prompted.
Once updated manually, future updates for Toolset plugins should be manageable from the admin area.
Problem:
The customer reported that their Toolset plugin throws a fatal error and mentioned a suggestion to reinstall a fresh copy of the plugin. Despite reinstalling, the issue persists with version 3.1.3, preventing them from providing debug info. Solution:
We recommended manually replacing and updating the plugins. The steps included making a backup, disabling and removing all Toolset plugins, downloading fresh versions of Toolset plugins (Types v3.5.2, Blocks v1.6.15), and then installing and activating them. When the initial solution didn't resolve the issue, we requested temporary access to the site to further investigate and manually install the plugins. After this intervention, the fatal error was not experienced during our tests.