Add-on scripts & integration / Kudos

[AgoraCart]

howdy,

just found this control panel and was trying to determine what type of add-on scripts were available.

I am the code keeper fer the AgoraCart shopping cart software and was looking into control panels for a client.

So far I am impressed!

but it did spark my interest in integrating our cart into this control panel (we're in CP currently), but I see some great potential with this control panel as it grows... not to mention what it can already do.

So, would one look at maybe skins development (calling up an installer script) to accomplish this or does the core files need to be altered to integrate scripts?

Anyway, this is looking like a great control panel. I might have to buy me a copy to try it out :)

Mister Ed ... of course .. of course
(AgoraCart Chief PropellerHead)

[l0rdphi1]

I'm currently trying to get them to implement a "plugin" system. We'll see what happens with that... more details will come if it materializes to anything. :) (and it better!) :D

[loopforever]

Originally posted by l0rdphi1
I'm currently trying to get them to implement a "plugin" system. We'll see what happens with that... more details will come if it materializes to anything. :) (and it better!) :D

Me too. I'm really looking to do some nifty things - perhaps we can work together and develop some new tools for people once it's available?

[nobaloney]

I'm also very interested in an integrated Shopping Cart and hope to get something going even in advance of automatic integration.

I'm looking at Modern Bill and Whois.Cart for automatic account setup, and perhaps one of them could automaticallly set up a cart as well for our eCommerce clients.

Jeff

[l0rdphi1]

Well, okay. Posting this certainly won't hurt anything.

Below are the two features I've emailed over to DA. I feel they're pretty well thought out, but any comments will surly be welcomed :)

I'm also looking to get this implemented ASAP, as the current workaround is ugly as.. well, you get the picture :)


Feature 1: A Templated Environment

For one to design a "plugin" system that is reusable by all DirectAdmin skins, we need a design template. As an example, below is an instance of this template for the 'power_user' skin.

|HTM_USER_TOP|
|OUTPUT|
|HTM_USER_BOTTOM|

Other skins, however, may fancy a different structure, thus requiring the existence of this template. BUT, for exemplar purposes, I'll stick with the 'power_user' skin in this email :)

I envision this new template invoked by a token similar to 'CMD_XTRA', which does a jolly good job of indicating that it's an extra or plugin to the DA core. This CMD_XTRA token however is not complete without the ability to set where it is to pull content. Thus, I now append '?SRC=' to the token/URI, resulting in: CMD_XTRA?SRC=

Now, this SRC parameter will be equivalent to the name/ID of the plugin we're invoking. For my upcoming Installatron, SRC will equal "iTron".

The next problem is, what does DirectAdmin do with this SRC value? Well, simple enough, that is. We are going to need a new directory inside the /usr/local/directadmin directory. Make it 'plugin'.

Inside /usr/local/directadmin/plugin there will be a directory for each plugin installed on the DirectAdmin server. When I request "CMD_XTRA?SRC=iTron", DA says, "O.K. Lets look in the /usr/local/directadmin/plugin/iTron directory for an index.* file." (If * == 'php', assume PHP; pl, PERL; sh, BASH; etc.) And once DA locates this index file, DA is to execute it, placing any output in the |OUTPUT| template variable.

This isn't a perfect solution, I don't mention the "|?TREE=...|" bit found in the default templates anywhere, but after all, that bit is not global across all templates, and thus shouldn't be defined herein.


Feature 2: I Can't Get In!

Currently, it is my understanding that all menus are hardcoded within the DirectAdmin binary. This is a problem for our new plugin system.

For the plugin system to work, we need a dynamic system to implement new menu items, a system that is completely skin independent. In an earlier email, I expressed the desire to be able to define new menu items somewhere in a file on the server, and that method still suites my tastes.

[nobaloney]

Originally posted by AgoraCart
Anyway, this is looking like a great control panel. I might have to buy me a copy to try it out :)
Mister Ed, I sent you an information request through your website and I look forward to hearing from you.

I have a testbed system I'd gladly let you use for a while to see if you can integrate AgoraCart.

Jeff

[DirectAdmin Support]

Hello,

