Would recommend temporarily setting your php.ini to show
errors and warnings to the screens to determine if there is an error being
thrown before enough of the drupal logging api gets started, and try
and hunt the error that way. Also make sure the instance is set to log the
errors to the screen. After doing this, make sure to do a view page source
to see if a php error isn't being thrown in the html header.
This is a wild shot, but I would also check to make sure
that you can't navigate to the page dircectly (not using clean urls, but
index.php?q=admin/modules. This would potentially eliminate a mod rewrite rule
overriding your page load.
Dave
Hi,
I've run into a puzzling behaviour on two separate Drupal installation
hosted on virtual servers by the same company. One is a 4.4 installation hosting
a single domain; the second is 4.6 and hosts several domains. For some reason,
both installations suddenly no longer display their modules page, although the
sites are functioning normally in all other respects.
- I checked the access and error logs and no memory errors were
evident
- I tried Firefox, Safari on OS X and MSIE 6 on WinXP (same behaviour on
all)
On the 4.6 installation:
- I increased the memory limit from 8M to 12M via php.ini, .htaccess and
/sites/default/settings.php (no change). I went as high as 128M using php.ini,
still no difference.
- I deleted then restored each contributed module one at a time (no
change)
- I ran the Repair Table command via phpMyAdmin on all tables for all sites
on the 4.6 installation (no change)
The host company says nothing has changed recently at their end (Apache/1.3.27 (Unix) (Red-Hat/Linux)
PHP/4.3.10). I'm at
a loss as to where to look next - any pointers would be most welcome.
TIA.
--
Ken
Mistakes are the portals of
discovery.
-
James Joyce