Tyssen Posted August 24, 2013 Share Posted August 24, 2013 I've got this in my template: <body class="<?php if($page->parent) echo $page->name; if($user->isLoggedin()) echo ' logged-in' ?>"> That works fine when you're logged out and also when you've entered the correct password, but if you enter the wrong password, I get an error: Call to a member function isLoggedin() on a non-object and template won't render past that point. I know I could swap around so that I have a logged-out class only when logged out which would probably avoid the problem, but I've already written a lot of CSS for the other way around, so would like to avoid that. Is there anything else I can do to start the template failing with a wrong password? Link to comment Share on other sites More sharing options...
Hani Posted August 24, 2013 Share Posted August 24, 2013 I'm not entirely certain why it's giving that error when a wrong password is provided - but the error message itself is saying that $user is a non-object. Which is strange. Can you try this? if($user->id && $user->isLoggedin()) echo ' logged-in' Link to comment Share on other sites More sharing options...
Tyssen Posted August 24, 2013 Author Share Posted August 24, 2013 Yeah, that works, no more errors, thanks. 1 Link to comment Share on other sites More sharing options...
ryan Posted August 24, 2013 Share Posted August 24, 2013 I'm wondering if your code that does the login might have overwritten the $user API variable provided to the template file? If so, you might want to change your use of $user to $u or some other name. Either that, or you could use wire('user')->isLoggedin() rather than $user->isLoggedin(). Link to comment Share on other sites More sharing options...
Tyssen Posted August 24, 2013 Author Share Posted August 24, 2013 The template that is adding the class to the body is a template that's included at the end of the template where the login form code is, i.e. it's a global framework template with the individual template passing various content variables in to different parts of the page. Would that cause the problem you're describing? Link to comment Share on other sites More sharing options...
ryan Posted August 27, 2013 Share Posted August 27, 2013 It's hard to say without actually looking at it. But if one of the solutions mentioned above solves it, I think all the mentioned solutions here seem perfectly safe. Link to comment Share on other sites More sharing options...
netcarver Posted August 27, 2013 Share Posted August 27, 2013 I'm wondering if your code that does the login might have overwritten the $user API variable provided to the template file? If so, you might want to change your use of $user to $u or some other name. Hi Ryan, Just wondering if moving over to using namespaces is slated on the roadmap for a future release? Should help avoid issues like this in the future. Link to comment Share on other sites More sharing options...
apeisa Posted August 27, 2013 Share Posted August 27, 2013 http://processwire.com/about/roadmap/ Summer 2013. Not sure which is the updated schedule? 1 Link to comment Share on other sites More sharing options...
netcarver Posted August 27, 2013 Share Posted August 27, 2013 Thanks Antti. Link to comment Share on other sites More sharing options...
ryan Posted September 1, 2013 Share Posted September 1, 2013 Just wondering if moving over to using namespaces is slated on the roadmap for a future release? Should help avoid issues like this in the future. Namespaces actually won't solve that particular issue unless someone opts to create their own namespace in their template file. That's something they could do now if they wanted to. So the switch to namespaces in PW's core won't change anything in this regard. If they want to overwrite a locally scoped API variable with their own, they will still be able to do it. I haven't updated the roadmap yet, but i'm slating namespaces for PW 3.0 rather than 2.4. Namespaces are going to require all modules to have "namespace ProcessWire" at the top. Either that, or use long/ugly syntax to access PW API calls. Likewise for template files (though I'm hoping to find a way to abstract that to compiled templates or something, so folks don't have to do this unless they want to). Once a module is updated for namespaces, it won't be compatible with previous versions of ProcessWire. Basically, it's all and a bigger and more annoying change (for most users) than I originally thought. But it's still a necessary one. Given the lack of compatibility for modules, I think it all needs to be tied to a larger version number like 3.0. Though if all goes well with the pre-compiled, auto-namespaced template file option I'm working on, then theoretically it could be applied to modules too. Such a solution would be applied to template files/modules that don't set their own namespace. That may enable us to add namespaces in the 2.x version tree, but I'm not confident enough that this solution will work in full just yet. I'm actually already working on 3.0 and have been for some time, so it'll probably be the next version of ProcessWire after 2.4 or 2.5, regardless of whether it ends up being 3.0 or 2.5, or 2.6. 2 Link to comment Share on other sites More sharing options...
kongondo Posted September 1, 2013 Share Posted September 1, 2013 <aside>ProcessWire 3.0!!. Yeah! Has a nice ring to it..</aside> 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now