Rock Spontaneously Displays Wrong Theme

[JimMichael]

Description

This is a weird one that I have now seen reports on at least three times, and I've seen it myself on demo.... so I'm finally opening an issue for it. The issue is that you visit a Rock site and see the correct content, but with the wrong theme. If you then observe the site settings, you can see the correct theme being used, but the files are coming from the wrong theme directory.

Steps to Reproduce

Unknown steps to reproduce. It seems to happen randomly and spontaneously on various people's instances.

Expected behavior:

Rock would always use the files from the correct theme.

Actual behavior:

It sometimes/somehow uses files from the wrong theme, or at least indicates that when you look at the site settings and view the site itself. Here are some threads in chat where this has been reported:

"I'm noticing something odd on demo server" -> https://chat.rockrms.com/group/rock-stars?msg=q2kzykiJdEB9StKGN

"I've got an interesting issue..." -> https://chat.rockrms.com/channel/troubleshooting?msg=LPMbNQ3Jo3wgKzLe5

"I just had something really strange happen..." -> https://chat.rockrms.com/group/rock-stars?msg=FMGBZtrRbLsbxu7Ah

"I have the Stark theme..." -> https://chat.rockrms.com/channel/troubleshooting?msg=ANLYzeJhwKypki3b9

At this point it's not reproducible (that I know of) but it's happening often enough to indicate some underlying problem that was probably introduced in v10.

Versions

10.x-11.0

┆Attachments: chrome_DHYeLPtbGv.png

[JimMichael]

At least one person has reported that adding the ?Theme=[correct theme] to the URL fixes it (even when you subsequently remove that from the querystring) and I had observed that when it was happening on demo for me, opening the same site on a incognito window showed the correct site... so maybe it's a cookie issue?

[mikedotmundy]

Thanks @JimMichael for addressing this issue. I will add this: by adding ?Theme=[correct theme] to the url fixed the issue for me. As soon as I did this, it fixed the page instantly, and then on page/116 the layout files were updated to the correct file path.

However, now I am seeing the exact same issue again. If I go to page/116, edit the external site, change the Theme to a different one, the layout file paths stay with the other theme.

I am seeing this on my dev server running v11. I went from v10.3 to v11 a few days after beta testing for v11 was released. Not sure if there is any further testing I can do to help with this since I am currently seeing the issue.

I will be bringing my dev server back to v10.3 this weekend so I can test upgrading to v11 once more. (Will be bringing my production site to v11 next week as we REALLY need mobile check in for next weekend when we launch kids ministry.)

[tstephens17]

Just wanted to add that we updated our dev server from 10.2 to 11 and I did not see this problem with our sites and the file paths changing like pictured above.

[nairdo]

@JimMichael @mikedotmundy , @tstephens17 I just wanted to add a bit of information since not everyone is aware of this behavior... (and Jim's right, it could be the cookie)

It's not advisable to manually pass in the theme through the query string -- because if you do Rock will do the following:

1. Write that to a cookie (as seen here)
2. Use that cookie to determine which theme to use each time you view a page (as seen here; if no cookie is found it returns the site's ConfiguredTheme).

(A telltale sign is seeing the lower case "rock" in the screenshot. That leads me to believe some theme= passing was performed.)

However, this behavior is important and used by the check-in system to create semi-permanent theme changes for check-in kiosks configured dynamically.

If you think some form of passing in a theme parameter was used prior to seeing this problem (perhaps you were testing the 'contactless/mobile check-in' from the same browser?) I would perhaps suggest closing this issue. But if you are positive you/they had not manually passed in a theme parameter, then let's leave this open until someone comes up with a sequence of reproduction steps.

[mikedotmundy]

@nairdo I did load /mobilecheckin from the same browser when I was setting everything up for mobile checkin. However, I did NOT manually pass a theme parameter by changing the url (if thats what you were explaining above). I did that only after already seeing the issue - I had a theme I had created selected, but all the paths showed /checkinelectric/.

I am doing a fresh install currently and will test this - without doing anything to the query string.

[nairdo]

I did load /mobilecheckin from the same browser when I was setting everything up for mobile checkin. However, I did NOT manually pass...

@mikedotmundy You don't have to do anything, because the mobile check-in block does it. So, that definitely explains your situation.

[mikedotmundy]

@nairdo Sorry, but I am not sure I am fully understanding? So the mobile check-in block intentionally sets a cookie on the device that will always make it pull up the theme from when the cookie was first set?

If so, I have 2 questions. 1) Should I never pull up the mobile check-in block on my computer in order to keep it from changing the theme? 2) If I ever want to change the theme, will it actually not change on peoples devices?

