VoteOnSiteHeader-Talk
Return to VoteOnSiteHeader
My main concern is to allow flexibility to the group/page authors (within the privileges provided by the admin of course). It should be easy and fairly obvious to override the default situation for any group and/or any page. The desired results are to:
- have neither a site-wide or a group-wide header
- have a site-wide header only
- have a group-wide header only
- have both a site-wide header and a group-wide header
For Pm's Proposal 1
For a given Group:
- Neither:
- have no Site.DefaultGroupHeader? and no group.GroupHeader?, or
- have an empty group.GroupHeader? so that the Site.DefaultGroupHeader? won't be used either
- Group-only: have a group.GroupHeader? file
- Site-only: have no group.GroupHeader? file so that the Site.DefaultGroupHeader? will be used
- Both: have a group.GroupHeader? file with an (:include Site.DefaultGroupHeader:)
It is also necessary for an individual page to be able to override the group settings and decide on its own. This gets complicated to describe every possible case, but it is always possible to use (:nogroupheader:) and then (:include Site.DefaultGroupHeader:) or (:include group.GroupHeader:) as desired. The one case (that I can foresee) that fails is that the page cannot force a site-only header when the group.GroupHeader? includes Site.DefaultGroupHeader?.
For Pm's Proposal 2a
For a given Group:
- Neither: I think you need a (:nogroupheader:) in an otherwise empty group.GroupHeader? to do this - this is too weird.
- Group-only: I think you need a (:nogroupheader:) in group.GroupHeader? followed by the group header markup to do this
- Site-only: have no group.GroupHeader? file so that only Site.AllGroupHeader? will be used
- Both: have a group.GroupHeader? file
It is also necessary for an individual page to be able to override the group settings and decide on its own:
- Neither: (:nogroupheader:)
- Group-only: (:nogroupheader:) and (:include group.GroupHeader:)
- Site-only: (:nogroupheader:) and (:include Site.AllGroupHeader:)
- Both: this is the normal case
For Pm's Proposal 2b
For a given Group:
- Neither: (:nositeheader:) in an otherwise empty group.GroupHeader?
- Group-only: (:nositeheader:) in group.GroupHeader?
- Site-only: have no group.GroupHeader? file so that only Site.SiteHeader? will be used
- Both: have a group.GroupHeader? file
It is also necessary for an individual page to be able to override the group settings and decide on its own:
- Neither: (:nositeheader:) and (:nogroupheader:)
- Group-only: (:nositeheader:)
- Site-only: (:nogroupheader:)
- Both: this is the normal case
Explanation on my vote:
Good for site wide messages, display page titles with dynamic information about a page (comments, creation date, last modified, file, hits and possibly others) this proved to be good for skins authors like myself, also important to keep this inside SiteAdmin for security. But I don't agree on (:nositeheader:) because this could be used to trick a user with a specially made GroupHeader that looks the same as a SiteHeader? if the SiteHeader? file is being used by a skin to display information about the currently browsed page. Plus, I think this is the easiest option to implement between all others and the admin has a way to comunicate with all users/editors of the site, whitout having the chance of someone supress the the content of SiteAdmin.SiteHeader?, using a (:nositeheader:) directive.
CarlosAB June 18, 2007, at 04:37 PM
About possibility 3:
I think that my reasons for not having 1a as a good option, are: simplicity and (a little bit more of) security.
Simplicity: One file only for the admin, to be sure that his message gets trough the whole site.
Security: No way to skip, supress or fake messages from the admin and it can be easily verified by users and editors - by just looking at SiteAdmin.SiteHeader? or been sure that the message comes right after a page title.
And another thing is that I'm thinking not as an editor but as an admin, I guess, so GroupHeader should be used by authors and SiteHeader? by the admin, and "skinners" only have to change $GroupHeaderFmt, to include a page (maybe SiteAdmin.SkinHeader?) it processed.
CarlosAB June 18, 2007, at 05:08 PM
Page footer
The current page footer (containing Edit - History - Print - Recent Changes - Search Page last modified on, which is specified in the Template should be moved to a SiteAdmin page and this would both meet the suggestion (2d) and provide a more and more easily customisable PmWiki! Simon
The site-wide and group-wide headers should be controllable separately. It's easy to conceive someone who would want to suppress the group-wide header and not the site-wide one. If this option is chosen, then a wiki administrator should be advised not to define wikistyles in the site's header because they'll vanish when someone does a (:nogroupheader:)...
(:nositewideheader:) is *much* more intuitive compared to (:noallgroupheader:) (to the uninitiated, not necessarily to the crowd who would read this note). Keep in mind that all authors will see the directive up at the top of the page. IMHO if it's confusing it's distracting, even for authors who don't care much about site-wide and group-wide wikitext.
--Hagan
Another thing is that wikistyles defined in SiteHeader? can be changed by an editor just defining the same style in GroupHeader, is this the best behavior? WikiStyles defined in SiteAdmin.SiteHeader? shouldn't be honored?
CarlosAB June 18, 2007, at 06:43 PM
If this seems difficult to vote on, it is. We are now trying to find a solution for three separate issues at the same time:
- define a site-wide group header that can't be turned off
- define a site-wide header that can be turned off
- define a default group header to be used when a group doesn't have it's own
All of these are useful things, but do we need all of them or can some be left as a recipe. Pm, do you want to pull us back on course?
Actually Scott, I think you've hit the nail on the head. These are the three things we want, now we can waste three times as much time discussing what names to use!
Scott and Simon,
I don't think these are the three things...
- Pm is not proposing a site-wide group header that can't be turned off. Scroll to the top of this page and read Pm's numbered list of desired results.
- Without a doubt we want a site-wide header that can be turned off. The questions are
- Should the site-wide header turn off automatically when a group header Page exists?
- Should
(:nogroupheader:)turn off both the site-wide and group headers, or - should there be a separate
(:nositeheader:)directive?
- No matter what it will be possible to define a default group header to be used when a group doesn't have it's own. The question is whether that should be the default behavior. I don't see this happening once it's thoroughly thought through.
IMHO
- The best solution is for the site-wide header not to "turn off automatically" by default. It should be able to be done using markup (conditional markup in the site-wide header). As a default, it could lead to unintended broken pages if there are wikistyle definitions in the site-wide header.
- A separate
(:nositeheader:)directive will give authors the most control with the least "surprise".
Coming up with names to use is probably the hardest part.
--Hagan
The list at the top of this page is confusing to me, is it an and list or an or list.
- You ask Should the site-wide header turn off automatically when a group header Page exists?
Its clear to me that the answer is No. This is because in a group header it can be turned off (for the group) by specifying (:nositeheader:) (I hope).
- should there be a separate
(:nositeheader:)directive?appealing to the principle of least surprise though consistency (with other similar features) I feel the answer is Yes.
So we are in agreement, now to convince everyone else! thanks Simon