The module hosting_client defines the block "hosting_clients", with the definiton enabling the block and assigning it to the region "left". This region may be present in the Eldir theme, but is not present in other themes that may be used with Aegir hosting.

The definition should define the block as disabled so that it can be assigned to a required region by an administrator.

The function hosting_client_block should be updated to change the value of the "enabled" parameter to 0, as per the following:

      case 'list' :
        $blocks['hosting_clients'] = array('info' => t('Hosting clients'), 
        'enabled' => 0, 'region' => 'left', 'weight' => 10);
        break;

Comments

jayelless’s picture

Patch attached.

jayelless’s picture

Status: Active » Needs review
jayelless’s picture

Project: Aegir Ubercart Integration » Hostmaster (Aegir)
StatusFileSize
new691 bytes

This issue was originally posted to the Ubercart Aegir integration project (uc_hosting) by mistake. Has now been moved to the correct project.

This fix did not make it into release 6.x-1.7, so here is an updated patch.

(note: this patch assumes that the patch from issue #1435114 has already been applied).

steven jones’s picture

The administrator can still assign the region for the block after the module has been enabled? I'm not sure I understand why we need this patch?

jayelless’s picture

I have been using a theme other than "eldir" which does not have a region called "left", so I was frequently getting error messages to the effect that the block was assigned to an invalid region and had been disabled.

These messages would appear whenever I visited the administration pages, even though I had assigned the block to a valid region or had disabled it. I can only assume that it was because the base information was being refreshed via a call to hook_block.

The error messages have not appeared since I applied the patch. Perhaps I am missing something here?

jayelless’s picture

I believe that I have now identified the cause of the problem. It is NOT because the client block is assigned by default to an invalid region (as this is the case for other blocks defined within the hostmaster set of modules).

The hook_block function in module hosting_client has the following code to define the block and to provide content for it.

function hosting_client_block($op = 'list', $delta = 0, $edit = array()) {
  $blocks = array();
  if (user_access('view client')) {
    switch ($op) {
      case 'list' :
        $blocks['hosting_clients'] = array('info' => t('Hosting clients'), 
        'enabled' => 1, 'region' => 'left', 'weight' => 10);
        break;
      case 'view' : 
        switch ($delta) {
          case 'hosting_clients':
            $blocks['title'] = t('Clients');
            $blocks['content'] = hosting_client_list();
            break;
        }
    }
  }
  return $blocks;
}

This will cause the block to vanish if a user without "view clients" permission triggers a scan of hook_block by Drupal. Drupal will then remove the information about the block from the system tables. The next time an administrator visits the block admin page, the block will re-appear as unassigned.

The function hook_block should restrict the "if" statement to just the returned content of the block, as per:

function hosting_client_block($op = 'list', $delta = 0, $edit = array()) {
  $blocks = array();
  switch ($op) {
    case 'list' :
      $blocks['hosting_clients'] = array('info' => t('Hosting clients'), 
      'enabled' => 1, 'region' => 'left', 'weight' => 10);
      break;
    case 'view' : 
      switch ($delta) {
        case 'hosting_clients':
          if (user_access('view client')) {
            $blocks['title'] = t('Clients');
            $blocks['content'] = hosting_client_list();
         }
          break;
      }
  }
  return $blocks;
}

This should stop the block from disappearing from its assigned region on a "unpredictable" basis as has been observed.

Patch attached.

steven jones’s picture

Status: Needs review » Fixed

Thanks very much for tracking this one down, pushed into 6.x-1.x and 6.x-2.x.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

  • Commit 017418a on 6.x-2.x, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-588728-views-integration, dev-1403208-new_roles, dev-helmo-3.x authored by jlscott, committed by Steven Jones:
    Issue #1441970 by jlscott: Fixed Client Block assigned by default to non...
  • Commit a8ee8cb on 6.x-2.x, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-588728-views-integration, dev-1403208-new_roles, dev-helmo-3.x by Steven Jones:
    Issue #1441970 by Steven Jones: Fixed Client Block assigned by default...

  • Commit 017418a on 6.x-2.x, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-588728-views-integration, dev-1403208-new_roles, dev-helmo-3.x authored by jlscott, committed by Steven Jones:
    Issue #1441970 by jlscott: Fixed Client Block assigned by default to non...
  • Commit a8ee8cb on 6.x-2.x, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-588728-views-integration, dev-1403208-new_roles, dev-helmo-3.x by Steven Jones:
    Issue #1441970 by Steven Jones: Fixed Client Block assigned by default...