Pre and Post hooks run in unintuitive order on non-redirect submit

[jcdm]

When I have a form which submits and doesn't redirect, the page is reloaded with the rebuilt form, but the preHooks for the form are run BEFORE the hooks for the submission.

This seems unintuitive to me - I'd expect to be able to have the hooks operate on the data and then use the preHooks to possibly manipulate that data further.

My use case was that I wanted to erase the form on a successful submit, but just save a running total for one field. I was doing this by setting a $_SESSION in a hook, but was then finding that the preHooks were unable to pick this up until after a subsequent page load (when the session variable had actually been set).

There may forms that rely on this order now, but if it's not too difficult to have them run in reversed order, maybe a system setting to allow the developer to choose would be a help.

[matdave]

Just as a chime in statement, I generally try to leave submittable variables to JUST be operated on by post-hooks. I try to save pre-hooks for form manipulation (e.g. setting options, adding fields), and not data manipulation. Setting one side as the primary handler prevents "dirty data" like this.

[isaacniebeling]

I'm running into this as well. Basically, the prehook loads a user's preference data, then they change it, and the posthook saves it to the user's account. But since there's no redirect, the prehook ends up firing before the posthook, which means it loads up the wrong data.

[isaacniebeling]

FWIW, I solved it by redirecting to [[*id]]... basically, it's redirecting to itself, but that causes it to fire the hooks in the right order. /shrug

[jcdm]

Great solution 👍🏻

On 1 Dec 2017, at 8:54 am, Isaac Niebeling notifications@github.com wrote:

FWIW, I solved it by redirecting to [[*id]]... basically, it's redirecting to itself, but that causes it to fire the hooks in the right order. /shrug

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[isaacniebeling]

Well... maybe not great, but functional 😆

[jcdm]

It's cleaner than modifying the pre code to look for submission variables and then not run which was my work around at the time. ᐧ

On 1 December 2017 at 09:05, Isaac Niebeling notifications@github.com wrote:

Well... maybe not great, but functional 😆

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Sterc/FormIt/issues/85#issuecomment-348343417, or mute the thread https://github.com/notifications/unsubscribe-auth/ACD3yXprDk597hPrN_9mgKQSJl3ih_Uoks5s7y3IgaJpZM4H0n4Y .

-- Joshua Curtis Digital Media 0403 312 267

[isaacniebeling]

I suppose that's true :D

[devlanda]

The preHook property is meant for hooks like e.g. FormItLoadSavedForm. I will close this issue.