update
parent
9607452346
commit
f484deabbc
|
@ -11,56 +11,21 @@ Currently admin prefs are per-admin, and are stored in the userdb.
|
||||||
That seems like a bad choice in the context of this idea. Instead, admin
|
That seems like a bad choice in the context of this idea. Instead, admin
|
||||||
setup should be configured on a separate page than the regular user prefs
|
setup should be configured on a separate page than the regular user prefs
|
||||||
page, and should be shared amoung all admins, and the ideal storage would be
|
page, and should be shared amoung all admins, and the ideal storage would be
|
||||||
another ikiwiki setup file, which could be loaded in, and written back out.
|
a ikiwiki setup file, which could be loaded in, and written back out.
|
||||||
|
|
||||||
If `ikiwiki-makerepo` were extended a little bit to generate the stub setup
|
The underlying work has been done to privide metadata about all options via
|
||||||
file that's enough to get `ikiwiki.cgi` working, and that sets values for
|
getsetup hooks, so it's just a matter of writing a web interface plugin.
|
||||||
all the dangerous options, leaving only safe ones 'undef', then users could
|
|
||||||
set up ikiwiki using it, and configure the rest with the web interface,
|
|
||||||
without ever needing to edit a setup file.
|
|
||||||
|
|
||||||
The setup page could `require` every available plugin, and then call a
|
The plugin could have these config options:
|
||||||
`getsetup` function, which would look something like:
|
|
||||||
|
|
||||||
sub getsetup () {
|
# list of options to include in web setup (safe = all things with safe = 1)
|
||||||
eval q{use Some::Thing};
|
websetup_include => [qw{safe}],
|
||||||
die $@ if $@;
|
# list of options to exclude from web setup
|
||||||
|
websetup_exclude => [qw{option_baz}],
|
||||||
|
|
||||||
return option_foo => {
|
Leaning toward just making it write out to the same setup file, rather than
|
||||||
safe => 1,
|
writing to a subsidiary setup file. However, this would mean that any
|
||||||
rebuild => 1,
|
comments in the file would be lost, and that it couldn't be used if the
|
||||||
type => "boolean",
|
setup file had weird stuff (perl code, etc).
|
||||||
default => 0,
|
|
||||||
description => gettext("Enable foo."),
|
|
||||||
},
|
|
||||||
option_bar => {
|
|
||||||
safe => 0,
|
|
||||||
rebuild => 0,
|
|
||||||
type => "password",
|
|
||||||
default => "",
|
|
||||||
description => gettext("Password for bar."),
|
|
||||||
};
|
|
||||||
}
|
|
||||||
|
|
||||||
The types would be: boolean, string, password, filename, other.
|
|
||||||
This would be the type of the leaf fields; if a value in `%config` is an
|
|
||||||
array or hash, the type specifies the type of values that go into it.
|
|
||||||
|
|
||||||
From this info, a form can be built, that has core setup values at the
|
|
||||||
top, followed by each plugin whose `getsetup` succeeded, with a check box
|
|
||||||
to enable/disable that plugin, and all of its setup options listed after
|
|
||||||
it.
|
|
||||||
|
|
||||||
The main setup file could control what options are read from the
|
|
||||||
online setup file:
|
|
||||||
|
|
||||||
online_setup_include => 'safe', # all things with safe = 1
|
|
||||||
online_setup_exclude => [qw{option_baz}],
|
|
||||||
|
|
||||||
Note that posting the setup form would sometimes need to cause a rebuild
|
|
||||||
of the whole wiki. This could be done with output streamed to the admin in
|
|
||||||
the web browser. The `rebuild` fields would be set to 1 for values that
|
|
||||||
require a wiki rebuild when changed, and to 0 for values that only need the
|
|
||||||
wrappers to be refreshed.
|
|
||||||
|
|
||||||
[[!tag wishlist]]
|
[[!tag wishlist]]
|
||||||
|
|
Loading…
Reference in New Issue