We at DirectAdmin are very interested in creating a seamless module system which would allow for extra modules (like AgoraCart) to be easily added. At the moment we need to first establish a common api for how this would be accomplished.. Things like setup for new databases and thing of that nature. Also, as mentioned above, a method of adding dynamic menu items for all skins so that skin modificatinos wouldn't be required when the modules are installed. We can start throwing ideas around.. maybe have one universal config file for each plugin that would allow DA to figure out what needs to be done for the install, and for the menu items, etc, etc..

John

[l0rdphi1]

That sounds great, John. I would, however, place this module/plugin system far above the database and similar APIs. Right now, you can simply fake POST data, and that works fine. But what we can *not* do is add links inside DA, or even make a "plugin" compatible with all skins. Take a look at how Installatron has to be implemented, it's a bloody mess! :) Thus, I say, this plugin system is very, very important.

[DirectAdmin Support]

Agreed. I just need to know how you guys want it to work. What would be the easiest.. like, you have a script for the install, fine. Who does it run as, where is it stored, how does it do thinks like create databases. Who can add them (Resellers?).. if Resellers then it can't run as root.. fun stuff like that ;) Would also need a way of telling DA how/where to put the links.

John

[loopforever]

The add on scripts should run as diradmin/diradmin and have all the same permissions as the DirectAdmin binary. These add ons will need to be able to read/write everything DA can read/write :).

[DirectAdmin Support]

Well.. if they run as diradmin, they won't be able to install anything to a users directory ;) .. Also, I'd rather give you guys a nicer alternative for interfacing with DA, instead of letting you lose on the config files ;) ... perhaps have your scripts echo a url encoded string telling what you want DA to do.

John

[l0rdphi1]

/usr/local/directadmin/plugin/ - housing directory for "plugins"

/usr/local/directadmin/plugin/iTron/ - directory for the plugin "Installatron"

/usr/local/directadmin/plugin/itron/handler - run this file when plugin is envoked, and like any script, the first line will determine the languge. (this replaces my index.* idea from above.)

/usr/local/directadmin/plugin/itron/user_links - with a value something like:Installatron=/CMD_XTRA?SRC=iTron&key=value or maybe simply- Installatron=key=value (where the '/CMD_XTRA?SRC=iTron&' part is assumed automatically)

Just some ideas :)

[l0rdphi1]

Originally posted by DirectAdmin Support
Well.. if they run as diradmin, they won't be able to install anything to a users directory ;) .. Also, I'd rather give you guys a nicer alternative for interfacing with DA, instead of letting you lose on the config files ;) ... perhaps have your scripts echo a url encoded string telling what you want DA to do.

John The problem is getting our plugins to use DA's skins. I'd love to keep them "seperate", but how would that work? For links, we can easily have a file that menu items are appended to (like in my above post).

Hmm.

[loopforever]

I agree, even though I think we're all mediocre coders (okay, maybe we're a bit better than that - *pat pat* ;)), we shoudln't trust our scripts to write to config files that could potentially screw up the overall operation of DA. How about this...

Using John's proposed directory structure, let's require all plug ins to have a mandatory "engine" (for lack of a better word). This file must contain:

Line 1: PluginName
Line 2: PluginDescription

Also require a "content" file, which will contain the specific HTML for this plugin.

Now, to integrate the plugin system with ANY skin, create a series of |PLUGIN| tokens. For example, on the "List Plugin" page: |LISTPLUGINS| will look in the "plugin" directory for all plug in's containing "engine" files, read the name and description, and return a nice formatted list of all plugins. On Plugin specific pages, where people will actually access the specific plug in, call |?PLUGID=PluginName| (where PluginName is the same as retrieved from the "engine" file). And when |PLUGIN| is invoked, print the "content" data for |PLUGID| onto the screen.

This method will enable ANY skin, to list and access the plugin feature.

Just my concept. Feel free to suggest another :).

[l0rdphi1]

Yes, that is basically what I think we're all getting at.

[l0rdphi1]

Any update on this? Can we expect anything for 1.21.4?

[DirectAdmin Support]

Added to versions, for real ;)

http://www.directadmin.com/features.php?id=370

John

[l0rdphi1]

Yay! :D

*praise* :)

[Protollix]

Hello,
I am one of the original founding members of the Postnuke (http://www.postnuke.com) 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:

$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):

