Skip Navigation

[Resolved] Toolset Form (CRED) set to AJAX will refresh page and append a 'tt' URL param

This support ticket is created 5 years, 3 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 - -
13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 - -

Supporter timezone: America/New_York (GMT-04:00)

This topic contains 7 replies, has 2 voices.

Last updated by davidB-27 5 years, 2 months ago.

Assisted by: Christian Cox.

Author
Posts
#1390321

Hello,

I'm using a Toolset Form to submit basic text data to a page. The form is set to submit with AJAX, and it works, but only AFTER I experience an error.

On my first form submit, the form refreshes the page and appends a parameter to the URL (e.g. ?tt=12345). The form submission doesn't appear to change post content in this instance - but when I try it again, I get my intended AJAX behavior (loading spinner, 'Post Saved' message, and the post content is successfully changed.

I'm building this 'form to content' flow for customers, so I'd rather have this work on the first try 🙂

I assume you may know where that 'tt' URL param is coming from and why it may be showing up once, then not again.

Thanks!

DB

#1390695

Hi, unfortunately even if the AJAX submission option is selected, the Form will reload the page after submission unless "Keep displaying the form" is selected in the Form configurations. The tt URL parameter is used internally by Forms and it is expected to be added to the URL...there's not a recommended way to remove it.

The form submission doesn't appear to change post content in this instance
That's not normal, a Form submission should change the post content immediately unless there is some error. Could I log in and see this in action somewhere on your site? Please provide login credentials in the private reply fields here and let me know where I can see the edit post Form on the front-end.

#1393771

Reactivating private reply fields

#1393775

Where can I see the multiple forms page on the front-end of the site?

#1393783

Okay I was able to submit the Form successfully here:
hidden link

I can see the Beaver Builder design for this page here:
hidden link

The shortcode to display the Form is here:

[cred_form form='home-two-content' post='236']

When I submit a change to the tagline for example, the AJAX spinner spins for a moment, then I see the message "Post Saved" appear before the first Form. Now if I edit post 236, I can see the change I made to the tagline. It appears immediately here:
hidden link

Further down the front-end page I can see the Home View, which displays content from post 236. This content is not yet updated. My guess is that when you submit changes in the Form with AJAX, you're expecting the View showing that post to update real-time. Unfortunately Forms isn't hooked into Views like this, and Views isn't designed to detect changes that occur in the background. If you want to update the content shown in a View by submitting a Form on the same page, you must disable AJAX on the Form and trigger full page reloads with Form submission. There is no JavaScript API available for Views to trigger an update of the results content on-the-fly, and no data-binding feature that will update a View in real-time based on database changes.

Hope that clears things up a bit, let me know if you have follow up questions about that.

#1393831

Thanks for taking a look!

"My guess is that when you submit changes in the Form with AJAX, you're expecting the View showing that post to update real-time."

Good guess, but that's not it - I don't expect the View to reflect AJAX changes and I was just throwing that in there to confirm that Views would reflect form changes if the view's containing page was refreshed. The error was something else.

It sounds like you didn't get the same error I did, where the 'first submission' of an AJAX form threw a validation error on other form embedded on that page and 'didn't AJAX the form.' This is really tough to replicate, since it fails sometimes and works other times.

Here's the rub - I think I may have to explore another solution than Toolset forms, because I'd like one form to be able to edit existing content AND add new content of a post type (even multiple post types). I'm trying to help customers build a website whose contents are mostly (if not all) text elements, and I'd like one 'master content form' to be the editing point (instead of navigating WordPress or a Page Builder).

I take it that's a custom job. I tried to stitch it together with Toolset, but I'm thinking this task demands some custom PHP. If you have any thoughts on it, I'm all ears 🙂

DB

#1397117

I'd like one form to be able to edit existing content AND add new content of a post type (even multiple post types). I'm trying to help customers build a website whose contents are mostly (if not all) text elements, and I'd like one 'master content form' to be the editing point (instead of navigating WordPress or a Page Builder).
Thanks for the additional information, and I understand your point about workflow and efficiency. Depending on the level of complexity of the post fields, post relationships, and so on, we might be able to accomplish this in one Form with Toolset. By default it is not possible to manage more than one post in a single Form - this requires custom code with our PHP APIs. If your field inputs are mostly text-based, the customization may be fairly straightforward. If you need the ability to create repeatable field group instances, that requires code that is outside the scope of our support forums. I'm available to help implement our APIs and provide code examples per our support policy: https://toolset.com/toolset-support-policy/.

Here is a general overview of the steps involved:
- Create the various custom post types as you would normally create them with Types, and note each post type's slug from the post type editor screen.
- Create all the custom fields for each post type, and note each field's slug. You can find the slug of a field in Toolset > Custom Fields > Post Fields. Edit the field group that contains the field and you'll see the slug attribute in the field editor panel.
- Create a new post Form for one of the custom post types. For now, you can use the drag-and-drop Form editor to design the Form.
- For each custom field in one of the other custom post types, you must now create a corresponding generic field in the Form. You can insert them with the drag-and-drop editor if you'd like. Use the same slugs you noted from the field editor. Here is more documentation about generic fields: https://toolset.com/documentation/user-guides/inserting-generic-fields-into-forms/
- For each standard WP field you want to manage in this Form, like post title or post contents, insert a corresponding generic field. The slug is arbitrary, so use a slug that makes sense to you. Something like post-title-for-book-post or post-content-for-author-post for example. The best format for a slug is all lowercase letters and dashes, no spaces or other special characters. Avoid using slugs that are completely numeric, since those are easily confused with numeric IDs. Each field slug in the form must be unique.
- Create a custom code snippet in Toolset > Settings > Custom Code, or add your code to a child theme's functions.php file.
- Use the Forms API hook cred_save_data to get the data submitted in the generic fields and use that data to programmatically insert a post with the corresponding Types fields populated. We have documentation for the Forms API hook available here:
https://toolset.com/documentation/programmer-reference/cred-api/#cred_save_data
And the WordPress API hook information is here:
https://developer.wordpress.org/reference/functions/wp_insert_post/
Similar tickets:
https://toolset.com/forums/topic/creating-a-custom-post-type-with-cred-and-user-registration-at-the-same-time/

It sounds like you didn't get the same error I did, where the 'first submission' of an AJAX form threw a validation error on other form embedded on that page and 'didn't AJAX the form.'
Correct, no errors were displayed for me during testing. If you'd like to continue exploring a multi-post form solution involving the PHP API as described above, I will continue to investigate this issue.

#1402077

I've decided to pursue a custom solution to this problem instead of trying to 'shoehorn' Toolset to fit. Thanks for your help!

DB