Re: [xwiki-users] Users not displayed

Christian Ribeaud &lt;christian.ribeaud(a)canoo.com&gt;om>: And when using the administration panel, items is displayed). 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 becoming 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. This is not an Xwiki problem, it is a Web problem. Ultimately, it's something that's entirely in the control of the person running the website, and not really something that Xwiki can control (other than the "defensive programming" bit). You might see this issue more often in Xwiki because the team is doing software development "the right way" which means continuous improvement, continuous revisions, regular releases, and lots of users testing and using the software in every possible unexpected situation, etc. Microsoft's "release infrequently, and badly" approach means users only get to see these kinds of compatibility problems on each new service pack or browser upgrade, and that's at best once every few years. With the furious pace of Xwiki development, we can end up seeing this bug every few months, and that's just fine by me. Shift-reload is your friend. So if you're having problems in this regard, it is in no way "Xwiki''s fault -- just change your sites sub-domain name, or the path to Xwiki documents -- and you'd implicitly fix this problem for this or any web software on each upgrade. If the web-site doesn't want users to see this problem, one can easily add a "revision number" in the path to the javascript libs so that the browser will automatically load the new "revision" (the path changed, nothing in cache) as opposed to using the one in the cache. (This might actually be a good bit of "defensive programming" for Xwiki -- add a "revision code" to the path of any javascript lib referenced in the browser, and then just have xwiki do the path-rewriting magic to verify incoming requests are for the correct "revision code", and serve up correct files out of <xe-WAR>/resources/js ). This is also a world where my BANK's website doesn't work on any current browser I use day-to-day (FireFox 3.5.3 on x86_64 Linux, Chrome on Windows) and pops up errors all over the place when using my current up-to-date IE 8. Which means we're doing financial transactions underpinned by something as flaky as IE's "Javascript." So really, in comparison, the kind of problems we see in Xwiki are minor in comparison. Furthermore, the architect and original designer has joined this thread, so he'll probably have it fixed in 5 minutes once we've actually done our part of the "open source social contract" and have helped better characterize the problem. No need to wait a year for Microsoft to deliver a new service pack here in Xwiki land.... Finally, Xwiki is "open" enough, both at the software level, and even at the data level with "everything is a wiki doc" that we can actually diagnose and fix these problems ourselves. You think you'd have been so quick to do the same kind of fix I suggested for Xwiki using, by analogy, Microsoft's "registry editor" ?? Xwiki is in great shape. It is undergoing a massive transformation at this time, typical of 1.0->2.0 transitions. Fundamentally, Xwiki is an amazing application and there's really no competition for it. ( http://blog.asyd.net/2008/12/xwiki-cest-decidemment-magique/ (C'est vrai!), http://www.opensolaris.org/os/community/web/restructuring/wiki_eval_x/ http://madplanet.com/xwiki/bin/view/Blog/Rough+Diamond ) You do not necessarily need to be running the latest and greatest revision unless you're ready to deal with the latest and greatest issues. This wisdom doesn't just apply for Xwiki... it's endemic to software. Sometimes, you just have to forgo upgrades, and just wait a bit. For example I'm still running Win XP Service Pack 2, and I'm not going to upgrade to Service Pack 3, which i already know will break a bunch of things that work just fine right now. (My use of Win XP is just an engine to run http://cygwin.com so I can use windows as an X terminal and also test whether things work in IE :-) ).. For critical things, it's *ALWAYS* safest to wait a few months to upgrade -- wait for all the reports from "bleeding edge" users like me that are willing to deal with some pain to get the latest and greatest. (IMHO, w/r/t Xwiki 2.0, the pain is well worth it !!! But then again, I'm an xwikizochist :-) ). Also, upgrades should never happen without a dry-run first. Clone the data, go through the entire upgrade process on a different system/server, and take notes and resolve any issues that arise before considering doing the same thing to a live site. Nothing ever goes right the first time, so instead of wasting a lot of back-patching issues, and handholding unhappy users, make sure your users won't be surprised in the first place by testing the upgrade and new software, before rolling out to a "live" site. -- Niels http://nielsmayer.com PS: Regarding the javascript shift-reload issue: I really think that digital signatures need to be incorporated into javascript used in browsers. Before an app uses a JS "package" it would request the digital signature of the JavaScript the browser is using, and check it against what the app expects to be using. Only after this check you'd know you're talking to the exact intended javascript lib, as opposed to either an old incompatible revision; or even worse, bogus javascript that has been specifically overridden in a few places to intercept or alter communications back to the server. Ultimately, each javascript closure being executed needs it's own digital signature, composed of the digital signatures of the transitive closure of all functions that might be called out of a given closure, and of course, any response by this closure back to the server would need to be signed by this signature,and checked on the other end for validity/tampering. Oh well, I can dream, can't I?