[geeklog-devel] Installing Geeklog affects plugins that install blocks

[Dirk Haun]

Tom wrote:

> Currently when a plugin wants to add a block it just goes ahead and accesses the block table directly. Well as of 1.9.0 the block table has changed since it doesn’t need the tid column (for topics) any more. This breaks installing plugins that add blocks like polls and the forum.
>  
> While I can go ahead and fix the polls plugin, 3rd party plugins are another matter. What should we do here?

I don't really have a good idea for that case. I guess we could leave the tid in and call it "deprecated" or unused, but that's a bit messy. The other alternative is to accept breakage and tell the plugin authors to update their plugins.


>  Also to fix this problem in the future (this doesn’t help with the issue above) I propose adding some functions to the plugins library that will handle adding, deleting and updating (enabling, disabling, etc.) blocks.

Do we need plugin API functions or would it be enough to add an entry in the structure that plugin_autoinstall_xxx returns? Do you need to be able to add a block at runtime?


> Should we attempt to tidy this up and what would the best way be?

It would be nice if Geeklog could take care of removing the blocks when a plugin is uninstalled. We would need a way to know which block belongs to which plugin. A naming convention could be one solution (while we're breaking compatibility anyway) or an additional entry in the blocks table.

bye, Dirk