By blorenzen on

I have Drupal 4.5 installed and running. Everything checks out fine, everything works . . except modules. I have reinstalled several times from scratch, with the same result each time.

The system (BSD) is running PHP4 and meets all requirements. .htaccess is properly modified. I can add users, add and change content, change config, change themes, and otherwise perform all functions. mod_rewrite is working fine.

When I click on Administer->modules, I get different responses from different broswers. IE6 gives me the standard useless page of "helpful" suggestions for a missing page or server problem. In Mozilla, the page I am on when I click "modules" just reloads (though it reflects /admin/modules url). In Safari, it tells me there is a header misconfigured. It always reflects the correct path to /admin/modules in the locaton bar.

I've searched the forums and can find only one post along these lines, which suggested a php memory_limit of at least 8M. It's set to 8M.

I am completely at a loss as to what to try next. Would appreciate any suggestions.

Brett

Comments

grohk’s picture

grohk commented

accessing the page with clean urls disabled?

Obviously the stock modules are working, since you have some functionality...Have you added an contrib modules?

blorenzen’s picture

blorenzen commented

Yes, have tried changing about every config setting on the various installs, including leaving clean urls out.

I loaded up a lot of modules on first install in hopes of saving time later. That was the first thing to go on re-install, so it is stock (as I can't otherwise administer the modules ;). I also have now tried a Civicspace install (which is essentially the same), and I get the exact same problem.

I assume it almost has to be either a PHP setting, or a required server setting that isn't listed in the documentation (which may be a PHP default that has been changed and I wouldn't know about?).

The current question on my mind is: is there any type of PHP or server setting that ONLY the modules requires, and that no other parts of the system need? Seems to me that would be the obvious place to start looking, given the consistency of the problem across installs, though I find it unlikely.

My next question would be: what directories need to be writeable by drupal BEFORE the first log-in and config wizard? Could it be that a directory is defaulting to the wrong permissions and something isn't getting recorded during the config process?

Thanks,

Brett

TDobes’s picture

TDobes commented

It sounds like one or more modules in your "modules" directory is incompatible with your PHP setup. When accessing the modules page, Drupal includes ALL the files ending in .module within the modules directory and any subdirectories (if they exist). Perhaps you could try removing all the modules you are not currently using from that directory, then adding them back one-by-one until you find the offending file.

now... in response to your questions:

is there any type of PHP or server setting that ONLY the modules requires

yes probably... I can't think of anything specific at the moment for the core modules, though... maybe blogapi requires some PHP extension/option? It seems most likely. If you've got some contrib modules in there, they'd be likely candidates as well.

what directories need to be writeable by drupal BEFORE the first log-in and config wizard?

A "files" directory should be created withing the Drupal root and should be writable by the web server process. Even if this was not done properly, I don't see how it could cause the problem you're having.

Could it be that a directory is defaulting to the wrong permissions and something isn't getting recorded during the config process?

Within the core modules, the "files" directory (as far as I can recall) is only used for uploaded files (upload.module) and uploaded user pictures/avatars (user.module) and blogapi if you attach a media file -- and none of those will prevent the modules page from loading if files is missing or unwritable.

The modules page logs all the files it finds and loads into the "system" database table... perhaps looking there might be helpful as well in troubleshooting.

blorenzen’s picture

blorenzen commented

I'll hammer away on some of these options tonight and post results.

Brett

banshee’s picture

banshee commented

Brett and others,

I have the same problem. It occured when I upgraded from Drupal 4.4.2 to 4.5. I posted http://drupal.org/node/13193 and http://drupal.org/node/6948 but I have had no success yet.

Brett ... did you find a fix? Please post solutions [if any] here for the reference of others.

Not trying to be a mongrel, but, I am kinda glad you have this problem too. It means that I didnt FxCK up the upgrade if you too have a fault in configuring modules. Interesting that you did a fresh install and not an upgrade like me. Could this be a bug?

Regards,

Banshee

blorenzen’s picture

blorenzen commented

Through some trial and error, here's what I found. I'll walk through steps because I think my solution is only partial.

I removed all modules that were not clearly related to core functionality. Left about a dozen, hit the site and it worked.

Started putting them back one by one. Along the way, individual modules would bring it down. I'd check them all in BBEdit to make sure there were no dumb mistakes like an accidental binary upload somewhere in the chain.

As I got to end of list, a lot more modules were crashing system, so I turned my attention to memory limits.

Sure enough, if I removed enough modules, eventually every module would work.

I then modified .htaccess to double php memory allocation, which had no effect.

I'm going back through now and making hard decisions about which modules I need and which I don't. Fortunately, by dumping buddy lists, mass mailing-related modules, textile, and events I can get close to whatever limit is kicking in. Still have to eliminate what seems to be another four or five beyond that and it eventually works.

Trying now for the best combination of funtionality.

I have no idea if this is a bug, a system limit I can't see, or a bad combination among the modules (that I have avoided by removing something that was causing the problem for everything else). Hard to tell from my end.

Anyway, it works if you remove enough modules. Hopefully someone can nail down why (or what system limitation I should be looking for that all those modules are tripping, esp. if it doesn't appear to be memory) . . . I'd like to think that with every new module I don't have to make hard choices. That might put a quick end to the project :(

Brett

sepeck’s picture

sepeck commented

Have you checked the php.ini memory limit?

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

TDobes’s picture

TDobes commented

Check and see if php was compiled with the --enable-memory-limit flag. If so, then that's a concern, and you should look into overriding it. If not, then the problem lies elsewhere.

To view your php configuration, put the following into a blank file with the .php extension, then point your browser to it:

phpinfo();

If this is the case, you'd add a line something like the following to .htaccess:
php_value memory_limit 20M

However, I remember a shared host I set up a site on a few years ago did NOT allow this setting to be overriden in the .htaccess file, and I had to e-mail the host and get them to turn it up in their global php.ini.

This page from the PHP manual may be helpful.

blorenzen’s picture

blorenzen commented

I'm having the host look into that now. Except for some odd behavior in the mail modules that I'm pretty sure isn't related (I'll download fresh versions of those), I'm hoping that fixes it.

Thanks

blorenzen’s picture

blorenzen commented

It's taken some tweaking, but everything is working now. In the end we had to up the php memory limit to 20 megs (16 didn't do it), and I've left the events module out because the module admin seems to work better without it (if I leave it in, sometimes it fails).

Thanks for all the help.

Brett