I just updated to 6.15 and the admin pages are blank - how do I fix this?

This is a large, working site - please help!

Comments

jim0203’s picture

redrider’s picture

Thank you for your reply.

I have been through the info in the link you supplied many times without any headway on the problem.

I am not a coder nor a big time developer but rather just some guy trying to use Drupal to organize the content on my website.

jim0203’s picture

Can you confirm that:

1. You've cleared the cache tables via phpMyAdmin or whatever SQL client you use? This is a very common cause.
2. That you've increased the PHP memory limits - and that you've confirmed that the increase has worked? Very often ISPs limit the memory available. You can check whether the memory limit increase has worked by creating a file called phpinfo.php in your site's root. It should contain the following code:

print phpinfo();

Then go to http://yoursite.com/phpinfo.php and check in the PHP info dump that the memory setting has worked.

redrider’s picture

I have emptied the database cache tables in phpmyadmin and have added "php_value memory_limit 32M" to my .htaccess file, I have regained some usability within the admin sections - but not near all yet.

The biggest issue is the the "Admin" from the menu returns a "Fatal error: Call to undefined function apture_extract_token() in /home/coaster/public_html/modules/apture/apture.install on line 23" error but the "advanced Admin menu allows me access to the admin sections.

This would seem Apture is having issues.

kaakuu’s picture

#509984: Call to undefined function apture_extract_token

Also make that 32M to 64M if possible, make sure that maximum allowed post size and file upload sizes are much greater than the actual size of the database. No idea how this can work but it worked in a few cases for me.

redrider’s picture

There is no file named "phpinfo.php" in the root directory.
Should there be? If so, how do I create one?

vm’s picture

no there isn't. As per the comment:

You can check whether the memory limit increase has worked by creating a file called phpinfo.php in your site's root

You create that file with a text editor and add the function to it. Upload it to your server and call it in your browser.

You can also put the phpinfo() function into a page content type and use the php input format. Then visit that node.
You can also use the devel.module which provides a link to do this
You can also check your host panel which in many cases, provides a link to do this

redrider’s picture

ok - got it - I checked the phpinfo.php file and the php memory limit is indeed 32M - but still no joy.

vm’s picture

32 may not be enough depending on how many and which modules you have installed.

Did you run update.php? did you get any errors when doing so? any warnings? any dialouge at all?

have you tried removing the offending files folder from your install? Tried disabling the module by setting the status of it to 0 in the database?

Have you checked your error logs? both drupal (if you've set up syslog to print to a file) or apache?

Worst case scenario, import your backup of the databse base that you took before you did the upgrade and get your site back to a working condition and try again. Though I'd never update a production site without first testing the update on a test site with a backup of my current installaton and databse.

redrider’s picture

I upped the php memory limit to 64M and ran update.

I got no errors or warnings during the update.

It happened before I updated the modules, which we're working fine before the core update.

I have a complete backup and know how to go back to it but it is better to have an updated and properly working site.

I do usually do an update in WAMP before it goes live, I didn't this time and that is spilt milk now.

vm’s picture

you didn't address:

have you tried removing the offending files folder from your install? Tried disabling the module by setting the status of it to 0 in the database?

Have you checked your error logs? both drupal (if you've set up syslog to print to a file) or apache?

Which could lead to clues about why the WSOD is occuring. Otherwise everyone is guessing at what is causing the WSOD. Offending files folder reference would be the apture module. which is what is throwing the one error you reference and is a known issues per the link kaakuu provided.

Otherwise your back to the first link given as ways to try and figure out why the WSOD is occuring and none of us can do those tasks for you.

redrider’s picture

VM,

I had error reporting on and the warning was because the apture module was out of date, updating the module cleared that error and now the WSOD is just that, blank.

The syslog in Drupal just shows that permission was denied to the administration page.
I do not know how to look at my apache syslog.

As an FYI in case it matters, this is a VDS on godaddy.

redrider’s picture

The offending module was indeed apture - I like apture and wish to use it.

vm’s picture

Then you should check the issue queue of the module in question for similar bug reports (and maybe an already existing patch) and if none are there. Report the bug.

If you have the skillset to fix the bug you can do so and supply a patch to the issue so that other users can also use the patch until such time as the maintainer of the module can roll the patch into the next release.