Add-on scripts & integration / Kudos

AgoraCart

New member
Joined
Mar 7, 2004
Messages
2
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)
 
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
 
l0rdphi1 said:
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?
 
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
 
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.
 
AgoraCart said:
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
 
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
 
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.
 
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
 
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 :).
 
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
 
/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 :)
 
DirectAdmin Support said:
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.
 
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 :).
 
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 ;)
 
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
 
Back
Top