On Mon, Aug 17, 2009 at 6:51 AM, Guillaume Lerouge <[email protected]>wrote:
> > 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. > 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 > 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 _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
