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

[Tom]

To answer one of my own questions after looking at PLG_getBlocks more and
the wiki (http://wiki.geeklog.net/index.php/Dynamic_Blocks) as well the
search rank plugin I think for most cases plugins can use
plugin_getBlocks_xxx because you can specify the order as well. This means
plugins shouldn't really be playing with the blocks table. (unless I am
missing something here)

I will update the polls plugin to use a dynamic block. Looking at the forum
plugin it's phpblock_forum_newposts block could work as a dynamic but the
forum menu block will still have problems since it needs to display only
when the forum is displayed. This information doesn't get passed to the api
and I am not really sure at the moment the best way to do this (ideas???)

Ben ... Your Paypal plugin uses blocks I believe, if they are not currently
dynamic would you have any problems converting them to dynamic or have I
overlooked something?

Tom



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

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

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