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 wanted to create a search form with drop-down options for filtering academic texts on their website, aiming to replicate a search functionality similar to that on the Jeb Dunnuck site. They faced difficulties implementing this using Toolset Views with the legacy editor.
Solution:
To achieve the desired search functionality, the customer was advised to add a select dropdown for post type filters within their view and use the following code for implementation:
I am trying to add a block type called "Open Sheet Music Display" as a custom field within a custom post type (music-styles). I attempted using a WYSIWYG and multi-line custom field, but they do not allow adding blocks. It seems I can only use Gutenberg blocks outside of custom fields.
Solution:
Blocks are a native feature of the WordPress editor and cannot be used within custom fields. Toolset cannot recreate block functionality inside custom fields because custom fields are standard WordPress features that do not support block content. You can only use blocks inside the main content editor.
The customer reported that since September 6, their security software marked the submit.php file from Toolset as suspicious, along with other files from various Toolset plugins. This issue affected all their sites using Toolset plugins, leading to concerns about potential security risks.
Solution:
We conducted a review of the flagged files and found no malicious content but recommended that the customer manually replace the plugin files with fresh copies from the Toolset downloads page. After the customer reported that reinstalling the fresh copies did not resolve the issue, we confirmed it was a false positive. We contacted the WPMU team to request whitelisting of the files.
The customer was advised that they could also reach out directly to the WPMU support team for faster assistance regarding the whitelisting process. Ultimately, the WPMU team confirmed that the files were whitelisted, resolving the customer's issue.
The customer was using the cred-delete-post shortcode to allow users to delete posts but encountered an error message ("Something went wrong, please reload the page and try again") when attempting to delete posts with any role other than administrator. Additionally, a user with the "Adm Entidades" role was incorrectly able to see an edit form that they should not have access to.
Solution:
Upon investigation, we found that the issue stemmed from a custom code snippet that was causing redirection conflicts. Specifically, when the code included a wp_redirect function, it led to an infinite redirect scenario, preventing users from performing the delete action.
To resolve this, we temporarily disabled the custom code and moved it to the Toolset custom code section. We ensured that it would not execute during AJAX calls by unchecking the "Llamadas AJAX" option in the settings. This adjustment allowed users with the "Adm Entidades" role to delete posts without encountering the error.
The customer was able to confirm that the changes worked as intended.
