Jump to content


Click here to lend your support to: Traq and make a donation at pledgie.com !
Photo

Plugins


  • Please log in to reply
17 replies to this topic

#1 Jack

Jack

    Project Founder

  • Administrators
  • 673 posts
  • LocationAustralia

Posted 03 January 2012 - 01:57 PM

The current plan is to completely change how the plugin system works, no ideas yet but just letting people know.

#2 Jack

Jack

    Project Founder

  • Administrators
  • 673 posts
  • LocationAustralia

Posted 21 January 2012 - 01:04 PM

The new plugin system has been finalised.

Traq 3.0 will be using FishHook 4.0, a custom library I created for Traq.

FishHook 3.0 used code evaluation, which while very very dangerous, didn't restrict what could be done to the variables that came before the "hook" call.

FishHook 4.0 has been rewritten to make things more secure. The way FishHook 4.0 works is, you have your plugin file "myplugin.php" which is a class, inside that class is a collection of methods.

To add these methods to FishHook so it can run them when the "myhook" hook is called, you would call the FishHook::add(); method, like so:

FishHook::add('myhook', array('myclass', 'mymethod'));


Now the "myhook" hook passes variables to the plugins, like so:

$fruit = array(
'Apple',
'Banana'
);
FishHook::run('myhook', array(&$fruit));


And the plugins method looks like:

function mymethod(&$fruit) {
$fruit[] = 'Orange'
}


Notice that the plugins method doesn't make use of "return" or "global", but will still add Orange to the fruit array.

This is possible because FishHook 4.0 passes variables as references, allowing plugins to modify the variable, not completely replace it, you can see this by the use of '&' before the variables.

#3 arturo182

arturo182

    Advanced Member

  • Contributor
  • PipPipPip
  • 151 posts

Posted 24 February 2012 - 08:38 AM

Plugins should also be allowed to have their own translation files.
Maybe the (base) locale class could iterate through the plugins and add their locale string to itself.

Another thing - install/uninstall.
If the plugin has to make modifications to the db (for example add a table), when will it do it? Having it add it's sql when activating and remove it when deactivating is not the best idea cause if a plugin keeps it's settings in the db and you deactive it and then active it again, all settings are lost.
Here's how I see it:
- there's no install option, when you active a plugin it checks if it's fields/tables exist, if not - create them.
- there is an uninstall option for deactivated plugins, a special function in the plugin is called which removes all the plugin's sql and (maybe) deletes the plugin file/dir. This option should probably have a confirm dialog ;)

#4 Jack

Jack

    Project Founder

  • Administrators
  • 673 posts
  • LocationAustralia

Posted 24 February 2012 - 01:54 PM

Yes, I will be adding install/uninstall and enable/disable features to the plugins shortly.

I have an idea for the plugin locale strings.

I'll set it up so that loading a locale file is done like so:


Locale::load('enus');


Then when plugins are loaded, the method "init()" will be called, this will be used to add their hooks to the hook system and load locales like so:


class MyPlugin
{
public static function init()
{
FishHook::add(...);
Locale::plugin_locale('MyPlugin');
}
}


The method "plugin_locale" may be different, it will look for, say 'ruRU' and fallback to enUS if it cannot be found in the plugins "locale" directory.

If the file exists, it will load the file, that will pretty much be:


return array(
'new_string' => "My new string"
);


All plugin locale strings will be accessed via "myplugin.new_string".

#5 Jack

Jack

    Project Founder

  • Administrators
  • 673 posts
  • LocationAustralia

Posted 22 March 2012 - 09:21 AM

Been doing some thinking about plugins and how to go about handling the install, enable, disable and uninstall stuff for them.

Perhaps something like this:

class MyPlugin
{
public static function __install();
public static function __enable();
public static function __disable();
public static function __uninstall();
}


Also been thinking about how plugins will ago about adding stuff to the database, mainly permissions.

I was thinking something like this:

class MyPlugin
{
public static function __install()
{
Permission::create_default($action, $value);
}
}


#6 arturo182

arturo182

    Advanced Member

  • Contributor
  • PipPipPip
  • 151 posts

Posted 23 July 2012 - 10:23 PM

So how about them plugins?

I think that plugins should be little apps that have their own controllers/models/views folders there should also be a way to add new routes and permissions.

For example if I wanted to add a "news" plugin which would add a new site (/news) and permissions (view_news, add_news), also a hook to add nav tabs would be needed. I would have to create a new controller, model and views.

I also have an idea for a avatars plugin, so a hook to add custom profile field is needed, also a way to add user's avatar before his name everywhere in Traq.

I'm not saying it has to be done for 3.0, but somewhere in the future.
Traq, yo!

