Thomas Gries wrote: A 1.4 backport has no future, so I'd rather not waste time and effort maintaining it. But feel free to set one up on your own web site. -- brion vibber (brion @ pobox.com)

Liking the new features, but the account creation totally boggled me. I entered my name, and my favourite "temporary" password, and clicked "Create new account". Without warning me, it sent me an email with a *new* password. The confusing thing is that it would seem that the system remembered the password I had entered previously, so when I tried to change it from the gash password from the email, it complained...I only found out by trial and error that my original password was operational. Is this actually a change in policy or is this just how the test system is set up? -- Phil [[en:User:Phil Boswell]]

"Brion Vibber" <brion(a)pobox.com> wrote in message news:4268C314.6060602@pobox.com... Oh, it worked fine...it was simply that it failed to tell me properly that my original password would be restored just as soon as the garbage one had been used to verify the account creation. The system seems to work OK, it just needs better instructions. Obviously there might be more technical problems underneath the bonnet :-) -- Phil [[en:User:Phil Boswell]]

the login password, as well as some general code cleanup backing that.The user >table has changed a bit, so those of you tracking CVS HEAD be sure to run update.php. Brion: In SpecialPreferences.php of CVS HEAD, all these 11 lines need to ***deleted*** now, please, This solves the feature, the users are complaining about. Tom (about line 269 seq. in SpecialPreferences CVS HEAD) if ($wgEmailAuthentication) { # mail the econfirm-token to the dirty address # on "save options", this user will be logged-out automatically $error = LoginForm::mailPasswordInternal( $wgUser, true, $dummy ); if ($error === '') { return LoginForm::mainLoginForm( wfMsg( 'confirmationmailsent', $wgUser->getName() ) ); } else { return LoginForm::mainLoginForm( wfMsg( 'mailerror', $error ) ); } # if user returns, that new email address gets confirmed in checkpassword() }

Brion: EConfirm, well done, I like it. There are some outstanding issues with ENotif (e.g. bugs), which I have fixed for the current head version on my pc; I think of posting the diff to bugzilla at about 27.06.2005 02:00 UTC . short: All enotif-calls as such have been moved from Article.php to logically correct place in RecentChange.php NotifyChange and NotifyNew, further decreasing total amount of code lines for enotif. "(last seen)" links. Optional e-mail notification for _new_ pages (for sysops, developers, and bureaucrats) in a few additional lines. Memcache-efficient way of user_newtalk signalling is fully back, this table is not handled by enotif. User page changes are also signalled in the newmessage marker. Updaters.inc included. Wikinaut Tom

The Email notification feature seems to be working OK but there are a couple of points which I've noticed: * The "You have new messages" banner when my talk page is changed does not go away when I read my talk page. Neither does it go away when I edit my talk page. It seems to go away only when I click the "Reset all notification flags" button on my watchlist: this is *not* expected behaviour. * When you click said "Reset all notification flags" button, you get taken to the "select for removal" mode of the watchlist: it would be more expected to show an updated watchlist with the "updated" flags removed. * It would be handy to have the option to roll up a bunch of notifications into a single email, say every hour, so that you don't get hit by a flurry of tiny little emails all looking very similar :-) * I would hope that the luminous green ENORMOUS flags on the Watchlist will be replaced by something rather smaller and better formatted: a green "U" to the left next to the existing "N" and "m" flags would be ideal. While on the subject, there's no chance the formatting of the watchlist/recentchanges could be cleaned up is there? When a long entry wraps, the result is really ugly, and the flags get lost in the noise. I know there are some people out there who react to HTML tables like a vampire to garlic, but these pages really let the project down when they look so messy. -- Phil [[en:User:Phil Boswell]]

One thing I just noticed: if you add a new section (usually by clicking the "+" link on a talk page) and then use the "Show Changes" feature, the result alleges that you are about to replace the *entire* page with your new section. Oops much? -- Phil [[en:User:Phil Boswell]]

Sabine Cretella wrote: Unless you're willing to put up with a lot, you should probably install the current 1.4 stable release. We have not yet released a beta test version of 1.5, and database structure changes are still being made. A stable release of 1.5 is currently scheduled for June 1. In theory, the upgrade from 1.4 to 1.5 should be automated and relatively clean. If you track the current development and future beta code, you might have to do more manual clean-up and fixing, and can fully expect to have things not working and possible data loss in the meantime. -- brion vibber (brion @ pobox.com)

Phil Boswell wrote: Good point, that feature will run this query: $dbw->update( 'watchlist', array( /* SET */ 'wl_notificationtimestamp' => 0 ), array( /* WHERE */ 'wl_title' => $title->getDBkey(), 'wl_namespace' => $title->getNamespace(), 'wl_user' => $this->getId() ), 'User::clearLastVisited' ); ...on every logged in page view. This should be made optional, because we'll have to switch it off on Wikipedia for performance. Knowing how MySQL locks have a tendency of infecting unrelated indexes, I dare say this will be a concurrency nightmare. -- Tim Starling

Thomas Gries wrote: Did you even read the post you're replying to? I'm sorry you consider our changes "butchering", but since you don't listen to any advice we give you, there's really no other option. -- Tim Starling