Scope of a Panel Configuration
Explanation
A Panel configuration is not global: the same wiki can show one set of Panels on its home page and another on a blog post. Three levels decide what a reader finally sees, each narrower than the last.
The wiki level is the Panel Wizard opened from the wiki administration. It writes leftPanels, rightPanels, showLeftPanels, showRightPanels, leftPanelsWidth and rightPanelsWidth onto the XWiki.XWikiPreferences xobject, and applies to every page that does not override them.
The page level is the same Wizard opened from a page's administration. It writes the same six properties onto that page's WebPreferences, and they replace the wiki values for that page and the pages under it. This is why the blog "Categories" Panel can appear beside a blog post and nowhere else.
The Panel level is the Panel's own "Content", and it is the only way to make a Panel conditional on something the two levels above cannot express, such as a single page or a group of users. A Panel that tests the current page before it outputs anything is placed once, at wiki level, and still shows up only where you want it:
#if ($doc.fullName == 'Main.WebHome')
#panelheader('Recent changes')
... the Panel's usual content ...
#panelfooter()
#endWhat none of the three levels controls is the shape of a column the reader can see: whether it is collapsed, and how wide it is, is each reader's own choice, kept in their browser.
FAQ
Why is a page-level configuration ignored on a child page?
It is not, unless that child sets its own. A page's configuration applies to the pages under it until one of them overrides it.
How do I go back to the wiki configuration for one page?
Remove the six panel properties from that page's WebPreferences xobject. An empty value is a value, and keeps overriding the wiki.
Which level wins if a Panel is listed at wiki level and excluded at page level?
The page level, because the two lists never merge: the narrower one replaces the wider one outright.
