05-07-2009, 08:28 PM
The plugin system in Traq 0.6 is vastly superior to that in Traq 0.5.
The best thing about the new plugin system is plugins can access all variables without doing some sort of "global $var" thing.
Here is an example on how to do create a plugin that can do that:
As you can see, the $code variable in the function contains PHP code, which is returned. This is because when a plugin hook is executed, all the functions attached to that hook are called and executed.
If the function(s) return PHP code that code is then executed as normal PHP code as if it were in the exact place the hook is in the file, giving the code access to everything above that code and the ability to effect anything below it.
You can still make plugins the old way like this:
Note: coding this way may not always turn out the way you expect, that is the reason why the former method was created.
This is where I asked myself if it were best to leave the code execution method as is, or store the plugin code in the database, allowing people to edit the plugin code.
I thought about it for a bit and decided against it as it will be using the database every time a plugin hook is executed, but this makes it a little tricky for developers.
So for Traq 0.8, possible 0.7 if I have time, I will expand the plugin system to use the database to store the plugin code as well as support the functions that have code in a variable.
The best thing about the new plugin system is plugins can access all variables without doing some sort of "global $var" thing.
Here is an example on how to do create a plugin that can do that:
PHP Code:
<?php
// My Plugin
function myPlugin()
{
$code = '
if(isset($project)) {
echo "project var is set";
}
';
return $code;
}
?>As you can see, the $code variable in the function contains PHP code, which is returned. This is because when a plugin hook is executed, all the functions attached to that hook are called and executed.
If the function(s) return PHP code that code is then executed as normal PHP code as if it were in the exact place the hook is in the file, giving the code access to everything above that code and the ability to effect anything below it.
You can still make plugins the old way like this:
PHP Code:
<?php
// My Plugin
function myPlugin()
{
global $project;
if(isset($project)) {
echo "project var is set";
}
}
?>This is where I asked myself if it were best to leave the code execution method as is, or store the plugin code in the database, allowing people to edit the plugin code.
I thought about it for a bit and decided against it as it will be using the database every time a plugin hook is executed, but this makes it a little tricky for developers.
So for Traq 0.8, possible 0.7 if I have time, I will expand the plugin system to use the database to store the plugin code as well as support the functions that have code in a variable.