Extend "Set default value via parameter" option

[Enuriru]

It would be nice to add support for {@constant.XXX} and other magic tags for "Set default value via parameter".

[jimtrue]

@Enuriru this is covered with {@get._any_}, see the Special Magic Tags documentation. https://pods.io/docs/build/special-magic-tags/

[Enuriru]

"Set default value via parameter" have to be _any_, not {@get._any_}. Doesn't work this way.
So I'm talking about adding magic tags support for this option.

[jimtrue]

Can you be more specific, @Enuriru? Setting a default parameter makes it a _GET variable and available through that magic tag. What is this not accomplishing for you?

[jamesgol]

I suspect they want to be able to have the default pulled from something other than _GET, like what is listed under the 'Dynamic tags' on that link you posted. So you could use a cookie, WP Option, other arbitrary values.

[Enuriru]

Yes, James is right :)

[jimtrue]

Okay, I'd like to update your description at the top for this issue, because it's not terribly clear as it currently stands. At present, Special Magic tags can only be used in these 4 locations:

Situations Where Special Magic Tags Can Be Used

• In the relationship ‘where’/ ‘having’ options in the field editor
• In the menu icon option for the Pod. See this tutorial for additional info.
• In the ‘where’/ ‘having’ field of Pods shortcodes
• In the ‘Wildcard URL’ option of a Pod Page

You would like the 'Set Default Value via a Parameter' to be able to use one of those dynamic values as it's 'value' based on a Magic Tag. I've always looked at that field as the place you name the parameter that the field will use, but you'd like it to serve double duty. Either take a straight value for the parameter to lookup and provide the value or switch to a magic tag format, so it opens up 'constant, get, user, or any of the other dynamically defined magic tags, right?

[Enuriru]

That's right. I want to build a convenient UI for my users and I need several defaults depend on user roles, site domain, etc. I.e. a have a couple of similar fields almost in every pod. Discussed improvement allows me just to set a couple of constants and use {@constant} instead of javascript hacks to set the fields.

Honestly I can't imagine a case where you use the get parameter for default values :)
Hooking into edit post links or what?...

[jamesgol]

I actually always wondered what usefulness that would have as well. I suspect it was implemented for a specific use case, but it would be better served by something a little more generic. There is some small potential for security abuse with it, but it would required the admin to make some bad choices (ie: sending the output of some user input into a dangerous function like eval)