$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 ;)

[DirectAdmin Support]

Thanks, that is definately valuable information. I was thinking along the same lines for the directory structure. Just deciding how and if we're going to add the link (hooks) to the skins system. I'd really like to add it, just have to decide if it's feasable with the current setup (I'll push to say yes :)).

John

[AgoraCart]

welpers, I guess I'll be watching for the API schtuff on this one. Meanwhile I'll be coding out some major enhancements over on the cart ;)

Is there anyway of monitoring the progress of the implementation this feature/ability?

Mister Ed

[DirectAdmin Support]

I'll keep this bit updated:

http://www.directadmin.com/features.php?id=370

John

[l0rdphi1]

How is the plugin.conf file going to set up? Will it be part of the plugin.tar.gz file?

Also, when one updates a plugin, how will updates work? Which file in the new tar.gz will be run to apply any changes? I think I'd also like to beable to specify a "build" value in the .conf file. Right now I do updates like this:
if ( old_build < 5 )
{
// ...do stuff updating from build 4 to 5
}

if ( old_build < 4 )
{
// ...do stuff updating from build 3 to 4
}

//etc.So the build file would be passed the old, pre-update build value.

It's looking good though :)

[DirectAdmin Support]

What if, for your installer, you have it copy a file called "current_version.txt" or something.. which is *not* in the tar.gz. Then DA updates will call an update.sh script you include which can peek in that file to see what the last version was.

I guess we can make all plugins installable from within the Admin Panel.

The plugin.conf file should be in the tar.gz and will end up being overwritten with each update.

*Actually... you could just create the plugin.conf with your installer, and update it as you need to with the updater.. I'll leave the door open so you guys can do what you want. DA will call install.sh for new install and update.sh for updates (the "plan" at this point).

Note that the versions system holds what has currently been planned thus far, but by no means is it guranteed to stay that way. :) .. so be ready for changes to it before it's finalized.

John

[Protollix]

It's looking good thus far :)

[DirectAdmin Support]

There are a few more changes (havn't updated the versions system quite yet).. but here's a screen shot...."Hey, you look different.. did you get a haircut?" :D

I've changed it so that you can decide if you want your plugin.conf to be included in the plugin.tar.gz file or not. The issue was that if it *is* there, updates would overwrite the old file which held the "active" and "installed" values. What I did was read in those values if the file exists, then extract the plugins.tar.gz, then rewrite the 2 values back to it. It no longer matters, but I'd say "yes" you should include the plugin.conf file in your tar.gz file :)

Additions include a callback for current version #, where it contacts the included url to "version_url=http://...." to display the current available version of your plugin. Also, it has a built in updater so it downloads, extracts and upates your plugins for you (runs ./scripts/update.sh).

:)

John

[l0rdphi1]

Sexy skin you got there :D ;)

[thoroughfare]

Hey guys,

Is the plugin system ready? It's been released I know, but is it ready to build around? I have a zillion plugin ideas :-D

Also, since the new skin has been released, are the power skins and default skins still being updated by Mark and John?

Cheers,
Matt :)

PS How many plugins can we add?

[l0rdphi1]

Hey :)

I'm currently converting Installatron over to the plugin system. The plugin API/system itself is working 100%. I'd like yet to see another API or two, but that's just extra stuff.

We should see iTron v2.0 this evening :)

Cheers!

[CyberAlien]

Originally posted by thoroughfare
PS How many plugins can we add?
For default skin there are 3 plugins limit for user, 4 for reseller, 4 for admin panels.
For enchanced skin there are 4 plugins limit for user, 4 for reseller and 4 for admin panels.

I think this number is too small. Plugins system is very simple so there will be lots of plugins. I think it is better to set to 10 plugins for every panel or something like that.

[DirectAdmin Support]

Hello,

There are 5 plugin hook tokens that are set to "" (for when no plugin exists). I'll up that to 10.. the actual tokens in the skins can be upto the skin designer.. I'll up it to 6 in our skins. If a skin designer goes past the limit without any plugins, then they'll see unfilled tokens on their page... you'd only add more tokens than the limit if you actually have more plugins.. they'll be filled all the way up so that all plugins get a token.

John