[pmwiki-users] Utility pages

Patrick R. Michaud pmichaud at pobox.com
Wed Jun 15 21:15:25 CDT 2005


On Wed, Jun 15, 2005 at 03:45:14PM -0500, Benjamin Wilson wrote:
> 
> I would say that using "Main" as the default term for those pages is a
> "not-broke" item. So, if it ain't broke, don't fix it. Give us either a
> core function allowing us to define $UtilityGroup as we please, or
> create a recipe that will override default PmWiki behavior (I prefer the
> former); but don't change the present layout of those pages.

Your comment about leaving "Main" alone makes lot of sense (and it's
the argument I used to make); unfortunately, there's an argument to be
made that the existing naming scheme is indeed "broken", or if not then
it's on the verge of breaking.

PmWiki already defines or uses:

    Main.AllRecentChanges
    Main.ApprovedUrls
    Main.PageNotFound
    Main.SearchWiki
    Main.SideBar

In addition, cookbook recipes add things like:

    Main.Blocklist

Soon we'll be adding "EditForm" and "ActionList" to the set, and
arguably the PmWiki.EditQuickReference and PmWiki.UploadQuickReference
pages are in the wrong place.

None of these pages are really "site content" (which is what Main should
probably contain) -- they're scaffolding to support other operations.  
So, it's a bit strange that they default to the group where new sites 
will naturally start placing content, and this is why we get frequent
questions about removing these pages from searches and various
page listings.

More to the point, in newly installed systems admins often have to be 
told or reminded to add passwords to the pages (because they're in 
"Main", which is open for editing), where some of them such as 
ApprovedUrls and Blocklist really ought to be protected by default 
without the admin having to remember to set a password.  This also
argues for these pages to go into a group away from "Main" that can
have appropriate protections.

> Are we going to
> increase the burden of upgrading for those who haven't come back in a
> great while? 

Oh, I'm certain I'll come up with something that makes the upgrading
process less painful, or at least somewhat seamless.  But it's not only
a question of increasing burden for existing sites, but also a question
of increasing burden for new adopters of PmWiki, or those who want to
extend it even further.

I agree that we could probably continue to patch things on the existing
scheme for a while to come, but eventually we'll want to switch.  It's
probably better to do it now, while PmWiki still has "beta" in its
release names, than to do it shortly after releasing 2.0.

And again, I'll definitely come up with something to try to make
this transition as seamless as I can.

Pm



More information about the pmwiki-users mailing list