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

[Tom]

I have finished pretty much allowing blocks to appear for one or more
topics. I have decided to do the topics update in stages as I am unsure if I
could get it all done by 1.9.0 potential release date (especially when
problems crop up) so I will be committing this part to core soon. Upgrading
the database from 1.8.1 to 1.9.0 s is not a problem but the install can be.

 

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?

 

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. (I
am not sure does the upgrade process have access to lib-plugins if a plugin
needs to add a block?)

 

Plugins also do not really have a way to identify their own blocks. Here are
a few line samples I saw in the polls plugin:

 

    DB_query ("UPDATE {$_TABLES['blocks']} SET is_enabled = $is_enabled
WHERE (type = 'phpblock') AND (phpblockfn = 'phpblock_polls')");

 

  // uninstall procedure

   'php_blocks' => array('phpblock_polls'),

 

$title = DB_getItem($_TABLES['blocks'], 'title', "name='poll_block'");

 

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

 

Finally, the forum also does a little bit of extra block magic when it makes
the forum block first,

 

// Retrieve the list of blocks to show on the left side and make the forum
menu the first block

function forum_GetUserBlocks($blocks = array('forum_menu')) {

    global $_TABLES, $_USER;

 

   $retval = '';

    $sql = "SELECT
name,owner_id,group_id,perm_owner,perm_group,perm_members,perm_anon FROM
{$_TABLES['blocks']} WHERE onleft = 1 AND is_enabled = 1";

...

 

While this update does not affect this, future table changes could since it
accessing the blocks table directly to gather information. I think for now I
will leave this but we should consider it when discussing the above
problems.

 

Tom

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20110921/69d41af9/attachment.html>