[Resolved] Only post once and prevent multiple submissions.

[Author]

Posts

[Stephen Vaughan]

Hi,

I am researching a setup for a members site. The client wants to allow members to submit content for their own member's page.

I am looking at Cred Forms and this will need certain requirements. The user can only submit one instance to match their singular page. We don't want then populating the site with several instances of thier profile page. Is there a way to configure forms for such a restriction?

On initial testing I note that if we redirect the user to another page, after submission from the form, and then accidentally hit the back button in the browser/mouse, we get the form submitting again, hence potential for multiple posts. Is there a way to prevent this?

[Stephen Vaughan]

Just a few more things.

When I follow the following guide for setting up the editing on a Cred form, when I get to the stage where I add the Edit button, clicking Edit doesn't reveal the editing form. This is as a shorcode in Bricks. NOTE: I also tested seting this up via a block in the block editor on a page and it seems to lock up, not allowing one to save the page.

https://toolset.com/lesson-placement/lesson-placements-1621521-1612095/#3-insert-link-to-the-content-template-that-displays-the-form

In another set up I have a view, showing the singular post as filtered to the user at the time. Below this is the submission/publish form and I want to set a conditional that only shows this when the view above it is empty. I see the wpv-view option in the conditional drop down and am assuming that I can target a view. Is this possible.

Lastly, as I am finding all the above frustrating can I assume that this area of Toolset is now a little bit broken and I might be flogging a dead horse trying to get any of this to work?

[Stephen Vaughan]

I note that if I embed the shortcode into the post type template in Bricks I can get the edti form to appear. As this will only appear when logged in I could set this as a pop up on the page. Assuming nothing else is fundamentally wrong now with CRED forms and other parts of Toolset?

[Christopher Amirian]

Hello,

Welcome to Toolset support. Let me see if I can address the point syou mentioned as much as I can.

Restricting users to a single profile post

There's no built-in setting for "one post per user," but the recommended pattern combines two layers — a conditional that hides the form once a post exists, and server-side validation that catches edge cases (like the back-button issue you described).

Layer A — Hide the form using a View as a conditional:
Create a View of the profile post type, filter by post author = current logged-in user, set it to return 1 result, and place the create form inside the No items found output. If the user already has a profile, the form simply isn't rendered.

Layer B — Server-side validation with cred_form_validate:
This is what actually solves the back-button problem. The hook runs on every submission and returns a friendly error if a profile already exists for that user — regardless of what the front-end is showing.

The cide would be something like this:

add_filter('cred_form_validate', 'profile_exists_validation', 10, 2);
function profile_exists_validation($error_fields, $form_data) {
    global $current_user;
    list($fields, $errors) = $error_fields;

    // Replace 12345 with your form ID, and 'profile' with your CPT slug
    if ($form_data['id'] == 12345) {
        $args = array(
            'author'         => $current_user->ID,
            'posts_per_page' => 1,
            'post_type'      => 'profile',
        );
        $profiles = get_posts($args);
        if (sizeof($profiles) > 0) {
            $errors['post_title'] = 'A profile already exists, so you cannot create another one.';
        }
    }
    return array($fields, $errors);
}

For more information:
https://toolset.com/documentation/programmer-reference/cred-api/#cred_form_validate

Edit button not revealing the form in Bricks

A few things to verify:

- The Content Template that holds the form is created at Toolset → Content Templates, kept unassigned, and contains nothing but the form shortcode.
- The edit link references that template's slug:

[toolset-edit-post-link content_template_slug="edit-profile-template"]Edit your profile[/toolset-edit-post-link]

For more information about the post edit link shortcode:
https://toolset.com/documentation/programmer-reference/forms/cred-shortcodes/#toolset-edit-post-link

Documentation:
https://toolset.com/course-lesson/front-end-forms-for-editing-content/

Your alternative approach, "placing the form directly into the post type template in Bricks and showing it via a popup for logged-in authors" is perfectly valid.

Conditional based on whether a View has results

Testing a View's output string in a wpv-conditional is unreliable because Views can inject whitespace or markup even when "no items found" is empty — the conditional then evaluates the string as non-empty. The recommended approach is to do this inside the View itself rather than around it:

- Build the View of the user's existing profile (filter: author = current logged-in user).
- Put the create form in the View's [wpv-no-items-found] section.
- Put any other content (e.g. the "you already have a profile" message) in the items-found section.

That way the View itself decides what to render, and you avoid the conditional altogether.

Thanks.

[Stephen Vaughan]

Thanks Christopher,

Spot on suggestion, using the view's alternative output if there are no results does the trick. I'll remeber that one in the future as a good option.

I had a go with Claud AI to create a function for this but your version is a lot neater so using that instead.