Hi - fantastic module, am using it to build a Drupal 7 site but can't figure out how to set up taxonomy terms for my vocabularies which are being saved in features, and I can't work out how to save blocks.

It seems the hook_install isn't being run, or I'm missing something - I'm using code from the standard install profile in the hook_install function so it should work ok. FE Block isn't working with D7 yet so I can't use that for the blocks, and I'm just using taxonomy_term_save for the terms.

Any tips welcome ;)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

Title: Can't get hook_install to work » Can't get hook_install to enable default blocks

I'm changing the title as I can see there's been some work on taxonomies already so I'm focusing on the blocks here. I still can't get them to work using profiler for 7.

When I put the standard .install functions in, it writes the block info to the block table, but the status remains as zero and the region isn't saved. The rest of the code works - input formats, theme defaults, etc.

Has anyone successfully used profiler with D7 to enable blocks?

q0rban’s picture

Hey Steve,

Sorry you're having troubles with this. Just to clarify, your hook_install runs, but the blocks you are trying to activate there don't work?

Anonymous’s picture

That's right, so in my install file I have the following:

  // Enable some standard blocks.
  $default_theme = 'purkiss_bartik';
  $admin_theme = 'seven';
  $values = array(
    array(
      'module' => 'system',
      'delta' => 'main',
      'theme' => $default_theme,
      'status' => 1,
      'weight' => 0,
      'region' => 'content',
      'pages' => '',
      'cache' => -1,
    ),
    array(
      'module' => 'node',
      'delta' => 'recent',
      'theme' => $admin_theme,
      'status' => 1,
      'weight' => 10,
      'region' => 'dashboard_main',
      'pages' => '',
      'cache' => -1,
    ),
    array(
      'module' => 'user',
      'delta' => 'login',
      'theme' => $default_theme,
      'status' => 1,
      'weight' => 0,
      'region' => 'sidebar_first',
      'pages' => '',
      'cache' => -1,
    ),
    array(
      'module' => 'system',
      'delta' => 'navigation',
      'theme' => $default_theme,
      'status' => 1,
      'weight' => 0,
      'region' => 'sidebar_first',
      'pages' => '',
      'cache' => -1,
    ),
    array(
      'module' => 'system',
      'delta' => 'powered-by',
      'theme' => $default_theme,
      'status' => 1,
      'weight' => 10,
      'region' => 'footer',
      'pages' => '',
      'cache' => -1,
    ),
    array(
      'module' => 'system',
      'delta' => 'help',
      'theme' => $default_theme,
      'status' => 1,
      'weight' => 0,
      'region' => 'help',
      'pages' => '',
      'cache' => -1,
    ),
    array(
      'module' => 'system',
      'delta' => 'main',
      'theme' => $admin_theme,
      'status' => 1,
      'weight' => 0,
      'region' => 'content',
      'pages' => '',
      'cache' => -1,
    ),
    array(
      'module' => 'system',
      'delta' => 'help',
      'theme' => $admin_theme,
      'status' => 1,
      'weight' => 0,
      'region' => 'help',
      'pages' => '',
      'cache' => -1,
    ),
    array(
      'module' => 'user',
      'delta' => 'login',
      'theme' => $admin_theme,
      'status' => 1,
      'weight' => 10,
      'region' => 'content',
      'pages' => '',
      'cache' => -1,
    ),
    array(
      'module' => 'user',
      'delta' => 'new',
      'theme' => $admin_theme,
      'status' => 1,
      'weight' => 0,
      'region' => 'dashboard_sidebar',
      'pages' => '',
      'cache' => -1,
    ),
  );
  $query = db_insert('block')->fields(array('module', 'delta', 'theme', 'status', 'weight', 'region', 'pages', 'cache'));
  foreach ($values as $record) {
    $query->values($record);
  }
  $query->execute();

Which produces this output in the database, as you can see the status and region aren't saved (not all records here, got bored typing tds ;):

