[geeklog-devel] Plugin Enhancements

Blaine Lang devel at portalparts.com
Fri Mar 21 09:59:49 EDT 2008

Joe Mucchiello wrote:
> I just had a thought and wanted to throw it out there. Obviously this 
> would be a project for 1.5.1/1.6.
> Why not add a field or two to the plugin table containing plugin 
> generated groups and features ids. This serves two purposes.
> First, the plugin's uninstall becomes trivial to write.
> Second, the plugin can query this field to find it's own group ids. I 
> know several plugins put this info in the vars table now. No need if 
> there's a spot for it on the plugin table.
Hi Joe,

On first review, this sounds like a good idea. It would be necessary 
though to also have hooks into the group admin functions that allow 
these features/groups assignments to be maintained. Also the 
GroupAccessBlock that I wrote a number of years ago which will 
add/remove feature access rights from Core Groups or any Group is often 
used. There are a number of ways that feature assignments can be 
added/removed and new Groups created that would alter the initial 

/* Alternative approach in general */
It may be better to create a couple new generic functions that can be 
called to return all groups with feature code 'yada.edit' and to 
removeFeatureCode('yada.edit') which would update all Group assignments 
and featurecode records.

Plugin Order or priority is an issue that I've had to address in the 
past with respect to loading common libraries provided by one plugin for 
others. Solution was to copy the first record, re-use it for our nexpro 
plugin and insert a new record of plugin 1. Adding plugin Order would 
address that and it could be used to order the display in menu's but not 
sure it has any other beneft.


More information about the geeklog-devel mailing list