Active
Project:
Region Visibility
Version:
6.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
3 Jun 2011 at 10:32 UTC
Updated:
30 Jul 2013 at 11:56 UTC
Jump to comment: Most recent file
Hi, I'm just wondering if this is still on the cards.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | region_visibility-d7.zip | 4.14 KB | nirbhasa |
Comments
Comment #1
alan d. commentedAlso, here is an alternative, based off core Drupal 7 block code. It has no dependencies and comes in at a mere 200 lines of code. Maybe 300 after some UI improvements, 400 with some more comments.
The module that I implemented this in was iwd, for the 3 hooks used.
hook_form_block_admin_display_form_alter() makes the region title a link in the list regions / blocks page.
hook_block_list_alter() removes the blocks on the list before they are rendered.
I would have really thought that this module would have a higher rate of usage. Dropping the dependency may help it usage stats.
Comment #2
nirbhasa commentedI took Alan D.'s work and also added the ability to edit regions per user role - in other words a sub editor could access the block configuration page, but certain regions can be made off limits. Here is the attached module
Comment #3
donquixote commentedCould you make this a sandbox project?
Comment #4
dubs commentedCan this be made a version 7 release - I don't mind doing it if I'm made a co-maintainer.
Comment #5
chefnelone commentedHope to see a D7 version, too.
Comment #6
chefnelone commentedusing the module attached in #2: I get this error:
Comment #7
dman commentedI've taken the work here, cleaned it up a fair bit (for internal docs, user-facing text, whitespace and PHP-strict notices), and put it into a D7 branch (rooted from the current 6.x-2.x) and it's up at
https://drupal.org/sandbox/dman/2052469 as a sandbox.
The UI and things seem to work as promised. I've not deep-tested the permissions and things yet as I don't know if I need them personally.. I feel that it may be a bit overkill. If my editors have block admin rights, then that's probably enough. Though I do understand that you may want them to be able to put blocks HERE but not THERE sometimes because they can completely destroy the theme like that.
It's sorta scope-creep for this module though. it becomes region_access as well as region_visibility. ... so yeah, still pretty close - not QUITE worth making into a separate supporting module.
Comment #8
dman commented@q0rban - if you'd like to let me and/or Dubs and/or Alan D join the project we could take on the D7 work?
Comment #9
alan d. commentedRemoving myself from the task.
The d6 to d7 upgrades were like small molehills in comparison to the d7 to d8 upgrades that are looking like huge mountains at this point in time, so my other projects will be getting all of my free time.
Comment #10
klonos@dman: the 6.x branch depends on Visibility API. Will that be the case for the 7.x version? I'm asking because currently there's not D7 version of that module: #1990008: D7 version of the Visibility API module.
Comment #11
dman commentedThe copy I took, from [#comment-5585104] above seems to work without it. I believe it's more of a rewrite than an upgrade.
This D7 version integrates tightly with the block management screen (in a clever way) while the D6 original is quite different and has its own stand-alone management UI. I think they just do a similar thing, but have little code in common.
So no, there is no dependency on visibility_api, for better or worse.
I still endorse context.module if we need to do block-visibility with any advanced logic.
Comment #12
alan d. commented@klonos - the dependency was dropped as I personally saw no reason for it, although q0rban may object to this. I have always hated enabling 2 modules for this functionality. I must admit that I usually just manually nuke regions in code as required now, meaning zero additional modules ;)
Comment #13
klonosGot it. Thanx for taking the time to reply guys.