Strange Drupal behaviour

Events happening in the community are now at Drupal community events on www.drupal.org.
david jeyachandran's picture

A friend here has a unusual problem with his site. When he installs a module, it seems like any module, the site starts behaving strangely. The Admin menu disappears and blocks don't work. I can't even get a simple test block to appear.

I've tried the simple things like flushing caches and changing the theme.

The Drupal setup is unusual. Drupal 6.16 running on Windows server. They're using the ERP module and a bunch of customised modules.

I'm a bit lost, not sure where to even start with a problem like this. Any suggestions?

One option I suggested was creating a new database and install everything from scratch and migrate the data. This would be a HUGE job.

Any ideas?

Comments

Any error messages? Maybe

tripper54's picture

Any error messages?

Maybe check the server error logs, php memory allocation and APC stats if you're using APC.

It might be completely

mudsurfer's picture

It might be completely different issue - as I never use windows servers - but I had some similarly strange behaviours on a site I inherited: Turned out to be related to Database table ownership. I suspect had occurred when previous person had manually fiddled around in the MySQL tables. Took me weeks to stumble on it. I created a copy of the database, and pointed the site to the new database, and it fixed it.
Might be nothing like your issue... Good luck.

Lots of red flags there

xurizaemon's picture

Old Drupal version, customised modules with unspecified changes ... there's a lot to warn you off getting involved here. It sounds like the site's in a bit of a stew.

That said, you can debug your way through anything, with enough time and patience and expendable sanity. Some questions to consider (don't answer these - just mull them over and try some and see what you find).

  • Are there any clues in the Drupal log (reports => recent log messages)?
  • Are there any clues in the webserver's error logs?
  • Are you enabling the modules using Drush or the web UI? What happens if you try the other method?
  • What happens in the system table when you enable the module? Does 'status' get set to 1?
  • Do the modules get enabled, then disabled again? Or do they never get enabled? Can you add debug code to module.inc to see if the writes go to the DB when enabling your module(s)?
  • Can you reproduce the issue if you copy the site to another server?
  • Can you reproduce the issue if you disable modules starting with A-L? M-Z?

If you don't know what's been changed on the customised modules, the Hacked module can be really helpful. (Of course, that requires adding another module to your site, which you've already said doesn't work so well.)

If my comments have helped you, please pay it forward!
Use issue queues to discuss module issues - this will help your questions assist others (including yourself!) in future.

One option I suggested was

xurizaemon's picture

One option I suggested was creating a new database and install everything from scratch and migrate the data. This would be a HUGE job.

Not really. You might do something like this -

  1. Generate a drush makefile for your site: http://buildamodule.com/video/change-management-and-version-control-how-...
  2. Generate patches for modules which have been patched, and add to the makefile. Now you have your customisations separated from your code. This gives you the safety to know you can update to the latest Drupal 6.x because your changes are living in a neat little patch (and you can see if Drupal core is patched at all).
  3. Get a DB dump.
  4. Use Drush make to build a clean version of the site, applying the patches on the way.
  5. Install the DB, see how it behaves.
  6. Modify the .make file to upgrade modules which need updates. (You'll find out when you rebuild the site if the patches apply or not.)

Separating the customisations from the base modules and core code is a huge leap forwards as far as debugging goes, because custom code is no longer lost amongst the modules. This removes a huge amount of uncertainty when it comes to updating (which typically fixes lots of other issues). If I had to deal with a site in that state, that's likely where I'd start.

If my comments have helped you, please pay it forward!
Use issue queues to discuss module issues - this will help your questions assist others (including yourself!) in future.

Are you using Internet

singularo's picture

Are you using Internet Explorer?
Maybe its the CSS file limit causing the issue?
Install Firefox or Chrome for an easy check, if it is that issue, just enable CSS aggregation should sort it longer term.

Tried different browsers

david jeyachandran's picture

Yeah I've tried different browsers - Firefox and Chrome. I think it's a PHP issue or a database issue given that we've switched themes and it affects things like block and menu changes.

How much memory do you have on the server

zyxware's picture

Is the site failing on menu rebuild after a new module is installed? It is possible if you are short on memory? You can check the size of the menu_router table to see if it keeps changing around

Will check the menu_router

david jeyachandran's picture

We've checked the PHP memory which we increased to 256Mb. We'll also check the menu_router table. Thanks.

Thank you

david jeyachandran's picture

First of all thank you for lots of good ideas - love the community!

Ok, I now feel we've got a bunch of things to try. I'm glad I'm just helping out a friend and it's not a project I need to take on. Especially thank you for the steps in doing a site rebuild. Still there are simple things we haven't checked like APC stats and webserver logs. I'll also try the database copy.

Thank you again :)

Australia

Group categories

Location

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week