I want the custom post types for farms and restaurants on my site to not display the post name in their permalinks, using only the post ID instead. This is because I’m building a paid member directory, and displaying the name in the URL could give away sensitive information.
Solution:
The URL structure of custom post types is managed by WordPress settings, not Toolset. To achieve ID-based URLs, go to WordPress Dashboard > Settings > Permalinks and set the structure to "Plain".
Alternatively, using a plugin like "Custom Post Type Permalinks" can help customize the permalink structure to meet your needs.
The customer was trying to connect their custom post type in WordPress to Activepieces to create multiple custom post types from data in Google Sheets. Although the connection was established without errors, the imported custom post types were completely blank.
Solution:
We identified that the option to "Expose custom fields managed by Types for posts, users, and terms through the REST API" is primarily for exporting data rather than importing. We suggested the customer check if they were using the WP All Import plugin, which has an add-on for Toolset Types, to handle the import process more effectively. Additionally, we recommended exporting data from Activepieces to a CSV file and then importing that CSV into Toolset using available CSV import plugins, as this could simplify the import process and ensure the data is processed correctly.
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:
[php]
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'
]);
}
}
}
}
}
}
[/php]
The customer wanted to add or delete a funder's name/logo to/from a dropdown list on a page. They were unsure how to achieve this and lacked guidance from the previous developer.
Solution:
We found that the dropdown is hard-coded in the child theme's functions.php file. Adding an image directly into elements of a dropdown is not supported by browsers. We suggested using a library like Select2 or Chosen for advanced customizations that allow images in dropdowns, but this requires significant code customization, which falls outside our support scope. We advised the customer to contact a Toolset contractor for further assistance.
The customer wanted to make a grid view on their website's tenders page more mobile-friendly. The desktop view looked good, but the mobile view was not user-friendly. The customer preferred the text to appear directly below the headings for each column on mobile devices.
Solution:
After reviewing the setup, we identified that the grid view was already responsive. To improve the mobile display, we suggested placing the headings and their corresponding text within the same parent block instead of using separate blocks for each element. This adjustment ensured the text appeared directly below the headings on mobile devices. We also recommended updating the padding and margins to achieve the desired look. The customer confirmed that the solution worked perfectly.
The customer wanted to enable users to filter archives on their website hosting academic texts, similar to how search results can be filtered. The customer specified that they needed the ability to filter texts by various criteria like publication year and language when viewing a specific category of texts. While they could easily set this up in a search view, they were unsure how to implement it in an archive view.
Solution:
We guided the customer to utilize the "Screen Options" tab available when editing the archive. By expanding this tab, they could enable search sections that are typically used when editing a View. This feature had been previously introduced in a pop-up when they first created a custom archive, which they may have dismissed.
The customer was advised to explore these options to achieve the desired filtering functionality for their archives.
