![]() |
|
|
#1
|
|||
|
|||
|
I'm looking at site which will have a separate area for registered users, which will also have a slightly different colour scheme to the guest site.
At the moment I'm doing this with a separate skin for registered users which references a different style sheet to handle the colour change. This, along with the changes Colin made which allow you to specify a page that a user is taken to when logging in or out works well, but I can't help thinking I'm not doing it the right way. One of the drawbacks of my "method" is that I have create and maintain separate copy of pages like the privacy policy and terms and conditions etc in both skins which is far from ideal. |
|
#2
|
|||
|
|||
|
Quote:
If I was doing this, the registered users skin would be a child skin of the default site skin. Then all you need to do is change the templates the control the look. As an example, look at the way the Blue and Black templates related to the Default template in the default install. The only difference between them is the Header template - and that's all that Blue and Black templates contain. Everything else is pulled in from the Default parent template. |
|
#3
|
|||
|
|||
|
I'll take a look, but I can see how that would work!
I haven't created any relationship between my two skins, can I do anything about that now? Actually, thinking about it a bit more, I've changed the navigation and a couple of other elements depending on whether logged in or not. Can I tell a template to only display if logged in, or even better display "this" template" if logged in or "that" template if not. |
|
#4
|
|||
|
|||
|
Yup - in the Skin Manager there is a Parent Skin option at the top.
The only thing you need to ensure is that your parent skin was created BEFORE the child skin. If not, you can get around this by creating a copy of the child skin using the Copy Skin option ![]() You can check if someone is logged in but it uses inline PHP: Code:
%% global $loggedin; if ($loggedin) ** displayTemplate(getTemplate('RegisteredTemplate')); ** else ** displayTemplate(getTemplate('UnregisteredTemplate')); ** %%
![]() |
|
#5
|
|||
|
|||
|
Cheers Colin, looks like I've got a bit of work to do there making it all work, I'll let you know how I get on.
|
|
#6
|
|||
|
|||
|
I've had a play with this now, and structured the skins as you've suggested Colin.
It's not working as expected though. I changed just the header in the child skin, but if logged in and as such using the child skin, when I view a page that is defined in the parent skin it all goes wrong! Viewing the source code generated, I'm getting the header from the parent skin, nothing at all in the page section, and the footer as expected. If I turn the "Include Comments When Displaying Templates" option on in site settings, a comment is being inserted for the correct page section, but no code. Any ideas? |
|
#7
|
|||
|
|||
|
Not off the top of my head.
Do you still have the original Default, Black and Blue skins to see what happens with them? |
|
#8
|
|||
|
|||
|
No, unfortunately I've deleted them...
|
|
#9
|
|||
|
|||
|
I'll do some testing here then
Will get back to you ASAP. |
|
#10
|
|||
|
|||
|
Just thinking about this, the way I've tended to structure my MonkeyCMS sites is to close the head tag within the page or content template rather than the header template as it allows me to add things to the head section on a per-page basis.
Could that have any bearing on it? I've also done some tests and the result i'm getting is the same as if I were calling page that doesn't exist. |
![]() |
| Thread Tools | |
| Display Modes | |
|
|