addHeaderItem depending on $isEditMode
Permalink
I have built a package with a block which contains extra JS and CSS.
The extra JS (Prototype Javascript Framework) interferes with C5's edit mode.
So, I have added a test for $isEditMode (in \packages\myPackage\blocks\myBlock\controller.php) to avoid including the JS while editing.
However,when I am logged in and in VIEW mode the JS still interferes with C5's interface, completely hiding the edit bar.
I am now looking for a way to distinguish between:
1. Logged in + VIEW mode
2. Not logged in + VIEW mode
Any ideas?
The extra JS (Prototype Javascript Framework) interferes with C5's edit mode.
So, I have added a test for $isEditMode (in \packages\myPackage\blocks\myBlock\controller.php) to avoid including the JS while editing.
However,when I am logged in and in VIEW mode the JS still interferes with C5's interface, completely hiding the edit bar.
I am now looking for a way to distinguish between:
1. Logged in + VIEW mode
2. Not logged in + VIEW mode
Any ideas?
Thanks a lot Remo!
I wonder however what happens in the following situation:
A user logs in to be able to view a single page (no back-end editing, just content viewing). In that case, while the user is logged in, the $uinfo->IsLoggedIn() will still return true, right?
Now, I wonder if there's a way to tap into the top edit bar code and set another variable there, identifying a 'back-end user logged in' status (as opposed to a 'front-end user').
If I understand well (I'm not sure I do), there seem to be two states for log in:
1. logged in
2. logged out
and then, two different states for editing:
1. isEditMode
2. ...not...
However, the isEditMode could also be false while still logged in at the back end.
Any ideas?
I wonder however what happens in the following situation:
A user logs in to be able to view a single page (no back-end editing, just content viewing). In that case, while the user is logged in, the $uinfo->IsLoggedIn() will still return true, right?
Now, I wonder if there's a way to tap into the top edit bar code and set another variable there, identifying a 'back-end user logged in' status (as opposed to a 'front-end user').
If I understand well (I'm not sure I do), there seem to be two states for log in:
1. logged in
2. logged out
and then, two different states for editing:
1. isEditMode
2. ...not...
However, the isEditMode could also be false while still logged in at the back end.
Any ideas?
if I understand your problem correctly, it's quite easy to fix.
you just need to check for edit permission. If the user has edit rights, the toolbar will be visible and you need to do your javascript magic..
?
I don't know without looking at the code how to check the permissions though
you just need to check for edit permission. If the user has edit rights, the toolbar will be visible and you need to do your javascript magic..
?
I don't know without looking at the code how to check the permissions though
This is probably the snippet you're looking for:
<?php $cp = new Permissions($c); if($cp->canWrite()) { } ?>
Indeed, this does the trick beautifully.
I needed to define $c as a global first as it seems not to be defined within the BlockController context.
Thanks a lot ryan & Remo, this is great community spirit!
I needed to define $c as a global first as it seems not to be defined within the BlockController context.
Thanks a lot ryan & Remo, this is great community spirit!
I'm having the same problem when adding a js to the header - the edit panel disappears.
I'm not exactly sure where to place the snippet of code above
? ? ?
Thanks for any tips -
I'm not exactly sure where to place the snippet of code above
$uinfo=NewUser(); if($uinfo->IsLoggedIn()){
? ? ?
Thanks for any tips -
