Problem: I would like to display a list of related posts on a taxonomy term archive. Related posts should be posts with terms that are siblings of the current archive term.
Solution:
- Create a View of these posts filtered by the same taxonomy, where the taxonomy term slug is set by one shortcode attribute.
- Use a custom shortcode to get the parent term slug based on the current archive term slug.
- Register the get_term_parent shortcode in Toolset > Settings > Third party shortcode arguments
- Apply a custom filter using PHP that will filter out all the posts in the current term archive, to prevent duplicates.
Problem:
How to hide filter labels if there are no options (checkboxes) available to filter by?
On the client site a View includes filter controls which in some circumstances may not have any available options, and the filter label should be hidden in such circumstances.
Solution:
Some custom JS needs adding which effectively checks the filter markup to determine whether a given label is followed by a filter control or not and can hide the label accordingly.
Examples are given below (the exact code will depend on the filters and their settings).
Problem: I would like to add a filter to my custom search View that has options with different price ranges. For example, Less than 50, 50 - 100, and 100+.
Solution: There is not an easy way to accomplish this in Toolset using a standard price filter. You would have to create a separate custom field that holds a value that represents each price range, then filter based on that custom field. To automate the process, you could use a hook like save_post or pmxi_saved_post to check the current price and update the value automatically:
Problem: I have a custom search View that includes a taxonomy filter with only two options. I would like to create another custom search View and predefine the selected taxonomy filter in both Views, and I would like to prevent Users from choosing a different taxonomy term in the filter.
Solution: You can combine a custom search View with predefined Query Filters. Set up the other filters as needed, then add your predefined taxonomy term Query Filter. You may have to expose the Query Filter panel by going to Screen Options in the top right corner of the View editor screen.
Can I possibly query the radio buttons that have just been clicked?
For example, there are 2 radio buttons and Radio Button 1 should display something specific and click on Radio Button 2 should display something else. Is this perhaps possible?
Solution:
It needs some custom JS codes, I suggest you follow Jquery document to setup the JS codes: https://api.jquery.com/click/
Problem: I would like to include a single select field for selecting a taxonomy term in CRED. The taxonomy is flat, not hierarchical.
Solution: CRED does not support a single select field for flat taxonomies, so you can either convert the taxonomy to a hierarchical taxonomy or you can use a generic field and the CRED API.
Problem: I have a Form that creates child posts. I would like to use the cred_form_validate API to ensure that the parent post chosen in the Form has specific terms and custom field values.
Solution: Use custom code to query the parent post and compare its terms and custom field values.
add_filter('cred_form_validate','validate_parent_consultant',10,2);
function validate_parent_consultant($field_data, $form_data)
{
list($fields,$errors)=$field_data;
//error_log(print_r($fields, true));
$forms = array( 6 );
// validate if correct CRED form ID
if ( in_array( $form_data['id'], $forms ) ) {
// edit these 6 lines as needed
$parent_field_post_name = '@consultant-event_parent';
$parent_field_name = '@consultant-event.parent';
$checkbox_slug = 'parent-checkbox-field';
$taxonomy_slug = 'consultant-taxonomy';
$taxonomy_terms = array('a', 'b');
$test_cbs = array( 'a', 'b', 'c' );
// get the parent ID from the form field
$parent_id = $_POST[$parent_field_post_name];
// check if parent has all matching checkboxes
$vals = types_render_field($checkbox_slug, array( "separator"=>",", "id"=>$parent_id));
$any = strlen($vals) > 0 ? explode(',', $vals) : array();
$cbs_match = sizeof($any) > 0 && sizeof(array_intersect( $any, $test_cbs)) == sizeof($test_cbs);
// Test if the parent has all the right term(s)
$matching_terms = [];
foreach($taxonomy_terms as $tax_term) {
if( is_object_in_term( $parent_id, $taxonomy_slug, $tax_term ) ){
$matching_terms[]= $tax_term;
}
}
$terms_match = sizeof($matching_terms) == sizeof($taxonomy_terms);
// combine parent validations
if( !$cbs_match || !$terms_match ) {
$errors[$parent_field_name] = __('Select a different parent post.', 'your-theme-domain');
}
}
//return result
return array($fields,$errors);
}
Problem: I have a Form that creates new child posts. I would like to use the cred_save_data API and the new Post Relationships API to update a custom field value in the parent post. I also have a Form that edits a parent post. I would like to use the APIs to update custom field values in all its child posts.
Solution:
To update the parent from the child post Form:
Problem: I would like to use cred_before_save_data to prevent a User from submitting the same form multiple times to create multiple posts, or to edit the same post more than once.
Solution: The cred_before_save_data hook should not be used to validate form submissions. Instead, use the cred_form_validate hook. This will allow you to return meaningful error messages to the front-end of the site. Here is an example showing how to prevent a User from creating more than one post, or how to prevent a User from editing a post where a specific custom field already has a value:
add_filter('cred_form_validate','profile_exists_validation',10,2);
function profile_exists_validation($error_fields, $form_data)
{
global $current_user;
//field data are field values and errors
list($fields,$errors)=$error_fields;
//uncomment this if you want to print the field values
//print_r($fields);
//validate if specific form
if ($form_data['id']==12345)
{
//check custom field value
if (isset($fields['wpcf-sel1']['value']) && $fields['wpcf-sel1']['value']!='')
{
//set error message for my_field
$errors['wpcf-sel1']='This custom field has already been defined for the post.';
}
//check if current User is already the author of a "Profile" custom post
$args = array(
'author' => $current_user->ID,
'orderby' => 'post_date',
'order' => 'ASC',
'posts_per_page' => 1,
'post_type' => 'profile'
);
$profiles = get_posts( $args );
if ( sizeof($profiles) > 0 )
{
//set error message for post title
$errors['post_title'] = 'Profile already exists, so you cannot create another one.';
}
}
//return result
return array($fields,$errors);
}
Problem:
Are the solr and redis cache plugins compatible with Toolset?
Solution:
We believe so. For the Solr plugin to work with Views queries you would need to add the parameter solr-integrate set to true for the WP_Query.
You would have to set that up yourself, meaning using the pre_get_posts hook to add that parameter to the required queries.
Problem:
The issue here is that the customer wanted to know if we have full support for the wordpress REST API
Solution:
Unfortunately no we currently don't have full REST support. What we have currently is for exposing the custom post types to the api for view purposes only.
I am trying to set up a view by url parameter. I have created the custom user field "test" that holds the ids of the posts but I do not know how to create the link that will output the ids in url.
Initially I used this code in the view template:
<a href="?test=[types usermeta='test' user_current='true' separator=',' output='raw'][/types]">show posts with ids same with the values from the custom field test</a>
The posts appear seperated by a comma in the url like:
domain.com/view-post-query/?test=1830,697,2167
and the view shows only the first post from the list
<a href="?test=[types usermeta='test' format='FIELD_NAME[]=FIELD_VALUE' user_current='true' separator='&'][/types]">show posts with ids same with the values from the custom field test</a>
Problem:
I am doing some tests to my development website with views and I discovered sth wird. I need to create user profiles and I am testing if it is faster and lighter to use a post view or a user view.
So here is how I did my test: I added 2.741 users to my website and 2.741 posts. Then I created a post view and a user view with exactly the same fields. According to query monitor, the user View needs 3.8 sec to generate the page (196 KB) when the post view needs 6.36 sec (188 KB). Big difference, right?
When I paginated my views sth very strange happened. The user view now needs 2.34 sec from 3.8 sec (188 KB) to create the page when the post view needs just 0.2 sec (13 KB) from 6.36 sec (188 KB)
Why may this is happening? Why the post view has so big difference when it is paginated and the user view remains almost the same? Is this a bug or am I missing a setting?
I am developing a site that may be huge in the future with a lot of users registered to it, so I would like to avoid adding extra content that is not needed. Ideally I would like to use just the user view without adding extra custom fields and custom post type for the creation of the profiles. Is there a way to make the user view faster like is happening with the post view when it is paginated?
Solution:
Q1) Why may this is happening? Why the post view has so big difference when it is paginated and the user view remains almost the same? Is this a bug or am I missing a setting?
There are lots of differences between them, the main difference is below
Views uses wordpress class WP_Query to query the posts in database table "wp_posts" https://codex.wordpress.org/Class_Reference/WP_Query
Q2) Is there a way to make the user view faster like is happening with the post view when it is paginated?
There are some documents you can refer:
1) shortcode [wpv-view]: https://toolset.com/documentation/user-guides/views-shortcodes/#wpv-view
Turn on cache feature of Views plugin:
cached (opt): off
Turns off the caching system for the View.
For example: [wpv-view ...cached="on"]
We document known issues and their solutions in Toolset errata. Save time by checking there first and seeing if what you are facing is a known issue. This list is kept short. We do our best to resolve all known issues with every release of Toolset plugins.
Support Policy
Toolset staff will help you use the Toolset plugins correctly, provide any information you need, help troubleshoot problems and advice on best-practices.
Please make sure to issue only one topic per each support ticket.
