Published by marco on
This article was originally published on the Encodo Blogs. Browse on over to see more!
Once you’ve got an XWiki up and running (whether you imported a Mediawiki or not), you’ll find you want to tweak the standard rollout a bit.
After working a while with XWiki, you may notice it getting slower. Our XWiki was kind of slow from the get-go and we pretty quickly figured out why: the slowdown was caused almost entirely by the pretty, DHTML list of all pages in the panel on the right side. It apparently takes quite some time to build this list (and ours included hundreds of pages from the import); it will have to go.
We edited the side-panel to replace the culprit Panels.SpaceDocs
with Panels.Spaces
. This still gives us the ability to navigate directly to a spaces WebHome, but doesn’t waste time building up enormous lists of pages that we almost never used.[1] Navigate to your Main-Page and enjoy your lightning fast XWiki.
Since the WYSIWYG editor trashed some of our converted pages (we never investigated why exactly) we switched the default editor to the XWiki editor.
This can be done for all users by setting the default editor on the Administration/Preferences/Editing
page. Each user can override this behaviour on their own user page.
Although the newest XWiki seems have a skin other than Albatross as a default, we updated the current skin to fix up the following things that annoyed us:
<pre>
and <code>
blocks takes up way too much space#toc
macro) show up with bullets—even when they’re numbered.Our fixes for these things are shown below. YMMV.
The first step is to create a custom skin (as described under “changing the logo for the Albatross skin”). Once you’ve done that, from the same form that you set the logo
property, you can set your own style
(it should be the second property in the form).
You can type any valid CSS into this box and it will be included in all of your XWiki pages. In fact, if this property is non-empty, it is the only skin-CSS included by XWiki. It sounds ominous; what does it mean? It means that you must copy the entire Albatross skin-CSS to your custom skin in order to at least start off with the base look-and-feel. The best way to do this is with the following standard CSS import[2]:
@import "http://yourwiki/xwiki/skins/albatross/style.css";
After this import statement, feel free to include any of the CSS snippets below.
Each heading has its own CSS-class associated with it. You have to set each and every one and our settings are shown below. We used values that matched our CI, more or less.
.heading-1 {
font-size:14pt;
margin:12pt 0pt 3pt;
padding:0pt;
line-height:1.5em;
}
.heading-1-1 {
font-size:12pt;
margin:12pt 0pt 3pt;
padding:0pt;
line-height:1.5em;
}
.heading-1-1-1 {
font-size:12pt;
margin:12pt 0pt 3pt;
padding:0pt;
line-height:1.5em;
font-weight: bold;
}
.heading-1-1-1-1 {
font-size:10pt;
margin:12pt 0pt 3pt;
padding:0pt;
line-height:1.5em;
font-weight: bold;
}
.heading-1-1-1-1-1 {
font-size:10pt;
margin:12pt 0pt 3pt;
padding:0pt;
line-height:1.5em;
font-weight: bold;
}
As with most of the other updates, this fix involves removing a lot of padding and margins, as well as toning down the coloring. We use the “Consolas” font by default because we all have Office 2007 installed (you’ll want other defaults, like “Monaco” if you’re using OS X). Code blocks still have a light-grey background color, whereas pure preformatted blocks no longer have any color or border at all.
.code {
background-color:#EEEEEE;
border:1px dotted #336699;
font-family:"Consolas",courier new,monospace;
font-size:9pt;
margin-bottom:4px;
margin-top:4px;
overflow:auto;
padding:5px;
white-space:pre;
width:85%;
}
.code pre {
padding: 0px;
margin: 0px;
border-width: 0px;
background-color: #EEEEEE;
}
pre {
background-color: white;
border: 0px;
padding:4px;
}
This is an easy one: simply remove the bullets.
.tocEntry {
list-style-type: none;
}
Tone down colors; remove margins and padding; make the hurting stop. Note the use of the !important
CSS directive to force the style to be used over another, more-specific style defined in another stylesheet.
.wiki-table th, .wiki-table td {
padding: 2px;
}
.wiki-table th {
padding: 4px 2px;
font-size: 100%;
font-weight: bold;
background-color: #EEEEEE;
border-bottom: 1px dotted #336699;
}
.wiki-table {
margin: .5em 0em;
border: 1px dotted #336699 !important;
background-color: #EEEEEE;
}
Make definition terms bold by default; fix up the margins for the definition body. Definition lists are really useful in wikis, so it’s important that they look good.
dt {
font-weight: bold;
}
dd {
margin: .15em 1.5em .75em 1.5em;
}
These areas benefit from the fixes for tables made above, but they still need a bit more massaging before their color and margins are subdued enough—they are, after all, not the main elements on the page. The fixes involve setting the remaining backgrounds/background-colors to none
or transparent
.
.xwikiintratitle {
font-size:100%;
font-style:normal;
font-weight:bold;
margin:0px;
padding:8px 0px;
}
#xwikidata #attachmentscontent, #xwikidata #attw, #xwikidata #commentscontent, #xwikidata #commentscontent .xwikititlewrapper
{
background: none;
}
#xwikidatacontents
{
margin: 1em 0em;
}
This fix removes the background color and turns the question mark brick-red, which is much more subtle than the default.
.wikicreatelinkqm
{
background: transparent;
color: #CC0000;
font-weight: bold;
}
And, finally, printing: here we remove the print header entirely[3] and take out the borders on the two main containers. The border change will affect the non-printing view as well, but it has no visible affect.
#printheader
{
display: none;
}
#xwikimaincontainerinner
{
border: 0px;
}
#xwikimaincontainer
{
border: 0px;
}
import
that file instead.↩