I started a forum topic about limiting blocks to certain user roles (http://drupal.org/node/49139). before i was pointed to the other issue for the block.module where this feature is being discussed for inclusion into 4.7 (http://drupal.org/node/18018), i ended up patching my own test site's copy of block.module to provide this functionality, trying to stay as close to the existing code in block.module as possible. now that this feature will work in 4.7, i'm very happy. but, since i know the new feature won't be added to 4.6, i figured i should post a patch against the 4.6 copy of block.module, in case any other 4.6 admins out there want to add this functionality to their site... i'm not sure if this is considered bad form, but since i already spent the effort getting this working, i figured i should share it. ;)

you just have to alter your "blocks" table (either using mysql directly, or via the dba.module) with the following statement:

ALTER TABLE blocks ADD COLUMN roles text NOT NULL AFTER types

(if your site is using DB table prefixes, you'll have to modify the above to include your prefix before "blocks").

yes, i can see how a separate table might be faster, but i was just copying what blocks.module did already, and i'm only storing role ids (rid), so there's no concern about role names that contain commas...

other than that, you just have to apply the attached patch to your blocks.module file. it applies cleanly against revision 1.162.2.5 (the current end of the DRUPAL-4-6 branch).

enjoy,
-derek

p.s. i'm setting the status of this issue to "duplicate", based on http://drupal.org/node/18018. i'm not expecting anyone to seriously review this patch, since i know it's not going to be applied to the real 4.6. if i could have attached the patch to my forum post, i would have just put it there. i'm only submitting this as an "issue" since it seemed like the best place to attach the patch. again, apologies if this is considered bad drupal.org etiquette.

CommentFileSizeAuthor
#1 block.module_by-role21.49 KBdww
4.6_block-by-role.patch6.17 KBdww
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dww’s picture

FileSize
21.49 KB

here's a patched version of block.module, in case a 4.6 site admin who is unfamiliar with patch/diff wants to install this...

just download the attached file (block.module_by-role), rename it to "block.module", save your existing copy of block.module, and install this one in its place.

nig’s picture

Title: Block access by role (4.6-specific patch) » blocks gone completely

Hi
Thank you very much for giving the patched version. I have wrestled for days with patching (with only my ignorance of php, a windows machine, and no shell access to help me) and failed. I was very touched that you placed this patched file here. If this practice is counter-cultural, it does seem in the spirit of open source!

Errr........ however
All blocks dissapear on all pages except the first opening of the home page. After the first opening, its gone on that page too. I made the addition to the blocks table in myPHPadmin.

Any ideas of what's gone wrong?

Thank you

dww’s picture

Title: blocks gone completely » Block access by role (4.6-specific patch)

please don't change the title of this issue (so other folks can find this if they're looking). it's confusing, but when you comment on an existing issue, the title is for the issue as a whole, not just a subject for your own post (like forums).

anyway, onto your question... i'm guessing that when you added that row to the DB, it's putting something in there be default (since i said it needed to be NON NULL, but not that what it should default to). i suppose i should have put in a clause in there to make sure it defaults to '' (the empty string). so, try this to fix the problem:

UPDATE blocks SET roles = '';

after that, your roles field should be empty, which will allow all roles to view each block. then, you can go in and change the settings to select which roles should see what blocks.

follow-up here (without changing the title *grin*) if that doesn't solve your problem.

-derek

nig’s picture

Derek
I tried it again this morning and - perfect!

I think what I had done wrong was -
1. upload the patched blocks.module
2. have a look
3. make the change to the table
This morning I did it in a different order - 3, 1, 2.

I know...... but that's the kind of thing you do as a newbie. ......... like changing subject.

So it looks like, for me anyway, and this morning anyway, it defaulted to the empty string by itself.

Thank you for your guidance and for an excellent module tweak. It will increase the usefulness of our site a lot.

Best wishes
Nigel

ravid’s picture

Title: Block access by role (4.6-specific patch) » Thanks DWW

Thanks for this wonderful module, something I used to do using php script is now automated with a mouse click. This is a great addition, pity it isn't part of the current Drupal build.

Cheers

Heine’s picture

Title: Thanks DWW » Block access by role (4.6-specific patch)

.

g76’s picture

HELP! I tried to change the table and it gave me an error, so I left off the "after types" portion, since there was no types field. It successfully added "roles" to the table. The I replaced the old block.module file with the new one provided here. I got an error message on the blocks config page, so I decided to revert back to the original blocks module.

Now there are no blocks showing and no left side content!!!!
HELP!!!!!!!!!!!

I am with a non profit organization and am running Civispace based on Drupal 4.6. I have poured hours and days and weeks into this install and getting it customized. I just don't know what I'll do if I have to do a fresh install. I have already spent weeks and months customizing the menu and blocks, entering in a wealth of taxonomy vocab and terms, setting up roles, and installing a full load of additional modules.

We don't have alot of money which is why I am doing this myself, but I could pay at least something if someone could resolve this for me. I really need help, this database will help alot of people in need and we're trying to get it up ASAP.

PLEASE HELP!!

-Jen Wolfe

leapmonkey’s picture

Hey i tried the patch but i have the same issues as nigel had before i am able to see th eblocks the 1st time then the error and they dissapear.

the error

user error: Unknown column 'roles' in 'field list'
query: INSERT INTO blocks (module, delta, status, weight, region, visibility, pages, custom, throttle, types, roles) VALUES 'block', '10', 0, 0, 0, 0, '', 0, 0, '', '') in C:....database.mysql.inc on line 66.

i get this acoplue of times
I tried redoing it over again but i get the same error every time.
i switched the order like nig did but it didnt wrk
any suggestions?

escape’s picture

To the users who are having the problem of their blocks disappearing after installing this patch. The issue is that the patch adds a 'role's attribute to each block but doesn't specify any roles by default. Additionally, after installing the patch, I noticed that all my blocks were defaulted to disabled, another reason why they were not appearing.

The solution is to access the blocks admin page directly, enable each block, and configure each block with at least one role (say admin).

I hope that makes sense. In the future, it would make sense to provide a patch that enables all the blocks, and all the roles for each block. Not difficult to do with a simple sql statement.

escape’s picture

By the way accessing blocks admin is via the url:
www.yoursite.com/?q=admin/block

dww’s picture

no, no, no. ;) if you don't select any roles, it's supposed to display the blocks for everyone. see my comment in #3 above. try that, instead. i guess i should make a new patch that adds an empty string as the default. oh well. sorry folks. i've been busy getting this feature into core (http://drupal.org/node/18018 -- now committed!) and a million other things.

dww’s picture

my last comment tried to undo the annoying bold this whole thread has taken. let's hope this does it. ;)

PAAHCweb’s picture

After many hours of searching, I found this elegant solution to a common request! Just wanted to say thanks. Works beautifully when the table is modified first, as you instructed. Only wish I'd found it sooner! :^)

Happy trails,
D Lynn