Optimizing XWiki
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.
Speeding up XWiki
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.
Changing the default editor
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.
Changes to the default skin
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:
- The default heading sizes are simply enormous
- The comments/attachments boxes are way too bulky, showing up as huge blue splotches at the bottom of every page.
- The default formatting for
<pre>
and<code>
blocks takes up way too much space - Tables have enormous margins and are bright blue
- Table-of-contents entries (displayed with the
#toc
macro) show up with bullets—even when they’re numbered. - The print-preview page has a thick, black border around it and it always prints the XWiki logo rather than the logo from the skin
- The “page not found” marker is over-the-top and distracting
- Definition lists have only default HTML formatting, which gives the definition block way too much left margin
Our fixes for these things are shown below. YMMV.
Setting Defaults
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.
Fixing Headings
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;
}
Fixing Code and Preformatted Blocks
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;
}
Fixing the Table-of-Contents
This is an easy one: simply remove the bullets.
.tocEntry {
list-style-type: none;
}
Fixing Tables
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;
}
Fixing Definition Lists
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;
}
Fixing Comments/Attachments
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;
}
Fixing “Page-not-found” Links
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;
}
Fixing Print-Preview
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.↩