[pmwiki-users] Re: more flexible page-sharing for farms

[Bronwyn Boltwood]

On 8/6/05, chr at home.se <chr at home.se> wrote:
> On Sat, 6 Aug 2005, Bronwyn Boltwood wrote:
> 
> > Now that I'm using my wikifarm more, I've noticed that my page-sharing
> > needs may be more complex than the Use Common Pages recipe
> > (http://www.pmwiki.org/wiki/Cookbook/UseCommonPagesInAWikiFarm) accounts
> > for. Many of the pages I want to use for shared, farmwide defaults, are
> > exactly the pages that I need to customize for my admin work (e.g.
> > Site.Sidebar). Yet other pages need to exist to ease maintenance, but
> > shouldn't be seen in the other fields.
> 
> I'm noticing similar issues. Not quite sure what you mean by "admin work"
> though?

Just the work of administering the wikifarm, really. 
 
> I'm trying to deal with this by having Site/ shared, while creating a
> group called Field/ in each field. Then I have to move field specific
> pages from Site/ into Field/.

That sounds promising, but I think I'll wait for you to get a livable
resolution for "[pmwiki-users] Problem with shared group and
AllRecentChanges" before I rearrange anything myself.  But I'm
starring that idea for later reference.

> What kind of problems do you have more specifically?

So far they fall into two cases:
- I need a default version of a page for sharing, but I also want a
version for this field.
	- Site.Sidebar.  Want an admin-customized version with links to the
documentation and configuration pages I use the most when working on
the wikifarm.
	- Skin furniture pages, like Site.ActionList and Site.Footer.  Want
versions customized for admin work (e.g. ?action=rename links)
- I need a version for this field, but don't want to share the page at all.
	- Your other thread now has me mildly worried about what must be
happening with the various recent changes pages.
	- I use Main.Linkdump to hold links to new pages for admin or testing
purposes, which really shouldn't be seen in random fields...
	
I've only enabled the code for using the wikifarm's wiki.d for default
pages in addition to wikilib.d.  I haven't enabled the code that, if a
shared page is edited from some other field, copies the edited version
back to the shared field.  I'm not sure how it would change the
situation for the better, and I thought that I might want to have
custom versions of certain pages in other fields.  Ironically, I want
them most in the very field that can't have them.

I thought I was just creating a shared field, but I was trying to do
several things in one action, without knowing it.  What I was trying
to achieve wasn't precisely a shared field, but more of a personal
wikilib.d, one that wouldn't get clobbered by upgrades.  Maybe adding
another layer doesn't help, but encourages infinite regression.  What
I want is
- admin-related content and skin, to be used while administering any field
	- collection of links to default versions of skin furniture pages
	- annotated collections of links most useful for certain areas (skin
development, markup, customization, etc)
	- collection of links to doc pages created by me that are kept in the
shared default content
- shared default content, like replacement quick reference and text
formatting pages, or skin furniture pages to be included in skin
distros

Now that my brain is turning over more rapidly, I see that there are
creative possibilities for some (:includes:) and/or (:if auth admins:)
here.

> > So, could we have a "shared page" attribute with similar levels of
> > configurability to passwords?  (That is, farm, field, group, and page
> > levels.)
> 
> Hmm... I'm not sure how well it'd work in pracitce.

Neither am I; it's just one idea for how to solve the problem I've
got, because one of the first things I realized was that certain pages
needed their sharedness status controlled at a page level, not a group
or field/farm level.

Bronwyn