Resetting/Clearing U-Tags

Richard Murphy · August 2020

Anyone know of a way to consistently reset/clear U-Tags? I've got an event template that is heavily dependent on U-Tags for setting session variables. The template is shared across many events and what typically happens going from one event to another is that wires get crossed and even though the U-Tags are technically being overwritten with new values the S80 tags which render the values are cached. Or is there a better placement in the wrapper/page to put U-Tags? I don't know that placement would make any different as I assume they're processed before the page is loaded but thought it was worth asking.

Also as a PSA it appears the max amount of U-Tags that can be set/called is 50 on an entire page load. Likely that is more than anyone would need but I did hit that ceiling. There didn't appear to be any warning/error/info that the limit was hit on the page as a comment or in the console but the Calendar Event just didn't work properly until I removed some of the U-Tags to go under that threshold. With a nice round number like 50 I can only assume that it is by design.

Let me know if any of this is unclear or if you have questions. Happy to provide any more information I can.

Thanks!

Brian Mucha · August 2020

They are rendered before the page loads, but then so is the S80 tag. So the location doesn't matter, but the order on the page does. You have to set the session variable higher in the DOM than where you consume them. So it's easiest to set them as soon as you can. At the top of the page wrapper if possible.

The U tags also don't all evaluate before the S80 tags render, so the same variable can have more then one value on a page.

<body>
[[U0:FOO=bar]]
[[S80:FOO]] < -- Renders bar

...stuff...
[[U0:FOO= thud ]]
[[S80:FOO]] < -- Renders thud

</body>

BPM

Jeremy Reynolds · August 2020

Brings up a good point, though. What if you don't know what tags are currently in use after a user moves from one event to another? I suppose one could always create a "reset" reusable that sets every possible variation to blank (yuck). Even then, it's tough to track down every little reusable that might have added an obscure U0 to the mix.

Besides that, setting [[U0:foo=]] doesn't actually remove [[S80:foo]], it just sets it to blank, right? Knowing things get wonky if you get too many S80's defined, it'd be good to be able to just nuke all of em.

Richard Murphy · August 2020

Brian Mucha:

They are rendered before the page loads, but then so is the S80 tag. So the location doesn't matter, but the order on the page does. You have to set the session variable higher in the DOM than where you consume them. So it's easiest to set them as soon as you can. At the top of the page wrapper if possible.

The U tags also don't all evaluate before the S80 tags render, so the same variable can have more then one value on a page.

<body>
[[U0:FOO=bar]]
[[S80:FOO]] < -- Renders bar

...stuff...
[[U0:FOO= thud ]]
[[S80:FOO]] < -- Renders thud

</body>

BPM

Thanks for the reply, Brian! I agree in theory that's how this would work but it doesn't in practice always.

So here are two examples of my customized Calendar Events (ticketed) in LO:

Example #1: http://act.autismspeaks.org/site/Calendar?id=103723&view=Detail

Example #2: http://act.autismspeaks.org/site/Calendar?id=103843&view=Detail

They both use the same wrapper and utilize a config file which is a reusable page that is called in by the wrapper dynamically using either the &id= parameter in the URL or a stored session variable called currentEventId.

If I open them both up in an Incognito window in separate tabs they work fine. But while both have been opened, refreshing one or the other the information I've set in the config file (or in this case the currentEventId) of one will bleed over to the other. Similar to how wrappers sometimes can do this while you're working on them in LO.

I think it all stems from currentEventId, which is set in the HEAD using:

[[?xxnullx::x[[S334:id]]x::::

[[U0:currentEventId=[[S334:id]]]]

]]

The call that is then used to bring in the config reusable pages (which has S80:currentEventId (brackets included just wasn't sure if this system would allow them) appended to the end of the name) is bringing in the wrong config file. Since the ID is incorrect, the API is bringing in incorrect information as well. I would lean completely on S334:id if possible but when you error on a ticketing form or throughout the process it's possible the resulting URL won't have ID any longer.

So I guess after thinking about it... it's less about clearing out the U-tags necessarily and more about why would the code above not re-write currentEventId when there is an &id= in the URL. It's simply not working as I expected it to be.

Everything is called in via the HEAD includes in the wrapper. Here is the code:

[[S51:reus_wrpr_2161_head]]

[[E51:special_event_config_[[S80:currentEventId]]]]

[[S51:reus_wrpr_2161_meta]]

First reus_wrpr_2161_head which includes the currentEventId setter as seen above. Then I load in the config file based off of currentEventId. I have also tried putting the config file include inside of reus_wrpr_2161_head at the very bottom. Same results. HEAD is loaded first, correct?

Maybe I'm overlooking something simple, I'm not sure. Just seems like it's solid in my eyes.

I also agree with Jeremy, it would be great if there was a way to reset S80's globally instead of needing resets.

Thanks so much for the help and taking a look!

Brian Mucha · August 2020

> one will bleed over to the other.

That's because these are session variables. They are stored in the user's session, which exists across both pages for as long as the user's session is active. The last one set will be the state of that variable going forward. It does seem like refreshing either page should cause that page to overwrite your variable though.

I'd try to simplify everything and test. Get rid of the reusables and have two Pagebuilder pages that only set and display a variable.

Page 1
[[U0:FOO=bar]]
[[S80:FOO]]

Page 2
[[U0:FOO= thud]]
[[S80:FOO]]

Does this get confused in the same way?

Clearing unknown session vars could be done by ending the user's session. I think they way to do that would be to delete the user's session cookie.

BPM

Jeremy Reynolds · August 2020

Richard Murphy:

First reus_wrpr_2161_head which includes the currentEventId setter as seen above. Then I load in the config file based off of currentEventId. I have also tried putting the config file include inside of reus_wrpr_2161_head at the very bottom. Same results. HEAD is loaded first, correct?

Maybe I'm overlooking something simple, I'm not sure. Just seems like it's solid in my eyes.

Do you have a lot of session variables in play? I've seen stuff like this pop up when I'm getting too many set. Not sure whether the system is defining each S80 in a first-in-first-out way (and dropping the event ID because it was created early on), or if the system just starts ignoring U tags after reaching a certain number. Either way the effect is the same: if it decides your currentEventId is off the list, most other stuff is hosed too. I've even edited the page wrapper to have the S80 as the last line in HEAD and first line in body, and seen the final render give two different results.

If you suspect you're running out of vars, one potential workaround would be to use S51 instead of S80 to try and reduce how many you're creating. Set a cookie or something and then make the reusable into a conditional that first checks S334 and falls back to S50 to read a cookie. You could even add in any other tags that could return something, such as S120.

Resetting/Clearing U-Tags

Comments

Categories