[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