I had an experience over the weekend trying to setup a development and test/staging instance on a production server. I find this is sometimes easier on a small project where tasks are shared by a couple people, to simply duplicate the production setup on subdomains on the same server as the production site.
When I copied over the module files from production to the subdomain, test updates to the modules on the subdomain were not being seen as applied. I also found changes to the filename of the backup_migrate module on the subdomain were being written to the production database. I experimented with the production system, applying an update there and found that was being seen on the subdomain as being applied. Next I checked to make sure I hadn't inadvertently copied the settings.php file over from production, but that was pointing to the development database. After trying a couple of times with the same result, I decided to sleep on it.
It dawned on me the next morning that perhaps it was session related. This lead me to the Secure Pages Hijack Prevention module. I found that if I removed this module from the subdomain module folder, logged out, and logged back in I was now looking at the correct database.
This seemed to work in this case, but I'm not sure if that is the "right solution". I think I will crack open Cracking Drupal and look into it further.
I understand this is part of core in Drupal 7 what would be the approach to diagnose or correct this issue in D7?
Perhaps something in the documentation to this effect would be in order?
Comments
Comment #1
grendzy commentedI don't really know what to say; securepages_prevent_hijack doesn't interact with the database at all (not even a single query), and it certainly doesn't alter $db_url.