I've got a 1.5 test wiki now up for you kind folks to use and abuse:
-- brion vibber (brion @ pobox.com)
Brion, can you please also set up REL1_4 + ENOTIF ? But then, I publish and send you a newer code than current http://bugzilla.wikipedia.org/show_bug.cgi?id=454
Tom
Brion Vibber schrieb:
I've got a 1.5 test wiki now up for you kind folks to use and abuse:
-- brion vibber (brion @ pobox.com)
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Thomas Gries wrote:
Brion, can you please also set up REL1_4 + ENOTIF ? But then, I publish and send you a newer code than current http://bugzilla.wikipedia.org/show_bug.cgi?id=454
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)
Brion Vibber wrote: I've got a 1.5 test wiki now up for you kind folks to use and abuse: http://test.leuksman.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 Boswell wrote:
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?
It's supposed to be an e-mail verification system, but it's pretty badly broken and needs to be replaced with one that actually works in a reasonable manner.
-- brion vibber (brion @ pobox.com)
"Brion Vibber" brion@pobox.com wrote in message news:4268C314.6060602@pobox.com...
Phil Boswell wrote:
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?
It's supposed to be an e-mail verification system, but it's pretty badly broken and needs to be replaced with one that actually works in a reasonable manner.
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 :-)
Brion Vibber wrote:
Phil Boswell wrote:
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?
It's supposed to be an e-mail verification system, but it's pretty badly broken and needs to be replaced with one that actually works in a reasonable manner.
I've cleaned it up a bit to separate the email confirmation token from 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 vibber (brion @ pobox.com)
Brian wrote I've cleaned it up a bit to separate the email confirmation token from
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() }
Thomas Gries wrote:
Brian wrote I've cleaned it up a bit to separate the email confirmation token from
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, I've already replaced all that.
-- brion vibber (brion @ pobox.com)
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
Thomas Gries schrieb:
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.04.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
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Brion Vibber wrote: I've got a 1.5 test wiki now up for you kind folks to use and abuse: http://test.leuksman.com/
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 Boswell wrote:
- 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.
It seems to work fine for me. Can you narrow it down to a reproducable set of actions which triggers the problem?
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.
We already have two different modes (normal and 'enhanced'). Are you complaining about only one of them, or both?
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote: I've got a 1.5 test wiki now up for you kind folks to use and abuse: http://test.leuksman.com/
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 Boswell" phil.boswell@gmail.com wrote in message news:d4l1su$6mh$1@sea.gmane.org... [snippety-snip]
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.
Tried it again, same result.
"Brion Vibber" brion@pobox.com wrote in message news:42682239.6000504@pobox.com...
I've got a 1.5 test wiki now up for you kind folks to use and abuse:
I'm getting the old "New Messages" message won't go away blues...I've tried null edits to my talk page, I've tried real edits...waaah!
Hi, I need to install a new wiki - now I am wondering what I should do - Install 1.5 and live for now with some bugs (I will be the one to create most of the pages - it is quite unlikely that there will be many contributors) or install 1.4.
Which difficulties do I encounter when updating from 1.4 to 1.5 and which when starting with 1.5 now and then updating to a more stable version?
What about database structure etc.?
Thanks for any hint!
Ciao, Sabine
Sabine Cretella wrote:
Hi, I need to install a new wiki - now I am wondering what I should do - Install 1.5 and live for now with some bugs (I will be the one to create most of the pages - it is quite unlikely that there will be many contributors) or install 1.4.
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.
Which difficulties do I encounter when updating from 1.4 to 1.5 and which when starting with 1.5 now and then updating to a more stable version?
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)
Latest strangeness: everything in my watchlist (http://test.leuksman.com/index.php/Special:Watchlist) is now marked as "New".
What **is** going on over there?
Phil Boswell wrote:
Latest strangeness: everything in my watchlist (http://test.leuksman.com/index.php/Special:Watchlist) is now marked as "New".
What **is** going on over there?
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
And Brion or Tim are kindly asked to add at least the patch of http://bugzilla.wikipedia.org/show_bug.cgi?id=2014 which solves problems resulting from developers having butchered e-notif since it was entered into CVS on 18.12.2004.
It also cleans up the Enotif code, so that it is now clearly "hooked" into RecentChange.php module (and not longer hooked into Article.php). The 2014 also re-establishes table user_newtalk which allows for bit-efficient memcaching of the newtalk status (as strongly advised by Tim last year) without losing the (optional) email-notification for user-talk-changes.
Tom
Tim Starling schrieb:
Phil Boswell wrote:
Latest strangeness: everything in my watchlist (http://test.leuksman.com/index.php/Special:Watchlist) is now marked as "New".
What **is** going on over there?
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
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Thomas Gries wrote:
And Brion or Tim are kindly asked to add at least the patch of http://bugzilla.wikipedia.org/show_bug.cgi?id=2014 which solves problems resulting from developers having butchered e-notif since it was entered into CVS on 18.12.2004.
It also cleans up the Enotif code, so that it is now clearly "hooked" into RecentChange.php module (and not longer hooked into Article.php). The 2014 also re-establishes table user_newtalk which allows for bit-efficient memcaching of the newtalk status (as strongly advised by Tim last year) without losing the (optional) email-notification for user-talk-changes.
Tom
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
wikitech-l@lists.wikimedia.org