[geeklog-modules] Geeklog plugin API Enhancements

[Tom Willett]

> 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