[geeklog-modules] Geeklog plugin API Enhancements
Tony Bibbs
tony at tonybibbs.com
Fri Jan 17 21:53:37 EST 2003
Ok, so there are a few new API methods:
1) API to support center blocks.
2) UserSettings API: Tom brought up a good point here on user
attributes. My opinion for 1.3.x is this, we need to make sure that
plugin developers *do not* add attributes to the core user table. If
they insist on adding an attribute (which is ok) do so in it's on user
table that ties to the core table, obviously, by user id. This way in
the event Dirk does get around to adding more user attributes the
upgrade for plugin users will still work.
Also, I'd like to see the preferences page have a tabbed look. On the
first table you will see any Gl-core perference setting. Then each
plugin (through this API) can have it's tab show up with it's
specialized perferences. This requires a near rewrite of
usersetting.php but it would make things much cleaner an usable.
3) getRelated(). Maybe this needs to be a function that plugins can
call to have Geeklog search for related stories and return them back to
a plugin for inclusion. Similarly this should work in the reverse where
Geeklog can have plugins report related data on a story. The algorithm
used to do the match would be interesting.
4) COM_emailUserTopics(). yes, other plugins may want to format their
stuff and send it in an email too. The only issue here is how can users
filter? For stories this is tied into the Display Preferences...how
would this work for plugins? Is the answer another API in display
preferences to get that stuff on a per plugin basis?
Tom to address your issue about dependencies on plugin names and
directories, I understand. I think this is entrenched enough in GL
1.3.x to leave it as is and, instead, address this in GL2. Seem reasonable?
Man, with all this coming out, the GL2 module API is already 70% done ;-)
--Tony
Blaine Lang wrote:
> 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
>
>
> _______________________________________________
> geeklog-modules mailing list
> geeklog-modules at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-modules
--
+-------------------+--------------------------------------------------+
|Tony Bibbs |[R]egardless of what you may think of our penal |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
| |less potential fisherman to clutter up your |
| |favorite pool or pond. --Ed Zern |
+-------------------+--------------------------------------------------+
More information about the geeklog-modules
mailing list