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

[Tom]

>> 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.

Those where my thoughts as well. I think it would be best to break the
plugins. I will give plugin authors as much notice as possible once the api
and table structure is defined.

>> Do we need plugin API functions or would it be enough to add an entry in
the structure that plugin_autoinstall_xxx returns? 

It would be safer if we do so just in case of changes to the table in the
future and then we most likely will not have to break the plugin.  We
already have plugin_getBlocks_xxx which allows plugins to specify a block to
appear on a side and for a certain topic. I guess the main problem with it
is you cannot specify an order.  Maybe we can just expand this api in some
way?

I am going to have to create some plugin api for topics anyways so I will
see what I come up with for blocks and get back to everyone. (unless anyone
has any other ideas)

>> Do you need to be able to add a block at runtime?

Probably not, I guess it depends if plugins delete blocks not in use or just
disables them.

>> A naming convention could be one solution (while we're breaking
compatibility anyway) or an additional entry in the blocks table.

Are you thinking of the naming convention for the Block Name? In regards to
my other email should the block name be unique or not?

Tom

-----Original Message-----
From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Dirk Haun
Sent: September-22-11 2:59 PM
To: Geeklog Development
Subject: Re: [geeklog-devel] Installing Geeklog affects plugins that install
blocks

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

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://eight.pairlist.net/mailman/listinfo/geeklog-devel