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.
Related
I have change a bit of code in my CSS from Magento for my header logo but Magento doesn't load my new CSS update and still shows the old one.
I have already refresh the cache in Magento
Flush Magento Cache
Flush Cache storage
Flush Javascript/CSS Cache
At System - Cache Management
I have a folder var/cache and in here folders like mage--0, mage--1
i have tried to back-up them so i can restore it when i delete them and something won't wrong but i cant back-up it.
Hello first of all you can always safely delete the contents of var/cache you do not need to back it up. I konw it might sound silly but did you clear browser cache? Also make shure you changed the correct css file, use Firebug to see if your changes are not overwritten by other rules. A link to the project and more information will be helpful.
It may be that the browser is caching your files, not the server. To check, try either merging your files or unmerging your files and refresh the page. If you see the changes, then it is indeed your browser that is caching the files.
In that case, we've developed a handy little extension that automatically refreshes the merged JS + CSS static files. http://extensions.activo.com/css-and-javascript-versioning.html
you may be using different theme. check in system config design section what package and theme you are using and then check for that folder in skin and change. delete the var cache and changes will show. you do not need to back up var cache
Its also important to check System -> Design, where design overrides are located. Recently we've had a problem with this, someone (we are not sure who, hacker?) added override without dates, and whole shop become broken (we have pretty sophisticated package with lots of modifications). It took us about 30 minutes to figure out what was going on.
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'm running WP 3.0.1 on a shared host using PHP5. I'm having issues uploading files that are a little larger via the media uploader in the admin section of WP.
Every time I try to upload a file thats over a few megabytes, it uploads, says its crunching, then gives me a big red "HTTP Error." - nothing more.
This only happens on files that are a little larger - ie a 20mb .mp3 file. A 5mb file seems to work fine. Whats weird is in the past we've uploaded 40mb files without a problem.
--
Here's the steps I've taken so far to try and remedy the situation:
Double checked php.ini to ensure increase upload, post and memory size were high enough.
Updated .htaccess to include filter the security mod I found elsewhere.
Double checked all file permissions via ftp to ensure they were 755.
Called the host - "They don't support 3rd party scripts" (I hate IPower)
Tried with different audio files of similar size.
Disabled all plugins
--
Do you guys have any more ideas regarding what might be causing the vague "HTTP Error." problem?
Thanks in advance.
I had a similar problem with Nginx and PHP5-FPM (and WordPress 4.1).
Symptoms: the file (< 5MB, so relatively small) is partway through the transfer, as indicated by the progress bar, when suddenly you get the HTTP error message.
Even if you've set upload_max_filesize in your php.ini, you should also check post_max_size is (at least) as big. Remember to restart php5-fpm.
If it still doesn't work, edit your nginx.conf file (in Debian/Ubuntu it's /etc/nginx/nginx.conf) and add this in the http block:
client_max_body_size 100m;
Then restart Nginx.
One of our clients, had the same issue.
Finally we found out that the wordpress "HTTP Error" when uploading images, was happening due to a change on the server side. The hosting comany, decided to add APC accelerate to the server in order to increase server's stability and speed. APC accelerate should work only with FastCGI and not with su, so they set PHP to run as FastCGI.
When using PHP as FastCGI, if you try to upload a file larger than 128KB, an error "mod_fcgid: HTTP request length 131388 (so far) exceeds MaxRequestLen (131072)" occurs and causes an 550 internal server error.
This happens because the value of MaxRequestLen directive is set to 131072 bytes (128KB) by default.
One way to correct this (if server uses Plesk), is to edit /etc/httpd/conf.d/fcgid.conf and set MaxRequestLen to a higher value, for example 15MB (MaxRequestLen 15728640).
If server uses cPanel, this change can be done via the WHM of the server.
So, if you can upload images up to 128KB, this is the solution to your problem.
Put this line in your wp-config file:
define('WP_MEMORY_LIMIT', '64M');
The problem, as you've already inferred, is in the size of your file upload. Just to remind you, HTTP isn't really built for transferring large files ... it can do it, but not always, and not very well. You're running into an issue where your host is cutting off the transfer because the file is too large. It's most likely a server setting somewhere that you don't have access to.
Since "they don't support 3rd party scripts" I'm guessing you're in a shared hosting environment, which is why something could change on your server without you doing anything. Possible solutions:
Get a different host
Use a dedicated server
Transfer your larger files via FTP rather than from within WordPress.
I had the same issue whenever I tried to upload media, except I got the "HTTP Error" on files larger than 124Kb! WP 3.3.1, PHP 5.2.
I called my host and they upped memory to 64M (also changed this in wp-config) and upload_limit to 8 MB (default was 2 MB). This didn't work so I resorted to almost everything else, from tampering with the .htaccess to reinstalling WP to installing a fresh WP on another server, but everything pointed to a server issue. I called the host again and spoke to another technician who increased the allowed HTTP Request Length setting.
For future readers, just managed to find the solution to this one after a tough day of searching.
There's a setting in the fcgid.conf file (for me in /etc/apache2/mods-enabled): FcgidMaxRequestLen. See https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidmaxrequestlen
I set that in bytes to an appropriate length and everything works. It seems that apache have changed their thinking on the default value (which is now 131072 bytes):
Before 2.3.6, this defaulted to 1GB. Most users of earlier versions should use this directive to set a more reasonable limit.
server maybe have imagick installed as default library , for a fix for wordpress
I put the following code into my functions.php file. It works!
add_filter( 'wp_image_editors', 'change_graphic_lib' );
function change_graphic_lib($array) {
return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
}
For me, "http error" issue occurred when php is running in fast cgi mode.
"MaxRequestLen" from mod_fcgid was limiting file upload size and wordpress was throwing "http error".
You need to add the following configurations in your httpd.conf (apache2.conf on ubuntu 14) :
<IfModule mod_fcgid.c>
# 20MB
MaxRequestLen 20000000
</IfModule>
I tried all the commonly suggested php.ini changes as well as wp-config changes with no luck. Finally found someone suggesting to look at the XHR async-upload.php details in my browser and found out that our firewall was flagging the upload as a trojan (MalAgent.H_9218 to be specific) for some reason. So don't forget to check there, it could identify other possible upload issues as well.
Chrome instructions:
Hit F12 and select the network tab, then attempt an upload with WordPress, make sure the filter row is on either All or XHR, in the left bottom pane find and select async-upload.php, in the right bottom pane select preview.
In my case solved by switching off Adblocker extention in browser
Our problem was that our load balancer ran out of hard disk space. Be sure to setup a log rotation that deletes the oldest logs after a period.
Our problem actually was client side: people tried to upload via drag and drop from OneDrive, files that have not been locally synchronised but showed up in the OneDrive folder. Resulted in "-200" error message. If file is on local harddrive, it worked fine.
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