[dokuwiki] Re: question on meta data and feature request for enabling disabled functionality for admins

On 09/18/07 17:09, Michael Klier wrote:

Jason Keltz wrote:

Hi.


Hi,


I have one question, and one feature request.
First, is there anywhere on the DokuWiki site where I can find information on exactly how to understand all the codes in the *.meta files in the data/meta directory of my DW installation? I'd like to understand how the revisions are stored. 

The contents of the .meta files are serialized php arrays and contain
various information about the wiki page. The revisions are stored in
data/attic (in fact the revisions are the old version of the wiki page -
filename is a md5sum of the page name and the timestamp I think). Each
wiki pages has a related .changes file in data/meta/, the revisions are
looked up using the log entries in those files.
(Thanks Myron for your script -- it definately sheds light on the .meta files!)
When I click on "Old revisions" for page X, am I basically seeing meta/X.changes? When I click on a specific revision, I guess I am seeing the data from attic. When, then, would the information from the meta file be used since it contains information on all the changes?
Second is pretty much a feature request -- I would like to be able to disable the "revision history" and "recent changes" buttons on a DW site, yet still maintain those buttons for the admin user. That is, the user cannot look at the revision history of documents, or recent changes, but the site maintainer can see it all. I think that most templates use tpl_actionlink in order to display the buttons, but tpl_actionlink first checks if "actionOK". If the features are "disabled", then actionOK returns false, and the button is not printed. This means that it's not up to the template whether the buttons get printed or not. Either tpl_actionlink should leave it up to the template to check the status of actionOK (which provides more flexibility, but more difficulty for template maintainers), or, DW could provide another config option that, by default, enables disabled functionality for admins. Does this make any sense? It certainly sounds like something that could be useful to other people. 

I recently made a plugin "ClosedWiki", you`ll find it at the plugins
page. It allows you enable/disable actions for non-logged in users (it
doesn`t disable the actions completely as the disable action config
options does). ATM moment in only checks wether a users is logged in or
not, but if requested, I could add another option to allow actions only
for users which are part of certain groups or even only the admin user.
I think the addition of the "group" option would make the plugin useful for my particular circumstances. I'm not sure what you mean about it not disabling the action "completely" though. Could you clarify? I guess my template which is looking for actionOK would still end up printing the button, but your plugin would intercept the call to the function, and disable the action with some kind of "permission denied" type message. 

Jason.

--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Other related posts: