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.
The attached patch fixes some random behaviour when submitting content_access-related forms.
This was messing up permissions for anonymous users (rid 1) because the arrays in question had the form "rid1 => 1; rid2 => 1" instead of "0 => rid1; 1 => rid2" (i.e., array_keys of the former).
I briefly tried the latest -dev, but this behaviour still seemed to be there.
Comment | File | Size | Author |
---|---|---|---|
#26 | Content access says: no | 23.77 KB | Danny_Joris |
#26 | Devel content access block says: yes | 17 KB | Danny_Joris |
content_access.patch | 1.13 KB | avf | |
Comments
Comment #1
fischerj CreditAttribution: fischerj commentedpatch works fine. Thx!
Comment #2
jwgreen1974 CreditAttribution: jwgreen1974 commentedIn my case I came across this on a new site I was building, and the module worked on one test site and not the other. The difference was that on the one that was not working, I had created a role for site administrators and put the super-admin in it, which was also the account that I was using to work on the site. When I did this on the site that did not have this problem, the problem showed up there as well. Both sites were bare-bones with no other modules installed but this and the ACL module. When I deleted the site admin role, going back and re-editing the permissions in the nodes that had problems fixed the issue.
Comment #3
picapaoo CreditAttribution: picapaoo commentedHi everybody,
i`d like to apply this patch too but I´m not a programmer.
What do I need to to?
Replace this code in the content_access.admin.inc file:
foreach (_content_access_get_operations() as $op) {
// Set the settings so that further calls will return this settings.
$settings[$op] = array_filter($form_state['values'][$op]);
}
// Save per-node settings.
content_access_save_per_node_settings($node, $settings);
if (module_exists('acl')) {
foreach (array('view', 'update', 'delete') as $op) {
acl_save_form($form_state['values']['acl'][$op]);
}
}
by this code (patch):
@@ -68,7 +68,7 @@
$node = $form_state['node'];
foreach (_content_access_get_operations() as $op) {
// Set the settings so that further calls will return this settings.
- $settings[$op] = array_filter($form_state['values'][$op]);
+ $settings[$op] = array_keys(array_filter($form_state['values'][$op]));
}
// Save per-node settings.
content_access_save_per_node_settings($node, $settings);
@@ -156,7 +156,7 @@
foreach (content_access_available_settings() as $setting) {
unset($settings[$setting][$form_state['type']]);
if (isset($form_state['values'][$setting])) {
- $settings[$setting][$form_state['type']] = is_array($form_state['values'][$setting]) ? array_filter($form_state['values'][$setting]) : $form_state['values'][$setting];
+ $settings[$setting][$form_state['type']] = is_array($form_state['values'][$setting]) ? array_keys(array_filter($form_state['values'][$setting])) : $form_state['values'][$setting];
}
}
content_access_set_settings($settings);
Please help!
Thanks,
Chris
Comment #4
grobemo CreditAttribution: grobemo commentedI had the same problem on a new site: I was unable to disable access to a "Staff Page" node type for anonymous users.
This patch solved the problem for me (using Content Access 6.x-1.0 on Drupal 6.10).
Thanks, avf!
Comment #5
xhochy CreditAttribution: xhochy commentedFlagged it as a bug report since this is a bug and not a request for support.
Comment #6
capmex CreditAttribution: capmex commentedTested patch, it fixed the issue.
Comment #7
pepó CreditAttribution: pepó commentedPatch works.
Comment #8
xhochy CreditAttribution: xhochy commentedComment #9
leon85321 CreditAttribution: leon85321 commentedNICE FIX!!! avf
Thank you very much!!
Leon
Comment #10
fagohm, I'm not totally sure what's the problem that got introduced with drupal 6.10, but indeed some tests failed and your patch fixed that. So I've added your fix to the rules integration too and committed it. thanks!
Comment #11
fagoPlease test the next generated dev snapshot.
Comment #12
tryitonce CreditAttribution: tryitonce commentedHi Chris,
did you work it out or are you still waiting for the answer?
Comment #13
jvieille CreditAttribution: jvieille commentedI tried today's dev. It doesn't work.
I am still unable to disable "View any content" and "View own content" for anonymous user
Comment #14
picapaoo CreditAttribution: picapaoo commentedHi tryitonce,
no i didn`t work it out yet. I`ve been waiting for the answer for a while. Then i switched to nodeaccess -that one works fine:-)
That doesn`t mean I`m not interested getting an answer anymore.
It´s just a matter of time having the same patch problem again with some other module...
So what do i need to do to use this patch (or other)?
Replace the ancient code by the patch code in the file? I know, this question sounds silly for some expert, but as i said: I´m no programmer!!
I`ve only got some basic skills in action-script1&2 programming, that`s it...
Thx in advance!
Chris
Comment #15
duozerskJust checked the latest dev available; it looks like the patch from this issue wasn't applied - just looked on the strings this patch changes and they were not changed.
Comment #16
tryitonce CreditAttribution: tryitonce commentedHi Chris,
You need to open the file "content_access.admin.inc" with a suitable editor - I use PSPad - http://www.pspad.com/.
The patch is for the replacement of two lines of code:
1. line
2. line
That is it. Now you have to make sure that the file is saved. It might take a few seconds to go through - a little longer if you are not working on your home local machine. You might need to clear your cache and make sure Drupal is running in development mode - with cache disabled - or clear the cache in Drupal as well.
Now you should have fixed the problem. Quite simple in a way, but not so easy the first time - as many of the experts assume we know all these simple mechanics of "brick layiing". I am not an expert and can very well understand how you feel. I hope it works and do ask the experts "silly" questions - well there are no silly questions - only silly or sometimes arrogant answers.
I guess patches are shown to include relevant code of the routine around the patch - so the expert can see exactly what the patch will do and whether it will work. So, fair enough.
I hope it helps and works for you. Good luck
CC
By the way - do report back how you solved your problem and do write how you did it - add file names and links to where you found help, files, etc. - lots of people joining Drupal will be grateful - for a simple, "start-with-the-basics"-approach.
Comment #17
TSE CreditAttribution: TSE commentedHi,
i had to use this patch since it's not in the latest dev version: 6.x-1.x-dev from 2009-Mar-16
Worked fine, Problem solved ;)
ThX TSE
Comment #18
akalsey CreditAttribution: akalsey commentedPatch tested against Mar 15 dev snapshot and 1.0 release. It applies perfectly and fixes the issue.
Changing the title to be more descriptive of the issue (to help other people find the issue and patch).
Comment #19
fagogrml, somehow the changes in .admin.inc were not committed. I've done it now, sry.
Again please test the next devel snapshot.
Comment #20
wdevn CreditAttribution: wdevn commentedThis patch really works!
Thanks a lot!
Comment #21
duozerskfago,
It looks like a major functionality fix for the CA and its Rules integration... so maybe it will be appropriate to release the 1.1 version?
Comment #22
swordedge CreditAttribution: swordedge commentedPatch works... silly way to apply it (manual editing of said file)
and when I finally disabled Anonymous from viewing my members only page, it said
Access denied
You are not authorized to access this page.
It is also a menu item and... disappeared from the menu... yay! Log in and it reappears.
Can I edit that access denied page message?
Over all, took all da?? day to find and configure a members only section. Way too long IMHO
Now to test autologout... 23 days logged in is idiocy
Comment #23
fago>It looks like a major functionality fix for the CA and its Rules integration... so maybe it will be appropriate to release the 1.1 version?
I agree, I just wanted to be sure it works.
Comment #25
CarbonPig CreditAttribution: CarbonPig commentedsubscribe
Comment #26
Danny_Joris CreditAttribution: Danny_Joris commentedI'm very sorry to open this after such a long time. But I still have this issue.
When I disable anonymous users to view a certain content type, this content type will still be viewable for anonymous users. According to 'Devel Node access by User' the permission is granted by Node Access permission. I have two screenshots in the attachment.
But disabling node access for anonymous users in permissions, makes it that I can't enable access for anonymous users using Content Access...
Thanks in advance,
Danny
Comment #27
tryitonce CreditAttribution: tryitonce commentedYou need to enable
node module - access content for anonymous users.
Otherwise they will not see anything.
Then you need to go into each Content Type and change the settings to what you require.
The problem comes if you grant node module - access content for anonymous users and later add the Content Access Module. In this case all Content Types will allow anonymous users to access all nodes. If you now load Content Access Module this setting remains and you have to visit each Content Type to change the settings.
Just as a note - under
you should check only administrator - not other user roles that should not have access to the admin. of the modules.
I hope this helps ... good luck ....
Comment #28
Danny_Joris CreditAttribution: Danny_Joris commentedHi tryitonce, thanks for you help, but I'm afraid that is what I already did. (Or maybe I'm reading your instructions wrong?)
1) I enabled anonymous permission for node module - access content and added the content access module later. Then I disabled access for anonymous users on on a specific node type. (first attachment of my previous post). Anonymous users are still able to see the node type. Also when I disable access for an authenticated user, this authenticated user will still be able to see the node.
2) something else on a side note: What I initially am trying to achieve is to disable access to a full page of a content type, but still to show this content type in a view. The reason for this is that I want to show content in a view, but I don't want their un-themed full nodes floating around. Nobody is ever going to find them, but I don't like the idea that they are still accessible for anonymous users. In the past I tried this method, and I will use it again if I don't find an alternative. The downside of this method is explained by someone else in that thread: that in redirects instead of giving a 'page not found' or a 'no permissions' error, which is not good for SEO.
My question is: if this module is able to deny access to a content type, will this module allow this content still be able to be shown in a view? I tried the nodeaccess module and it does deny access to anonymous users, but this content won't be shown in my views anymore.
I would like to make a comparison with published nodes. Anonymous users don't have access to unpublished nodes, but you can set up a view where you are able to show all unpublished nodes to anonymous users.
Thanks again for your feedback.
Comment #29
tryitonce CreditAttribution: tryitonce commentedDanny,
I think you are trying to make a contradiction to work.
If you want to block a node it should not show up at all - not in views, as a teaser or so on for that role.
You could try to work with unpublished nodes.
In views you can include unpublished views to make them show up. This way user will not get the unpublished node - but should see it in views.
Another option is using CCK - with the cck access module you can allow users to see fields related to their role. So, anony. can see say basic fields, while auth. members can see those plus 3 (any number) more and premium members can see the whole story.
I have used unpublished nodes to create a database for certain information that is then displayed in a Views table - without a link to the node of course.
I hope this helps a bit - good luck .....
Comment #30
Danny_Joris CreditAttribution: Danny_Joris commentedI did that in my first websites, until I saw that it confused my clients. They didn't accept it, which is normal.
Another downside to that is that you can never really unpublish such a node.
So I know now it is not possible, but having a functionality to overwrite this node access for views would not be unrealistic in my eyes.
Thanks for your thoughts on this
Comment #31
salvisI haven't really digested #27 through #30, but if you're still wondering why Anonymous can view the node, then post a screenshot of the other DNA block.
Comment #32
AndreaD CreditAttribution: AndreaD commentedI had some problems with this module. I would say this post have help me a lot: http://www.zivtech.com/blog/drupal-node-access-explained-0
I have tried some different access modules before.
But I thought Content Access will be suitable for my needs.
I needed to rebuild my permissions, (You can find this option at admin/content/node-settings which is the 'Post Settings' configuration screen.) now it is working correct.
(Hope it helps someone in the future.)
Thanks for this great module. Just what I needed!!
AndreaD
Comment #33
fagoPlease don't make use of this issue in order to post support questions. Open separate issues.
If there is still a problem related to the original issue, please re-open a new one as this issue is messed up.
Comment #34
anewbie CreditAttribution: anewbie commentedThis one(#32) works for me. Just rebuild the permission, simple enough. Thanks.