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.Allow an addition to block feature syntax to mean only blocks in given regions. For instance:
skinr[second_sidebar][features][] = block-sidebar_second
skinr[second_sidebar][title] = Second sidebar
skinr[second_sidebar][description] = Theming for left-hand column blocks.
skinr[second_sidebar][type] = checkboxes
After looking through the issue queue, and not finding this functionality to greatly improve the usability of Skinr from a site administrator's perspective, i implemented it for Drupal 6. Coming to file this issue, i did find the successfully fixed issue to do the same in Drupal 7 #523820: Ability to specify regions in info file. Not sure if this should be posted to that issue, or mark it patch to be ported over there. (There never was a patch posted to that issue, it was just marked fixed.) However, this is a working patch for Drupal 6, for anyone who might be interested.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | skinr-901236-4-allow-block-features-to-be-region-specific.patch | 1.95 KB | mlncn |
| #2 | skinr-901236-1-allow-block-features-to-be-region-specific.patch | 1.86 KB | mlncn |
Comments
Comment #1
JacineOh, nice :)
Did you forget the patch?
Comment #2
mlncn CreditAttribution: mlncn commentedPatch attached.
Note that this patch takes a different approach to the syntax put into in Drupal 7, according to Jacine's documentation at #755722: Update documentation for Drupal 7 - regions and rules. Given that only blocks can be region-specific, i think the syntax used here - which happens to be the same as originally proposed in the D7 issue #523820: Ability to specify regions in info file - makes more sense.
Comment #3
moonray CreditAttribution: moonray commentedThe only issue with region specific blocks is that when the block is put into a different region, the skin remains.
Comment #4
mlncn CreditAttribution: mlncn commentedThis patch fixes two bugs in my original patch: incorrect deltas when they included dashes (needed to use explode with a limit), and using a $module variable that conflicted with the existing use of $module. Oops! This will now work for blocks not provided directly by the block module.
Comment #5
JacineI haven't had a chance to test this out, but does the latest patch in solve the issue @moonray brings up in #3? That's a bit of a WTF.
Comment #6
mlncn CreditAttribution: mlncn commentedNo, the patch in #4 does not fix the problem brought up in #3. Also, i've handed off the site i added this for, and won't have an actual need for this in D6, so i recommend we leave this issue for anyone who does want this in 6, if anyone cares that much, and figure out this functionality first in 7. Maybe it has all been figured out properly? I'm happy to help anywhere the D7 issue is re-taken up.
Comment #7
JacineThanks Ben!
Yeah, we have semi-working functionality in D7 for regions themselves. I think we'd have the same issue with moving blocks around in D7, but we could definitely try to make it work.
Comment #8
Jacine:)
Comment #9
moonray CreditAttribution: moonray commentedSee post #3. This patch needs work.
We might go about this by checking the following: when a block is moved, check if the skinr settings still apply. If not, A) we toss out a warning (but where? and do we do that every time they visit the admin/build/blocks page?) or B) we drop those particular skinr settings (after a one-time warning).
Any other, better approaches? I don't like either very much, but couldn't think of a better solution.
Comment #10
moonray CreditAttribution: moonray commentedPostponing. This is going nowhere and we need a good plan to be able to do this.
Comment #11
moonray CreditAttribution: moonray at Chapter Three commentedNew features start in latest version.