Each plugin has various bits installed in different areas of the server hierarchy, and then some injected functions in GL supplied files.
That's not entirely true. Plugins should only have code in a few directories. For example sake, let's assume our plugin name is myPlugin:
This is the primary plugin directory where the SQL files, docs and common code should go.
This is where the interface into your plugins will reside (everything except for the admin interface).
This is where any administrative interface into your plugin should go.
4) (optional) /path/to/geeklog/system/lib-custom.php
This is where some plugins may recommend to add code for things like PHP blocks and what not. This, IMHO, isn't the best place...I'd instead put it in the functions.inc for the plugin instead.
Geeklog 2 is addressing this in one of two ways. First, we are going to encourage plugins to use the built-in Model-View-Controller (MVC) package
. This will allow litterally all code to reside in a directory outside of the webtree. For those plugins who don't want to use the MVC package we will recommend how to still achieve putting code in only one directory.
Some Plugins seem to extend existing GL tables, rather than staying entirely within their own tables. Is this simply an exception that breaks the rules?
Right, this is bad practice. We have tossed around the idea of "certified Geeklog plugins" which would require plugins to meet a basic set of requirements before we will recommend their use on their site. The biggest problem with this is finding someone who would be willing to devote time to review plugins (any takers?).
Keep in mind that any plugin that requires modification to core GL files is not a true plugin. Your HTMLArea widget is one such example. That doesn't diminish the usefulness of the code, it just means that coordination between the other and the developers of GL hasn't reach a point where we can discuss how to better integrate things so modification to the core GL code doesn't have to happen. In fact, we have made many modifications to the GL plugin API to meet the needs of plugin authors and we would recommend others do the same.
Thanks for your input.
The reason people blame things on previous generations is that there's only one other choice.