AxeWP/wp-graphql-gravity-forms

Confirmation Page Redirect to Return slug or URL

robmarshall opened this issue · 4 comments

robmarshall commented

What problem does this address?

Currently the query returns a pageId when a confirmation is set to a "Page" redirect. This makes sense on a WordPress side as it is possible to use WordPress functions to take this and convert into a URL. Good old PHP.

However, on the static site side (Gatsby etc) we have no understanding of an ID. It would be good to have a URL passed in the same was as "Redirect" does.

Thanks!

What is your proposed solution?

The URL key within the confirmation object to hold the URL of the page that the user wants to redirect to.

What alternatives have you considered?

No response

Additional Context

No response

justlevine commented

Hey @robmarshall ,

So the new SubmissionConfirmation type on the submit mutation response provides a type: MESSAGE|REDIRECT, message: ?string and url: ?string, as per the information returned from GFAPI::submit_form(). That latter will return the fully qualified url for either a page or redirect form confirmation type.

Are you seeing something different?

robmarshall commented

@justlevine I do get that. However the confirmation object that can be queried before submission contains far more information. Conditionals etc. In my mind (and please disagree) it makes sense to have the page URL included here as well.

What are your thoughts?

  • 👍1
justlevine commented

Thanks for clarifying.

I'm not sure how comfortable I am with this. SubmissionConfirmation.url contains the fully-qualified URL - including the query parameters which can only have their merge tags replaced with data from the actual entry.

We could mock GFFormDisplay::get_confirmation_url() to resolve FormConfirmation.url. If so, the result would be different that that supplied by SubmissionConfirmation. Options (as I see them) are

  • We don't add the query params to the URL
  • We build the URL using the query param placeholders.

Either IMO makes for confusing DX by differing from the expected result from SubmissionConfirmation, and I'm not sure what we gain by it. (Prefetching maybe?)

I think a good middle-ground would be to add a connection to the Page object (like we did in #272), since confirmations[0].page.node.permalink makes it pretty clear that there's no expectation for the query params to be included.

If you've got use cases for using a FormConfirmation.url over a SubmissionConfirmation.url, where a FormConfirmationToPageConnection comes up short, please share - I'm happy to reconsider :-)

robmarshall commented

A connection may well do the job. As long as the URL for the pageId is included in the same object I think we are set!

  • 👍1