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

[Tom]

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

I hadn't thought of that...

This could be assigned in the Configuration could it not like you did for
the other options in the search rank plugin and then checked when the
plugin_getBlocks_xxx is run? (a group dropdown would have to be created for
the configuration  though). The plugin would also have to deal with group
deletes on that configuration option and change it to some sort of default.
On a related note I guess we should also do something similar with topics so
we can assign a dynamic block in the configuration to a topic as well. I
guess the only thing I do not like about all this is that this makes
managing blocks a little more difficult since it is not all done via the
Geeklog Block Manager.

I just did a test with the polls plugin and notice that it does not handle
group deletes at all (it should use plugin_group_changed_xxx). I deleted the
Polls Admin and lost access to the polls admin forms (but not the
configuration for some reason). Plus when I look at the database I still see
the polls block and a poll still assigned to the old Polls Admin id (19).

I just did another test and assigned a story to a group I just created. I
then deleted the group but I still see the story in the db assigned to that
group. Stories does not handle it either and I am willing to bet the other
core plugins do not as well.

I guess the first question is should we allow Plugin Admin groups to be
deleted? I do not really want to add another group type (I guess they could
be considered a core group) but I think that it is okay as long as
everything gets reassigned properly. I guess in situations like this the
polls plugin should have reassigned all of its objects that are assigned to
the deleted group to first the  Polls Admin Group (if it exists) and then
the root group if it does not.

Thoughts?

Tom

-----Original Message-----
From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Rouslan
Placella
Sent: September-23-11 6:45 AM
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Installing Geeklog affects plugins that install
blocks

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


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