bid module delta theme status weight region custom visibility pages title cache
1 system main purkiss_bartik 0 0 -1 0 0     -1
2 node recent seven 1 10 dashboard_inactive 0 0     -1
3 user login purkiss_bartik 0 0 -1 0 0     -1
4 system navigation purkiss_bartik 0 0 -1 0 0     -1
5 system powered-by purkiss_bartik 0 10 -1 0 0     -1
6 system help purkiss_bartik 0 0 -1 0 0     -1
ao2’s picture

Hi, I too have run into the issue at #3, but is this profiler specific?

Thanks,
Antonio

ao2’s picture

Status: Active » Needs review
Issue tags: ++patch
FileSize
1.27 KB

Ah, this behavior is due to profiler indeed.

The attached patch fixed it for me, but I'd like to know the rationale behind disabling blocks.

Thanks,
Antonio

Anonymous’s picture

Thanks! Can't believe I missed that one, must've been looking at the code for too long ;)

Anonymous’s picture

Can't get the patch working

; Patch profiler with #1165672-5: Don't disable blocks
libraries[profiler][patch][] = "http://drupal.org/files/issues/0001-Issue-1165672-don-t-disable-blocks.patch"

...not sure if it's just not formatted correctly or whether it can't patch libraries.

ao2’s picture

drush_make needs to be patched to handle patches made with git, see #745224: Apply patches from git diff and git format-patch

q0rban’s picture

Ah, yes, this is legacy code left over from Drupal 6 profiler, since there are some default blocks enabled in Drupal 6 that are undesired. If this is no longer the case in 7, we should apply this patch. Can you double check that there are no blocks enabled on a clean install profile using Profiler in 7?

Anonymous’s picture

I have just rebuilt my D7 profile without any code in my .install file - the only blocks enabled are the ones in the inactive dashboard region.

adamdicarlo’s picture

Also, D7 has a "Main page content" block that is supposed to be assigned to the "Content" region (or wherever you want your main page content to go). In fact, the core Blocks form in D7 won't validate if "Main page content" is disabled. So turning off *all* blocks seems very wrong in D7.

q0rban’s picture

Title: Can't get hook_install to enable default blocks » Do not disable blocks
Category: support » bug
Status: Needs review » Fixed
ao2’s picture

Thanks @q0rban, if it is easier to you next time you can use git am to merge my patches (generated with git format-patch), this way you do not have t worry about setting the right author, and the long commit message (which I always use) is preserved too.

Regards,
Antonio

q0rban’s picture

Thanks ao2, i actually prefer git apply as that gives me more control, and also your patch no longer applied. I still wanted to give you credit for it, though! :)

ao2’s picture

@q0rban, I see, just let me tell you how I tend to do things.

If a patch for a project of mine is not good enough (if it does not apply anymore, if the commit message is not explicative enough, if the code needs to be adjusted) I get back to the submitter and explain what's wrong asking to reroll the patch himself, this can even happen a couple of times before the patch can be validated. If the submitter is responsive then he also learns how to submit proper patches the next time he contributes to that particular project of mine.

With this workflow git format-patch and git am are the tools: the patches I merge are exactly what the contributor sent, this makes the project history more transparent, in my view the author takes responsibility also for the commit message.

Finally a note on commit messages, I like to always have a long commit message (with a blank line after the short commit messages), and to make me remember that I never use the -m option of git commit, so I have to compose the commit messages in the interactive editor (I get the spellchecker for free too this way).

The bottomline is that I do not want to have more control than it is strictly necessary :), and if after git am the patch is still not perfect there's always git commit --amend.

OK, but that's just me. I just wanted to share my personal POV :)

Keep up the good work,
Antonio

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

JurriaanRoelofs’s picture

Issue summary: View changes
Status: Closed (fixed) » Active

I'm building a distro with profiler and ran into this issue. I want to show blocks after installation and this piece of code was disabling them

  if (module_exists('block')) {
    db_query("UPDATE {block} SET status = 0, region = ''");
  }

profiler_api.inc

ao2’s picture

Status: Active » Closed (works as designed)

The code mentioned by JurriaanRoelofs in #17 is in 7.x-2.0-beta1 but it's not in 7.x-2.0-beta2, so I am closing the issue again, it has been fixed indeed.