[pmwiki-users] PmWiki configuration via PmWiki (was: Action lists in skins)

Joachim Durchholz jo at durchholz.org
Wed Apr 20 15:51:08 CDT 2005


Neil Herber wrote:
> At 2005-04-09  11:18 PM +0200, Joachim Durchholz is rumored to have said:
> 
>> Neil Herber wrote:
>>
>>> Then I came across Gemini Two which allowed me to specify my own set 
>>> of actions in whatever order I chose, and they were both highly 
>>> desirable traits. I did not have to look at the sticky entrails of 
>>> CSS, I just had to populate a list on a PmWiki page. The biggest 
>>> advantage being that I could modify the menus with any browser from 
>>> anywhere. I did not have to be able to FTP a new CSS file to some 
>>> remote server. This is not an insignificant point to me.
>>
>> Would it be more of a problem if that were done in config.php?
> 
> Yes, this is more of a problem if done in config.php because I can't 
> edit config.php when sitting in an internet cafe. With a 
> PmWiki-page-based solution, I just need browser access ( and to remember 
> my password for the menu/action/bar pages).
> 
> Usually the only menus that I change after establishing a stable 
> configuration are the left and right sidebars.

Ah, OK.

I was thinking in terms of learning curves.

Hmm... I do agree that having configuration in wiki pages is generally a 
good idea. And it's not just limited to the question of how to separate 
action lists from skins, it's a general thing.

Some things definitely must be done within config.php - stuff like 
setting up $ScriptUrl that makes sure that you can access the site in 
the first place.

However, most of the things that are currently done could be done via 
wiki pages. PmWiki already can accept input from a HTTP connection and 
store it in files, so why not move everything (except those very basic 
things) into pages?

There are a few details that currently prevent recipe authors from 
reading configuration info off wiki pages:

1) There is no convention for that. For example, if the PmWiki 
documentation stated something like "the PmWikiConfiguration group is 
reserved for storing configuration information; we recommend that recipe 
Foo store its configuration data in PmWikiConfiguration.Foo", recipe 
authors would pick up on that lead. (The current lead is "configure in 
local/config.php". I confess I haven't thought much about real 
alternatives; one of the things that made me instinctively shy away from 
a wikipage-based configuration for action lists was that it would 
distribute the configuration over two places, config.php and wikipages; 
that would make transferring a configuration from one wiki to another 
more difficult, for example.)

2) Recipe writers aren't sure how to read data from wiki pages. This 
starts with the question what function to call ($page->ReadPage(), I 
think), whether the returned data has wiki markups substituted or not 
(not, I think).

3) For configuration pages, markup processing should be completely 
switched off. Say a configuration line says
   $UploadUrlFmt = 'http://www.maquaris.de/uploads'
PmWiki would apply all markup to the line, making the http://... stuff 
into a link. Actually this particular example wouldn't be a real 
problem, but other markup might render the settings entirely unreadable.

4) Configuration pages should be excluded from page search functions 
(i.e. (:pagelist:) and (:pagesearch:) markups). Either this would have 
to become a page attribute, or the pages should go to a separate group, 
or some other characteristic of the page should be used for that.

5) For me, it's unclear whether configuration pages should use PHP, 
PmWiki, or skin syntax. I'd prefer to have just one syntax for all 
configuration, but that may be impossible to achieve, or simply impractical.

What does everybody think?

Regards,
Jo



More information about the pmwiki-users mailing list