CRED is a WordPress plugin that lets you easily build front-end forms for creating and editing content and users.
CRED User Guides include detailed documentation on creating forms, including related fields that belong to the content or the users, validating the input and displaying the forms with custom HTML styling.
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’s form at https://www.domain.com/apply-form/ was experiencing issues with the date picker and conditional logic fields, which were not functioning as expected. The issue was identified as jQuery not loading correctly on the page.
Solution:
Upon investigation, it was found that the Autoptimize plugin was preventing jQuery from loading, which affected the date picker and conditional logic functionalities. The solution steps included:
1- Disabling the Autoptimize Plugin Temporarily: The plugin was disabled, which restored the date picker functionality on the form page.
2- Recommendation for Long-term Fix: The customer was advised to reach out to Autoptimize plugin support to determine why jQuery wasn’t loading on all pages. This would allow them to keep the plugin enabled without impacting jQuery-dependent functionalities.
The customer wanted to enable users to upload files (resumes and certificates) via a Toolset form and store these files in a custom directory (/wp-content/bewerbungsunterlagen) rather than the default uploads folder. The initial code attempts failed, saving files in the standard uploads directory.
Solution:
We suggested refining the upload_dir filter to ensure it only applies when necessary and removed afterward to avoid conflicts. Additionally, the permissions for the custom post type 'Bewerbungen' were adjusted in Toolset > Access Control to allow guest users to upload files without needing to log in. To prevent WordPress from generating thumbnails for PDF files, a code snippet was added to the functions.php file to disable PDF previews:
The customer wanted to customize the login form to replace the email and username fields with only the email field and apply custom styling. They were following Toolset documentation but encountered limitations with the Toolset plugin.
Solution:
We explained that Toolset only allows pulling the default WordPress login form, which can be customized using CSS but does not support creating a fully custom login form. To customize the labels and structure, the customer would need to implement custom code. We provided links to WordPress documentation on how to customize the login form using native WordPress functions.
The customer noticed that users were able to have multiple photos attached to their profiles in the WordPress Admin, even though only one photo should be allowed. He wanted to ensure that if a user removes their profile photo and resubmits the form, the photo is permanently deleted. Additionally, if a user chooses a new photo, it should replace the existing one.
Solution:
We explained that Toolset Forms does not natively support this feature but provided a workaround using custom code:
1- Use the cred_save_data action hook to trigger a PHP function when a user submits the post form.
2- In the PHP function:
• Retrieve images attached to the current post using get_attached_media.
• Access images stored in the custom repeating image field using get_post_meta.
• Compare these sets of images to identify and remove unused files using wp_delete_attachment.
Problem:
The customer is unable to view their form on a mobile device. They expected to see the form on the page but instead, the form is not visible.
Solution:
We tested the form on a mobile device and found that the form is visible when logged in but not visible when logged out. This indicates that the issue might be related to form visibility settings for non-logged-in users.
The customer wants users to edit their own custom and WordPress posts using a front-end Toolset form. However, when users click the edit post link, they are redirected to the edit page, which includes unnecessary theme elements like the sidebar, double images, and other Elementor theme components.
Solution:
Initially, I tested the issue by creating and editing posts but could not reproduce the problem. The customer added a "company profile" and posts to my account for testing.
I identified that the issue was related to the Elementor templates and provided a solution by following steps outlined in a similar case: https://toolset.com/forums/topic/how-to-edit-posts-with-a-front-end-form-if-using-elementor-templates/#post-2365825
How to Edit Posts with a Front-end Form if Using Elementor Templates
The customer followed the provided steps, which resolved the issue, removing the unwanted theme elements and displaying only the edit fields.
The customer wants to place the label behind the input in the search form to manipulate the label based on the input status using CSS. However, the input is currently placed inside the label, making this manipulation difficult.
Solution:
I confirmed that the customer is using legacy views to create the search form.
I checked internally and found that it is not possible to separate the label from the input using shortcodes in legacy views.
As a workaround, I suggested using JavaScript to manipulate the label based on the checkbox's checked status. Here is an example code snippet:
jQuery(function($){
$(".class_containing_your_checkbox input[type='checkbox']").change(function(event){
var checkbox = $(event.target);
var status = checkbox.prop('checked');
if (status) checkbox.parent().css('background-color', '#569cc3');
else checkbox.parent().css('background-color', '');
});
});
The code above applies CSS rules based on whether the checkbox is selected or not. The customer needs to change the function to target the specific div class containing the checkbox and apply the desired CSS for the labels.
Problem:
The customer created a form with Toolset and added it to a new page using a Toolset form block. While the form appears in the Gutenberg editor, it does not appear on the front end. Only the page title is visible. Solution:
Initially, I suspected the issue was due to the Toolset Access plugin's guest permissions not being set for the form. I advised checking the form permissions under Toolset -> Access Control -> Forms and ensuring the guest option was checked.
Upon further investigation, the issue was identified as a conflict or misconfiguration with the plugin 'Restrict User Access'. Disabling this plugin allowed the form to appear correctly on the front end.
Problem:
The customer wants to modify the labels of the login form so that users can log in with their email only, not their username. They can add the login form via shortcode but need to customize the form labels. Solution:
We informed the customer that customizing the login form labels requires adding custom code to the theme/child theme's function.php file. We initially provided the following code snippet:
add_filter('gettext', 'user_label_change', 20, 3);
function user_label_change($translated_text, $text, $domain) {
if ($text === 'Username or Email' && $domain == 'default') {
$translated_text = 'Email';
}
return $translated_text;
}
The customer later managed to achieve their goal with a different function:
add_filter('gettext', 'register_text');
function register_text($translating) {
$translated = str_ireplace('Username or Email', 'Your Custom Text', $translating);
return $translated;
}
