Skip Navigation

[Resolved] 3 user forms to property listing, qualification, schedule? (Part 2)

This support ticket is created 4 years, 1 month 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
- 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 -
- 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 -

Supporter timezone: Europe/London (GMT+00:00)

This topic contains 27 replies, has 2 voices.

Last updated by Nigel 3 years, 12 months ago.

Assisted by: Nigel.

Author
Posts
#1526063
D47CE5B5-CE84-4D25-8922-CF80879EFD15.jpeg
09434665-D042-4825-B819-A5F6629DB41F.jpeg
BEF37D67-4066-4A4B-B1E8-48F30C19BD1C.jpeg

Hi Toolset team. Circling back on an earlier/closed technical issue concerning a similar workflow that connects 3 forms to a new user registration. I tried updating the prior ticket, but it won’t let me add to so I’m linking to it below. The issue remains unresolved, I’ve since migrated my Toolset configuration to a new server, but am still stuck in the logistics of the solution described above.

Original Support Case:
https://toolset.com/forums/topic/3-user-forms-to-property-listing-qualification-schedule

Specifically, is the workflow described by Luo below simply setting form settings to “display the post,” embedding that form into a page, and having that page configured with both the form and view that shows qualifications post types filtered by the current author?

Since these are new users to the site that I am trying to have step through three different pages/forms for Qualifications -> Property -> Schedule, it seems more appropriate to use the example workflow outlined for connecting one post type to another through the user post author, as you guys have outlined below. Is this correct?

https://toolset.com/documentation/post-relationships/how-to-create-custom-searches-and-relationships-for-users/

I have attached screenshots below of the current form, page, and view settings I have configured to accomplish this workflow. Thanks in advance for your continued support.

Cliff


1) After user submit the "qualification form", redirect the user to the single "qualification" he just created,

2) In the single "qualification" post, display below:

a) Post view, list "property" posts created by current user:
https://toolset.com/documentation/user-guides/filtering-views-query-by-author/

b) Toolset form for creating "property" post

3) Same as above, in a single "property" post, display the "schedule" posts list and a form for creating "schedule" post

#1526983

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

Hi Cliff

I don't want to make and recommendations or comments until I've understood what you are aiming to do.

Am I right in thinking that you want a basic workflow that sees users register, then proceed to a form to publish a Qualifications post, then to a form to publish a Property post, then to a form to publish a Schedule post?

The user would be the author of each of these posts.

Do you need some other way to connect these posts? Would a user ever be able to publish more than one of any of these post types?

In which case the author field wouldn't be sufficient to tie the Qualification, Property, and Schedule posts together, and you would likely need post relationships to connect them, either one-to-one relationships if that made sense, or perhaps one-to-many relationships if, for example, more than one Property post could be linked to a single Qualification post.

In which case it sounds like your workflow would be

- user registration, leads to
- publish Qualification, leads to
- publish child Property, leads to
- publish child Schedule

Is that the objective here?

#1531317
02CA4D1F-AA56-4C8B-974A-3619118F3EFF.jpeg
8DAD1EC9-67BD-4160-82C1-7FC7C3AD1A80.jpeg

Hi Nigel,

Thanks for responding. Yes, you are correct. However thinking through the workflow in context of parent-child relationships and think it would need to be:

User registration leads to:
Publish Property leads to:
Publish Qualification leads to:
Publish Schedule

After this is complete I would need to present the user with the link to their property page/view which shows the property details and includes a link for renters to apply to the property, validating with each form of their own that they meet the Qualifications defined by the property owner.

In advance of reaching out for support, I have already created relationships between Properties, Owners, Qualifications, and Schedules, which also do appear to show up in the WordPress dashboard when adding a new property manually. So I’d basically like to duplicate that on the front end through a user-friend form.

Let me know if this make sense. I’ve attached screenshots below.

Cliff

#1531755

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

Are you sure your relationships are right?

There is a one-to-many relationship between qualifications (parent) and property (child).

That means several properties can each be children of the same qualification.

Then there is a one-to-one relationship between properties and schedules. So any one property can only be connected to a single schedule, and a schedule can only be connected to that same property.

