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)
Related
Excuse my lack of server architecture knowledge, but I'm a bit confused on what applications, servers, environments, etc.. are and how they can communicate with each other. I just got AWS and here is what I want to do ultimately.
I want to create a Google Chrome extension. For simplicity, lets say that I'm trying to make an app that records the number of times that all users with the extension collectively visit a given webpage plus information about the visits, such as the time they visited and duration. So if I go to Facebook.com and 100 other people with the extension did, I would see an iframe, lets say, that says "100 users have been here and they visited at these times: ...". Of course, the extension also needs to communicate with the server to increase the count by one. The point is, there is no need to visit any webpage for this app to work since it's an extension and the point isn't to go to a webpage, although it still returns HTML and Javascript.
Now, I also want a homepage for the app in case people are interested in the extension for whatever reason. Just like Adblock, you don't need to go to their actual website, but it's good to have one.
My question is, how do I set this up? Do I just have a normal website, ie. www.example.com/ and set it up normally with Wordpress (what I'd like to use) then just designate one address, ie www.example.com/app, to be answered by my Python app? If so, how do I do that? What do I need in AWS? I'm familiar with Flask and have written apps on my local server using it—can that be integrated with Wordpress?
Sorry if this is confusing.
I also want a homepage for the app in case people are interested in
the extension
The simplest is to host the home page as a static website (Html, css, js) in an S3 bucket.
But if you really want WordPress, you can do that too.
For Backend web services for your plugin to talk to, you can use Elastic Beanstalk, it is a very simple way to do that, without tinkering all the components yourself.
We're working on an Umbraco site - multiple development machines using a shared development database.
When one developers makes changes in the CMS to content and does a Save and Publish the change is reflected on his machine but not other development machines.
This doesn't seem to make sense as we're all looking at the same database.? We've tried doing an IIS reset to see if it's caching at work but this doesn't seem to make a difference either.
Any ideas what on earth could be going on?
Umbraco does a lot of caching, so it doesn't have to hit the database all the time. Normally, all of the published content is cached in an xml file at App_Data\umbraco.config. You just need to have your developers right click on the root of the content tree in the umbraco backoffice and click "Republish the entire site" to regenerate that xml cache on disk from the xml cache in the database.
You also might need to reindex your examine indexes. You can normally find the "Examine Management" dashboard on the developer section in the backoffice of umbraco. By default, there are three indexes: InternalMember, Internal, and External. Unless you have membership going on in your umbraco site, you can ignore that index. The External index is used mostly for site searches. The Internal index is much more critical. It is used to cache media. I believe it is also used in the backoffice, but I'm not 100% certain. Make sure that the Internal index is regenerated.
Remember that media files are stored in the /media directory by default. That means if developer 'A' uploads a file, the physical file won't show up on developer 'B's machine automatically.
I'll bet you there's some cool ways to set up load balancing to handle a caching for your dev setup. I'm pretty sure there are also ways to store the media in the database, so you don't have to worry about transferring them back and forth.
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).
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 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.