I have a recently upgraded 5.1 site which we'd like to put private forums and moderators on. When we install forum access, non-admins get access denied to all non-forum posts (most of them are cck content types), and some of our views blocks show content from a year ago (although I think this might be cached blocks shown to anon users, so probably exactly the same issue).

Then when we try to disable forum_access in modules administration, unticking the box works, but clicking "submit" leads to a blank page, and going back to module admin shows it as still enabled.

Our solution to this has been to manually disable forum access in system table, then empty the acl and node_access tables, putting the single realm all, grant_view 1 line back in.

I'm not 100% sure this is an issue with forum_access - we used to have strange behaviour with TAC before as well. But that was with 4.6 and I understand there's been major changes with node access arbitrator and stuff.

Some basic information about the site:

13,000 nodes
130,000 comments
six vocabularies (inc one large freetagging vocabulary)
only forum posts get attached to the forums vocabulary - not available to other content types.
Forum posts do not get placed in any other vocabularies.

The forums and private forum appear to work fine in terms of permissions, it's everything else that gets affected.

We've had to manually restore node access at least once before, so it might be messed up (or something related), but this combined with not being able to disable the module got me to stick it here.

There's no errors in the drupal logs relating to it.

I have a copy of the site running on the same server that we used for a dry-run of the update - almost the same db. So could install forum_access on that to give more detailed information about the changes it's making.

Any help much appreciated!

Comments

merlinofchaos’s picture

Hmm. Your problem may largely have to do with having 13,000 nodes -- when forum access is enabled (or disabled) it has to rebuild the status of all those nodes. It came to my attention recently there's a bug in core with that at this time, that's going to have to be fixed. Unfortunately I don't have a bug number to point you at, but it has to do with nodes being cached causing all memory to be used up.

catch’s picture

ah ok, that sounds reasonable.

fwiw, I can't get search indexing to work either - stops at 21 or 300 nodes depending on a couple of things (seperate bug report for that). Is it possible these are related?

I'd be happy to try out patches and debug to the best of my ability, or give access to you or any other developers I 'know' to help get this fixed.

jlmeredith’s picture

I recently faced the same problem and after quite a bit of digging found out about the bug in core regarding the rebuilding of the node access permissions. To make a long story short, the process is flawed because the function used to rebuild the permissions - node_access_build() - loads all nodes and caches them. In my case I have about 4000 nodes, 8 roles and 80 users. Rebuilding the node permissions would burn up 128 megs and then error.

The solution for me was updating to the HEAD version of Drupal, where a patch for this issue has been submitted. Since that time I have had no problems and I have been testing several access modules. I even loaded up a scratch install with over 20,000 nodes, 100 roles and 10,000 users. It took a long time, but did not error out and I believe the memory never crossed over 75 meg.

My understanding is that they are working on a batching process for node_access_build() which will also be used for other processes in 6.x. such as update.php with a graphical process display. Here is the node I found about the memory issue and the batch process in planning.

http://drupal.org/node/108752
http://drupal.org/node/144337

Hope this helps.

catch’s picture

Status: Active » Closed (duplicate)

thanks I've been following those issues, marking this as duplicate.