Toolset Forms are geared up for adding child posts to parents, but in your description you'll be doing the opposite, creating the child post (a property) before publishing the parent post, so that will require some more creative thinking.

#1532819
067E9232-5C60-46FB-96B7-2D20ADE5B6B2.jpeg

Hi Nigel. Yes, the relationships are correct since the intent is (ultimately) to have owners create a series of both qualifications and properties that they can reuse and interconnect.

For example: a relaxed qualification for a slower-renting property versus a stricter qualification for a property in greater demand.

In that case Owners that are created through the User Registration step would (I assume) be their own custom post type as the top-level parent, which is allowed to create multiple properties, multiple qualifications, and multiple schedules, each related back to the top level Owner, with some way to ensure that when a specific Owner is creating a new Property, that it is linked/related to a specific Schedule and Qualification.

So:

User Registration -> Owner Form -> Property Form -> Qualification Form -> Schedule Form

Does this make more sense?
In that workflow, can the Owner post type still be the parent of all the owner post types?

As I mentioned at the start, I’m still struggling with understanding exactly how to ensure one form (on submission) includes the right configuration to bump the user to the next/child form, while still showing the data they just entered in for their form. In other words, is the Property Form embedded into a View, Template, or Page?

#1532831

I should also point out that the core structure of how the different custom post types interact is quite similar to the Toolset Real Estate configuration (https://toolset.com/home/toolset-real-estate).

Previously, I had tried to start with that template and simply modify it to suit my needs. However since I don’t a variety of the different post types, the relationships between them got too distracting and I thought it would be easier to simply start from scratch versus modify the existing template.

Open to revisiting that option, if you think it would be easier to build from that and simply remove the post types, views, and pages that I would not require.

#1535665

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

I feel like a little clarification is still required before I get down to implementation.

...the intent is (ultimately) to have owners create a series of both qualifications and properties that they can reuse and interconnect

Okay, it makes sense that a property can only ever belong to one qualification post (a property can only have one qualification at a time, while the same qualification may apply to several properties).

But property and schedule should be a one-to-one relationship?

If I own 5 apartments in the same block they might all operate with the same schedule, but a one-to-one relationship doesn't allow for that, you would have to publish 5 schedule posts to connect to the 5 apartments (even if their content was identical).

So, maybe schedule << property should also be a one-to-many relationship?

You've added an 'owner' post type into the mix. You may want to create such a post type to expand the user profile, but I think it should be sufficient that the user will be the author of each of the property, schedule, and qualification posts to "connect" them, unless you know otherwise.

Also, regarding your workflow, you seem to be looking solely at what happens when the user registers, even though you suggest that they may be subsequently adding more content (e.g. properties and qualifications) on later visits and changing which posts are connected to which etc. And what if your user were to register, start the workflow you describe, but abandon it midway through and then return a couple of days later, how would that work?

It seems to me like you may want a dashboard kind of page, where users can add new properties, new qualifications etc., and connect such existing posts. Such a page would use Views to display links to existing properties, or links to edit them, or links to create new ones etc., and is where they would be first directed upon registration.

Your thoughts on something like that before I proceed?

#1541161

Hi Nigel,

Appreciate the detailed Q&A. Some additional context/explanation of goals and objectives:

Q: you seem to be looking solely at what happens when the user registers, even though you suggest that they may be subsequently adding more content (e.g. properties and qualifications) on later visits and changing which posts are connected to which etc. And what if your user were to register, start the workflow you describe, but abandon it midway through and then return a couple of days later, how would that work?

A: What I am trying to do is balance the needs of both the initial user sign-up (which would ideally include access to create only 1 property, 1 Qualification, and 1 schedule) versus a paid dashboard that would allow access to X properties/schedules/qualifications, similar to what we would expect to see in a larger property management company that owns multiple buildings and has several leasing agents working for them.

That last part is where I have been struggling to determine the best Toolset approach since the initial user sign-up / top level parent relationship may actually be a COMPANY that employs multiple AGENTS each with their own SCHEDULE and linked either 1:many or many-many to several PROPERTIES.

Q: So, maybe schedule << property should also be a one-to-many relationship?

A: The way I envisioned the schedules working was to have template schedules that could be simply selected from a list (say Mon-Fri 9-5 vs Sat-Sun 9-5) but allow users to also create their own, custom schedule and apply to each property they’re leasing. So I’m not against the idea of one schedule applying to multiple properties, but would that mean that users would have to create a schedule BEFORE they can create their property given the parent-child relationship discussed earlier?

Q: It seems to me like you may want a dashboard kind of page, where users can add new properties, new qualifications etc., and connect such existing posts. Such a page would use Views to display links to existing properties, or links to edit them, or links to create new ones etc., and is where they would be first directed upon registration.

A: Ultimately yes, and I’m not at all against a dashboard approach, just concerned about overwhelming the user by dumping them into a dashboard with too many options. In fact, before going down the Toolset forms route I had investigated options for customizing the WordPress dashboard and found most of the out of the box solutions to be pretty limited. Hence the need to create a front-end form-based workflow to replace a custom WordPress dashboard.

As posted my February 28th reply, I am aware I could also have links to create new qualifications/schedules/etc right alongside the standard new Property form, but had wanted to control the order of each form submission to ensure they’re understanding the importance of defining property, qualifications, and availability/schedules.

Additionally, once this owner side is done, I’ll also need to build out the equivalent renter side forms including the same fields owners are defining for qualifications: such that potential renters click through the Property View page and are prompted to completely their own Qualifications form, that is then compared to the Property’s Qualifications entry prior the scheduling of an appointment.

Assuming that’s an entire other support request so I’ve left it out for now, but mention here as context of where I’m ultimately looking to go with the design.

Does that help?

#1542323

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

When I talked about a dashboard, I mean a front-end "dashboard" page of your own design rather than the backend dashboard.

With schedules, I think you are going to need to be able to re-use the same schedule post with different properties and it makes sense to set it up that way at the outset rather than wrestle with converting it later.

Anyway, let's go through what's involved in this workflow:

1. register
2. publish property
3. publish qualification (linked to property)
4. publish schedule (linked to property)

1. register
You'll have a page with a user registration form.

You are going to need to auto-login the user if they are to proceed with this workflow without the distraction of using a log-in form after registration.

See this page for an example of what's required: hidden link

The form settings will be to redirect to the page with your publish property form.

2. publish property
The newly registered and logged-in user will be the post author of the resulting published property.

The form needs to redirect to the next page in the chain.

But we need to pass the ID of the property so that the qualification post can be attached to the property post.

To do that you'll need to intercept the form as it is being redirected, using the cred_success_redirect filter: https://toolset.com/documentation/programmer-reference/cred-api/#cred_success_redirect

You'll need to append a URL parameter with the property post ID to the $url argument.

3. publish qualification (linked to property)
This is a parent post, so the form itself can't include a field for the child post ID.

The form will need to redirect to the next page in the chain.

You will again need to use the cred_success_redirect hook, but this time it will have a little more work to do.

You will first connect this qualification post to the property post (you should be able to retrieve the URL parameter value for it using the global $_GET object), using the API function toolset_connect_posts (https://toolset.com/documentation/customizing-sites-using-php/post-relationships-api/#toolset_connect_posts).

Then add the property ID as a URL parameter again the same way because it will also be needed in the final step.

4. publish schedule (linked to property)
This time you are essentially repeating the 3rd step, without the need to pass on the property ID again with any redirect.

You'll still need to use the toolset_connect_posts function in the same way to connect the schedule and property posts.

#1543291

Appreciate the detailed breakout Nigel. Are there instructions or a video on how to use the code in the Programmers' Reference that you have above for the success redirect or is the assumption that I already know PHP and can make sense of the code snippets? Frankly, I'm not even sure where to put the code to intercept the form and the documentation at https://toolset.com/documentation is higher level than the specific implementation of the programmer's reference.

Absent that, I suspect I'll need to employ one of the developers in the contractors section of the site, since I have no formal training in PHP, which was the reason for looking into Toolset at the start.

#1544585

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

"I have no formal training in PHP, which was the reason for looking into Toolset at the start."

To be fair, it's only really an issue because the workflows you envisage are the opposite of the expected use, i.e. publishing child posts before parent posts.

Using Projects << Tasks as an example of a one-to-many relationship, you would typically publish Projects, then add Tasks to the project posts, whereas your workflow is more like publish Tasks, then publish Projects attached to a task post.

Hence why this is more complex than you may have expected.

We don't realy have additional documentation other than the API docs I already shared.

But I am happy to walk you through what's required if you are stuck on something.

We can take it one step at a time.

See if you can make a start with the above, and then ask me specifically about something you are stuck on, and we'll see if we can iterate to a solution.

#1545163

Well I got past step #1 of adding the auto-login function, since the instructions basically told me exactly where to put the code snippet.

For step #2, I'm unclear on where I would put the example code provided in the programmer's reference, which I've modified below with with the post ID of the property submission form, since that's form ID 14.

My question is, where does that code actually get inserted? My instinct was that I would insert that into the actual Post Form Editor by the Submit button, but that appears to be just HTML shortcodes that are calling Toolset fields, is that right?

For example:

[cred_field field='form_submit' value='Submit' urlparam='' class='btn btn-primary btn-lg' output='bootstrap']

//This filter can also be applied for a specific form, using the form ID:
add_filter('cred_success_redirect_14', 'custom_redirect_for_form_with_id_14', 10, 3);
function custom_redirect_for_form_with_id_14( $url, $post_id, $form_data )
{   
    $newurl = '<em><u>hidden link</u></em>';
    return $newurl;
}

[/credform]
#1545193
Screenshot 2020-03-09 at 10.43.40 PM.png

Also: you mentioned that the reason that we must use the custom code calls is that we're creating child posts before parents. This implies a change in order of post creation could simplify the workflow. Am I correct in assuming that any post type that can have multiple others connected to is the parent? If so, based on both Qualifications and Schedules being 1:many to Properties, would creating those post types first (as parents to Properties) streamline the workflow above?

Moreover, if both Schedules and Qualifications are 1:many to Properties, I assume that means Properties is a child to two different parents posts types?

#1545265

PPS: I went back to the Snippets plugin where I added the auto user login and tried dropping the following code there to see if it would redirect, only to discover there's no way to know since the form settings are already set to redirect so how would if the code's working of the form settings are the one forcing the form to redirect.

In any case, spent two hours trying to make sense of the example code, with no apparent success since all I get when the forms redirect is something like this, which is not what we're looking for:

<em><u>hidden link</u></em>

In any case, here's what I pasted into Snippets plugin, intentionally making the URL different than the second to try and determine which one it's supposed to act on, which was neither:

add_filter('cred_success_redirect', 'custom_redirect',10,3);
function custom_redirect($url, $post_id, $form_data)
{
    if ($form_data['id']==14)
        return '<em><u>hidden link</u></em>?';
   
    return $url;
}
 
//This filter can also be applied for a specific form, using the form ID:
add_filter('cred_success_redirect_14', 'custom_redirect_for_form_with_id_14', 10, 3);
function custom_redirect_for_form_with_id_14( $url, $post_id, $form_data )
{   
    $newurl = '<em><u>hidden link</u></em>';
    return $newurl;
}
#1545865

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

You can add custom snippets of PHP in Toolset > Settings > Custom Code (no need for a separate plugin).

The form in step 2 needs to be set to redirect to the page that contains the form for step 3.

You can then use the cred_success_redirect filter to modify the URL being redirected to (replace it with something else or change it).

The form settings must be set to redirect somewhere after the form is submitted, otherwise the filter to modify the redirect URL will never get triggered, and in this case we want it to redirect to the page for the next step, but we are going to use the filter to add a URL parameter that specifies the ID of the post just published so that our next form can connect it.

function ts_redirect_forms( $url, $post_id, $form_data ){

    if ( $form_data['id'] == 14 ){
        // code for form in Step 2
        // Append URL parameter with post ID to redirect URL
        $url .= '?id='.$post_id;
    }

    return $url;
}
add_filter( 'cred_success_redirect', 'ts_redirect_forms', 10, 3 );

If the form in step 2 has an ID of 14 then you shouldn't need to change that.

Now when you submit the form it should redirect to the intended page, but the URL should have added an id parameter, something like site.com/target-page/?id=123

Does that work? Then we can move on.

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.