By polymathnyc on
I am trying to set up a local development environment based on a client's production site. I am exporting the production database using the Backup and Migrate module. When I import the database to my dev site, the admin dashboard tries to link to the production site's dashboard.
Can someone point me to the specific tables in the database that are causing absolute links to the admin area so that I can delete or modify them?
Comments
.
Normally there should be nothing in the database which would link to any specific domain.
Except
- if you have set the optional $base_url in the settings.php file with a domain name.
- if you have added any redirects or rewrites in the .htaccess file with a domain name
- if you have created menu links or links in the content explicitly with a domain name
To get a more specific answer, describe one specific link which you click, where it leads, what kind of link it is and how it was created, with complete example URLs.
Thanks for the reply. There
Thanks for the reply. There is no $base_url set in the settings.php and the are no absolute redirects in .htaccess. It sounds like you're thinking in the right direction though.
For example, the production site is located at http://exampleboutique.com and the dev site is on a local virtual host at http://example
When I attempt to access http://example/admin/build/blocks through the admin menu (which is hardcoded as /admin/build/blocks in the source), I am redirected to https://exampleboutique.com/admin/build/blocks
So it seems that something is causing the base url to be directed to https://exampleboutique.com.
.
So, even system paths do that... I can't think any other cause except the first two.
Try running /update.php and go through all the steps. That should clear all caches and rebuild the menus.
.
I ran update.php and I'm still having the same problem. So it seems like the problem must be in the files somewhere.
There are 2 things that are worth noting.
- The site uses a custom dashboard module.
- The original developer of the site placed the active theme in a new Sites file. The site name is exampleboutique.com, which is the same as the production site domain. So the file structure looks like Sites>exampleboutique.com>themes>example. Could this somehow be causing the linkage?
.
The "sites/exampleboutique.com" directory should not matter, because it is not used on your local server.
On your local server, check the settings.php file which is under "sites/default" (or whatever you are using), not the one that is under "sites/exampleboutique.com". Does the "sites/defaut/settings.php" file contain a $base_url?
.
The "sites/exampleboutique.com" directory is used on my local server assuming that I use the same file structure. This site folder contains the theme with the appropriate site files to create the dev clone.
To troubleshoot this, I created a new folder titled "example" in sites/all on my local server. With a clean database, I activated this theme and the admin menu operated properly. Then, after importing the production database, the admin menu was again linked to the production backend. This does make it seem that the problem must derive from the database.
I have also tried going through the database and replacing all of the references to the "exampleboutique.com" theme with a REPLACE statement, so that they reference the new directory on the local server. Still no luck.
.
How did you make your local installation read your theme from the "sites/exampleboutique.com" directory, and not from "sites/default" or from "sites/localhost" as drupal it normally does?
.
By importing the database. Although how it was done originally on the production site I am not sure.
.
Drupal first tries the domain name that you typed in your browser to get there (for example http://localhost/drupal), and if it doesn't find a matching sites/localhost.drupal directory then it looks in sites/default.
The database alone can't change where Drupal looks for modules and themes.
.
Hmm... The domain typed in the browser is a virtual host which references the root of the local drupal installation (http://example). I'm not sure what you mean by a matching sites/localhost.drupal directory, but the original installation does point at sites/default.
The production theme is stored in sites/exampleboutique.com/themes/example. After importing the database, the site seems to display this theme, however I cannot login to the admin without being routed to the production site https://exampleboutique.com.
How else would Drupal know where to reference an additional site in the sites folder, if not a setting saved in the database? Do I need to set up a virtual host at sites/exampleboutique.com instead of the root of the drupal installation?
.
No, all virtual hosts should point to the place where Drupal's index.php is.
Drupal knows which site you want by checking your browser's request ($_SERVER['HTTP_HOST']). Then it looks for a matching sites/subdirectory name and if it doesn't find any it uses in sites/default.
There is nothing in the database to change that. The only other places which could redirect Drupal are the settings.php file which it actually reads (the $base_url), and the .htaccess file.
So, I have no idea why your local installation looks in sites/exampleboutique.com and why even it turns it into https.
.
OK, I see. So the sites folder should be named sites/example in order to be active on the virtual host http://example.
Now that we have discussed it, I realize that I manually activated the theme "example," which was located within the sites/exampleboutique.com folder. Possibly this is why the local installation is referencing the production site, because it is trying to access https://exampleboutique.com to match the sites folder where the active theme is located?
I suppose that I could change the name of the folder "sites/exampleboutique.com" to "sites/example" to match my virtual host. Or possibly I need to use the structure "sites/localhost.example"? However, if this were to work, there are many references to sites/exampleboutique.com in the database that would need to be changed.
It does seem that the multi-site file structure is the cause of this problem. Thanks again for all your help so far, I think that we are getting close.
.
I doubt that selecting a theme could have caused Drupal to change where it looks for the theme or for the settings.php file. It is still a mystery.
Do you need to revisit this ??
The problem I had was eerily similar to what you were having here. I think you were on the right track when thinking it was the database. I could not get past the login screen without it switching from the dev URL over to the production URL. I was also having issues with the https which made me think it was the secure pages module. I discovered that I needed to go into the variable table in the dev db and modify the securepages_basepath & securepages_basepath_ssl fields to point to the dev URLs (or I could have just disabled the module for the dev site by changing the securepages_enable value). This allowed me to get past the login screen.
Then make sure you don’t get tripped up on the permissions for the default folder and settings.php file. They need to allow for user write access. When I went to administer > site building > secure pages, the changes I made in the dev db were not showing up on the site until I changed those permissions.
Everything is working as expected for me now. Hope this helps.
This was exactly the cause of
This was exactly the cause of my Drupal 6 redirect issues that were, at the start, inexplicable. After ensuring the redirect was not being caused by my settings.php nor .htaccess files I ran a query for the URL I was incorrectly getting redirected to and found 2 entries in the "Variable" table - securepages_basepath & securepages_basepath_ssl
Updating these to my development URL completely resolved my redirect issues. Hope this helps someone out there!
mobile tools
Hi all,
I had the exact same problem, that after bringing my production code- and database to a local installation when calling up my local site I would always be redirected to the production site. I finally figured that there had to be something in the bootstrap process that would do the redirect. And really, it was the mobile tools module. After deactivation everything went fine.
My advice: Check table 'system' in your local database for modules that have the 'bootstrap' field set to '1'. Deactivate these modules and try again.
Cheers, Peter.
I had the exact same issue.
I had the exact same issue. I had the following modules changing this behaviour including secure pages (disable through drush), Mobify and one of the translation modules. My recommendation is to check the variable table for the production domain.
Do a search on the 'value' column. My issue was also with a the mobify_redirect_base and language_default variable Change that to the development, staging, local, etc... domain and then run update.php
- Seecure Pages module can be safely disabled with drush (and works).
- Mobify was disabled and still causing this behaviour. (which is why when I disabled ALL the modules it still had this redirect)
delete db cache table
simply deleting the cache table in the dev database should solve the problem