Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Author unclhos

    (@unclhos)

    Sounds like you should use the option to clear on submit. But I’ll look into changing priorities.

    Thread Starter psteinweber

    (@psteinweber)

    Thanks for the quick reply!

    I don’t think clearing on submit would do my use case any good.
    It would be great to be able to only clear the one (dynamically populated) field. Just an idea…!

    fried_eggz

    (@fried_eggz)

    This should be possible by comparing the keys in the query string to the keys saved in options and let query string take precedence

    Any more news on this issue? I’m having the same problem. not sure how to change the keys to let the query string take precedence?

    Any more news on this issue? I’m having the same problem. This way the dynamic populated fields option isn’t working and therefor useless.
    Love to get an update on this.

    I fixed it myself.
    Hopefully this gets added to the plugin.

    https://codeshare.io/TvhoH

    The problem was the plugin didn’t do anything with the inputName variable. This is the variable GF uses for population.

    Have fun with it! ??

    Plugin Author unclhos

    (@unclhos)

    Thanks for the code. Just recently looking back at this plugin after a long programming break. The problem with using your code as is the query variable would always take precedent. I didn’t want that to happen, as if there was already saved data (which I check for), means the user has started to fill the form out before. I will need to add in a priority system, or drop down and warning for different input values. The thinking is if someone used a link to get to the form, the field might change every time (timestamp or something), and they might try to use that same link to find the form again (I know I would).

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Data persistence and query strings’ is closed to new replies.