Package: collective.editskinswitcher
ContentsCollective edit skin switcherCompatibilityWhat does it do?Other optionsAm I authenticated?Why not CMFUrlSkinSwitcher?How do I know this is working?PreviewPer-folder default skinSub sites with navigation rootInstallation using zc.buildoutChangelog for collective.editskinswitcher3.2 (2015-03-24)3.1 (2013-09-16)3.0 (2013-02-16)2.5 (2013-02-15)2.4 (2012-09-13)2.3 (2012-04-11)2.2 (2012-02-15)2.1 (2012-02-15)2.0 (2011-09-28)1.6 (2011-06-11)1.5 (2011-01-04)1.4 (2010-12-31)1.3 (2010-12-14)1.2 (2010-12-07)1.1 (2010-12-07)1.0 (2010-06-07)0.9 (2010-04-19)0.8 (2010-04-16)0.7 (2008-10-04)0.6 (2008-08-27)0.5 (2008-03-07)0.4 (2008-02-12)0.3 (2008-01-30)0.2 (2008-01-28)0.1 (2008-01-25)Collective edit skin switcherFor a customer ofZest SoftwareI [Maurits van Rees] created a
package calledcollective.editskinswitcher.  I gladly took some code
from colleague Mark van Lent who did something similar for a different
web site.  The package is on the Python Package Index so it can be easy
installed.  And the code is in the Plone githubcollective.Compatibilitycollective.editskinswitcher3.0 is compatible with Plone version
4.1 until and including 4.3.  For earlier Plone versions please usecollective.editskinswitcher2.x.What does it do?Let’s say you have a Plone Site.  Anyway, whatever site you have is
available on two urls:www.example.comandedit.example.com.
Some day you should ask your local Apache guru how he did that.Withcollective.editskinswitcherinstalled (with the portal quick
installer), visitors that go to the website with the urledit.example.comwill see the Editor Skin.  (This can be set in
a property, as we shall see later.)  Visitors towww.example.comwill see whatever skin you have set as the
default skin in portal_skins.  Can be pretty handy.To avoid confusion: we will call what you have set as “default skin”
the Visitor Skin.  And the skin meant for editors we call the Editor
Skin.Developer types probably like the fact that you also get the Visitor
Skin when visitinglocalhostand the Editor Skin when you go to127.0.0.1.You can also set a different default skin in a
folder.  So you can set it up so that folder-1 uses a red theme,
folder-2 a blue theme and when you edit either folder you still use
Sunburst Theme.  See also thePer-folder default skinsection.Other optionsThere are some options you can set.  Go toportal_properties, and
then go to theeditskin_switcherproperty sheet.  These options
are available:edit_skin: set the skin that editors get.  The default is “Plone
Default”.switch_skin_action: choose the url condition that is used for
switching to the edit skin.  Note: this is a multiple select: ifoneof the selected options gives a positive result, then we
switch to the edit skin.  Options are:based on edit URL: With this you get the behaviour described above.
This is the default.based on specific domain: If this is specified the edit skin is
used when the first part of the url matches one of the entries in
thespecific_domainsproperty.  This url is the url for the
root of the Plone Site; so usually this will be a domain, likehttp://special.example.com/.  Note that you need to very
explicitly use the exact url to your Plone Site root.  For
example, when trying this locally you may need something like
this:http://localhost:8080/Plonebased on admin header: If this is chosen you will need to set up your proxy
server, eg. Apache, to add a ‘HTTP_PLONEADMIN’ header to the request. It can
do this based on the url for instance. An example is given in
/tests/ploneadmin_header.txtbased on SSL: If this is chosen, then any urls that are SSL
will get the edit skin and others will get the default skin.No URL based switching: do not base the skin switching on the url;
instead we check theneed_authenticationoption.need_authentication: when True you need to be logged in before
your skin is switched.  By default this is set to False.  See
the sectionAm I authenticated?below for some notes.force_login_header: when the request has this header, only
authenticated use is allowed.  This does not actually switch the
skin; you just get redirected to the login_form.  By default this is
set to the stringX_FORCE_LOGIN.  Note that this is not done for
the login_form and other pages like that.  Such a page probably
looks ugly though, as you still are forced to login before you can
get the css and images for that page.If you combine the switch skin action and the authentication, then you
need to have the right url and you need to be logged in.When both are not used, nothing happens: then you might as well simply
uninstall this product as it is not useful.Am I authenticated?Theneed_authenticationoption looks for the__accookie that
Plone gives you when logged in.  There are a few possible problems
with this:Logging in via the Zope Management Interface is handled without
cookies, so the editskin switcher regards you as anonymous then.We do not check if the the cookie is actually valid.  This can
mostly give a surprise when you are developing multiple websites on
your own local computer: Plone stores the__accookie for the
localhost domain, without differentiating between multiple Plone
sites.  So if you are logged into Plone Site A on localhost with a
cookie, then the skin switcher thinks you are authenticated for all
websites on localhost.Alternatively, we could checkgetSecurityManager().getUser(), but
that check always thinks we are anonymous, presumably because our
check is done during traversal, which apparently is too soon for
anyone to be recognized as being logged in.Why not CMFUrlSkinSwitcher?I looked at CMFUrlSkinSwitcher first but it had not been touched in
two years.  One import error (CMFCorePermissions) could easily be
fixed as that import was not even used.  But after that tests were
failing all over the place.  Theoretically always fixable of course,
but rolling an own package seemed easier, cleaner and faster.Also, CMFUrlSkinSwitcher does some more things.  At least it messes
around with some methods like absolute_url.  It could be that I find
out later that this is necessary incollective.editskinswitchertoo,
but currently it does not look like that will be the case.How do I know this is working?The easiest way to test this package in a default plone site (apart
from running the tests of course), is:Installcollective.editskinswitcher.Go to portal_skins in the ZMI.Create a new skin selection based on Sunburst Theme.  Call this
“Visitor Skin”.Make Visitor Skin the default skin.Remove the custom skin layer from Sunburst Theme.Customize the main template or the logo or something else that
is easy to spot.Visit127.0.0.1:8080/plonesiteand you will see default Plone.Visitlocalhost:8080/plonesiteand you will see Plone with
your customization.On Linux you can edit/etc/hostsand add a line like:127.0.0.1 edit.example.com www.example.comNow visitingedit.example.comshould give you the Editor Skin
andwww.example.comshould give you the Visitor Skin with the
customizations.You can also let the edit urls begin withcmsormanage.  As
long as the url is something like:...//(edit|cms|manage).something.something....you end up in the edit skin.PreviewThe preview option allows you to see the default skin via the edit skin.It does so by using an iframe which accesses the edit skin content but flips
it to the default skin. This allows you to easily view previous versions,
private content etc. as it will appear in the default skin if published.This is particularly useful in cases where your default skin differs
radically from the edit skin. It allows the edit interface to maintain some
wysiwyg functionality.Preview can either be used as a separate preview tab, or as a replacement
for the view tab content in the edit skin.Both are implemented within the tests folder and tested, but neither is
used by default.For the preview of editskinswitcher to be of use it requires an
accompanying theme.egg holding the configuration for the default (and
edit) skins.  In order to use preview, it must be turned on within
this accompanying theme egg. Example code to do this are within the
tests folder.Instructions for replacing view with preview are given in
tests/skins/README.txtTo add it as a separate preview tab:Add the browser view by putting what is in testing.zcml in your
theme egg configure.zcml or loading that file in the part of your
buildout that creates thezope2instance, something like:zcml =
    collective.editskinswitcher-testingWithin tests/add_preview.py there is ACTIONSCONFIG
