Bug: initializeUserHandler now broken
I believe the recent change to
can't work as this call is done before plugins are initialised. Whilst it is good to move away from the hard coding of the
name, we will need another way of initialising plugins, as the existing initialisation passes the user information, which you won't know when you call a SessionPlugin
- Install the SessionPlugin.
- Add %WIKINAME% to a page
authview) you should see your Wiki username, but you won't with recent changes to
| TWiki version:
|| 30 Dec 2002
| TWiki plugins:
| Server OS:
| Web server:
| Perl version:
| Client OS:
| Web Browser:
- 04 Jan 2003
That is a bug indeed, introduced as part of MorePluginHooks
. Not sure how this can be fixed in a clean way. There is a chicken-and-egg problem:
- The Plugin initialization depends on the Preferences initialization
- The Preferences initialization depends on the user initialization
- The Plugins::initializeUserHandler depends on the login user name
One possible solution is to split up the Preferences initialization into two parts. Then it is possible to do this sequence:
- Init Preferences without user
- Init Plugins
- Call Plugins::initializeUserHandler
- Init Preferences with user
That should work but does change the spec: The user is not initialized at Plugin initalization time, which could break a Plugin that depends on the user info (e.g. to get a user preference at init time).
May be a correct solution is that the Plugins::initializeUserHandler checks each Plugins if one exposes an initializeUserHandler. If yes, initialize just that Plugin and call initializeUserHandler.
- 05 Jan 2003
I think you are on the right lines. If we were starting from scratch then an init and later a user initialisation would make sense, but I think we should preserve compatibility with existing plugins. It might be cleaner to have:
- Init plugins that include
- Deal with preferences
- Init plugins as currently.
- 08 Jan 2003
I've got most of a cleaner solution for this, but I suggest this waits for the CairoRelease
and for now we go back to hard coding the reference to
, it's not so bad as you can only really have one plugin performing this function.
- 18 Jan 2003
For the BeijingRelease
I reverted the code back to the old spec. John, could you test this out?
A clean solution needs to be worked out in the CairoRelease
. (Therefore the bug is still open)
- 21 Jan 2003
The reversion works fine.
- 21 Jan 2003
Guys, just a big thank you for actually documenting this problem. Ive been tearing my hair out (and trust me, I dont have many folicles to spare...) for the last day or so trying to track down why I was having problems with my new skin & sessionplugin.
After upgrading from the the Dec beta to the final release everything is working.... Phew...
- 03 Feb 2003
I don't understand. My TWiki:Plugins/SmartSessionPlugin
does not require any fix (though it's upsetting that I have to call it
since BeijingRelease has that hard coded as the only session handler).
As long as _init_authuser inside TWiki:Plugins/SmartSessionPlugin
is called first
there's no problem with the current release. Granted, it would be nice for
to do this at the appropriate time, but is it necessary?
All I'm saying is that it seems silly to worry about changing TWiki to accomodate TWiki:Plugins/SessionPlugin
seems to be in a poor state. The TWiki:Plugins/SmartSessionPlugin
is intended to be a complete rewrite and replacement for TWiki:Plugins/SessionPlugin
And by the way, SmallTyposInPluginsPM
should probably be something that's fixed. It's related to this bug. It's not a big deal though.
- 17 Jul 2003
I have a proper fix that allows a plugin of any name to work. Extra code is needed as this special plugin call must be done at a point earlier in the code than where plugins are initialised.
- 19 Jul 2003
I'm just finishing off some final testing then fix will be in. A session plugin will have to define an extra function. More soon.
- 25 Aug 2003
The bug responsible for this topic also causes problems with session plugins and SpeedyCGI
. This is discussed at SmartSessionPluginDev
The only way to make session plugins work with modperl/SpeedyCGI/etc. is to put all of the session initialization functions within initializeUserHandler
, which makes little sense and is purely a hack.
Having a way to initialize the session plugin (perhaps by forcing the initPlugin of the session plugin before initializeUserHandler is called) very early is very important.
Will the fix that's going into CairoRelease
make it so that session plugins can finally work with SpeedyCGI
- 02 Sep 2003
CVS updated. Note new earlyInitPlugin method in DefaultPlugin
- 04 Sep 2003
Can you have a look at LoginShownAsGuest
? I think this is due to these code changes, in a TWiki site not using any session plugins.
- 22 Sep 2003
Patch supplied in LoginShownAsGuest
has been applied.
- 23 Sep 2003
has a bug under Cairo. See its Dev page for a fix.
- 12 Apr 2004
I'm going to assume that this issue is done and finished. If there are any new reports, please start a new BugReport
- 24 Jun 2004