GT plugin system bug (or "feature" :-), problems, and additional info (FYI) & Solution suggestion
I noticed a very interesting problem, with the GT plugin system. I hooked the 'handle_page' in PRE mode, in my several plugins (Extended_link, Advanced_Link_Expirator, Timer_Page).
Well, this means, all hooked functions of these 3 plugins, should be executed in a sequence (using 'handle_page' in PRE mode).
Except, if one function will have a STOP action.
If one has STOP action, the execution of this PRE hook will stop, and the remaining plugin functionss be will *NOT* executed, neither the original code.
=> So if the function sequence has the following order: (Extended_link, Advanced_Link_Expirator, Timer_Page), and we have a STOP action in Extended_link to stop the original code, we also get the result, that the rest of the functions of Advanced_Link_Expirator, Timer_Page will be NOT executed!
We do *NOT WANT* to execute the original code, but we still *WANT* to execute the function of Advanced_Link_Expirator, Timer_Page, but they will be not executed, because the Extended_link function already had a STOP action, to stop original code. Eh...
Interesting, right?
Well, this functionality is good, it is a feature, so should work like this. And here comes the BUT.
But problem is, that we can NOT change or define the execution order of different plugins' functions, that belongs to same hook.
Why? Because the plugins (and plugin names, too), are stored in a hash, which is loaded from plugin.cfg file. It is stored as hash of hashes. The plugin names are the keys, and we know, the keys are not stored sorted internally in Perl in any way. Therefore, when a hook is executed, the order of executed plugin functions can NOT changed or defined by the plugin developer in any way, it is assigned by Perl itself internally.
I hear, some of you may say, this is not a bug, this is a "feature"
. IMHO, this is a bug. I do not argue about that. Does not matter.
Solutions to correct the bug:
1) This is basically a workaround:
The bug is in admin/GT/Plugins.pm in sub load_cfg function somewhere around line 207:
...
}The keys are not sorted, before they are used.
The corrected code (bugfix) should look like:
...
}Well, this is the easiest bugfix we can do now, to correct the problem of unsorted function executing. After applying this bugfix, we can have some plugins executed with higher priority, than other plugins, if we change the plugin name, to be first or last in the abc order.
Now, if I rename Extended_link to => Xtended_Link_Display, and Timer_Page to => AAA_Timer_Page, then the execution order will be the following for the 'handle_page' hook:
. . . a) executes the function of AAA_Timer_Page plugin, hooked to 'handle_page', then
. . . b) executes the function of Advanced_Link_Expirator plugin, hooked to 'handle_page', then
. . . c) executes the function of Xtended_Link_Display plugin, hooked to 'handle_page'.
If we have a STOP action in function of Xtended_Link_Display plugin, it will stop executing the original code, which would be executed otherwise.
Finally we reached to execute some plugins with higher priority, others with lower (depending on plugin name). That was what we wanted.
2) The following is a difficulter solution, to implement sortable execution of plugins in the GT plugin system.
We would like the following results:
. . . a) sortable execution order of the functions using the same hook, but which can be found in different plugins.
Example: each our installed plugins use the hook 'handle_page', and we want to decide which one to execute with higher, which with lower, and which with normal (does not matter in what order we execute it)
. . . b) also there is possible (but seems not too much logic to do that) to have the same hook used multiple times in the same plugin. These should also have sortable execution order. The solution I suggest for a) will solve the problem of b), if there will be ever need for that.
Solution:
The plugin.cfg now has the following format (shortened version):
'Timer_Page' => {
'hooks' => [
[
'handle_page',
'PRE',
'Plugins::Timer_Page::function',
'1'
]
],
'menu' => [],
'meta' => {},
'registry' => {},
'user' => [],
'version' => '2.01'
},
'Extended_link' => {
'hooks' => [
[
'handle_page',
'PRE',
'Plugins::Extended_link::function',
'1'
]
],
'menu' => [],
'meta' => {},
'registry' => {},
'user' => [],
'version' => '1.0'
},
'Advanced_Link_Expirator' => {
'hooks' => [
[
'handle_page',
'PRE',
'Plugins::Advanced_Link_Expirator::function',
'1'
]
],
'menu' => [ ],
'meta' => {},
'registry' => {},
'user' => [],
'version' => '1.0'
}
};
Warning! Please do not do any changes in the PLUGIN.CFG! This is strictly development information only, for advanced Perl-LSQL developers (Alex, GT staff), and not for Links SQL users!
We should modify it to the following (the code with red is added in the format):
[
{
'Timer_Page' => {
'hooks' => [
[
'handle_page',
'PRE',
'Plugins::Timer_Page::function',
# plugin priority level (0 disabled, 1 lowest, 5 highest, 3 is normal user level)
'5',
# plugin subpriority level (1 lowest, 100 highest, 50 is normal user level)
'75'
]
],
'menu' => [],
'meta' => {},
'registry' => {},
'user' => [],
'version' => '2.01'
},
},
{
'Extended_link' => {
'hooks' => [
[
'handle_page',
'PRE',
'Plugins::Extended_link::function',
# plugin priority level (0 disabled, 1 lowest, 5 highest, 3 is normal user level)
'1',
# plugin subpriority level (1 lowest, 100 highest, 50 is normal user level)
'50'
]
],
'menu' => [],
'meta' => {},
'registry' => {},
'user' => [],
'version' => '1.0'
},
},
{
'Advanced_Link_Expirator' => {
'hooks' => [
[
'handle_page',
'PRE',
'Plugins::Advanced_Link_Expirator::function',
# plugin priority level (0 disabled, 1 lowest, 5 highest, 3 is normal user level)
'3',
# plugin subpriority level (1 lowest, 100 highest, 50 is normal user level)
'50'
]
],
'menu' => [ ],
'meta' => {},
'registry' => {},
'user' => [],
'version' => '1.0'
}
}
]
};
Plugin Priority Options:
- plugin priority level: is valid, if number and between 0-5.
0 means, plugin is disabled
1 means, plugin has the lowest priority
3 is normal user level (but all noncompatible plugins, or those which are compatible only with earlier GT plugin system, will set automatically the 1(lowest) level.)
5 means, plugin has the highest priority (this should be used only in very rare cases, when the plugin should be executed very last in the hook function list)
- plugin subpriority level: is valid, if number and between 1-100.
1 means, plugin has the lowest priority
50 is normal user level (but all noncompatible plugins, or those which are compatible only with earlier GT plugin system, will set automatically the 1(lowest) level.)
100 means, plugin has the highest subpriority ( The highest priority (100) should be extremely rarely used by plugins. User plugins should only use max 90, as the highest priority, to leave space for very important plugins. GT should not allow higher subpriorities, than 90 in general, except in extreme cases, when it is really required, and proved by the plugin developer. )
The plugin should be executed very last in the hook function list.
101+ Should be Never used by user created plugins. Allowed only for special system plugins of GT.
The current plugin system mainly should be changed in:
- the /admin/GT/Plugins.pm in sub load_cfg and sub save_cfg functions. These funtions are responsible to load (or save), order, then merge hook functions into _pre_hook and _post_hook hashes, which contains the function lists sorted by plugins.
- Also /admin/Links/Plugins.pm should be changed to manage those new config structures (get, set, etc...)
- Of course there we also need an admin interface, to be able to manage those new features, and change plugin priorities, so changes in admin.pm are also needed.
These are the main places, what should be changed for the new Plugin System (maybe at other places, too but I did not investigated this).
I'm sure, this Improved Plugin System would qualify almost every needs. Would it?
In addition to this plugin system improvement, I just would need a 'user_page' hook in Links.pm and I would be 99% satisfied
Opinions, comments, constructive critics are welcome!
(I may ask edit right for this thread later, if I may find any error, what I would like to correct. I have to go now, so I post it without rereading this long post.)
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Well, this means, all hooked functions of these 3 plugins, should be executed in a sequence (using 'handle_page' in PRE mode).
Except, if one function will have a STOP action.
If one has STOP action, the execution of this PRE hook will stop, and the remaining plugin functionss be will *NOT* executed, neither the original code.
=> So if the function sequence has the following order: (Extended_link, Advanced_Link_Expirator, Timer_Page), and we have a STOP action in Extended_link to stop the original code, we also get the result, that the rest of the functions of Advanced_Link_Expirator, Timer_Page will be NOT executed!
We do *NOT WANT* to execute the original code, but we still *WANT* to execute the function of Advanced_Link_Expirator, Timer_Page, but they will be not executed, because the Extended_link function already had a STOP action, to stop original code. Eh...
Interesting, right?
Well, this functionality is good, it is a feature, so should work like this. And here comes the BUT.
But problem is, that we can NOT change or define the execution order of different plugins' functions, that belongs to same hook.
Why? Because the plugins (and plugin names, too), are stored in a hash, which is loaded from plugin.cfg file. It is stored as hash of hashes. The plugin names are the keys, and we know, the keys are not stored sorted internally in Perl in any way. Therefore, when a hook is executed, the order of executed plugin functions can NOT changed or defined by the plugin developer in any way, it is assigned by Perl itself internally.
I hear, some of you may say, this is not a bug, this is a "feature"
. IMHO, this is a bug. I do not argue about that. Does not matter. Solutions to correct the bug:
1) This is basically a workaround:
The bug is in admin/GT/Plugins.pm in sub load_cfg function somewhere around line 207:
Code:
foreach my $plugin (keys %$PLUGIN_CFG) { ...
}
The corrected code (bugfix) should look like:
Code:
foreach my $plugin (sort keys %$PLUGIN_CFG) { ...
}
Now, if I rename Extended_link to => Xtended_Link_Display, and Timer_Page to => AAA_Timer_Page, then the execution order will be the following for the 'handle_page' hook:
. . . a) executes the function of AAA_Timer_Page plugin, hooked to 'handle_page', then
. . . b) executes the function of Advanced_Link_Expirator plugin, hooked to 'handle_page', then
. . . c) executes the function of Xtended_Link_Display plugin, hooked to 'handle_page'.
If we have a STOP action in function of Xtended_Link_Display plugin, it will stop executing the original code, which would be executed otherwise.
Finally we reached to execute some plugins with higher priority, others with lower (depending on plugin name). That was what we wanted.
2) The following is a difficulter solution, to implement sortable execution of plugins in the GT plugin system.
We would like the following results:
. . . a) sortable execution order of the functions using the same hook, but which can be found in different plugins.
Example: each our installed plugins use the hook 'handle_page', and we want to decide which one to execute with higher, which with lower, and which with normal (does not matter in what order we execute it)
. . . b) also there is possible (but seems not too much logic to do that) to have the same hook used multiple times in the same plugin. These should also have sortable execution order. The solution I suggest for a) will solve the problem of b), if there will be ever need for that.
Solution:
The plugin.cfg now has the following format (shortened version):
Code:
$DUMP = { 'Timer_Page' => {
'hooks' => [
[
'handle_page',
'PRE',
'Plugins::Timer_Page::function',
'1'
]
],
'menu' => [],
'meta' => {},
'registry' => {},
'user' => [],
'version' => '2.01'
},
'Extended_link' => {
'hooks' => [
[
'handle_page',
'PRE',
'Plugins::Extended_link::function',
'1'
]
],
'menu' => [],
'meta' => {},
'registry' => {},
'user' => [],
'version' => '1.0'
},
'Advanced_Link_Expirator' => {
'hooks' => [
[
'handle_page',
'PRE',
'Plugins::Advanced_Link_Expirator::function',
'1'
]
],
'menu' => [ ],
'meta' => {},
'registry' => {},
'user' => [],
'version' => '1.0'
}
};
Warning! Please do not do any changes in the PLUGIN.CFG! This is strictly development information only, for advanced Perl-LSQL developers (Alex, GT staff), and not for Links SQL users!
We should modify it to the following (the code with red is added in the format):
Code:
$DUMP = { [
{
'Timer_Page' => {
'hooks' => [
[
'handle_page',
'PRE',
'Plugins::Timer_Page::function',
# plugin priority level (0 disabled, 1 lowest, 5 highest, 3 is normal user level)
'5',
# plugin subpriority level (1 lowest, 100 highest, 50 is normal user level)
'75'
]
],
'menu' => [],
'meta' => {},
'registry' => {},
'user' => [],
'version' => '2.01'
},
},
{
'Extended_link' => {
'hooks' => [
[
'handle_page',
'PRE',
'Plugins::Extended_link::function',
# plugin priority level (0 disabled, 1 lowest, 5 highest, 3 is normal user level)
'1',
# plugin subpriority level (1 lowest, 100 highest, 50 is normal user level)
'50'
]
],
'menu' => [],
'meta' => {},
'registry' => {},
'user' => [],
'version' => '1.0'
},
},
{
'Advanced_Link_Expirator' => {
'hooks' => [
[
'handle_page',
'PRE',
'Plugins::Advanced_Link_Expirator::function',
# plugin priority level (0 disabled, 1 lowest, 5 highest, 3 is normal user level)
'3',
# plugin subpriority level (1 lowest, 100 highest, 50 is normal user level)
'50'
]
],
'menu' => [ ],
'meta' => {},
'registry' => {},
'user' => [],
'version' => '1.0'
}
}
]
};
Plugin Priority Options:
- plugin priority level: is valid, if number and between 0-5.
0 means, plugin is disabled
1 means, plugin has the lowest priority
3 is normal user level (but all noncompatible plugins, or those which are compatible only with earlier GT plugin system, will set automatically the 1(lowest) level.)
5 means, plugin has the highest priority (this should be used only in very rare cases, when the plugin should be executed very last in the hook function list)
- plugin subpriority level: is valid, if number and between 1-100.
1 means, plugin has the lowest priority
50 is normal user level (but all noncompatible plugins, or those which are compatible only with earlier GT plugin system, will set automatically the 1(lowest) level.)
100 means, plugin has the highest subpriority ( The highest priority (100) should be extremely rarely used by plugins. User plugins should only use max 90, as the highest priority, to leave space for very important plugins. GT should not allow higher subpriorities, than 90 in general, except in extreme cases, when it is really required, and proved by the plugin developer. )
The plugin should be executed very last in the hook function list.
101+ Should be Never used by user created plugins. Allowed only for special system plugins of GT.
The current plugin system mainly should be changed in:
- the /admin/GT/Plugins.pm in sub load_cfg and sub save_cfg functions. These funtions are responsible to load (or save), order, then merge hook functions into _pre_hook and _post_hook hashes, which contains the function lists sorted by plugins.
- Also /admin/Links/Plugins.pm should be changed to manage those new config structures (get, set, etc...)
- Of course there we also need an admin interface, to be able to manage those new features, and change plugin priorities, so changes in admin.pm are also needed.
These are the main places, what should be changed for the new Plugin System (maybe at other places, too but I did not investigated this).
I'm sure, this Improved Plugin System would qualify almost every needs. Would it?
In addition to this plugin system improvement, I just would need a 'user_page' hook in Links.pm and I would be 99% satisfied
Opinions, comments, constructive critics are welcome!
(I may ask edit right for this thread later, if I may find any error, what I would like to correct. I have to go now, so I post it without rereading this long post.)
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Re: [yogi] GT plugin system bug (or "feature" :-), problems, and additional info (FYI) & Solution suggestion