[Pmwiki-users] Easily Hackable?

Fabio Reis Cecin frcecin
Mon Apr 5 07:33:48 CDT 2004


On 4 Apr 2004 at 23:23, Eric Celeste wrote:

> (...)
>    staff/committees/personnel
>    staff/committees/operations
>    staff/committees/outreach
> 
> In this example, all the leafs (main, cookbook, niftymenu, niftysidebar,
> comments, personnel, operation, outreach) are pages. If I try to go to
> "staff/committees" I find a page with the "Describe committees? here" note,
> because it does not yet exist as a page. However "staff/committees" does
> exist as a group, and the attributes assigned to that group also apply to
> all pages inside that group, until overridden by deeper attributes.

Question: In the current PmWiki I can come up with pages with the same 
name, but in different groups. Does this scheme supports this? (two pages 
with the same  name, but in different contexts (groups)).

What about implementing the group metadata inside pages? In the example
above, the page "staff" could have contents like this (mock-up markup):

<group>
committees
</group>

And the page "committees" could have these contents:

<group>
personnel
operations
outreach
</group>

They would display as a "this page is a group", with a list of the pages
in the group, and maybe other options such as "click here to administer
this group's passwords" or something like that.

So the page's contents would be a place to store all kinds of metadata and
scriptlets and etc. for the group. Of course, wiki vandals would have then 
pages they can vandalise and cause major hassle to the wiki (an entire 
group of pages...). Maybe group pages could be set to an "append only"
mode, where you can just add pages to the <group> tag, not remove 
(like, currently you can add pages to a group, but not remove pages from
a group or move pages between groups). 

This suggestion may not be so good (actually it sucks) but my point is that 
if there is a way to keep your idea working as smoothly as with the 
current group.page scheme (where you can create and manage groups, 
and passwords to pages and groups using your _browser_ not a ssh 
client to the machine and vi to edit the *.php -- oh the pain), then I'm all 
for it :-)

I'm willing to bet that most wiki admins can cope with lots of extra 
_browsing and clicking_ to configure their wikis properly, but not extra
(download .php, configure .php via shh/vi to the server, patch .phps, ...)

- Fabio



More information about the pmwiki-users mailing list