Sorry, I don't fully understand how to read C# to see what the code is doing to the cookies. I just want to make sure that I set it up the proper way - I am setting it up on my prod site in the next few days.

Thank you!

[tstephens17]

@nairdo to clarify, I never experienced the issue. I just was checking to see if my system reproduced what was posted in Rocket Chat where the file paths for the theme seemed to be incorrect after updating to v11. My system from 10.2 -> 11 looked fine.

[JimMichael]

I have never witnessed this on my own system. I only saw it on demo when visiting (per one of the links I provided in original issue) so I shouldn’t have had “the cookie” for the public theme, yet when I logged into demo I got the wrong theme for the internal site. If that could have been a consequence of someone else forcing a theme in the querystring, then that could explain it.

I only opened this issue because of the multiple reports and then seeing it myself (and I 100% did not force theme in querystring) on demo.

[nairdo]

So the mobile check-in block intentionally sets a cookie on the device that will always make it pull up the theme from when the cookie was first set?

Yes. This is done so that the subsequent pages (which are likely defined on another Rock "site") don't change to match that site's theme. This is also what allows you to configure Rock kiosks to have/use different themes.

If so, I have 2 questions. 1) Should I never pull up the mobile check-in block on my computer in order to keep it from changing the theme? 2) If I ever want to change the theme, will it actually not change on peoples devices?

1. Yes, although it would only effect you. But if you ever do, you can use a cookie editor to delete the Site:<#>:theme cookie (or clear all cookies for the website):
2. If you change the theme on the Mobile Check-in block's settings, it will force set (?theme=) the theme for everyone -- so yes, it will take effect for the person viewing the mobile check-in block.

[mikedotmundy]

Makes sense @nairdo. Thanks for taking the time to explain this to me!

[hbcpn]

I just experienced this while helping another church with their Rock site which is running v10.2. I was running Chrome at the time. I did not use the forced theme querystring at any point. It happened while I was in the middle of editing a page on the site and another team was fixing the SSL cert. I noticed the cert change happened so I refreshed and re-logged in. Everything looked great on both Int/Ext sites, then I went back to the Int rock site and it reset the theme paths similar to described above, except it used the custom Stark paths that I was working on. I just closed everything on my local machine, cleared cache and cookies via ccleaner and everything is back to what it should be. This is a really freaky bug and throws you for a loop when it first happens and the internal site theme is wrong.

[nairdo]

@hbcpn (Ben or Michael?) Thanks for the update. Would you be willing to share a few details about that Rock site configuration and the URLs/domains you use when you access the external and internal sites?

For example, using the pre-alpha site...

For external access: http://www.rockrmslatest.com/ For internal access https://prealpha.rocksolidchurchdemo.com/ with these domains configured for those sites:

[mikedotmundy]

[hbcpn]

Running on v10.2

For external access: my.gospelcentral.church For internal access: rock.gospelcentral.church

with these domains configured for those sites:

Again, clearing my own personal browser cache corrected the issue.

[trydyingtolive]

I ran into this for the first time tonight, it's subtle . In most cases a property on a Model and a ModelCache are same. However, Site.Theme isn't stored in SiteCache.Theme, it's actually in SiteCache.ConfiguredTheme. SiteCache.Theme uses the Site:{ Id }:theme cookie with a fall back to SiteCache.ConfiguredTheme. This is fine.... except that all of the configuration blocks inside of Rock also use SiteCache.Theme. So if your cookie follows you into the internal site, it will appear as if all of your settings have changed even though they haven't. Even more tricky is that LayoutService.RegisterLayouts will also read your cookies and add new layouts to your theme really selling the illusion.

tl;dr: The cookie is a lie. Change SiteCache.Theme to SiteCache.ConfiguredTheme in site config.

[nairdo]

This is a weird one that I have now seen reports on at least three times, and I've seen it myself on demo....

I have never witnessed this on my own system. I only saw it on demo when ...

I had observed that when it was happening on demo for me, opening the same site on a incognito window showed the correct site... so maybe it's a cookie issue?

So if your cookie follows you into the internal site, it will appear as if all of your settings have changed even though they haven't.

Thank you everyone who participated in this discussion and investigation.

I know this is another oldie, but we've concluded this is a problem with a cookie that "follows you into the internal site" as Mark so nicely put it. We know this will definitely happen on the demo site since those Site domains/sites are really shared/intermingled in a way that should not normally happen on a real Rock site (unless you're bouncing back and fourth between two sites in a not-so-correct way). So, we're just going to close this one.