Posted by Avaya on March 12, 2009 at 12:37pm
I've been trying to get various access control modules to work; all require the content access permissions to be rebuilt
The content access permissions need to be rebuilt. Please visit this page.
After starting the rebuild, it hangs at:
Rebuilding content access permissions
Remaining 1 of 1.
I've let this run for as long as 9 hours, and still nothing. I do not have a big site either.
When I click on a different link to interrupt the rebuild, I get the following error:
An HTTP error 0 occurred. /drupal/?=batch&id=22&op=do
Looking for any advice on how to resolve this issue.
Comments
In node.module this piece of
In node.module this piece of code, is setting time limit to 240 secs which might be still low than ur php.ini. You can try increasing set_time_limit arg to 1000 and then changing it back to 240 to keep code consistent.
if (!ini_get('safe_mode')) {
set_time_limit(240);
}
$result = db_query("SELECT nid FROM {node}");
while ($node = db_fetch_object($result)) {
$loaded_node = node_load($node->nid, NULL, TRUE);
// To preserve database integrity, only aquire grants if the node
// loads successfully.
if (!empty($loaded_node)) {
node_access_acquire_grants($loaded_node);
}
}
}
}
If anyone knows a more non core hackish way then I'll like to know as well.
--------------------------------------------------------
Dipen Chaudhary
www.qed42.com ( Drupal development services specialize in social networks and other user generated content platforms )
www.dipenchaudhary.com
Had this problem in the past...
It came down to a combination of a specific module and malformed data. We resolved it by turning off all modules except core, and seeing if we could trigger the problem at that point. Then, we slowly enabled modules until the problem appeared. Then isolated the module, and looked at both it and it's related config and content data until we found/fixed the problem. Took a day or so (we use a lot of modules), but we found it (it was a sub-module of Domain Access that somehow got messed up during a transfer to a new sit).
I've disabled all modules
I've disabled all modules except the "Core- optional". The "The content access permissions need to be rebuilt. Please visit this page." goes away, but I don't have any access control list.
I've tried turning on each access control list one by one, and only one at a time:
Organic Groups
Book Access
Content Access
Taxonomy Access Control
Each one requires the "rebuild" and each hangs. I even changed the 240 to 1000 in node.module (and repeating the above) and it still hangs...
What could be wrong?
"I forgot my pen"
Time to check your apache
Time to check your apache error log.
--------------------------------------------------------
Dipen Chaudhary
www.qed42.com ( Drupal development services specialize in social networks and other user generated content platforms )
www.dipenchaudhary.com
RESOLVED
This is sounds crazy, but every time I interrupted the build I got the
error.
I though maybe it had problems with a node. So I deleted that node (after making a backup of it). The next time I ran the rebuild the id would change; I then deleted that node. I started noticing that all these nodes had a status of 0 (zero). I also noticed (through my recollection) that these were nodes that were originally from Wordpress, imported into another another Wordpress and then imported into Drupal.
I did a
DELETE * from `nodes` WHERE status=0;I activated one of the access control modules and it rebuilt in about 3 seconds. I disabled one and activated another access control module and that works.
I'm thinking something was "funky" with those nodes maybe.
Either way. This has been resolved.
"I forgot my pen"
Cleaning worked
Removing the 0 status content also resolved my problem with v6.14
Shivnibble: The Ultimate Brady Experience
I just have to reply to this
I just have to reply to this suggestion, as this is the worst suggestion that you could perform.
You are basically asking people to delete all unpublished content from your node table which is a HORRIBLE and POTENTIALLY DANGEROUS suggestion.
If you have any sort of workflow process for generating content, you will delete all content that is unpublished.
The reason you are getting the "You are not authorized to access this page" message is due to the fact that the content you are trying to access has a status = 0. Anonymous users cannot access nodes in this state.
You need to publish the node in "Publishing Options" when editing a node to fix this problem.
Unless a module supersedes the permissions system of drupal core.
I would highly suggest NOT executing this query against your database.
Another possible hack
Not sure why this is happening to me, but I've found that I can just force node_access_rebuild() to not use batch mode by changing line 2314 of node.module from:
<?phpif ($batch_mode) {
?>
to:
<?phpif (FALSE) {
?>
It solved my problem. I was
It solved my problem. I was hitting rebuild for whole day finally I set $batch_mode to FALSE. after that my content permission rebuild was successful
Thanks monotaga
Doesn't seem to work in 6.14
Monotaga,
This hack doesn't seem to work for ver 6.14. Also in this version, the correct line would be 2310.
In my case this appeared after updating OG.
OG seem to make that problem
OG seem to make that problem for me too. but It worked for me. I am using 6.14 ver.
unending rebuild
Thanks a ton, monotaga. I have spent two days cracking this, including a shot at Simple Access. But, my surprise was that this happened only after we moved the site from shared to VPS. Never faced this issue on the shared host. DOes this have anything to do with the host?
Thank you
Good thinking there....after waiting a 1/2 hour for it to rebuild...your solution worked great...did you reset the script back to original?
thank you so much, this was a
thank you so much, this was a lifesaver!
You Rock
Resolved and rebuilt in 10 secs thanks dude.
droopal enthusiast
It worked for me. Thanks
It worked for me. Thanks
thank you!!!!
monotaga - thank you, this worked. My permissions rebuilt in TWO seconds after this.
Where is node.module?
Where is node.module located?
module/node/node.module
module/node/node.module
ok
this worked for me too, and im using pressflow 6.20. But i'm not sure if this is a correct solution. Have no clue what is the source of this problem at first place.
didn't work
Also didn't work for me using v6.14. Not using OG. Did just migrate site from VM platform to our own server though.
Currently investigating the other fixes.
Shivnibble: The Ultimate Brady Experience
Added and Enables StringOverrides Module when Hang Occurred
I had installed String Overrides module and then enabled that and Node Privacy Module when I got the "The content access permissions need to be rebuilt. Please visit this page." message. At first it hung up and then the screen went blank (white). I used the Back button, then read a few strings on this issue, then returned to start turning off/on modules, but thought I'd try and see what node it might be handing up on. It dutifully performed the rebuild in under a minute. I'm not sure what the hangup was, but it could have been some other server issue I suppose. I hope this may be helpful in some way.
I believe this is a FF browser / JavaScript issue
When the browser hangs (i.e. stops loading without displaying the progress bar), I reload the page (i.e. I click into the address field and hit Enter, NOT refresh), and this has always allowed the batch to proceed.
Rebuilding Content Access Permissions
This is really scary when it happens. Each time it seems like there is a different issue to tackle. This time it took all Thanksgiving day to figure out the issue. ACL & Forum Access & even User Relationship Access would trigger the dreaded 'your content permissions haven't been built properly' error and batch errors. This time I found that I had eliminated some content types and not the nodes with them. Still, once I fixed this issue, this did not cure the problem (but probably was adding to the problem). I found that an old UID of 0 that I had was associated with some 100 nodes I created. When I would click on those old node UID links they triggered a 'page not found' response. So, I just changed them all to a non-0 UID for another of my usernames on the site and bingo. No ACL, Forum Access, or User Relationship Access problems. Everything works. Let me tell you, I thought 3 years of drupal was down the drain because everything was seeming to come apart at once with all kinds of pink warnings of so many different kinds. Bad enough an active website had to be down all day. Yet, I am so relieved that fixing this one problem has cleared up everything.
protoplasm
Same problem
@protoplasm
No idea what went wrong with mine in the first place but the replacing UID method worked a treat! phew!
is this not a (core) bug
i believe this is a legacy issue, but surely there should be some core fix for the possibility that a user is deleted but nodes remain - or am misinterpreting this?
Computed_field + Search
My problem was with Computed_field module and Search module, where rebuilding node cause loop by loading the same nodes again and over again, so even cron was not working correctly.
Maybe, there are some nodes,
Maybe, there are some nodes, which is not in use, cause the problem. If you removed a node-type, but didn't delete that nodes, you should do it!
http://drupal.org/node/432938#comment-2667862
-----------
Önismeret, személyiségfejlesztés, meditáció, spiritualitás.
I had the same problem. My
I had the same problem. My reason was that I deleted users on user administration page, and after it I had problem with rebuilding access permissions.
I checked tables 'node' and 'node_revision' - even after I deleted user 72 , the node created by this user still had uid=72 , I changed it
UPDATE `node_revisions` SET uid = 64 WHERE uid = 72
UPDATE `node` SET uid = 64 WHERE uid = 72
for another user.
And after it I was able to rebuild access permissions.
this worked for me in 6.16
monotaga's reply from above, that is. This reply didn't end up in the right place, sorry.
It works!
I've changed FALSE instead of $batch_mode in modules/node/node.module and it works.
Thank you!
Seems to have saved me as
Seems to have saved me as well, worked for Openatrium beta7, based on Drupal 6.17
-------------------------------------------------------------------------
ExtendOpera.org, extend your Opera.
jQuery can cause hang
I was using jQuery update module with jQuery 1.4. This causes the batch to not update.
To fix it, you have to prevent newer jQuery from loading when the URI contains "batch".
This is my function replacement:
function jquery_update_jquery_path() {$curr_uri = request_uri();
if (strpos($curr_uri,'admin')>0 || strpos($curr_uri,'edit')>0 || strpos($curr_uri,'add')>0 || strpos($curr_uri,'batch')>0 ){
$jquery_file = array('none' => 'jquery.js', 'min' => 'jquery.min.js');
return JQUERY_UPDATE_REPLACE_PATH .'/'. $jquery_file[variable_get('jquery_update_compression_type', 'min')];
}
else {
$jquery_file = array('none' => 'jquery-latest.js', 'min' => 'jquery-latest.min.js');
return JQUERY_UPDATE_REPLACE_PATH .'/'. $jquery_file[variable_get('jquery_update_compression_type', 'min')];
}
}
This worked for me...
For those of you who are wondering how to use multiple versions of jquery I've been using the following code located at the end of the jquery_update.module, this is definetely a hack but it's worked painlessly for me, especially since views won't work with any of the new jquery's
/**
* Add whatever conditions you need to if list for pages which should use an older version.
*/
function jquery_update_jquery_path() {
if (arg(0)=='admin'||arg(0)=='batch'||arg(2)=='edit')) {
$jquery_file = array('none' => 'jquery-1.3.2.js', 'min' => 'jquery-1.3.2.min.js');
return JQUERY_UPDATE_REPLACE_PATH .'/'. $jquery_file[variable_get('jquery_update_compression_type', 'min')];
}
else {
$jquery_file = array('none' => 'jquery.js', 'min' => 'jquery.min.js');
return JQUERY_UPDATE_REPLACE_PATH .'/'. $jquery_file[variable_get('jquery_update_compression_type', 'min')];
}
}
Here is the code that I am
Here is the code that I am using for the jquery update fix. It is basically the same as above, just a bit cleaner.
function jquery_update_jquery_path() {
$jquery_file = preg_match('/(admin|edit|add|batch)/', request_uri()) ?
array('none' => 'jquery.js', 'min' => 'jquery.min.js') :
array('none' => 'jquery-1.4.2.js', 'min' => 'jquery.min.1.4.4.js');
return JQUERY_UPDATE_REPLACE_PATH . '/' . $jquery_file[variable_get('jquery_update_compression_type', 'min')];
}
jQuery update and this post
I tried all of the things in this list and none worked - I never got past initializing!
I checked the settings for jquery update and had "minified" instead of "none", once set to the correct setting, it worked within seconds.
What a relief after many hours searching. Hope this helps someone else.
Every time I tried to rebuild
Every time I tried to rebuild permissions, it never got past "Initializing". I tried every solution here and nothing worked. It turns out I needed to switch out of my custom theme. Both were sub-themes, using Zen. Another theme I created never had this issue. I can't quite figure out what the problem was, but it's another thing to try if anyone else is having issues.
in my case, i had a problem
in my case, i had a problem in my custom template. I activated root candy or any of the core and repeated the operation... i even did not arrive to see the percentage progression. After the change and very slowly, but it worked: 1%... 10%... 75%... and worked fine :-). It can be simply a problem with your theme and js.