Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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 ;)
Comment | File | Size | Author |
---|---|---|---|
#5 | 0001-Issue-1165672-don-t-disable-blocks.patch | 1.27 KB | ao2 |
Comments
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedI'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?
Comment #2
q0rban CreditAttribution: q0rban commentedHey 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?
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedThat's right, so in my install file I have the following:
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 ;):
Comment #4
ao2 CreditAttribution: ao2 commentedHi, I too have run into the issue at #3, but is this profiler specific?
Thanks,
Antonio
Comment #5
ao2 CreditAttribution: ao2 commentedAh, 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
Comment #6
Anonymous (not verified) CreditAttribution: Anonymous commentedThanks! Can't believe I missed that one, must've been looking at the code for too long ;)
Comment #7
Anonymous (not verified) CreditAttribution: Anonymous commentedCan't get the patch working
...not sure if it's just not formatted correctly or whether it can't patch libraries.
Comment #8
ao2 CreditAttribution: ao2 commenteddrush_make needs to be patched to handle patches made with git, see #745224: Apply patches from git diff and git format-patch
Comment #9
q0rban CreditAttribution: q0rban commentedAh, 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?
Comment #10
Anonymous (not verified) CreditAttribution: Anonymous commentedI 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.
Comment #11
adamdicarlo CreditAttribution: adamdicarlo commentedAlso, 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.
Comment #12
q0rban CreditAttribution: q0rban commentedThanks! Committed: http://drupal.org/commitlog/commit/13682/4fbcb1a5644f21e32ce640943580440...
Comment #13
ao2 CreditAttribution: ao2 commentedThanks @q0rban, if it is easier to you next time you can use
git am
to merge my patches (generated withgit 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
Comment #14
q0rban CreditAttribution: q0rban commentedThanks 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! :)
Comment #15
ao2 CreditAttribution: ao2 commented@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
andgit 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 ofgit 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 alwaysgit commit --amend
.OK, but that's just me. I just wanted to share my personal POV :)
Keep up the good work,
Antonio
Comment #17
JurriaanRoelofs CreditAttribution: JurriaanRoelofs commentedI'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
profiler_api.inc
Comment #18
ao2 CreditAttribution: ao2 as a volunteer commentedThe 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.