Thread

I often use {if logged_in}...{/if} to restrict certain content to logged in members who are writing content for the site, however a certain member using Firefox on Windows could not see the content only displayed to logged in members. I tried this in Firefox on a Mac & I couldn’t see the content either, but it is fine on Safari.

With Firefox, the content between the {if logged_in}...{/if} tags isn’t displaying, as if Firefox isn’t registering that someone is signed in. However, I can still use the Control Panel as normal when signed in with Firefox to edit templates and publish posts.

I assume that there is some setting on Firefox which I need to change.
Does anyone know what I need to do to get Firefox to recognise the {if logged_in}...{/if} tags?

Thanks

Scott

I don’t really think this is a Firefox problem (but I’m not ruling it out).  Is the user in question a member of the Super Admins group? 
I had this problem on my site - I am a Super Admin and when I go a page using {if logged_in} even if I say {if logged_in && member_group == "1"} or {if logged_in && group_id == "1"} it will still not do what I need it to.

Try assigning the user to another group and see if the same thing comes up.

Yes, the user is definitely a Super Admin. I’ve tried using Firefox myself and I get the same problem: anything entered between the {if logged_in}...{/if} tags isn’t displaying, whereas it works fine with Safari.

The other user is using a PC and it works OK with IE, but he prefers to use Firefox.

Tags like {if logged_in} are never seen by the browser - any browser.  They are parsed by EE server-side as the page is created then the rendered page is sent to the browser.

My suspicion is there might be some basic HTML issues with the content you are expecting to see once logged in.  Firefox is much pickier about valid code than IE is. 

Get the code to load in IE, then run it through the HTML validator.

Interestingly this EXACT same problem started happening to me this morning, but in Google Chrome, and with EE 1.7. I have been using the exact same code for several months now without any problem.

Have you had any success fixing it, Scott?

Edit: I’ve tried logging in as a few different users and groups, no dice.

Editedit: Code works properly on dev and staging sites. Some kind of domain issue? Restarting live server.

Editeditedit: For seemingly no reason, everything is working again.

Solution: I removed a rule from my .htaccess file that broke the forcing of www on our domain. This, combined with my use of www in the control panel system settings, confused EE into thinking that I was not logged in when I was on domain.com, and that I was logged in on http://www.domain.com.

Use Firefox to see if you can get markup or script errors.  Download Web Developer, a plugin for Firefox, and then run your code.  It will tell you where your page errors are and why they aren’t displayed.

@Boyink!
Thanks - I should have realised that the tags are parsed by EE on the server before the browser sees the html. However it’s not an issue with the browsers rendering the code differently, because it is distinctly different code showing up. For example, I don’t include the google analytics code when I’m logged into the control panel because I don’t want to affect site statistics when doing lots of testing and development on the site, but it will be included for normal site visitors. I also don’t let logged out visitors see menu items for new sections I’m working on until they’re ready to go public. At the moment there aren’t any users who’ll be logged in except for myself and the client.

@Daniel
I checked and it seems to be an issue with having www in the URL for the control panel and not using www when viewing the site.

So I’ve done a couple of tests and it seems that the other user was using http://www.domain.com for logging into the control panel and viewing the site without the www at http://domain.com. That slur on Firefox must just have been a coincidence

I’m not doing anything with .htaccess other than removing index.php using the “exclude” list method. I tested another site that uses the “include” list method to remove index.php and I get the same behaviour.

So its not a problem for me because I always use the same subdomain (www or non-www) for the control panel and for viewing the site, and I’ll just need to explain this to the other user. Or I could try forcing this behaviour with .htaccess.

Does anyone know whether I can change this using Security and Session Preferences, so that you can be logged into the www version of the domain, and for this to also show you as logged in for the non-www version of the domain? Its not too much of a problem if you can’t do this.

I’ve resolved this issue by removing the default link to the website’s homepage at the top tight of the control panel. This pointed to the www version of the domain, and was causing a problem with my client when he was logged into the non-www version of the domain.

I’ve replaced this with LG Add Sitename, which I’ve configured so that the displayed sitename links to the correct www or non-www version of the domain homepage, depending on which one the user is logged into. Works a treat.