17 Aug
2009
17 Aug
'09
10:48 p.m.
On Mon, Aug 17, 2009 at 6:51 AM, Guillaume Lerouge <guillaume(a)xwiki.com>wrote;wrote:
Please consider that there may be issues in upgrading from old Xwikis into
either 1.9 or 2.0. For example, I previously mentioned two possibilities:
(1) Old javascript from previous version of Xwiki running at same
URL,residing in user's browser-cache, breaking on mismatch with new server
code for new xwiki version, leaving critical-documents in half-updated
state. This happens after first edit to membership of users or groups prior
to browser cache getting updated. (Is there a way to have javascript
recognize it's gone stale and "shift-reload" itself automatically on first
run after upgrade??)
One more thought on this issue: if you have upgraded your Xwiki, be sure to
Today I have
been told
that the xwiki database was imported from a previous xwiki instance and
not created from the scratch. So we decided to make a xwiki
installation from the scratch and this worked like a charm. Having a
look at the
log would also probably have helped us. There were a lot of exceptions
thrown by Hibernate (but I am not sure that they are all related to my
problem).
We'll be glad to receive further feedback through the lists as you keep
using XWiki.
issue a shift-reload command in your browser on the
home page, and probably
on any important administrative pages. The bug we're seeing could be
coming from two different possible sources: (1) New upgrade XAR overwriting
system-specific configurations present
in XWiki.XWikiAdminGroup, XWiki/.WikiAllGroup, XWiki.XWikiPreferences; (2)
New upgrade WAR containing new javascript code, but same-path as previous
javascript code that resides in browser cache. The new WAR was expecting to
talk to the new javascript, but instead, talks to the old javascript. On
browsers like Mozilla/FireFox, errors like calling nonexistent javascript
functions happen without the end-user noticing, unless special steps are
taken to see if javascript errors are happening. If the latter scenario
happened, it could have left your Xwiki in a "half updated" state because
the application never got the expected response from Javascript. (The bug
would then be the lack of "defensive programming" on the part of Xwiki to
detect this situation ...)
It is entirely possible that the initial add-user and
edit-groups bugs
that cause these administrative features to break happened with "old
javascript in the browser" coming from a previous version of Xwiki.
(2) Something changed (schema? data-format? new fields?
new-UTF8-dependency?) such that old XWikiPreferences XWikiAdminGroup or
XWikiAllGroup need to be "reset" by hand:
First, browse /xwiki/bin/view/XWiki/XWikiAllGroup if this doesn't have all
the registered users of your wiki listed, then they
will not have privilege
to do much of anything on the wiki. This can happen, for example, if you
overwrite your original XWikiAllGroup file with the one from the XAR at
import-time. If that happens, or if XWikiAdminGroup is similarly
overwritten or damaged, then additional administrators won't be granted that
privilege.
Hand editing of the objects associated with these
documents may be
necessary if the above happens,. Hand editing is also necessitated by the
new bug that occurs from "add user" or "add member to group" causing
/xwiki/bin/view/XWiki/XWikiAllGroup and
/xwiki/bin/view/XWiki/XWikiAdminGroup to not list the associated users. I
guess this must be a regression introduced into 1.9 as 1.8 didn't have this
problem, and also had a different implementation and appearance for viewing
XWikiAllGroup and XWikiAdminGroup.
To hand-edit these documents, as 'Admin',
select document menu
Edit->Object.
In the object editor, note that each object is displayed in an "accordion"
with each object
heading looking like "XWiki.XWikiGroups[11]" (1.8) or "Objects of type
XWiki.XWikiGroups...XWikiGroups 6:
XWiki.NielsMayer" (2.0). Fully expand the
accordions to see the contents of the objects you want to verify and edit.
On each of these group-documents (e.g.
XWiki.XWikiAdminGroup,
XWiki.XWikiAllGroup), there are multiple object instances of
XWiki.XWikiGroups, each having a single "Member" field; that field contains
a single valid XWiki user. Verify that the document referenced as the user,
e.g. XWiki.NielsMayer exists and has appropriate "rights" for each user
listed as "Member." Delete any XWiki.XWikiGroups instances that don't
correspond to a real user on your wiki; use the "Add Object" panel on the
right to add new instances of XWiki.XWikiGroups to the group docs for any
users not listed. (You don't need to
delete an invalid member and separately add a valid one, just change the
invalid document in the "member" field to a
valid one).
Finally, go to Administration->Rights and make sure
the group documents you
just "hand edited" have appropriate rights, e.g. Wiki.XWikiAdminGroup should
probably have "Edit" "Delete" and "Admin" checked;
XWiki.XWikiAllGroup
should probably have "View" and "Comment" selected. This might be
needed
if you overwrote XWiki.XWikiPreferences in importing the new XAR. On the
other hand, sometimes you might need to overwrite XWiki.XWikiPreferences
(e.g. in upgrading Xwiki across big revision changes).
It's probably a good idea to allow XWiki.XWikiPreferences to get overwritten
across big Xwiki revision changes, just re-do
Administration-> General,
Presentation, Registration, Programming and Rights.
One helpful tip is to use your browser's form-field autocompletion features
to save the contents of the fields of the "old
wiki" by re-saving General,
Presentation, Registration, Programming and Rights prior to upgrading the
wiki. After upgrading, use your browser's memory of prior form fileds to
reinsert the appropriate prior form-field contents back into the form, and
re-save.
-- Niels
http://nielsmayer.com