-
-
Notifications
You must be signed in to change notification settings - Fork 509
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Session tag wildcard method could fails when a conflicting variable exists in the current context #10643
Comments
Also ... It is worth mentioning that trying to access session data using {{ session.variableToShare }} (using a dot) does not work, as "session" is not a variable accessible from the cascade ... unlike this commit title suggests : 1b2567a |
This seems similar to #10612, where the value of the item in context is being passed to the wildcard tag, instead of the plain key. 🤔 You shouldn't need to use
The |
This is going to be confusing, so bear with me. 😅 In this bit: {{ variableToShare = { heavy:processing } }}
{{ session:set :variableToShare="variableToShare" }} Pretend for a moment that In Then over here: {{ myRetrievedVariabled = {session:variableToShare} }} => myRetrievedVariabled is empty, it does not work The shorthand session tag will try to grab the key from the context. So, you have a variable named This behavior where we grab stuff from the context is a bit weird in hindsight, but to "fix" it now would be a breaking change. We can probably get rid of it in v6 though. Then, over here: {{ myRetrievedVariabled = {session:value key="variableToShare"} }} => myRetrievedVariabled is filled, it's ok. You are getting a key of literally What you probably should do is this:
All together it could look like this: {{ nocache }}
{{ variableToShare = {heavy:processing} }}
{{ session:set :foo="variableToShare" }}
{{ /nocache }}
{{ nocache }}
{{ myRetrievedValue = {session:foo} }}
or
{{ myRetrievedValue = {session:value key="foo"} }}
{{ /nocache }} |
It indeed works, but looks more like a workarround to me ;) Would it still be a breaking change if in the "wildcard" method we check first in the session, and if no result, we fallback to lookup in the "context" ? ie something like that ( caution : "hardcore coding" bellow ) ?
If not... maybe add a "warning" in the session doc specifying "carefull, if a variable in the current scope has the same name, it would be returned instead" ? anyway ... Thanks for your previous answer :) |
Yes, it is indeed a workaround. We can fix the core issue in v6, which is coming next year. I think the workaround Jason suggested is fine until then (considering how many people have ran into the issue in the years it's worked like this). |
Bug description
AFAIK Ihe variables created inside {{ nocache tag }} are not accessible to other nocachetag... So my idea was to use the session to share existing data between two {{ nocache tag }} but it seems that fetching data from session can behave inconsistently according to the variable defined in the current scope (context)
ie :
So put simply I could say : if a variable named "xxx" exist in the current context, the tag {{ session:xxx }} would not work as intended (documented).
Moreover, the {{ session:value key="xxx" }} tag method is not documented (source diving helps ;))
How to reproduce
{{ my_var = 'value' }}
{{ session:set my_var="another value" }}
{{ session:my_var }} {# output nothing : it's broken }}
{{ session:value key="my_var" }} {# output "another value" : it's working }}
Logs
No response
Environment
Installation
Fresh statamic/statamic site via CLI
Additional details
No response
The text was updated successfully, but these errors were encountered: