phpwiki-talk

Re: [Phpwiki-talk] SiteMap plugin

[Reini U. <ru...@x-...>]

Lawrence F. London, Jr. schrieb:
> /cgi-bin/viewcvs.cgi/phpwiki/phpwiki/SiteMap: unknown location
> 
> Got the same message at http://phpwiki.sourceforge.net/phpwiki/SiteMap
> when executing:     *  Src: PhpWikiCvs:lib/plugin/SiteMap.php

Sorry, there must be brackets around it.
* Src: [PhpWikiCvs:lib/plugin/SiteMap.php]

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phpwiki/phpwiki/lib/plugin/SiteMap.php

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] visualwiki & webdot

[Reini U. <ru...@x-...>]

aphid schrieb:
> does VisualWiki give a hoot which version of webdot is used (tcl or perl)?

we are using the natively compiled dot version.
on sf.net even a static build, because there's no gcc.
no tcl/tk support included, no perl, no X. just dot.

http://www.graphviz.org/
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] index.php vs config.php

[Joby W. <joby@u.washington.edu>]

Thanks for the comments Jeff.  I wasn't actually proposing that we (or 
I, as if I had the skill...) write the bindings for Webmin or a 
Gnome/KDE plugin, just that this model would make it a bit easier to do 
so if desired in the future.

I just want to propose a more atomic structure for the configuration 
files.  We have the following goals for our config file structure:

1) Seperation between user settings and defaults
2) No parsing to get user or default settings (this is ok for a daemon, 
but for a script that has to reparse for each pageview, it is just more 
overhead).
3) One authoritative source for config variables and the potential 
values for those variables.
4) Clean interfaces which increase flexability and will decrease 
breakage over time.

Seperate config-user.php and config-dist.php files does (1). Having the 
config-user and config-dist files be in php does (2). (3) can be done in 
a variety of ways, but in my proposal config-valid.php's only purpose is 
to be authoritiative. By putting validation and only validation in one 
file we can design a clean interface so that the validation tools can be 
used by a variety of interfaces and those interfaces should not need 
significant management to maintain compatability over time.

> 
>>class valid_bool{
> 
> ...
> 
>>	is_valid($new){
>>		if(is_bool($new)){
>>			$this->new = $new;
>>			return true;
>>		}
>>	}
> 
> 
> Since it changes the state of the valid_bool object,
> is_valid is a BAD, BAD method name.  (Should be,
> maybe, set_new(), or set_new_checked() or something
> like that.)
> 

Yeah I saw that just before I sent it, but since this was more for the 
idea rather than the actual code, I left it.  Should have split 
is_valid() into is_valid() and set_new() and have set_new() call is_valid().

jbw

[Phpwiki-talk] visualwiki & webdot

[aphid <me...@ap...>]

does VisualWiki give a hoot which version of webdot is used (tcl or 
perl)?

cheers
a

Re: [Phpwiki-talk] index.php vs config.php

[Jeff D. <da...@da...>]

> A proposal:

It sounds like a decent one.

A few not particularly germaine comments:

> Config applications:
> n) more options, such as a plugin to a web management app (webmin), a 
> GUI app (Gnome or KDE), or perhaps a ncurses app.

Just in case you're seriously considering writing something like that:
keep in mind that (I think) the way to go is to use a scripting-type
language (e.g. python or perl) with GUI (or curses) bindings.  Development
is
much easier (IMHO), and the result is (or can be) much more portable
(easily).  (A fair amount of our user base seems to be Windows based...)
(Or one could use Java... which makes it, in theory (haha), automatically
portable...)


> class valid_bool{
...
> 	is_valid($new){
> 		if(is_bool($new)){
> 			$this->new = $new;
> 			return true;
> 		}
> 	}

Since it changes the state of the valid_bool object,
is_valid is a BAD, BAD method name.  (Should be,
maybe, set_new(), or set_new_checked() or something
like that.)

> ... thus config-valid.php would be the authoritative source.
> 
> Configurator.php and cli-config.php would just know how to use the tools
> 
> presented by config-valid.php and generate an interface.

Seems good.  "One authoritative source" is a good goal.
And if it's in PHP (rather than something we have to parse)
life will be easier.  (Until you want to write the fancy GUI
C/perl code...)

Re: [Phpwiki-talk] index.php vs config.php

[Aredridel <rs...@nb...>]

Having defaults (loaded first) and a user-override file makes a lot of
sense -- it's easy to parse, and easy to write a configurator for.
That'd be my preference for sure.

If one uses a configurator, the defaults could be coded into a
load-configuration routine, leaving the option typing and structure in
code, where it's most flexible and doesn't involve writing any parser.

Having a configurator spit out a file to upload isn't too bad, and I
like the idea of a CLI configurator.

Downsides:  If done this way, a configurator would either have to parse
PHP or be written in PHP -- not an issue I think, since this /is/
PHPWiki, and there's no sense in using something else since this is a
prerequisite for the rest of the project anyway.

Simplicity is a good thing, as is a central place for configuration in
the code.  In my own projects, I use defines if not defined in my
libraries, and to override, just define before require.  Documenting
settings is easy, really, and a configurator could serve as
documentation rather easily.  The system is scalable, and defines are a
plus since they're inherently superglobal even in PHP3, so no version
messes to deal with.  Code optimizers deal with them efficiently, and
the parse time on my several thousand lines of code is milliseconds.

Ari

Re: [Phpwiki-talk] index.php vs config.php

[Joby W. <joby@u.washington.edu>]

A proposal:

My solution is a bit more complicated (because there are four elements), 
but it would involve a lot less parsing and allow for multiple methods 
of configuration.

The current proposal is for three parts:

1) config-dist.php -> Default distribution config settings
2) config-user.php -> Implimentation's config settings
3) Configurator.php -> elements to configure via wiki

The current debate is whether to put the validation elements in 
config-dist.php (as notes in the comments) or Configurator.php (would 
just be code).  Since the validation of settings is really a seperate 
function, I would just make it a fourth file, thus:

Config elements:
1) config-dist.php -> Default distribution config settings
2) config-user.php -> Implimentation's config settings
3) config-valid.php -> defines what is a valid data for a setting 
(authoritative source).

Config applications:
1) Configurator.php -> elements to configure via wiki
2) cli-config.php -> config via command line
n) more options, such as a plugin to a web management app (webmin), a 
GUI app (Gnome or KDE), or perhaps a ncurses app.

config-dist.php and config-user.php would just be the define()s and 
variables set.

config-valid.php would contain classes to validate configuration data 
and the authoritative settings, such as:

-------------------------------------
class valid_bool{
	valid_bool($variable){}
	get_default(){}
	get_current(){}
	get_description(){}
	is_valid($new){
		if(is_bool($new)){
			$this->new = $new;
			return true;
		}
	}
	
	get_new(){
		if(isset($new)){
			return $new;
		} else {
			return $current;
		}
	}
	

}

$reverseDNS = array(
		'type' => 'boolean',
		'define' => true, // true if use define, else variable
		'name' => 'ENABLE_REVERSE_DNS',
		'description' => "If set, we will perform...");

$valid_reverseDNS = new valid_bool($reverseDNS);

-----------------------------------------------

The above is really rough and just for the idea.  In this situation, 
when someone starts a virginwiki and the Configurator.php file is called 
the config-dist.php file would be generated from this config.valid file 
-- thus config-valid.php would be the authoritative source.

Configurator.php and cli-config.php would just know how to use the tools 
presented by config-valid.php and generate an interface.

jbw

Re: [Phpwiki-talk] SiteMap plugin

[Lawrence F. L. Jr. <lf...@in...>]

Reini Urban wrote:
> Lawrence F. London, Jr. schrieb:
>> Is there a location where I can download a SiteMap plugin?

> Enter this in your wiki 
>   PhpWikiCvs:lib/plugin/SiteMap.php
> or see http://phpwiki.sourceforge.net/phpwiki/SiteMap

Thanks Reini,

When editing a test page I added this line:

! View Site Map for the Permaculture Wiki:   PhpWikiCvs:lib/plugin/SiteMap.php

... and got this error message when trying to run sitemap from the saved page:

/cgi-bin/viewcvs.cgi/phpwiki/phpwiki/SiteMap: unknown location

Got the same message at http://phpwiki.sourceforge.net/phpwiki/SiteMap
when executing:     *  Src: PhpWikiCvs:lib/plugin/SiteMap.php

-- 
L.F.London
lf...@in...
http://market-farming.com
PermacultureWiki
http://www.ibiblio.org/ecolandtech/pcwiki/index.php

Re: [Phpwiki-talk] simplify default template

[Jeff D. <da...@da...>]

> >>How about changing the pagename "FindPage" => "Search" on the default 
> >>template? (German: "Suche")
> > 
> > 
> > A little confusing.  I would think "Search" would be the submit
> > button for the quick search form.  "FindPage" serves the function
> > that on most web pages is labeled "Advanced Search".
> 
> Why not call it then pgsrc/AdvancedSearch and add a RedirectTo FindPage?

I suppose that would be okay.  I kinda like FindPage though.  It's
really more descriptive of what you get on that page.  (The only
"advanced search option" you get there is whether to do a title
or a full text search...  And the idea is that FindPage should have
links to any good IndexPages or other browsing entry points on the wiki.)

("FindPage" has a long wiki-history, as well...  it originated on the
original wiki.)

("AdvancedSearch" definitely takes more real estate than "FindPage", too.)

> Okay. I'll revert.

Thanks!

Re: [Phpwiki-talk] Single word action pages?

[Jeff D. <da...@da...>]

> But if the single word page in question has the plugin included it 
> qualifies as actionpage also, so it would be okay to remove it.

Not as the code currently stands... but that could be changed.
(Currently the action has to match $WikiNameRegexp before the
check for a <?plugin is made.)

Re: [Phpwiki-talk] simplify default template

[Reini U. <ru...@x-...>]

Jeff Dairiki schrieb:
> On Sun, 15 Sep 2002 21:26:24 +0100
> Reini Urban <ru...@x-...> wrote:
>>I now committed it now to CVS.
> 
> As I think I said, I, at least, don't like it.
> 
> If I had to pick one out of (Info, Diff, PageHistory) to leave
> on the main page I'd definitely pick PageHistory.  Most of the 
> Info stuff is just not interesting to most readers.
> 
> If you're reading a page, what are you most likely to want to
> know about that page:
> 
>   Who wrote it (both the latest version, and who's contributed
>   to the page the most)  
> 
>   When it was written (when were the bulk of the changes made
>   to the page?) (when was the most recent change?)
> 
>   What changes were made?
> 
> Who cares how may words are on the page (the viewers already
> looking at the page)?  The hit count may be
> of interest, but probably only to the pages author.  What markup
> version?  Only someone who's going to edit the page cares, and
> they'll find that out when they try to edit it.
> Everything else on the Info page (and much more) is available
> on the PageHistory page...
> 
> 
>>How about changing the pagename "FindPage" => "Search" on the default 
>>template? (German: "Suche")
> 
> 
> A little confusing.  I would think "Search" would be the submit
> button for the quick search form.  "FindPage" serves the function
> that on most web pages is labeled "Advanced Search".

Why not call it then pgsrc/AdvancedSearch and add a RedirectTo FindPage?

> Also FindPage is a wiki link (to the page FindPage).  Are you planning
> on renaming pgsrc/FindPage to pgsrc/Search?  I don't think it's 
> worth the trouble.

Yes, this was my idea.

> In the end either is okay, but I would vote for the status quo,
> because it's the status quo.  (If you move the page FindPage to Search,
> it just creates a little more pain for everyone who upgrades their
> PhpWiki.)
> 
> 
>>Of course one can create his own navbar.tmpl template version.
> 
> Of course.  So there's no need to keep mucking with the stock one. :-)
> 
> Leaving too many buttons in the stock template is probably better
> than too few (within limits, of course) -- at least people will
> see what's possible, and it's much easier to figure out how to
> delete them from the templates than it is to figure out how to
> add them back....

Okay. I'll revert.

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] SiteMap plugin

[Reini U. <ru...@x-...>]

Reini Urban schrieb:
> Lawrence F. London, Jr. schrieb:
>> Is there a location where I can download a SiteMap plugin?

> or see http://phpwiki.sourceforge.net/phpwiki/SiteMap

Note that it doesn't yet include breadth-first search,
which will be fixed really soon.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Single word action pages?

[Reini U. <ru...@x-...>]

Jeff Dairiki schrieb:
> I just found this in WikiRequest::isActionPage:
> 
>  $singleWordActionPages = array("Historique", "Info", _('Preferences'));
> 
> I really would like to avoid hardcoding magic pagenames into the
> PhpWiki source code.  I know there are other places where page
> names are hardcoded as well (e.g. HomePage and InterwikiMap)
> 
> But, in this case, this seems completely unnecessary to me.
> Why shouldn't these pages be called PageInfo and UserPreferences
> (both of which are significantly more descriptive of their
> purpose than just Info and Preferences.)

True. I was just testing single word SubPages.
I liked the idea of [/Info] [/Help] [/Preferences] ...

But if the single word page in question has the plugin included it 
qualifies as actionpage also, so it would be okay to remove it.

> (I know no French, so can't rag specifically on Historique.  But
> I suspect that similar arguments apply...)
> 
> Also _("Today"), _("Administration"), and _("Help") appear
> as hardcoded action page names in WikiRequest::requiredAuthority().
> I'm not sure if these are even used...  But: keep in mind that
> these are names of wiki pages.  Can't they be more descriptively named?
> The requirement that they be WikiWords doesn't really seem
> overly restrictive to me in these cases.

I found this useful on my test setup. I believe it was only for 
aesthetic reasons, so that these buttons appear consistently with the 
neighbors.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] SiteMap plugin

[Reini U. <ru...@x-...>]

Lawrence F. London, Jr. schrieb:
> Is there a location where I can download a SiteMap plugin?

Enter this in your wiki

   PhpWikiCvs:lib/plugin/SiteMap.php

or see http://phpwiki.sourceforge.net/phpwiki/SiteMap
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Single word action pages?

[Jeff D. <da...@da...>]

I just found this in WikiRequest::isActionPage:

 $singleWordActionPages = array("Historique", "Info", _('Preferences'));

I really would like to avoid hardcoding magic pagenames into the
PhpWiki source code.  I know there are other places where page
names are hardcoded as well (e.g. HomePage and InterwikiMap)

But, in this case, this seems completely unnecessary to me.
Why shouldn't these pages be called PageInfo and UserPreferences
(both of which are significantly more descriptive of their
purpose than just Info and Preferences.)

(I know no French, so can't rag specifically on Historique.  But
I suspect that similar arguments apply...)

Also _("Today"), _("Administration"), and _("Help") appear
as hardcoded action page names in WikiRequest::requiredAuthority().
I'm not sure if these are even used...  But: keep in mind that
these are names of wiki pages.  Can't they be more descriptively named?
The requirement that they be WikiWords doesn't really seem
overly restrictive to me in these cases.

[Phpwiki-talk] SiteMap plugin

[Lawrence F. L. Jr. <lf...@in...>]

Is there a location where I can download a SiteMap plugin?
-- 
L.F.London
lf...@in...
http://market-farming.com
PermacultureWiki
http://www.ibiblio.org/ecolandtech/pcwiki/index.php

Re: [Phpwiki-talk] New Markup

[Jeff D. <da...@da...>]

I've just added support for named anchors within wiki-text.

They work as per the suggestions made on NewInlineMarkup.

Anchors are defined like this: here is #[anchor1].
You can reference it like this: please see [#anchor1].
You can also, of course, specify the text for the anchor (or the link).

Anchor two is #[here | anchor2].
Please see [above | #anchor2] for the definition of anchor two.

You can of course also link to [anchors on other pages | SandBox#demo ].




I am working towards eliminating the old markup transformation code
in transform.php in favor of the new markup code.  To this end I am
working on a translator which will translate old markup to new markup.
(The named anchors were necessary to be able to implement support
for the old-markup footnotes.)

I think now the only other old-markup construct which cannot be
translated to new markup is the old-style tables.
As I've yet to come up with a syntax for tables which I like enough
to incorporate into the new markup rules, I think for the interim,
I'm just going to write an OldStyleTable plugin which will make
it possible to completely translate any old-style markup to new-style.

Anyone have a better idea for a table syntax?

One we're back to one markup transform engine, I'm going to work
on unifying the link extraction with the markup engine, and,
best of all, work on caching marked up wiki-text.

Re: [Phpwiki-talk] simplify default template

[aphid <me...@ap...>]

On Monday, September 16, 2002, at 11:41  AM, Jeff Dairiki wrote:
> ...
> Who cares how may words are on the page (the viewers already
> looking at the page)?  The hit count may be
> of interest, but probably only to the pages author.  What markup
> version?  Only someone who's going to edit the page cares, and
> they'll find that out when they try to edit it.
> Everything else on the Info page (and much more) is available
> on the PageHistory page...
>

Maybe there should be separate menubar templates for admin and user.  
Rather than checking for admin for each button, do it once for the page 
and figure out which files to include.  Just a thought.

Cheers
A

Re: [Phpwiki-talk] index.php vs config.php

[Joby W. <joby@u.washington.edu>]

Jeff Dairiki wrote:
>>First it would be in PHP, I hate writing Perl.
> My current first choice would be python :-)

Python is pretty cool, but I am a language bigot.  I prefer C-like 
syntax languages.

> 
> More seriously, many people may not have the CGI/standalone version of
> PHP installed (properly) which makes running standalone PHP scripts
> a bit problematic.   The standalone PHP does not seem to be available
> in the RedHat 7.1 distribution, for example (though it is included
> in the 7.2 RPMs --- dunno about 7.3.)
>  

Oh I agree that not all would use it, but if we can provide 
configuration application independance by having settings be determined 
by the default config settings file (config-dist.php), then maintaining 
different configuration applications is trivial.  Although devising the 
commented code and parsing it seems non-trivial.

> 
>>My main motivation is to avoid exposing my database settings over the 
>>web.  Do you want it potentially available on the web that your data is 
>>in a MySQL database named 'phpwiki' on host 'sql.example.com' and logs 
>>into that database as 'wikiuser' with the password of 'securepasswd'?
> 
> 
> I see your point.
> 
> Perhaps the configurator script could be made so that it doesn't
> reveal the current values of sensitive settings --- it would still,
> of course, give you the option to change the setting to something else.
> You'd see something like:
> 
>   MySQL database name: <has been set, not shown for security reasons>
>             Change to: _______________________
> 
> (Or if a database name hasn't yet been set)
> 
>   MySQL database name: _________________________
> 

This would only work because the configurator exports the 
config-user.php file to be used.  If the file it exports has the current 
settings (assuming no changes) then we have the same problem.  If it 
doesn't include the settings then the end user will have to: 1) add the 
info each time, 2) manually merge the current (old) with the exported 
(new), 3) we would have to provide a tool to merge the data.

Another work around for the above senario would be to split the 
config-user.php file into multiple files -- non ideal.

> An alternative would be to make it so that the configurator never reads
> the installed config file.  Instead give the user an opportunity
> to POST a config file from which settings would be pulled.

This is more secure, but it does involve many extra steps:

1) download current config-user.php
2) Access action=configurator
3) upload current config-user.php
4) Edit
5) download new config-user.php
6) upload new config-user.php

This does also expose the database settings to man-in-the-middle attacks.

I understand that I am being extra paranoid (part of my job), so I don't 
want to veto ideas because they don't meet my needs even though they 
might be sufficient for the vast majority of other users.  Having the 
config settigs be accessable only by an administrator and using https 
should be sufficient for most users.

But from my paranoid perspective, I would like to provide a very secure 
route for configuration -- which is command line.

jbw

Re: [Phpwiki-talk] index.php vs config.php

[Jeff D. <da...@da...>]

> First it would be in PHP, I hate writing Perl.

My current first choice would be python :-)

More seriously, many people may not have the CGI/standalone version of
PHP installed (properly) which makes running standalone PHP scripts
a bit problematic.   The standalone PHP does not seem to be available
in the RedHat 7.1 distribution, for example (though it is included
in the 7.2 RPMs --- dunno about 7.3.)
 
> My main motivation is to avoid exposing my database settings over the 
> web.  Do you want it potentially available on the web that your data is 
> in a MySQL database named 'phpwiki' on host 'sql.example.com' and logs 
> into that database as 'wikiuser' with the password of 'securepasswd'?

I see your point.

Perhaps the configurator script could be made so that it doesn't
reveal the current values of sensitive settings --- it would still,
of course, give you the option to change the setting to something else.
You'd see something like:

  MySQL database name: <has been set, not shown for security reasons>
            Change to: _______________________

(Or if a database name hasn't yet been set)

  MySQL database name: _________________________



An alternative would be to make it so that the configurator never reads
the installed config file.  Instead give the user an opportunity
to POST a config file from which settings would be pulled.

Re: [Phpwiki-talk] index.php vs config.php

[Joby W. <joby@u.washington.edu>]

Jeff Dairiki wrote:
> Of course, if Joby wants to write a perl configurator as well, then
> the problem comes back....  oh well  Personally, I'm not sure we need
> a standalone (non web based) configurator script.  It think Reini has
> already suggested this but here's a possible UserStory:
> 

First it would be in PHP, I hate writing Perl.

My main motivation is to avoid exposing my database settings over the 
web.  Do you want it potentially available on the web that your data is 
in a MySQL database named 'phpwiki' on host 'sql.example.com' and logs 
into that database as 'wikiuser' with the password of 'securepasswd'?

jbw

Re: [Phpwiki-talk] simplify default template

[Jeff D. <da...@da...>]

On Sun, 15 Sep 2002 21:26:24 +0100
Reini Urban <ru...@x-...> wrote:

> I now committed it now to CVS.

As I think I said, I, at least, don't like it.

If I had to pick one out of (Info, Diff, PageHistory) to leave
on the main page I'd definitely pick PageHistory.  Most of the 
Info stuff is just not interesting to most readers.

If you're reading a page, what are you most likely to want to
know about that page:

  Who wrote it (both the latest version, and who's contributed
  to the page the most)  

  When it was written (when were the bulk of the changes made
  to the page?) (when was the most recent change?)

  What changes were made?

Who cares how may words are on the page (the viewers already
looking at the page)?  The hit count may be
of interest, but probably only to the pages author.  What markup
version?  Only someone who's going to edit the page cares, and
they'll find that out when they try to edit it.
Everything else on the Info page (and much more) is available
on the PageHistory page...


> How about changing the pagename "FindPage" => "Search" on the default 
> template? (German: "Suche")

A little confusing.  I would think "Search" would be the submit
button for the quick search form.  "FindPage" serves the function
that on most web pages is labeled "Advanced Search".

Also FindPage is a wiki link (to the page FindPage).  Are you planning
on renaming pgsrc/FindPage to pgsrc/Search?  I don't think it's 
worth the trouble.

In the end either is okay, but I would vote for the status quo,
because it's the status quo.  (If you move the page FindPage to Search,
it just creates a little more pain for everyone who upgrades their
PhpWiki.)

> Of course one can create his own navbar.tmpl template version.

Of course.  So there's no need to keep mucking with the stock one. :-)

Leaving too many buttons in the stock template is probably better
than too few (within limits, of course) -- at least people will
see what's possible, and it's much easier to figure out how to
delete them from the templates than it is to figure out how to
add them back....

Re: [Phpwiki-talk] index.php vs config.php

[Jeff D. <da...@da...>]

> No, it doesn't work that way. The configurator knows nothing about the
> config-dist.php file at the moment.
> 
> But I agree that it would be cool to have the configurator get it's
> data from a config-dist.php file which should be a fully functional
> file itself.

Yes, or we just treat the configurator.php as the ultimate authority
and generate the default config file using configurator.php.
Then the problem of keeping the two in sync goes away.

Of course, if Joby wants to write a perl configurator as well, then
the problem comes back....  oh well  Personally, I'm not sure we need
a standalone (non web based) configurator script.  It think Reini has
already suggested this but here's a possible UserStory:

(First: configurator.php should not be the entry point, the entry
should be through the main wiki script --- this allows configurator.php
to properly autodect things like VIRTUAL_PATH...)

1. The Configurator is fired up by browsing the main wiki script, either
   with a query_arg of action=configurator, or if the wiki is a virgin,
   unconfigured wiki, it fires up the configurator automatically...

   Note that configurator.php should not be the entry point, the entry
   should be through the main wiki script --- this allows the configurator
   to properly autodect things like VIRTUAL_PATH.

2. The configurator reads in the current configuration file (if it
exists),
   merges in defaults and autodetected values, then presents the user
   with the configurator form.

   Specially formatted comments in the
   config file could be used to indicate the default/autodetected values
   of each setting --- this would allow the configurator script to
determine
   whether a setting has been customized, and would also allow give the
   human reader useful information.  E.g.:

	/* VIRTUAL_PATH
         *
         * VIRTUAL_PATH is the ... blah blah...
         *
         * Example: 
         *   define('VIRTUAL_PATH', '/SomeWiki')
         *
         * Default Value:
         *   define('VIRTUAL_PATH', '/foowiki')
         */
        define('VIRTUAL_PATH', '/foowiki');

   When merging the current configuration with default/autodetected 
   values the configurator would pick the current config values only
   if they had been changed from their default values (at the time
   the current config script was produced).

3. When the user has changed whatever settings he wanted to change, he
   hits the "Download new configuration" button, and a new config file
   gets downloaded (to the client computer, not the server).

4. Then the new configuration file must then be manually installed on the
   server in the appropriate place (via FTP, rcp, scp, etc...)
  

Re: [Phpwiki-talk] index.php vs config.php

[Martin G. <gim...@gi...>]

Jeff Dairiki <da...@da...> writes:

> I think it would be real slick if the config script got all its info
> from (specially formatted) comments (and code) in the dist-config
> file. (Maybe it already works that way?)

No, it doesn't work that way. The configurator knows nothing about the
config-dist.php file at the moment.

But I agree that it would be cool to have the configurator get it's
data from a config-dist.php file which should be a fully functional
file itself.

Perhaps something we could extend the JavaDoc like comments:

<?php

/*#
 * Select driver for X.
 *
 * If you want to do X, then you have to select the right
 * driver.
 *
 * #type     select
 * #choices  foo bar baz
 * #depends  Y
 */
if (!defined('X')) define('X', 'foo');

/*#
 * The greeting
 *
 * Please specify a greeting.
 *
 * #type     text
 * #default  Hello World
 */
if (!defined('Y')) define('Y', 'Hello World');

?>
 
I just don't know how this scheme could be made general enough to work
with all cases. For PhpWeather I have a system with dependencies and
validators which gives me a lot of flexibility. I think it will be
hard to turn that into a system with enhanced comments.

Unless, of course we simply hide the relevant PHP code in a comment
and then have the configurator execute it:

<?php

/* ## Begin configurator code
 *
 * $port_validator = new pw_validator_range("Sorry, '%s' is not a valid port-number " .
 *                                          "because is't outside the range 1-65536",
 *                                          1, 65536);
 *
 * $proxy_dep = new pw_dependency('use_proxy', 'true');
 * 
 * $options['proxy_port'] =
 *     new pw_option_integer('proxy_port',
 *                           "This is the port number of the proxy server. The " .
 *                           "default is what is used by the Squid proxy server. " .
 *                           "Another common port number is '8080'",
 *                           array($proxy_dep), $port_validator, 3128);
 *
 * ## End configurator code
 */ 

The configurator script could find the right comment, strip the
leading ' * ' from each line and run it through exec(). But isn't this
getting kind of silly now? :-)

> Then problems with keeping the configurator in sync with the config
> options go away....

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

Re: [Phpwiki-talk] index.php vs config.php

[Jeff D. <da...@da...>]

> The current configurator lets you create a configuration that you can
> /download/ and then later upload using FTP or whatever mechanism you
> use for this.

Oh yes, I agree.  I think that's definitely the way it ought to work.
(If I said something else, I didn't mean it...)

What I was trying to suggest was that the generated config file should
contain the values for those config settings which are being defaulted (or
auto-detected) as well as those modified by the user.   I.e. all the
defaulting and auto-detecting should happen in configurator.php, rather
than (as it is currently done) in lib/config.php.

This saves the run-time overhead of computing the defaults on every
invocation of PhpWiki, and allows the user to easily override the defaults
via configurator.php (or by manually editing the resulting config file.)