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

[Rouslan Placella]

On Thu, 2011-09-22 at 21:27 -0400, Tom wrote:
> 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)

The problem with dynamic blocks is that there is zero support for
"group" privileges...

> 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
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel