[geeklog-modules] Geeklog plugin API Enhancements

[Blaine Lang]

Another API is from a note that Tony made sometime ago. GL now has a
COM_emailUserTopics() function but as the Plugins advance, we need a way for
a user to request a summary of all new site activity.

Plugins could have as fine a control for their users as they want .. but the
lib-common function needs to make a call to PLG_pluginEmailupdates()

Do we need a API call for plugins that is called when users login and
logout?

Any more ideas?

Blaine

----- Original Message -----
From: "Tony Bibbs" <tony at tonybibbs.com>
To: <geeklog-modules at lists.geeklog.net>
Sent: Thursday, January 02, 2003 10:21 AM
Subject: Re: [geeklog-modules] Geeklog plugin API Enhancements



> You'll be happy to know that GL2 will support threading of anything in any

> order.  Not sure how many of you were in on those discussions but the

> concept behind GL2 is simple.  Everything on the front page is considered

> an 'item'.  An item is just an abstract object that holds some

> characteristics common to all plugins (uid of owner, gid of group, GL

> security stuff, date posted, status (i.e. is it a submission or not), etc.

>

> So, if you will, imagine a page where you can post an article, then

> instead of just comments you can attach polls, documents, etc.

>

> As for arbitrary user attributes, GL2 may need to consider supporting some

> sort of registry where modules can register user attributes that other

> modules may want to use.

>

> --Tony

>

> On Thu, 2 Jan 2003, Tom Willett wrote:

>

> > > 1) New API to support a center block

> > > I would like to see a Plugin API call in index.php to check to see if

any

> > > registered plugins have a function for a centerblock.

> > >

> > > Possibly the lib-plugins.php function would be

> > > PLG_TopCenterBlock($topic,$homepage=true);

> > >

> > > Then the plugin function would be responsible for any security checks

and

> > > return the formated HTML. Block Developers could easily tap into this

as

> > > well by releasing the plugin as a basic plugin with possibly just a

simple

> > > install, uninstall and this block function. Need to support some

concept of

> > > order when there are several.

> > >

> > I like this -- it is a step toward making the stories just another block

and

> > turning the center into another block column.  The big problem I see

here is

> > order.  It would be essential to use the block order number and that

> > complicates programming such a beast.  You would have to call all the

> > plugins and keep the results in an array until you got ready to display

it.

> > Along with this, what if I want to make my block come after the stories

or

> > after the main story? and before the rest of the stories?

> > > 2) Usersettings API's to allow plugins to extend the usersettings in

the

> > > account information.

> > >

> > >    - Need a API called on user (add/edit,delete,display)

> > >    - Plugins could add there functions as required and keep there user

> > > settings in separate tables but linked via UID

> > >

> > The problem I see here is collisions -- what if two plugins want the AIM

> > username?  You have two problems that could arise here -- a variable

name

> > collision and requiring the user to enter the information twice.  How

about

> > a compromise.  Build the extensibility into geeklog and have one master

list

> > and one master table that the plugins could use through an api.  So we

could

> > have three api calls:

> >

> > two for setup:

> > PLG_getUserSettings           to return the list of extended user

settings.

> > PLG_addUserSetting            to add a user setting to the list.

> >

> > one for normal use:

> > PLG_getUserSetting            to read an extended user setting

> > or

> > PLG_getUserSettings           to read all extended settings (fewer db

calls)

> >

> > > 3) Story related Link ....

> > >

> > >    - Plugins could be called and be related to a story.

> > >    - Example: Link at end of story intro - to start a new forum

discussion

> > > (or view the current disussion)

> > >

> > >   - This may make sense more for the forum plugin but should we make

it

> > > generic and topic specific. Maybe some sites may use a particular

topic

> > area

> > > and want the  stories related to a plugin.

> > >

> >

> > Good idea.  But I see uses well beyond the forum plugin, infact beyond

> > plugins.  How about an easy way to add anything to the what's related

box.

> > Then you would not have to include hyperlinks in line in text, they

could

> > just be entered in the what's related box.

> >

> > Actually this seems to me a geeklog core issue and not one for a plugin

api.

> >

> >

> > And now I will bring up another plugin issue.  The requirement that the

> > plugin be in a directory that corresponds to its name is a serious

> > deficiency.  It causes 3 problems as I see it.   1)  What about two

plugins,

> > written by different authors with the same name but different purposes?

2)

> > What about name collisions with system directories  (I have run into

this

> > with my stats plugin).  3)  Limitations on a descriptive name for the

> > plugin.  The easiest way around this is to add a field to the gl_plugins

> > table that has the directory the plugin resides in.  It would then be

simple

> > to find the plugin and make it easy to put the plugin in different

directory.

> >

> > --

> > Tom Willett

> > tomw at pigstye.net

> > _______________________________________________

> > geeklog-modules mailing list

> > geeklog-modules at lists.geeklog.net

> > http://lists.geeklog.net/listinfo/geeklog-modules

> >

>

> _______________________________________________

> geeklog-modules mailing list

> geeklog-modules at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-modules