I have just installed the ACL and Content Access module. Imedietly after enabling them I was asked to rebuild the permissions. All perfectly normal I am told.
However, I set the 'rebuild' permissions page running about 40 minutes ago and it still says 'Initializing'. How long should it take? Am I doing something wrong?
The standard "rebuild perms" duration is roughly proportional to the number of node multiplied by the number of access modules enabled.
On a site with 100k nodes, you can easily take more than 24hours to rebuild permissions. Which means you simply don't want to do it interactively. But you can launch that rebuild from drush or use one of the faster non-standard rebuild methods.
To do it via drush, use:
drush php-eval 'node_access_rebuild();'
Just refresh the page. The perms get rebuilt in a few seconds :).
Note: If it takes you 24 hours to rebuild on a site with 100K nodes, something is wrong. It takes us about 30min on a site with 200K+ FWIW. For a smaller site it should be much less; I suspect you were experiencing an error of some kind.
A quick solution can be just change your theme back to default GARLAND theme and than try again rebuilding permissions, most probably it will work. As sometime it is JS errors which is causing it to stuck on Initialization.
And if your site has too much data (node like 100k , 200K) you can also use this script by placing it in a php file in Drupal root and running it. The code is under the heading
WSODs Due to Specific Modules -> Node Access
on this link :
http://drupal.org/node/158043
Related
I have a running Kentico 11 portal engine site and need to update the transformations in my navigation menu control. Something I have done many times before.
Today I went through all of the steps and the save button does not update the code. It never displays the change were saved messaging.
When I open the browser dev tools I see several errors on the page:
errors
A couple of things to check.
Is this happening in different browsers, also?
Can you save other transformations?
On this particular web part, if you select a different transformation, will that save successfully?
And, is the event log registering any errors?
Sounds like it may be a caching issue. What I'd suggest is the following:
restarting IIS
Open a private browser window and log in
attempt to make an edit to the code in question
If this does not resolve the issue, have you made any changes recently to the web.config, in particular the CMSHashstringsalt value? If so, this will cause your macros to become invalidated. You'll need to go to System > Macros > Signatures and check both boxes and resign the macros. It may take some time depending on your site but this could also help resolve your issue.
i am currently hosting my site on justhost (just as a test server), when i save my work on my local computer through aptana the files are automatically uploaded to the hosting server, and they appear fine. However this only works for my actual files like .php and .html
They do not work for my .css files, so if i save them and upload them the changes do not take effect, until like the next day, or if i turn my computer on and off and leave it a couple of hours, i am not sure why they are not taking effect immediately like the rest of the fiels.
I have tried deleting my cache and adding ?ver=1.0 to the end of the file name, but still no luck.
Also, i checked the hosting directly and the css file has updated to the correct version, but just does not show in browser.
Any ideas on what could be wrong, it would make life much easier if i could get them updating like the other files.
Thanks
I can't be sure what is causing this, but if I'm correct - the files do upload, its not a case of not uploading. It's one of these things
The Cache is holding it (already cleared it though?)
The file is doing some odd cross server transfer, depends what sort of hosting your on, but it may be the file is getting held up somewhere
Try clearing the DNS Cache
Start > type CMD > in the dialog type:
ipconfig /flushdns
That may force the computer to reload the file.
As for an ongoing solution to prevent it in the future I'm out...
I know it has been a while, but as others may find this question the way I did, the solution for me was to enable Cloudflare Developer Mode. Cloudflare was keeping the css files in cache and it drove me crazy to find the solution in another forum. I hope your case may be the same as mine as thus you can solve it as well.
I am currently building a website using drupal 7.x. Unfortunately I cannot seem to enter the admin/config page. Every time I click on the configuration tab on the administration menu, I only get a blank page. Then I created another sample site. It also has the same problem and I am using WAMP server. I cleared cache and finds no difference. I have searched for similar issues, but could find none. Can someone please tell me what I am doing wrong?
A number of things can cause the White Screen of Death, but the most common things to check:
As suggested above, memory limit may need to be increased.
Have you enabled any modules other than those in Drupal core? Try disabling contributed modules and enable individually until you experience the error, to help you identify which module is causing trouble. If you can't access the modules admin page, you can disable them in the database - the system table has a 'status' field. 1 means enable, 0 is disabled.
Could it be a permissions issue? Check admin access permissions or try logging in as the superuser (user ID 1).
Lots more and discussion here and here.
Finally I got the answer. Increase the max_execution_time in php.ini file. It solves the issue.
A few things to try...
Check your php error log for clues.
Create a simple file that calls phpinfo() and see what your memory_limit is. It may need to be increased.
Try tweaking your php.ini to get it to display an error message instead of a blank page.
I tracked this very issue to l10_update module, once I enable it, admin/config shows the WSOD. Once I disabled it, everything's fine. So:
- unchecking the localization_update module in the "modules" list
- de-installing it from the modules list
- deleting directory sites/all/modules/l10n_update
- and re-installing the module (from the same tar.gz file)
Source: https://www.drupal.org/node/1141160
I just picked up a client who's Wordpress web site takes anywhere between 8 to 22 seconds to START loading. The loading delay also occurs when using the Wordpress backend so I'd like to fix the loading issue first before starting my work (template re-design). What's the quickest yet efficient way to determine why this Wordpress site is taking so long to start loading?
Thanks in advance
P.S. - They currently have a caching plugin installed (WP Super Cache) which I assume the previous web developer installed to help with the loading issue but it only helps with the front-end and not the back-end.
Try to run some test like YSlow and Google Page Speed and read their results and suggestions.
Google Speed Online is helping me a lot with analysis of my websites.
http://pagespeed.googlelabs.com/
I use browsermob. They use real browsers to test the site load performance. Shows very nice graphs showing how long each and every request took. Also shows how many requests happen in parallel. As they use real browser, you can see how long it will take to load on a real browser. Then you can choose from which location you want to test. You can choose a UK location to test how fast your page loads from UK.
By the way, I am in no way related to browsermob. I just happen to be a satisfied user of this.
And it is free.
Your server is probably loading far too many modules and is thrashing the disks as it's run out of memory.
You need to both reduce how much memory each PHP instance consumes and limit how many PHP instances can run simultanouesly to ensure you don't use virtual memory for your PHP instances.
I've written a detailed answer to a very similar problem here on Stack Overflow:
How can I figure out why my Wordpress pages load so slowly?
Well, i have came across a similar situation, such things happen when your website is hosted on a GridHosting server, which means it changes according to the server load, but sometimes the things are just opposite the scenario, the best way to check why it is slow is to first ping the website at random interval , so in this way you will know if the distance is the cause or the packet dropping is the issue, secondly, you need to make sure your server's configurations is good, i.e; request your host about a RAW log of your website, in this way you can know what is it taking long for your server to response, and the least best method is to check and make sure that your DNS resolves in a good time, and try to use some free CDN services like CloudFlare.
Hope this helps.
I'm TEN pages from finishing Using Drupal and I'm stuck. I turned on the Theme Info module to aid in theme customization. However, I can no longer access the admin>>modules page to turn on/off modules (including the Theme Info module). It brings up this white error page that says it tried to access about twice as much memory as is allowed. I could reinstall Drupal, but it'd be pretty lame if that's the only solution.
Any help would be greatly appreciated!
-Landon
Two options.
Remove the 'Devel' module from your modules directory entirely. Reload the page. Voila! No Theme Info module. Downside: If you drag the module back in, it will still be enabled.
Open PHPMyAdmin (if you're using MAMP, WAMP, or a server that has it installed) and run the following query: UPDATE system SET status = 0 WHERE name = 'devel_themer';
Those should work to disable any module "in a pinch." You can also edit the php.ini file in your MAMP/WAMP configuration to give it more memory temporarily, though that trick won't work if you're running on a shared host that doesn't recognize php.ini changes.
First apply Eaton's suggestion (I prefer the second one).
Then increase memory_limit in your php.ini config (usually /etc/php5/apache2/php.ini). A WSOD for just that module means you really don't have enough RAM per script for anything serious: most configurations these days needs 32M at least.