I'm setting up access to a Drupal 7 site. The site sits alone on a box that answers to a number of domains and that number is likely to grow. What I'd like to do is to tell Drupal to load the site regardless of which actual domain brought us to the box (the rest of the URL will always be the same, of course). Currently most of those domains send me to the install page.
The problem is the lack of a directory (symlink) in the sites/ directory.
I can probably rewrite requests coming through alternate domains in Nginx, but I'm wondering whether there's an application level answer. As it stands right now, accessing the box/site by any domain other than the canonical domain sends me to the install page.
Is there anything I can do?
It looks to me that you didn't configure your Drupal site as the "default" one.
The file "sites/default/settings.php" is loaded if no better (more specific to the current request) settings file can be found in the sites/folder... This is in fact a "wildcard" config, so the best solution would be to move the site files to the default folder. See the multi-site documentation for more details.
If you can't do that, then you can use sites.php for the rewriting, but you will need to update it to add any new URL you want to match. There's a little shortcut though: you can add a bunch of rewrites such as
$sites['com'] = 'default';
$sites['net'] = 'default';
$sites['org'] = 'default';
...
which will act as catch-all rewrites for sites ending in .com, .net, .org and so on, saving you a lot of (but not all) the manual rewrites.
Altering the conf_path() function should really be your last solution, since it will make updating Drupal a slower process (and if you forget to re-apply the changes after an update, your setup won't work any more).
Related
I have a firebase site with a domain of gs-domain1.web.app.
I have a second firebase site with a domain of gs-domain1.web.app.
Now, I want all traffic to go through the gs-domain1.web.app. However, when the path matches a specific route, like, /users/:id/pages, I want the site on gs-domain2.web.app to take over without switching the domain, but maintaining the path.
I believe a redirect will not work because it physically switches the domain.
I believe a rewrite will not work because I can't recreate the path on the destination.
Both the application on domain1 and domain2 are single-page applications (react and vue respectfully).
In firebase, you could host more than one site in one project and that would solve your problem.
Host/Deploy the react code to firebase and link the site with the URL of gs-domain2.web.app
and
do another hosting in the same project as the react but vue on gs-domain2.web.app
After you have successfully linked the domain and hosted the sites... Link the URL together with or anyone you like.
PROS: Your sites would load separately and would be faster.
Also,
It would be great if you put all the code under one domain
Then you can use different paths for the 2 sites so they would be easily identifiable.
so you have : gs-domain1.web.app/path1 and gs-domain1.web.app/path2
You will find the add another site function at the bottom of the hosting section below 1
I am not sure exactly what you mean by "take over without switching the domain, but maintaining the path". If you mean that you want the user to now see the page on gs-domain1.web.app when at this specific path, but still have gs-domain1.web.app as the domain in the url in their browser, I can only really think of two good ways to do this.
You use an iFrame to display the page from gs-domain2.web.app as the entire contents of the page on gs-domain1.web.app at the specific path. This can potentially introduce weirdness if the second page is complex.
You get rid of the second domain and instead move that codebase over to the first domain and write some middleware that serves from the first codebase whenever the user is requesting a path that should come from gs-domain1.web.app currently and serves from the second codebase whenever a user requests a path that should currently be coming from gs-domain2.web.app. I feel that this would be the more 'correct' approach if this is the desired behavior you want.
Alternatively, if you do not care what domain the user is seeing, I would suggest, as you mentioned, merely setting up some clever redirects to bounce users between the two based on which path they are requesting.
I hope this was helpful and goodluck!
I have inherited a Drupal 6 site to maintain.
I am new to Drupal so there is an element of learning as I go.
I have encountered a strange issue after attempting to set up a test site on my local machine.
All my links on my local site continue to point to the live server. So all menus, login buttons, etc. all point towards the live site.
Steps I have taken:
checked settings.php to ensure that $base_url is set to "http://localhost:456"
checked settings.php to ensure that MySQL settings are correct
Taken an SQL dump of the entire local database and searched for any references to live site URL
deleted all the local cache data from database
Checked various blocks to ensure that there was no hard coding of links
Disabled language support as that does use separate URLS for each language
I am at a total loss as to where to go from here.
I can navigate through the site locally by replacing the URL in the address bar to point to the local site, and I have even managed to change the local theme so I can see which version of the site I'm on. The fact that I could do this means that the database is set up correctly.
Totally stumped as to where to go from here. Any takers?
The problem was that in the 'variable' table there was an entry with the URL for default language pointing to live site. There is a 'language' table which holds the URLS for each language e.g. eng.example.com for english and ru.example.com for russian. I had changed the urls here to point to local server, but it seems there is also an entry in the variable table which needed to be changed.
In case anybody runs into this problem and wants to change it, you need to change the metadata for the entry as well where S22 represents a string of 22 characters, you need to change it to the length of the string that you are entering, youll see what I mean when you look in the table!
Also, you need to clear your cache after making any change.
In your local server, go to your site directory->site->default and open your settings.php file
look for the base url and comment out that line it should be around line 144
The only thing left is you need to a search for the live site url in your complete code base. See if any module is changing the base url using the code. Though I am not sure how it can be done using code.
However instead of replacing the url you can edit the hosts file and add an entry like
127.0.0.1 livesite.com
If you are using Linux the location of the file is /etc/hosts
I had this problem. I moved the entire site from the remote to the local server to work on, but whenever I loaded the site it went to the live site. I believe the problem was the .htpaccess file. I updated all the core Drupal files, but as the .htpaccess file was hidden I didn't notice it was still there.
Note that even after I removed it, it wasn't until I opened a different site on the local server and then went back that the path worked correctly.
I currently develop Drupal web sites using its multi-site feature that allows me to have a single code base and support multiple distinct settings per each site.
I set up a dev server and I was quite happy with my arrangement of domains like example.com.local (not that happy because I had to perform a small conversion before entering production, but still quite happy) and the thing used to work well. Too bad I recently started to work at places outside the LAN in which my dev server resides--mostly at clients' places where I need to demo their sites. First of all I set up a dyndns.org account and the server is accessible through the Internet.
Unfortunately the whole domain-based multi-site ungracefully fell down, since I'm now accessing the server via myservername.dyndns.org and Drupal's algorithm takes the domain name into account, so I'm forced to use at least the TLD as part of the directory name (namely sites/local.example.com). So I decided to switch to directory-based multi-site, and now I'm able to access my server from inside the LAN using myservername.local/example.com (having renamed the sites/ subdirectories accordingly). You should easily see why this is suboptimal, since when I browse to myservername.dyndns.org/example.com Drupal looks for sites/org.example.com. I temporarily ended up making a link from sites/org.example.com to sites/local.example.com but again, this does not scale well If and when I'll have to drop dyndns.org for, say, dev.mycorporatesite.com...
Is there any other possibility? I have full access to the server, I can change Apache2's configs, .htaccess and all the stuff.
I would recommend against referencing drupal multisites in folders but instead would set up your server to have a fixed domain name and each site in a subdomain.
So your dev server is at mydevserver.com
and then each site could be
client1.mydevserver.com
client2.mydevserver.com
etc.
If you also at the same time as creating these, you move the files folder from the default to whatever the live site will be i.e.
sites/livesite.com/files
Then when you have to go live, all the references will be correct (if you are drupal 7 this might not be an issue)
I usually place an app_offline.htm in my root directory when I am releasing a website to a production environment. However sometimes if there has been a few big changes to the site, I would like to click around first to make sure it's stable without allowing access to anyone other than me.
As far as I am aware this isn't possible, but I'm hoping someone has a neat solution...
The solution has to include if someone has a deeplink into the site, so using a default.htm/asp page in the root won't do the trick unfortunately.
I agree with the staging environment answer above, but otherwise here's one possible approach: Temporarily block all IP addresses besides your own. This can be achieved through IIS Directory Security configuration, or programmatically in any number of ways
You can redirect all the non-authorized users to an Under Construction page of some sort. Meanwhile, you can happily browse the site from your IP. When the site is vetted, you remove that IP restriction and the site becomes available to the world at large.
It's a difficult thing to achieve. That's why you should have a staging environment where everything should be validated before shipping into production. Then during the deployment process (if it takes long, but it shouldn't) you could use an App_Offline file. This staging environment should be as close as possible to your production environment (in terms of software, patches and configurations installed, not in terms of hardware power of course).
Another quick suggestion that would allow you to control things from the web.config might include a custom module that redirected all requests to a static page except those defined by a filter (i.e. hostname, url sniffing) that could be configured via the web.config.
The situation is the following: I created a site with Plone, developed, used, but behind a test URL. Now it has to be published, but the test URL is not appropriate and I don't want to move the site. I think, if I use a redirect, it won't be appear in the URL-bar, only in the case of site start page. Am I wrong? (The test URL should not be used, because it will be a "semi-official" site.) What do you suggest to do?
As far as I can see Plone uses absolute URLs everywhere. I can add relative URLs, but if I create a new page, a new event, etc., then they have absolute URLs on other automatically generated inner pages. Is there any way to convert these URLs to relative paths? Is there any setting possibilty where only a checkbox changes this default setting?
Plone does not store your URLs in the database. It uses the inbound host header (and any virtual hosting configuration set up with rewrite rules in Apache or Nginx) to calculate the correct absolute URL when rendering the page.
In other words - as soon as you actually point the relevant domain name to the server with your Plone instance, it'll just work.
P.S.
You should put a bit more effort into asking your question. This is just a copy and paste of a half-finished email chain where you tried to get the answer from me in private. It's not very easy to understand what you're asking.
I think what you are looking for is url rewriting to handle virtual hosting. ie to get your site to appear as if it's the root url of a domain.
This is normally done via the webserver that normally sits in front of plone. For apache, here is a howto
http://plone.org/documentation/kb/plone-apache/virtualhost
for other servers
http://plone.org/documentation/manual/plone-community-developer-documentation/hosting
You can also achieve this directly in zope (via ZMI) using something called the Virtual Host
Monster. see http://docs.zope.org/zope2/zope2book/VirtualHosting.html
PS. I don't think your question is badly worded. Plone does serve pages with a "base" tag and what appears to be absolute urls. They aren't baked into the database but it's also not obvious that the solution to getting the url you want is the VHM url syntax and a proxying frontend webserver. There is a reason why it doesn't use relative urls... which I can't remember it was so long ago.