[TigerC10]

Originally Posted by Marco van Herwaarden

There is nothing in your PHP=code that is browser dependent. If there is a dependecy then it is in 1 of the templates used.

He's right, manning. PHP is a server-side script - it doesn't care what browser you're using, it will always deliver the same HTML/Javascript/XML to your end user.

Originally Posted by manning

Only thing in template is basic html ... nothing that would cause OPERA to keep returning no permission screen... thats in this php file.

Just how basic? Because some people use browser-dependent CSS with their HTML without realizing it. Some styles unwittingly use browser-dependent CSS too.


As an avid Opera user myself, I find that it's the other browsers that do funky things. After all, Firefox only just started passing the ACID 2 Browser Test (on the release build, FF has been passing for years on a few select nightly builds but they don't count). In fact, one thing that I absolutly detest about Firefox is that it makes assumptions about the code on the page - if a tag is not closed, Firefox will close it for you (this was a NIGHTMARE for some AJAX stuff). Needless to say, sometimes Firefox guessed where to close it incorrectly. I've had friends who abused the hell out of that feature, they would only write a quarter of the necessary code for a page to work properly and rely on Firefox to do everything else - when it didn't work for me they told me to switch to Firefox. I've come to loath the firefox subculture for that. But I digress...

I think the problem is that your other browsers cache is interfering with the results of the script. Force a re-download of the page

Firefox:
Hold shift and press the refresh button

Internet Explorer:
Hold CTRL and press the refresh button


If they don't come up with the same error that Opera does, then it's not what I think it is... However, if they do come up with errors then I think the problem is that you're missing this line from your PHP file:

global $vbulletin;

You can't use $vbulletin->userinfo[usergroupid] without knowing about $vbulletin in the first place (that it was defined in some other PHP file), and to do that you have to tell it that $vbulletin is defined globally.

Try printing the valueof usergroupid instead of printing no permission... That might give you a clue as to what the real cause is.




One time I had a very similar problem when it came to admin logins. After changing the subdomain on which vB was installed, vB couldn't find any of the cookie data. SessionIDs started appending to the ends of the URLs, and vB wouldn't even let me access the admin panel without a cookie login. I recommend that you upload the "tools.php" file from your "do_not_upload" folder and run the cookie repair utility just to rule out cookie settings errors.