Add this as a profiles/default/actions.xml file.
Change the default visible=False property to True.  Or do it by
hand by going to portal_actions, object, and adding a preview
action with url expressionstring:${object_url}/@@preview.Note that it looks like currently our++resourece++iframe.jsis
not properly loaded, which in my tests unhelpfully makes the iframe
about two centimeters high, though that probably depends on what you
have set as the edit skin.  If you use this feature and are hit by
this bug and maybe even know how to fix it, contact me.Per-folder default skinSelecting a default skin for a specific folder is also supported. A
‘Skins’ menu entry should show up in the content area, right next to
the ‘Display’ and ‘Actions’ menu. Once you select a skin from that
dropdown, it will be used as the default skin when visiting that
folder instead of the site-wide default skin.This menu is available for everyone who has theSet default skinpermission, which by default is for Managers and Owners.  So if you do
not want anyone to have this menu, you can do so by not giving anyone
this permission.  In the rolemap.xml file of your GenericSetup profile
that would look like this:<?xml version="1.0"?>
<rolemap>
  <permissions>
   <permission name="Set default skin" acquire="False" />
  </permissions>
</rolemap>Sub sites with navigation rootUsing thePer-folder default skinmenu you already mostly have a to
make simple subsites.  The only other basic thing needed is to set the
folder as a navigation root, so giving it theplone.app.layout.navigation.interfaces.INavigationRootmarker
inferface.  This option has now been added to the menu, guarded by new
permission “Set navigation root”, by default only for Manager.Installation using zc.buildoutFor using collective.editskinswitcher with zc.buildout you have to addcollective.editskinswitcherto theeggssection:eggs = collective.editskinswitcher
...Have fun!Maurits van ReesChangelog for collective.editskinswitcher3.2 (2015-03-24)Remove no longer neededbased_on_urlproperty.  Merge it with
theswitch_skin_actionproperty.
[maurits]Remove backwards compatibility code that is not needed on the
supported Plone 4.1 and higher.
[maurits]Fix upgrade error when coming from really old version, like 0.5.
Fixes ValueError: The property switch_skin_action does not exist
[maurits]3.1 (2013-09-16)Fix handling the specific_domains property.  It seems this has only
worked when the exact url of a page is in the property, but the
domain (including the protocol) should be enough.
Fixeshttps://github.com/collective/collective.editskinswitcher/issues/1[davidemoro, realefab, maurits]3.0 (2013-02-16)Removed zope.app dependencies.
[maurits]Compatible with Plone 4.1, 4.2, 4.3.
[maurits]2.5 (2013-02-15)Nothing changed yet.2.4 (2012-09-13)Added dependencies for Plone 4.2 compatibility:
zope.app.publication and zope.app.publisher.
[maurits]Moved to github:https://github.com/collective/collective.editskinswitcher[maurits]2.3 (2012-04-11)using Sunburst Theme as default theme (we are now in Plone 4 country
since a while)
[ajung]2.2 (2012-02-15)Fixed broken release by fixing MANIFEST.in.
[maurits]2.1 (2012-02-15)Changed the calculation for the iframe height.  With the original
code Firefox was behaving quircky, the height was 150px.  That is
too small.  With help of Mark we could fix this.
[mirella]2.0 (2011-09-28)Added MANIFEST.in so we can automatically include .mo files with
zest.pocompile.
[maurits]Replace the PAGE_WHITE_LIST and SUFFIX_WHITE_LIST with a list of
regular expressions (WHITELIST_REGEXPS). Using regexps we can also
whitelist more complex URLs, e.g. for the password reset tool
(/passwordreset/1234…). [markvl]1.6 (2011-06-11)Also set the theme specific browser layers when switching skins.
Code heavily inspired by themetweaker.themeswitcher. [markvl]1.5 (2011-01-04)Always show the Styles menu when the user has the “Set navigation
root” permission.
[maurits]Check our permissions on the folder when we are on a default page.
This might give a difference.
[maurits]1.4 (2010-12-31)Added menu item to set the context as a navigation root
(plone.app.layout.navigation.interfaces.INavigationRoot) guarded by
new permission “Set navigation root”, by default only for Manager.
[maurits]1.3 (2010-12-14)Do not show the Styles menu when there are no styles to choose.
[maurits]Moved PAGE_WHITE_LIST and SUFFIX_WHITE_LIST from traversal.py to new
config.py.
[maurits]Added SUFFIX_WHITE_LIST to avoid triggering a forced login for css
or javascript files, otherwise the login form will look ugly.  Also
added logo.jpg/png/gif and favicon.ico to the PAGE_WHITE_LIST for
the same reason.
[maurits]1.2 (2010-12-07)Do not force logging in when you get this header for a login page
(specified by the PAGE_WHITE_LIST).
[maurits]1.1 (2010-12-07)Useget_headerinstead ofgetwhen looking for headers to
force logging in or force using the edit skin.
[maurits]Allow setting a default skin on a folder, using the new Styles
context menu.
[dreamcatcher]1.0 (2010-06-07)Fix: when we need authentication and we are anonymous then we donotwant to switch: we want to have the default behaviour of
getting the standard skin instead of the edit skin.  Added some more
inline documentation.
[maurits]Switch back to checking the__accookie to see if someone is
anonymous or not; the getSecurityManager check always says we are
anonymous, though I thought I had seen it working previously.
[maurits]Add logging lines for debugging.
[maurits]0.9 (2010-04-19)Change the switch skin action to a multiple selection.  When one
of the selected actions returns True, we switch the skin.
[maurits]Also accept urls like admin.example.org as edit urls.
[maurits]0.8 (2010-04-16)Slightly better check for anonymous users, using getSecurityManager
instead of checking for an__accookie.
[maurits]When a X_FORCE_LOGIN header is passed (exact spelling is configurable)
only allow access to logged in users (you get redirected usually).
[maurits]Allow specifying the admin_header; defaults to HTTP_PLONEADMIN.
[maurits]Added z3c.autoinclude.plugin entry point for plone, to avoid having
collective.editskinswitcher in the zcml option of your zope
instance; only effective in Plone 3.3 or higher.  In earlier
versions you still need to do this manually.
[maurits]0.7 (2008-10-04)Added switching option based on a request header flag set by the
proxy server (eg. Apache)
[Ed Crewe, ILRT - University of Bristol]0.6 (2008-08-27)New preview feature so that the default skin can be seen via the
edit skin interface to preserve some level of WYSIWYG for editing.
(Based on part of an unreleased plone 2 product by Dominic Hiles.)
Preview feature is available as a viewlet for use via a view or a
viewletManager, but it is turned off by default.  Examples of how to
enable it are included in the tests, where it is enabled and tested.
[Ed Crewe, ILRT - University of Bristol]Extra URL skin switching options of SSL or specific URLs
[Ed Crewe, ILRT - University of Bristol]Setting eol style in subversion correctly. [reinout]0.5 (2008-03-07)Bug fix: when called on the zope root (can happen in some cases)
portal_properties was not found, which was not caught correctly.
[maurits]0.4 (2008-02-12)Bug fix: if object has no changeSkin, try its context.  Happens at
least on the sharing tab when searching for users, as object is a
KSS view then.
[maurits]0.3 (2008-01-30)Instead of an Access Rule, use a pre-traversal hook.  Idea: David
Convent.  Thanks!  Is a lot cleaner.
[maurits]Avoid confusion in README.txt: talk about Editor Skin and Visitor
Skin instead of Plone Default and the default skin.
[maurits]Update README.txt to tell about the new options introduced in
version 0.2.
[maurits]0.2 (2008-01-28)When testing if the user is logged in, check for the __ac cookie in
the request instead of portal_membership.isAnonymousUser as this
does not work in real life; probably because we use an AccessRule.
[maurits]Add based_on_url property (default: True).  When True, the skin
switching is done when you visit the site via an edit url.  When
combined with need_authentication=True, only logged-in users on the
edit url get the edit skin.
[maurits]Add need_authentication property (default: False).  When True, the
skin switching is only done when you are authenticated (logged in).
[maurits]In the base test cases, create the new default skin.
[maurits]Split tests/setup.txt in two files for separating some unrelated
tests.
[maurits]Add a more readable README.txt and move the old one into the
tests directory as it contains most of our tests.
[maurits]0.1 (2008-01-25)Add a property sheet editskin_switcher with property edit_skin.
Default value: Plone Default.  Use that for determining which
skin to give to editors.
[maurits]Initial package structure.
[zopeskel]