Geeklog Forums

Hi there, Still working on a plugin, I have a few questions: - Is there any parameter to the plugin_itemlist_ function? - How do I get the search type to show up in the Search list? (plugin_getsearchtypes_ doesn't seem to be enough. - How do I get to have mu entries to show up in the user and admin blocks? (Again plugin_showuseroptions_ and plugin_adminoptions_ don't seem to be working alone...) Thanks in advance, Laurent

Did you insert a record into the plugin table? All the plugin code first checks all plugins in the plugin table that have enabled set to 1. I bet if you insert that record it will fix all your troubles. Also, email me with suggestions on how the plugin API could be better. Your the first person besides me to try developing any. If you haven't already, you may want to reverse engineer the staticpages plugins as it handles most of the plug-in API minus the submission stuff. ----- The reason people blame things on previous generations is that there's only one other choice.

---

The reason people blame things on previous generations is that there's only one other choice.

Yes, there is a record in the plugin table. Although I installed it manually it is listed in the Plugins admin page. Do you see something else?

No arguments are passed to plugin_itemlist_<pluginname> AFAIK. The bizzare thing about it is it seems the only part of the API to use classes (I think it is the beginning of a trend). An example: function plugin_itemlist_dog() { $returnPlugin = new Plugin(); $returnPlugin->submissionlabel = 'Dog Submissions'; $returnPlugin->getsubmissionssql = 'SELECT did, name, breed FROM dogsubmission'; $returnPlugin->submissionheading = array('name,breed'); return $returnPlugin; } I don't know if this is the 'correct' way, but it works. Also, note that getsubmissionsql seems to be a field and not a method oddly enough, and that you leave out the ID from submissionheading (or else stuff gets messed up). Hope that helps! --- Gnuyen

If you'd like some suggestions on how to improve the plugin interface here are a few: Either make return values all classes or no classes, returning arrays some of the time and Plugins other parts of the time is at best odd. Also, I think plugins should be split into type handlers and modules, for there's no need to force that all type handlers have their own directory off the site_url. This prevents modules from utilizing multiple types (many modules [like mine] require multiple types e.g. phpbb has posts vs private messages etc which might have different databases for comments as well as different submission forms). Make a Module Class of which all plugins will be derivations . Also make a Type Class for types. This way we can get around all that forced naming stuff. I.e $th = new COM_getTypeHandler('<type>', maybesomeargs); $th->getItemList(); $th->Submit(); etc... where COM_getTypeHandler calls the registered constructor for that Type. Also, For purposes of orthogonality (and to provide good examples on how plugins work) convert links and events to plugins. Another thing, I don't see anywhere in the code where it's required that the plugin's submission table really needs to be named <pluginname>submission and the regular table needs to be <pluginname>. If this was a requirement I'd suggest removing it, but AFAICS it's not actually really a requirement since you specify the table in plugin_moderationvalues_<pluginname> as well as passing SQL around everywhere else.

I don't really get the security module for different plugins, I can't really tell but it seems that plugin admins get to handle all the plugin type submissions? I don't think thats actually how it is, but if it is that should be changed so each type or module can have it's own admin groups.

I've managed to sucessfully reverse-engineer almost every other plugin API but this one is too absurd!

1. The object-oriented nature of this API makes it difficult enough to understand but...
2. The criss-crossing of function calls is what makes this especially problematic for plugin designers. i.e., moderation.php::commandcontrol() calls lib-plugins.php:LG_showModerationList(). lib-plugins.php:LG_showModerationList() - in turn - calls moderation.php::itemlist() repeatedly instead of havingt PLG_showModerationList() return a list to moderation.php::commandcontrol() and letting commandcontrol() iterate over the list along with the default values of 'story', 'link', and 'event'.

Stop the merry-go-round - I'm getting dizzy!!!

---
Eric P.
Sunnyvale, CA

---

Eric P.
Sunnyvale, CA

Your point being ...?

FYI, Tom Willet and Blaine Lang are currently working on a better documentation of the plugin interface, see this story on Tom's site.

If you have any proper suggestions on how to improve the plugin interface then I'd suggest you voice them on the geeklog-devel mailing list. While it is unlikely that we will introduce any incompatible changes in the 1.3.x plugin API, your input may be of interest for the design of the GL2 API.

bye, Dirk

Sorry... I just had to rant. :^(---Eric P. Sunnyvale, CA

---

Eric P.
Sunnyvale, CA