Hello,
I am one of the original founding members of the
Postnuke project. I departed from the project a while ago but I think I recall a few things of how we tackled modularized plugins. I don't recall it all, however.
Basically, we started off with a
modules directory (akin to the "plugins" directory mentioned above). This directory contained one directory for each plugin ie:
modules/Plugin1
modules/Plugin2
...etc...
each plugin had to have a config file. This config file was standardized and contained some basic info:
Module name
Author Name
Version
...etc...
This file also held the names of what functions to execute for what (like the installation functions, etc)
Next, there were other standardized files that Postnuke would include. I don't recall the exact implementation of this part...
Basically though it was something like each module would implement the functions mentioned in the config file.
Next, just because you downloaded and extracted a module to your
modules directory, does not mean that it is installed and ready for use.
What Postnuke did was present the admin with a list of available modules present on the system and if they were installed/initialized or not.
If a module was not initialized, he could then click a button/icon and Postnuke would call the function the module defined as what should be called to initialize the module. This would create database tables, etc. Then Postnuke would update an internal module table or something that designated the module was installed.
So there is a basic background of one implemented, and very successfull module system.
I guess I don't even know what language we could write plugins in. PHP? Perl? I should probably read more eh?
Anyhow, the basic architecture could possibly go something like this (using PHP):
plugins/HelloWorldPlugin
the directory for our plugin
plugins/HelloWorldPlugin/configure.php
the config file. We can define an array that looks something like:
PHP:
$plugin_config = array('Name'=>'Hello World',
'Version'=>'1.0',
'Internal Name'=>'hwPluginv1',
'install_function'=>'hwInstall',
'deinstall_function'=>'hwDeinstall',
'class_name'=>'hwClass');
Classes would be an excellent way to implement something like this, hence the configuration item "class_name".
plugins/HelloWorldPlugin/functions
A directory to hold our logic. Each file in this directory will implement our class. Since a user cannot be on the user and admin screen at the exact same time, there should not be a problem with redeclaring a classname
plugins/HelloWorldPlugin/functions/admin.php
This file would implement class_name (hwClass in this case) with admin-level functions (including install_function and deinstall_function)
plugins/HelloWorldPlugin/functions/reseller.php
This file would implement class_name (hwClass in this case) with reseller-level functions
plugins/HelloWorldPlugin/functions/user.php
This file would implement class_name (hwClass in this case) with user-level functions
plugins/HelloWorldPlugin/menu
This directory would hold files that define an array of menu links. There can be different arrays here for different levels of menus. I am thinking the class should determine which menu to show based on what logic is being performed.
plugins/HelloWorldPlugin/menu/admin.php
Admin menu arrays
plugins/HelloWorldPlugin/menu/reseller.php
Reseller menu arrays
plugins/HelloWorldPlugin/menu/user.php
User menu arrays
So that about defines the module's structure.
Next, DirectAdmin could have some basic hooks and logic that calls our modules functions.
DA could provide a configuration area to let admins/resellers define WHERE the links to the plugins should show up. Tossing everything under some generic "plugins" menu is not ideal and NOT acceptable to me. I don't know about the rest of you!
Now, moving a line back to calling the module:
Lets say the menu option had a link to something like /DO_PLUGIN?name=hwPluginv1&op=display_hello
DirectAdmin could then lookup what the class name is and do something like (again, I don't know if DA is even written to use PHP):
PHP:
$plugin_module = new $plugins[$name]();
$plugin_module->$op();
Of course, it needs quite a bit of polishing up, but there you have it. My basic module system proposal.
I didn't even touch on presentation/templates. I would imagine there should be some way to use the current DA template/skin. That would require more knowledge of how DA works on my part
