FS#1773 DW as read-only homepage

2009-10-08 furun

Would be useful if DW has a option witch switches off all Wiki functions to use it as a read-only homepage.
Only login index and search etc allowed, no register, history, edit or other do= options for not logged in users. This need changes on some PHPs and on the template (buttons etc), plugins can not do this.

I work on a patch for this (), Interested?

2009-11-27 chi

Any news on the patch?

Personally, I think a correct mix between template/conf[disableactions] or maybe a custom action plugin should be enough to fit this specific need. No need to patch DW core IMO.

2009-11-27 furun

The idea of course was to not need such more complex and not 100% working solutions, but have a native and clean one. (template developers could use it too from $conf.)
I think there on a simple option in the settings witch make dw immediately read only, and hide all html elements and switch of all actions accordingly (not block actions but change them, to "show" for example, and use white-listing not black-listing). Optionally even with a message, if a wiki is only temporary read-only (in a tpl_() function), for example because of holidays of the admin. Such a solution could even make a partly open wiki possible, witch only selected autos have write access, and users don't see in the first view that the web site is a wiki.

I think that many users like to use cms software on a simple level and have maybe no programming skills. (puzzling the actions and even plugins together for such a function, and hacking template codes is not a simple solution.)

But it is ok, i have in the moment anyway no time anymore to make such a patch in the intended quality. (for now my template is able to do this, and for the rest i use a dirty hack in doku.php for $ACT)

If you are anyway interested, give me some hints how you see this best realized, and best code places for the patches. Maybe i find time wen i have to make the next big update (not in the near future).

2009-12-17 furun

This is a list of intended changes, all actions independent form other options, switched on/off only by the 'read-only mode' option:
- Effects on Guests and optionally even unknown users (usertypes: Guest (not loged in), unknown users, known (trusted) users, managers, admins)
- Make all sites read only
- Change all not allowed actions to 'show' (by white list)
- Disable Upload and Media manager (using temporary redirect to the page)
- Hide all tpl_ for unused elements (hiding login should be left to template developers)
- Exclude EDIT in html meta
- Hide/change registration text (no new registrations by users, only by admin on emals request)
- Show optionally 'read only' information in tpl_ for template (define the tpl_ in the code, but maybe left the decision of showing it in the template options)
- Use a new text instead of 'newpage' a 'nopage'
- Hide the Playground site
- Hide other elements/infos witch are only used in a editable Wiki (? JSINFO)
- (Maybe include a additional css, to make easy changes of a read only layout possible)
- ... and maybe more
- (Maybe Internally is speedup possible, because no edit from guests is sure)

(i don't see how all of this can be done by a plugin, and even if so, those are in me opinion better placed in the code)

2009-12-17 chi

Okay, lets try to summarize how this could be done using only one plugin with a couple of action components:

- Make all sites read only
! This is covered by the fact that we only allow the 'show' action and disable everything else - see below.

- Change all not allowed actions to 'show' (by white list)
! Catch all actions using the ACTION_ACT_PREPROCESS event - if the plugin is active always return "show" for all requested actions

- Disable Upload and Media manager (using temporary redirect to the page)
! Use MEDIA_MANAGER_STARTED and either explicitely kill the session calling exit() or redirect using header() to redirect.

- Hide all tpl_ for unused elements (hiding login should be left to template developers)
! If the plugin is enabled use an action plugin component using TPL_METAHEADER_OUTPUT and inject some CSS to hide all those elements (this of course, can't be guaranteed to work with all templates, especially if they use custom elements and not those provided by the tpl_<foo> functions).

- Exclude EDIT in html meta
! Same here, use TPL_METAHEADER_OUTPUT to change this on the fly if the plugin is active.

- Hide/change registration text (no new registrations by users, only by admin on emals request)
! Use DOKUWIKI_STARTED and explicitely disable registrations (hides the registration text).

- Show optionally 'read only' information in tpl_ for template (define the tpl_ in the code, but maybe left the decision of showing it in the template options)
! Use TPL_CONTENT_DISPLAY to do that.

- Use a new text instead of 'newpage' a 'nopage'
? Hmmm, I don't understand this one. Could you clarify please?

- Hide the Playground site
? Why, do=edit doesn't work anyway because we disabled it already.

- Hide other elements/infos witch are only used in a editable Wiki (? JSINFO)
! Again an action plugin component could be used to explicitely remove this info.

- (Maybe include a additional css, to make easy changes of a read only layout possible)
! No problemo using a plugin.

- (Maybe Internally is speedup possible, because no edit from guests is sure)
! DOKUWIKI_STARTED could be used to explicitely set the cache time to be nearly infinite to ensure that pages are never rebuild when the plugin is active.

2009-12-17 andi

use plugin

2009-12-17 furun

- Use a new text instead of 'newpage' a 'nopage'
? Hmmm, I don't understand this one. Could you clarify please?
- The newpage.txt or nopage.txt, return message file

- Hide the Playground site
? Why, do=edit doesn't work anyway because we disabled it already.
- Because it should be not shown at all. (specially for some templates witch show the index in a sitebar. But this could be done with a event witch modify the hide list.... i see)

Could you let the Task open, so that plugin developers could see it? The Feature Request still is there, even if it is solved with a plugin, especially because of the amount of required modifications and events.
(I have expect to solve possible conflicts (had some once with plugins) by implement such a solution in code instead of by plugin, and not know all events you list, thanks for the response.)

2009-12-17 andi

plugin wishes belong into the plugin wish forum

FS#1773 DW as read-only homepage

ACL & Authentication