Hi Nigel,
On Mon, Nov 2, 2009 at 3:09 AM, Nigel Smith<subscriptions(a)nianca.net>wrote;wrote:
Hello,
I'm a very keen and happy user of xwiki. We use it for our corporate
intranet and our users love it!
Glad to hear that :-)
I generally move directly between major
versions as soon as convenient. The factor that has the most bearing on
when we upgrade is the ease with which we can move between new versions.
I remember seeing an items relating to simpler installation. I'd like to
ask when that is scheduled to be worked on, and perhaps share some of my
experiences in upgrading and some suggestions.
A part of it (related to import) is being worked on right now. The work on
a
full-fledged Extension Manager has not started yet.
I'd like to give you an idea of what has to be done to move between
versions. It's a bit long, so bear with me,
but here it is:
* Download the latest xwiki xar to your local machine
* Download the latest xwiki war to the machine which will run xwiki.
* Backup the entire xwiki installation directory (the one that contains
the directories database, jetty, lucene etc), and move the old directory
aside (rename to xwiki.old)
* //We do this to easily be able to get the jetty, hsql, etc dirs back
in place//: Restore the backed up xwiki directory, thus putting the
xwiki dir back in place
* Delete the directory xwiki/webapps/xwiki
* In xwiki/webapps, create an xwiki directory
* Unzip the xwiki war in the xwiki/webapps/xwiki directory
* //Getting our corp logo back//: Copy
xwiki.old/webapps/xwiki/skins/toucan/mywiki.jpg to
xwiki/webapps/xwiki/skins/toucan/mywiki.jpg
* //Next few steps: need to merge old config with new config//: Do a
diff between xwiki.old/webapps/xwiki/WEB-INF/xwiki.cfg and
xwiki/webapps/xwiki/WEB-INF/xwiki.cfg. Update
xwiki/webapps/xwiki/WEB-INF/xwiki.cfg as needed.
* Do a diff between xwiki.old/webapps/xwiki/WEB-INF/xwiki.properties and
xwiki/webapps/xwiki/WEB-INF/xwiki.properties. Update
xwiki/webapps/xwiki/WEB-INF/xwiki.properties as needed.
* Do a diff between xwiki.old/webapps/xwiki/WEB-INF/hibernate.cfg.xml
and xwiki/webapps/xwiki/WEB-INF/hibernate.cfg.xml. Update
xwiki/webapps/xwiki/WEB-INF/hibernate.cfg.xml as needed.
* //This is the part we fear the most, for we might accidentally delete
some configuration that we need and we would need to start the whole
process again//: Start XWiki and import the default wiki xar. Be careful
of what you import - read the instructions at
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Installation#HUpgrading…
.
** The normally excluded pages from import are:
*** XWiki.XWikiPreferences
*** XWiki.XWikiGroups
*** XWiki.XWikiAdminGroup
*** XWiki.WebPreferences
*** XWiki.WebHome
*** XWiki.XWikiUsers
*** XWiki.XWikiAllGroup
*** XWiki.DefaultSkin
*** Main.WebHome
*** Panels.QuickLinks
*** Panels.Search
* //We customise the PDF cover//: The PDF covers files has been manually
modified. Do a diff between
xwiki.old/webapps/xwiki/templates/pdfcover.vm and
xwiki/webapps/xwiki/templates/pdfcover.vm. Merge the differences.
* //We customise the PDF footer//: The PDF footers file has been
modified by hand. Do a diff between
xwiki.old/webapps/xwiki/templates/pdffooter.vm and
xwiki/webapps/xwiki/templates/pdffooter.vm. Merge the differences.
* //We do this to be able to specify the PDF template to use in "Export
as PDF"//: The Menuitems have to be edited by hand, so that PDFs are
exported using the correct stylesheet. Do a diff between
xwiki.old/webapps/xwiki/templates/menuview.vm and
xwiki/webapps/xwiki/templates/menuview.vm. Merge the differences (there
should only be one line).As you can see, there are quite a few steps,
and it normally takes 1/2hr - 1hr to complete. Note that we will move to
MySQL eventually, but the performance of HSQL is OK ATM.
Thanks for the feedback.
This may not be the most optimal upgrade path, so if there are any clear
improvements you can see, please let me know.
The part that needs to be improved upon the most, in my opinion, is the
"import default XAR" step because it is easy to overwrite an important
page. I would like to put in a big vote for separating information that
can be modified by the user from information that xwiki needs to be able
to operate, that comes with default xwiki. Perhaps making certain pages
"system" pages so that it is clear that if a page is modified it may
interrupt the operation of the wiki, and may be difficult to upgrade.
Definitely. This is the most dangerous part and it has triggered manny
mistakes in the past. One of the XWiki developers is currently working on a
patch that will improve the way the import works: imported pages will add a
version to existing pages instead of overriding them. He should be able to
commit his patch in the 2.1 timeframe.
About marking "system" pages, that has been started a bit too ->
you'll
notive that in the default XAR some pages are marked as having been modified
by the "superadmin" user.
The next most important thing to be improved is
the storage of
configuration that now sits in xwiki.cfg and xwiki.properties. This is
difficult to migrate between versions. If this was automatically
migrated between versions like the pages are, this would be much easier
to manage. At our office we have a large system written in Java and we
solved a similar problem using the Java Preferences API.
Being able to fully customise the PDF layout (not just the stylesheet)
inside xwiki, and also specify a default PDF style sheet to use during
export would be #3 on my list.
You can already do that:
Edit your XWiki.XWikiSkins XClass definition document with the class editor
and add the following TextArea properties to it: pdfcover.vm, pdfheader.vm,
pdffooter.vm and put your code here. By the way, you can also add a
menuview.vm property to your skin XClass and put your code for that vm right
in the skin. Then once you define the Skin Document you're using as you'
wiki's skin document in the preferences your custom skin will be applied to
the wiki.
Better, just add the two files as attachments, without changing the
class or the object.