#7 Jack

Jack

    Project Founder

  • Administrators
  • 673 posts
  • LocationAustralia

Posted 24 July 2012 - 01:47 AM

My plan is to allow plugins to register controller and view locations with the framework, not sure when though, but I will get to it, I want to do it a certain way.

#8 Jack

Jack

    Project Founder

  • Administrators
  • 673 posts
  • LocationAustralia

Posted 25 July 2012 - 09:25 PM

Well the plugin system is pretty much done, there's two things left to do.

The first is to move the plugin system into the framework, so the framework can be hooked into and not just Traq.

The last is to add plugin hooks everywhere.

If anyone wants to start requesting plugin hooks now you are welcome to do so, just point out the files + line numbers and the variables you need access to.

#9 Jack

Jack

    Project Founder

  • Administrators
  • 673 posts
  • LocationAustralia

Posted 27 July 2012 - 02:51 PM

Here's an example plugin for anyone wanting to create plugins:

class Plugin_myplugin
{
public static function init()
{
FishHook::add('model:__get', array('Plugin_myplugin', 'username'));
}

// The model name, variable name and model data is passed.
// The return value of the Model::__get() method is also passed, but as a reference.
// All you need to do is $val = "modified value";
// No need to return anything.
public static function username($model, $var, $data, &$val)
{
if ($model == 'User' and $var == 'name' and $data['group_id'] == 1)
{
$val = "{$val}";
}
}
}


#10 arturo182

arturo182

    Advanced Member

  • Contributor
  • PipPipPip
  • 151 posts

Posted 27 July 2012 - 08:53 PM

You're missing a ")" in the FishHook::add line.

Also, hook request:
Ability to add new .css and .js files to the page head, so probably file system\views\default\layouts\default.php about line 10.
Traq, yo!

#11 arturo182

arturo182

    Advanced Member

  • Contributor
  • PipPipPip
  • 151 posts

Posted 30 July 2012 - 10:18 AM

Another hook request:
system\views\default\users\usercp.php lines 25 and 38
Traq, yo!

#12 arturo182

arturo182

    Advanced Member

  • Contributor
  • PipPipPip
  • 151 posts

Posted 05 September 2012 - 05:21 PM

And another reqs:

system/views/default/projectsettings/_nav.php: 9
system/views/default/projectsettings/options/_form.php: end

I require adding my own models for plugins.

Is there a way to add properties to already existing models? model::__construct only provides the name, it could provide a pointer to the created model but the properties are protected so it would be impossible to edit them. Why can't the model just get the columns info from the table it's bound to? That would make things easier.

As you can see, I have something big coming ;)
Traq, yo!

#13 Jack

Jack

    Project Founder

  • Administrators
  • 673 posts
  • LocationAustralia

Posted 06 September 2012 - 01:55 PM

Plugins should now be able to add to model properties as well as access the model object.

I know it's annoying having to define table columns, it was something that is needed for the current model/orm design.

I have plans for the model/orm that will remove that requirement, well actually it's not entirely required right now, only to ensure stability.

But this rewrite would require a lot of changes to Traq and will be done in 4.0.

And trust me when I say 4.0 is not far off, by that I mean Traq 3.0 -> 3.1 -> 4.0.

Traq 4.0 is, well, not a rewrite, but sort of is. It's a framework upgrade to the PHP 5.4 framework I've started.

This framework is actually already started working it's way into Traq. That's where Avalon's autoloader came from.

#14 arturo182

arturo182

    Advanced Member

  • Contributor
  • PipPipPip
  • 151 posts

Posted 06 September 2012 - 02:21 PM

Hope it will have backward compability so I won't have to rewrite my plugins.
Traq, yo!

#15 Jack

Jack

    Project Founder

  • Administrators
  • 673 posts
  • LocationAustralia

Posted 07 September 2012 - 03:10 AM

Model related stuff has been split into a new post: Model system changes.

#16 arturo182

arturo182

    Advanced Member

  • Contributor
  • PipPipPip
  • 151 posts

Posted 17 September 2012 - 11:29 AM

system/views/default/users/view.php:22
Traq, yo!

#17 Jack

Jack

    Project Founder

  • Administrators
  • 673 posts
  • LocationAustralia

Posted 20 September 2012 - 11:18 PM

Plugins now use namespaces.

#18 Jack

Jack

    Project Founder

  • Administrators
  • 673 posts
  • LocationAustralia

Posted 29 November 2012 - 03:38 PM

Just an update about how plugins should be named.

The directory and file should be named "my_plugin_name" while the class should be named "MyPluginName".

This change keeps things consistent with the rest of Traq.


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users