[Resolved] Forms and Maps Features

[Author]

Posts

[cortJ]

Hi,

We're thinking of shifting some of our forms from Gravity Forms to Toolset Forms, because the Toolset stack has tighter integration with custom fields (Types).

Some of the features we require in forms includes a multipage form and the ability to save and continue. Both of these are inbuilt in Gravity Forms and provide a good user experience especially in forms with many fields.

Multipage: Is there a multipage option coming soon to Toolset Forms? For now, is this (https://toolset.com/forums/topic/multi-page-forms/) the only workaround available?

Save and continue: Is this feature going to come anytime soon to Toolset Forms? Is there a workaround you suggest for that we could use for now?

A few more questions I have are about Toolset Maps. Essentially, what I want is similar to the real estate example (hidden link) but I'm not sure about a couple of things.

I want users to fill a form with their state/country (either using the Address field of Maps or a dropdown selection of state/country), and all entries should appear on one map (using Google Map API) where they can be filtered by Country and State. The restriction is that the country should be either US or Canada. How can I implement this? Will I have to impose the country restrictions using the Google Maps API?

From what I understand, if I want a marker to show on the map the user has to fill the address field in the form, as this field would be the marker source in the view (like the property_location field in the real estate site). Can I choose to have the marker source as a dropdown of country and state instead? I don't see that as an option in the view -- it only shows 'address' fields (screenshot attached).

Another thing I require clarity on is that in the real estate site, the search houses form on hidden link is able to filter using the State and City dropdowns. I've registered for the demo site and am looking into the code on hidden link but it's a bit confusing.

In each house post, how does the city_house field get the city? Is this manually filled on the site for demonstration purposes? I see that editing the address field to New York does not change the city_house field. The search form still shows the house ('Small house for sale) in Virginia even though I moved the address field to New York (screenshot attached). I thought they were automatically mapped but it appears they aren't?

I just want a custom field that's able to extract the state/city from the maps address field that a user inputs, so that this custom field can act as a filter.

Thanks.

[Nigel]

Hi there

You have a few questions here, let me address them individually. We have a one-issue-per-thread policy in the forums, so if we need to continue discussion I may need to split this up into separate topics.

1. multi-part forms
Toolset Forms doesn't explicitly support this, but it can be achieved by chaining together an initial publish post form (which contains the fields required for "page one"), and separate edit forms which edit the newly published post and contain the fields for "page two", "page three" etc.

2. save and continue
If by that you mean that users can partially complete a form, go away, come back and resume where they left off, no there is no specific support for that. Forms either publish or edit content, so you could have a form to publish content, which a user could "save" that would publish the content, and then they could use an edit form for the same post which would be partially filled, depending on how far they got.

3. states and cities and address fields
The real estate reference site doesn't automatically link the address field (used for locating the house on a map) with the city and states used to filter the search, which are not actually custom fields, but in this implementation are custom post types connected in a post relationship to the house and other property post types.

The connections are maintained manually. The site is for illustration purposes and you would want to improve on this solution for a real site.

I would probably extract the state and city from the address object returned by the Google API and save these as custom fields for city and state on the posts, so that you could then use those as search filters.

When you use a Types address field which Google autocompletes, Google returns more than just the formatted text field, but we don't use anything else apart from the lat/lon coordinates, though it is possible to add some custom JS to extract different parts of the address for your own use.

In this linked thread I gave an example of extracting the zip code, while another user added a more generic example to extract all available fields: https://toolset.com/forums/topic/separating-content-from-the-address-field/

[cortJ]

Thanks Nigel.

I'll write only about editing multi-part and single forms here, and create separate tickets for other topics.

Before I ask about chaining multiple forms for a multipage workaround, I'd like to ask about editing a single form We want guest users to fill a form, submit it, and if later they want, they can request to edit it. What I want to know is how do we setup editing for such users who are not logged into WP.

The method I have in mind is for users to share their email address in the original form, and when they fill a request edit form along with what they want to edit, a link is generated and sent to them where they can edit the form.

Does Toolset have any inbuilt capability to support such a method, or parts of it? Or if any other method that you recommend for editing?

The user guide (https://toolset.com/documentation/getting-started-with-toolset/publish-content-from-the-front-end/forms-for-editing/) shows how to add an edit link, which I added in the view which lists all posts in a loop. The access documentation for forms (https://toolset.com/documentation/user-guides/access-control-for-cred-forms/) shows the permission: Edit own custom post with CRED Form "FormName"

I gave this permission for Guests and tried filling a form without logging in. I didn't expect this to work because a guest user doesn't have a fixed ID like a registered user, so I thought it might identify the user with the IP address or a cookie which isn't reliable. I filled two stories from Chrome on Mac and another one from my phone (Chrome on Android); both on different internet connections (therefore different IPs). Both guest users (on two different devices) were able to edit each other's story but not the story filled from a logged-in account. Therefore, this means that "Edit own custom post with CRED Form" will not work with Guests, correct?

Any suggestions on how to build a more reliable and secure way for guest users to edit only their forms? The email request mentioned before comes to mind but I don't know if that will be possible to build around Toolset. Please advise.

Thanks,

[Nigel]

I'm kind of surprised that guest users can edit content, but it turns out in testing that they can, as you have found.

Without being identified by logging in I think it is impossible to limit them to editing only their 'own' content, because in normal WordPress terms we can't know who 'they' are.

So the only option would be to not display the edit links anywhere – except in an email that is sent to them at the time they publish the post.

I haven't tested it, but I would insert the toolset-edit-post-link (that you might otherwise display in the template for single posts, for example) in an email notification sent when the post is published to an email address recorded in the form.

The problem with this is that it is vulnerable to hacking, you just need to append the same URL parameter to any other post to be able to edit it, I don't know if that is likely to be an issue for you.

Otherwise, if you were willing to work on a bespoke solution, when the post is submitted you could record the email address of the guest user that published it (it is saved as a custom field along with the post).

Then display your edit links however you like.

The guest fills in the edit form to update the post, and includes their email.

You then use the form validation hook (https://toolset.com/documentation/programmer-reference/cred-api/#cred_form_validate) and validate the form before accepting the submission, getting the saved email address for the post and comparing it to the email address entered in the edit form, and rejecting if they are not the same.

That looks like a workable solution. You would display edit links to users who can't in fact edit the content, but I don't see any way around that.

[cortJ]

Thanks Nigel for the workarounds.

We are willing to work on a custom solution. Ideally we'd want the user to fill a form to validate their email, and then a customized edit form link (temporary link that expires in 24 hrs or so) to be emailed to the user automatically. I believe this is not possible as a customized edit post link cannot be created; such links have a fixed URL parameter. Please confirm.

We could have a modified version of the second approach you listed. Maybe we could have an edit form request form where a user fills in their email address? Then after validating the email, the appropriate edit form would open:

Clicking on edit link ----> Fill email in edit form request form (form 1) ---> If email validates, display edit post form (form 2)

Is something like this possible using/extending the hooks provided by Toolset? Can we have a custom program between the moment the user clicks on an edit link and before the edit post form is displayed by Toolset? Here, the email validation should take place before the edit form (form 2) is displayed, using the email field provided in form 1.

[Nigel]

Firstly, yes, edit links have a fixed URL parameter, there is no way to implement expiring links.

Once guests have already submitted posts along with their email address (which is stored as a field against the post to determine who 'owns' the post), to later edit that post I understand your suggestion as

- they submit their email address in a request form
- they get emailed the edit link to their post, if such exists
- clicking the link takes them to a form to edit the post

So the request form would include a notification which sends the email with the link.

There are two API hooks where you can intervene with the notifications, namely cred_mail_headers and cred_notification_recipients, which both do similar things inasmuch as they let you modify who the email is addressed to, but neither lets you modify the content of the email.

I think the most useful information for you is that shortcodes included in the notification body are parsed.

So you could create a custom shortcode which looks up the post belonging to the requester based on their email and builds the link to edit the post, which is simply the post URL plus the parameter specifying the template which contains the edit form, e.g.

site.com/thing/some-thing/?content-template-id=99

The problem with this is that the parameter is the same for all posts, so if you know the URLs of other posts you can edit any post by appending the same parameter manually.

Which means you may need server-side validation using the cred_form_validate hook I described before.

[cortJ]

Thanks Nigel.

Yes, the cred_form_validate hook will be required. In addition to comparing the email entered in the form with the stored email, we'd like to send a verification code to the email and have the user enter it. I don't think services like this one (https://wordpress.org/plugins/miniorange-otp-verification/) integrate with Toolset Forms; they do with many others. Can you recommend any services, if any, that can integrate with Toolset Forms to provide email verification using a code (OTP)?

If there aren't any, we'll have to build a custom program for it, and probably test if it'll work with the hook or not. After submitting the form, another field should appear where the user enters the OTP and on successful input the edit form should submit successfully. Maybe we'll need a multi form workaround, or perhaps some conditional logic might work in the same form for the extra OTP field.

[Nigel]

I looked at your OTP link and it, together with the other solutions I found, it seems to be designed to work with user registration pages, and you don't want users to register.

(Toolset Forms custom registration is built on top of standard WordPress registration functions, so I see no reason why it couldn't work with such plugins for registration.)

Sorry, I don't have any recommendations for how to set up a OTP service for your workflow.

[cortJ]

I'd like to request deletion of the screenshots in the first post as they have some personal information we don't want to make public. Also would like to delete the hidden link link in the first post. It was after this post we realized that the support tickets are public.

I don't see a way to edit the first post, and also don't see a way to contact you in private about this request. Which is why I'm writing about this here. Please delete this message as well after processing the request. Thanks.

[Nigel]

I deleted the photos.

If you visit the forum post when not logged in you will see that external links (apart from a handful of whitelisted sites like Stack Overflow, WordPress documentation etc.) are hidden, and can only be seen by the original poster and support.

[cortJ]

Thanks.

I'll work on a custom solution for OTP and hope it works well for us.