[pmwiki-users] Working solution for CMS style interface with IMS caching
Henrik Bechmann
henrik at bechmannsoftware.com
Sun Aug 6 17:08:08 CDT 2006
Patrick,
I have implemented a working solution for differentiation of page layout
based on native PmWiki password protection state, in the presence of IMS
caching, as follows:
In my farmconfig.php I have:
$HandleActions['logout'] = 'CacheLogoutHandler';
function CacheLogoutHandler($pagename, $auth = 'read') {
global $EnableIMSCaching;
$EnableIMSCaching = 0;
HandleLogoutA($pagename, $auth); # call the legit handler
}
(Thanks to Dominique for this) This code allows refresh after logout in
the presence of $EnableIMSCaching=1. (I have caching turned on so that
page position is preserved for users who go back to a page after
clicking through -- many of our pages are quite long).
Later in farmconfig.php I have:
include_once('local/config.php');
$pagename = ResolvePageName($pagename);
$isEditAuthorized = (boolean)RetrieveAuthPage($pagename, 'edit', false,
READPAGE_CURRENT);
Thanks to you for this. It sets the $isEditAuthorized variable so that I
can use it elsewhere to make page layout decisions. The include_once is
required so as to allow for initialization required by the native
Resolve... and Retrieve... functions.
Then later again in farmconfig.php (for example) I make custodian (ie.
'author') layout decisions:
function GetCustodianMenu() {
global $isEditAuthorized;
if (!$isEditAuthorized) {
print "<li><a href='$PageUrl?action=login'>Login</a></li>";
} else {
print "<li><a id='currentpagelink' href='$PageUrl'>View page</a></li>
<li><a href='$PageUrl?action=edit'>Edit Page</a></li>
<li><a href='$PageUrl?action=diff'>Page History</a></li>
<li><a href='$PageUrl-Sidebar?action=edit'>Edit Page Sidebar</a></li>
<li><a href='$ScriptUrl/$Group/Sidebar?action=edit'>Edit Group
Sidebar</a></li>
<li><a
href='$ScriptUrl/$DefaultGroup/DepartmentSidebar?action=edit'>Edit
Department Sidebar</a></li>
<li><a href='$ScriptUrl/$DefaultGroup.SectionList?action=edit'>Edit
Folders Menu</a></li>
<li><a href='$ScriptUrl/$Group/ArticleList?action=edit'>Edit Documents
Menu</a></li>
<li><a href='$ScriptUrl/LibraryOfStories.FrontPage'>Library Of
Stories</a></li>
<li><a target='_blank' href='/gallery/index.php'>Photo Gallery</a></li>
<li><a target='_blank'
href='/common/wiki/pmwiki.php?n=DufferinParkWiki.FrontPage'>Custodian
Help</a></li>
<li><a href='$PageUrl?action=logout'>Logout</a></li>";
}
}
...which is called from the page template as
<!--function:GetCustodianMenu--> in the appropriate sidebar location.
All of this works as expected in Internet Explorer. The Firefox cache is
not as responsive however, and requires special procedures. Also, it
turns out that PmWiki deletes the Author Name cookie with the logout
operation (which I do not think is desirable in most situations).
To deal with the Firefox cache, and PmWiki cookie issue, I have
customized Site.AuthForm (and added it to shared.d) by adding the
following two notices for my authors:
---------------------
Page refresh required after login/logout
If you are using Firefox, you will have to refresh the web page after
login or logout in order to see the page layout associated with the
current authorization. To do this, hold down the shift key and click on
the refresh icon on the browser's toolbar.
Author Name removed from cookie with logout
For either Firefox or Internet Explorer, after logout the Author: Name
that is required to save an edit is removed by PmWiki from your cookie,
so you will have to re-enter it the next time you want to save an edit.
To avoid this, do not use logout.
-----------------------
Therefore my authors are routinely reminded of procedures to follow to
deal with these issues (they use FF, and normally do not need to logout
as such).
Note that Ctrl+R does NOT work in Firefox. Apparently <Shift> + the
refresh icon does a deeper refresh.
So it's not the prettiest thing in the world, but it's acceptable, at
least for a while.
My suggestions:
1. Hunt down the tweak required to get FF to refresh (if available).
2. IMHO the Author Name (as opposed to ID) should never be removed from
the cookie. It is not a security feature, but rather a convenience for
the author, such that he/she doesn't have to keep adding his/her name
from the same computer all the time (when $EnablePostAuthorRequired =
1). Perhaps a $EnablePersistAuthorCookieValues variable or some such
could give people a choice, if that is an issue.
Thanks again to all (particularly Pm, Dominique, and Hagan) for your
help and patience on this one.
All the best,
- Henrik
--
Henrik Bechmann
www.osscommons.ca
www.bechmannsoftware.com
Webmaster, www.dufferinpark.ca
More information about the pmwiki-users
mailing list