There are reasons for why the plugin system initialization happens in the order that it does, primarily, in order to be able to support authentication plugins in the future, the plugin system will need to initialize itself before the authentication system is initialized.

For your specific purpose though, if you need to load a configuration value from inside your plugin's init() method, you will need to call the API's as appropriate to load the value from only the global configurations. Eg, config_get_global() is safe, and plugin_config_get( <value>, null, true ) will chain to config_getglobal() as well. Both variants ignore the database and ignore the current user; ie, they only load values from config*inc.php and from plugins' default configurations.

The reason the plugins' init() functions are called during initialization is for that exact reason, to initialize the plugin itself; nothing more. Uses for this function should be limited to actions that bootstrap plugin code, such as loading API's for your plugin, etc. If you want your plugin to do something beyond bootstrapping after it has been initialized, you will need to hook an appropriate event.

Now, that does bring up an interesting point that there is no event that is appropriate for doing some processing after core API's are loaded, but before execution of a page has begun. In this case, you've discovered a use case for plugins that I have not envisioned. I will ponder this, and may add a new event for something of this purpose.

For now I've created file "custom_functions_inc.php", which is called exactly in the right place and placed such code in it:

event_signal('EVENT_INIT_DONE');

Then in my plugin I just add hook to this event and everything works. I assume, that this is exactly what you proposed, that means it's a good idea in any case.

Yes, what you've done is basically an off-the-cuff version of what I'd implement, except that it happens just slightly sooner than I'd prefer. :P

Returning to my plugin's initial task (single sign-on) I require a lot of new events in various places along authentication system, like

• after user is created
• after user is deleted
• after user is updated
• after user is logged in
• after user is logged out
  and so on.

Maybe this is related to 0004235, but it seems, that nothing actually is implemented in there.

Another problem is about "custom_functionoverride*" functions. Such functions only will work for function, that are called using helper_call_custom_function function. By now there are few places where this function is used.

By now both custom_functionoverride* and event/hook system is oriented on changing information, that is being displayed to user. I propose to add more events in authentication/user management system, like in MediaWiki. This will allow plugins to do what ever they need.

There is no other way, but to place such new event calls directly in Mantis core code :( If this helps I could then place patches to any file i've changed here.

New event CORE_READY has been added and signalled at the end of core.php, and committed to master branch. Event hooks for authentication is an eventual target, but will likely not make it into 1.2. Issue 0004235 is the appropriate issue for tracking that. Other needs should be addressed in other issues as needed.

This http://www.mantisbt.org/bugs/plugin.php?page=Source/view&id=14096 is changeset for this issue. Didn't link to this issue by itself I suppose.