Does anyone here have any idea what would cause a Drupal 7 site to redirect to the user account page when certain admin functions are performed?

I previously thought the Tweetbutton module was causing this problem, but I disabled that.

Now when I try to save certain Ubercart store product edits and when I try to access store reports made through the Who Bought What module, the system redirects to the user account page instead of working as it should. I think there may be other scenarios where I'm getting thrown to the user account page as well, but these are the ones I'm currently noticing.

If anyone has encountered this behavior before, please pass along any insight you can. I think this is going to be a finding a needle in a haystack kind of endeavor to solve this though.


pramod_patil’s picture

Try disabling your custom modules and see if it works. If it works then something wrong written in you custom module which redirecting to user account page.

wildlife’s picture

I can't disable anything required by Ubercart and the Who Bought What report because then I wouldn't be able to test if it works. So I disabled all that I could and that had no impact.

I've also noticed this happening when I save edits to certain nodes. Saving does not happen, the system redirects me to the user account and my edits are not present when I go back to the edit screen. But this doesn't happen with all nodes.

What I'm doing now is a clean Drupal 7 install with all the modules needed for this site enabled. I'm going to test if this problem happens then with an otherwise empty site. If I can't figure out the exact cause, then I'll have to rebuild the entire site for the client. I'm really hoping to avoid that.

John_B’s picture

First I agree wit pramod_patil to keep an eye out for custom (rather than contrib) modules on the site. Are there any? This is because custom modules are sometimes very hacky, and misuse of drupal_goto redirects is not unusual in my experience.

Some sites will redirect a user to the account or login page if that user tries to do something which the system thinks (even if wrongly!) that user has no permission to do. This is not default Drupal 7 behaviour, but it can be added. If you built the site yourself you would know about this, if you had set it up. If you did not build the site, you could check whether this is the way the site behaves generally (for example by trying to visit an admin page while logged out).

Now, if the site turns out to redirect a user to the account or login page when that user tries to do something he has no permission to do, the explanation may be that the site (even if incorrectly) *thinks* that the currently logged-in user has no permission to do the edit you were trying to do. That does not solve the problem but gets closer.

John_B’s picture

If none of that helps I would be asking questions about the hosting (e.g. is it standard hosting, or is it server where there may be some caching such as APC set up, which can give odd symptoms when it goes wrong), and maybe try a copy of the site elsewhere, before thinking about rebuilding.

wildlife’s picture

In there, it says

Upload progress Not enabled
Your server is capable of displaying file upload progress, but does not have the required libraries. It is recommended to install the PECL uploadprogress library (preferred) or to install APC.

wildlife’s picture

All the modules on the site are ones that I got from's modules area. Is that what you mean by custom vs. contrib?

I'm logged in as the superuser and it is still redirecting me to the user account page when certain admin functions are attempted. Another user has admin permissions to do everything, and it's happening to him too.

How do I test for what you are saying?

I built the site.

When I try to go to http://[site domain]/admin as an anonymous user, the site takes me to the Access Denied page as expected.

In the case of the Who Bought What report redirecting instead of displaying the report, that only started recently. I thought it may have been when I upgraded the version of the module, so I rolled the version back to an older version that worked before. But it still didn't work.

John_B’s picture

No closer then. I seem to recall I have seen something like this, but cannot explain it. I assume you have disabled overlay module? If not, do so.

What hosting are you on?

wildlife’s picture

I hate that module. ;)

Hosted on . It is the only Drupal 7 site I have hosted there, so I don't have any other site to compare it with.

wildlife’s picture

I have set up a clean Drupal 7 site and added all the modules present on this site. I'm going to test if it does the same thing. If it does, then it's something with one of the modules, I'd assume. If it doesn't then something in the site database is causing the problem.

I think at one time I found one node that was corrupt in some way. It didn't have it's content type defined in the database. When I removed that node from the database, that solved another problem. I was thinking this might be something like that. But when I looked through all nodes in the database this time, none were missing the content type.

John_B’s picture

So probably the hosting does not have any complicated caching mechanisms. It might just be baling out (in which case a copy of the site on a better server or laptop would work), though the symptom is an odd one. Do the nodes get saved? If not, are the nodes where the save fails, particularly large ones?

wildlife’s picture

Nothing complicated that I know of.

I could try setting it up on another server just to test. I have some sites hosted on's shared hosting and other sites on a VPS.

When it happens on an edit page, the edits do not get saved when I hit the save button. I can create the node initially, and that saves, but then this will happen when I try to edit and save later. It doesn't happen on all nodes. I haven't determined yet if it only happens on certain content types. I've asked the client if he's noticed any pattern and will let you know if he indicates there is one when he replies.

John_B’s picture

There are a few reasons a save can fail. One is that on shared hosting a neighbour is hammering the database with requests and the hosting company are not managing the issue, especially if the connection to the database is set to time out and the time is just to short. On large and complex pages you may also hit various php and database restrictions on the amount of data, which I do not think is likely relevant. On fairly basic shared hosting, it is more likely that the database server is simply not up to the job it is being asked to do.

For minimum hassle I would encourage clients for entry-level hosting to spend a bit more and host on a Drupal specialist such as, - happily the number of options is increasing. For 90% of sites this will sort out a lot of problems, though for larger sites of course you need to beyond the basic offerings of such companies. You can run a VPS yourself, but doing it well can be a lot of work.

To be fair we do not know this is a hosting issue - just a suspicion!

wildlife’s picture

When it happens with saving an edit, it happens on specific nodes and is consistent with those nodes. Once one attempt to save does this, you cannot get any attempt to save to work going forward. If it was something with the database traffic, I'd assume that it would save fine one time, not save another, etc.

This is only happening on one Drupal 7 site. I have Drupal 6 sites on Hostmonster that have never done this.