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

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.

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?

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.

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]

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;
}