Problem: I would like to automatically create a profile page for each new User who signs up with CRED.
Solution: You can use the cred_save_data API to automatically create a post after registration. Create a "Profile" post type, and add the following custom code to functions.php:
add_action('cred_save_data', 'ts_new_user_profile_action',10,2);
function ts_new_user_profile_action($user_id, $form_data)
{
// if a specific form
if ($form_data['id']==1234)
{
// Create post object
$my_post = array(
'post_title' => $_POST['first_name'] . ' ' . $_POST['last_name'],
'post_content' => '',
'post_status' => 'publish',
'post_author' => $user_id,
'post_type' => 'profile'
);
// Insert the post into the database
wp_insert_post( $my_post );
}
}
Replace 1234 with the numeric ID of the CRED registration form, replace "profile" with the slug of the post type you want to create, and modify the post_title if you want the title of the post to be anything other than the new User's name.
Problem: I would like to use CRED to allow my site Users to upload multiple images, and associate those images with CPTs. Some of those CPTs are child posts, some are parents, some are grandparents. What is the best way to associate the images with all levels of the CPT hierarchy?
Solution: It depends on your site's requirements. There are several things to consider.
- It is easier to create custom search filters using custom fields attached to the same post type shown in the View.
- However, it is not possible to use repeating fields in child posts in the current stable version of Types. The new beta M2M features will address some of this issue.
- Taxonomies can be used to relate the images to multiple CPTs, but they must be managed by your Users.
- Galleries and Carousels in Divi Builder have limited options for filtering the results, and it is not possible to use shortcodes as filters. So Divi cannot access custom fields effectively in the Gallery or Carousel module.
- Elementor ACF Gallery modules may or may not work with Types custom fields. Types custom fields are stored in the postmeta table using the previx "wpcf-".
Problem:
What are the options for displaying different content to different users on the front-end?
Solution:
To display different content on the front-end according to some criteria you essentially have two options.
If the thing being tested relates to the person doing the looking (the user browsing the website is registered and has a certain role because they have paid for a particular membership, for example) then you can use Access to restrict the visibility of whole pages, or to selectively show certain content on a page (as described here: https://toolset.com/documentation/user-guides/access-control-texts-inside-page-content/).
If the thing being tested relates to the thing being looked at then you would need to add custom fields to the content being viewed and then use the wpv-conditional shortcodes to test the content of those custom fields and selectively display what is wrapped in the shortcode, as described here: https://toolset.com/documentation/user-guides/conditional-html-output-in-views/
Problem:
Is it recommended to use taxonomies (with checkboxes) or checkboxes custom fields?
Solution:
If you intend to filter a View using these checkboxes you should probably use taxonomies rather than a checkboxes custom field, because within WordPress taxonomy filters are more performant that meta query filters (https://tomjn.com/2017/02/27/not-post-meta-bad/).
See the answer below for a more detailed discussion.
The issue here is that the user wanted to know if its better to use User fields or Post Fields. Solution:
In this case the user was advised to create a profile CPT and allow his users to create a profile on the profile CPT. If you are using a CPT to store the user's profile then its best to use a Post Field. Otherwise you will need to use User Fields.
Solution:
There are three ways to connect users to posts.
The simplest and preferred method is to make the users the authors of the posts, thereby using the built-in means of connecting posts to users with no additional overhead.
There may be reasons why that is not possible, the main problem typically being that you can only assign a single author to a post.
A second option would be to create a custom field for post "owner" that stored the ID of the associated user. By making this a repeating field, you could connect multiple users.
The final method would be to make a custom post type for users which stores additional profile info for an individual user (who you make author of the post), and this custom post can then be connected to other post types using Types post relationships.
