37signals is a web app company. Some of their applications:
basecamp, to manage projects
highrise, to manage contacts
backpack, like a wiki
they use different domains for each application (basecamphq.com, highrisehq.com, etc)
in basecamp, this is the address of a particular comment for a post in a project of my company (acme) https://acme.basecamphq.com/projects/431678/posts/2964581/comments#5854236
if 37signals had chosen to host all the applications under their domain using folders (eg 37signals.com/basecamp/..., how would you design the paths RESTfully?
Um, how about something like
http://www.37signals.com/[PRODUCTNAME]/projects/431678/posts/2964581/comments#5854236
Not quite sure what you're asking, really.
Related
I'm wondering if this is possible and I'm not sure that it is. Before I explain, I found one other post [here]: Separate Domain Registrar and Host, possible to use CDN? which sounds similar to my problem, but I specifically don't want to point the Name Servers away. I only mention this because my question is going to sound very similar.
So I'm trying to help a friend who has a Domain Name registered on Site A (let's assume it's a place like Wix). He also has a hosting package on Site B (to have cpanel access for a site he had built with HTML & PHP).
for example:
1. www.yourdomain.com is hosted on Wix with a template website
2. "database" is a cpanel folder on Site B
Is there a way to have www.yourdomain.com/database link to the "database" folder on Site B's hosting -- without changing the Name Servers?
I don’t believe you can point a directory to a completely different server or hosting package.
However creating a sub domain instead could be your answer.
Is there anything stopping you from using database.yourdomain.com and creating an A record for this in your domain registrar and point it to the hosting package of database?
I have an account on some VPS(friend's apache server with cPanel) and there I have one public_html directory.
We have in there about 5-6 websites:
/home/myusername/public_html/domain-1.name/index.php
/home/myusername/public_html/domain-2.name/index.php
but I don't like this way, I'd like to orginise it better and be able to separate and isolate some stuff for each website.
So what if I create like that:
/home/myusername/websites/domain-1.name/public_html/index.php
/home/myusername/websites/domain-2.name/public_html/index.php and so on
Would it be a correct way of structurising web directories?
And would apache work like that?
Perhaps there are out there some other conventions or common workarounds?
Thanks
This is perfectly fine. In fact I'd highly recommend against using the domain folder as the document root as typical web application will also contain data that is not publically accessable (e.g. configuration files, management scripts, version control files, etc.)
Personally I prefer the name htdocs and I keep my sites under /srv/http
For example:
/srv/http/user1/domain1/htdocs/
/srv/http/user1/domain2/htdocs/
/srv/http/user1/domain3/htdocs/
/srv/http/user2/domain4/htdocs/
/srv/http/user3/domain5/htdocs/
That way you can set the DocumentRoot to the htdocs directory and put other stuff that is not meant to be delivered by the web server in a different sub directory of the domain directory.
Ok, I want just to conclude and to outline the way I went with.
Thanks to #bikeshedder for ideas!
So having a single account(none-root) /home/myusername/ under linux VPS server, I didn't want to abstract completely from existent directory structure, but at the same time I wanted to create proper environment to isolate and separate clients and their spaces.
Main goals were:
* The new directory structure should help to keep all files and folders in a nice and clear order.
* Easy to navigate and browse.
* Each developer or client would have access only to their space.
The structure:
/home/myusername/http/client-1/domain-1/public_html/index.php
/home/myusername/http/client-1/domain-1/resources/
/home/myusername/http/client-1/domain-1/configuration.php
/home/myusername/http/client-1/domain-2/public_html/index.php
/home/myusername/http/client-1/client's_resource_dir/
/home/myusername/http/client-2/domain-3/public_html/index.php
/home/myusername/http/client-2/domain-3/subdomain/public_html/index.php
As result:
* We have isolated client's space and isolated domain space. That makes enough room for any type of web projects.
* Files and dirs are not mixed up with other projects, domains and clients anymore.
* For subdomain paths it can be
- as subdirectories /domain-3.name/subdomain/public_html/
- or additional subdomain directory /subdomain.domain-3.name/public_html/depending on requirements or size of subdomain website.
* Public_html is going to be a DocumentRoot for each website.
I did not go for srv/ and var/www dirs, cuz to me it sounds like server in the server and also I don't feel variable data var/ in current setup falls under web stuff.
Though it may make sense for our coming soon local web/file sharing server
But here now I have another question:
How would I specify new path to be a default one for cPanel? and only for my user?
Cuz now there is going to be multiple DocumentRoot directories in one user space.
Is that possible by Apache design?
I better create new question :) And then will edit my question with answer
Any suggestion welcome!
Normally go with this once hosting from 5-30++ sites, depending on complexity of content, traffic, perceived future migration strategies to more dedicated virtual or bare metal servers/instances.
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/index.<html|php|jsp|aspx|what-not>
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/assets/...
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/index.<html|php|jsp|aspx|what-not>
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/assets/...
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/index.<html|php|jsp|aspx|what-not>
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/assets/...
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/index.<html|php|jsp|aspx|what-not>
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/assets/...
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/index.<html|php|jsp|aspx|what-not>
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/assets/...
My client owns "domain.com". We need to give various applications friendly names for internal and external access. The applications are WCF web services and MVC web applications with varying levels of authentication (Windows auth within and across AD domains and plain text authentication). It looks a little like this:
UAT Environment
service1.uat.services.domain.com
service2.uat.services.domain.com
service3.uat.services.domain.com
service4.uat.services.domain.com
application1.uat.apps.domain.com
application2.uat.apps.domain.com
Production Environment
service1.services.domain.com
service2.services.domain.com
service3.services.domain.com
service4.services.domain.com
application1.apps.domain.com
application2.apps.domain.com
We're likely to have a LOT more sub domains, and everything needs to be secured with SSL.
We've changed our minds on how to configure this a number of times, but now we've hit a possible restriction. We thought a wildcard SSL certificate might work, but apparently they only work to a single level of subdomain i.e. *.services.domain.com.
Because of budget, we'd like to register a single wildcard SSL certificate and apply it to multiple servers (belonging to multiple AD Domains, and also a few servers in our DMZ).
This morning I had an idea, but I don't know enough about this stuff to make a definite decision. Do any of you foresee any restrictions on using the following naming convention instead of the above?
service1-uat-services.domain.com
service2-uat-services.domain.com
service3-uat-services.domain.com
service4-uat-services.domain.com
application1-uat-apps.domain.com
application2-uat-apps.domain.com
service1-services.domain.com
service2-services.domain.com
service3-services.domain.com
service4-services.domain.com
application1-apps.domain.com
application2-apps.domain.com
That way, we can register a wildcard for *.domain.com and use a single level subdomain for each application / service, but still allow us to keep everything logically separate. Are there any technical issues anyone can identify using this set up?
There shouldn't be any problem with that.
Right now there's two different accounts, with both domains having each their own hosting account,
for similar website (let's say domain.fr and domain.co.uk)!
I've merged the two websites into one (currently hosted as 0.0.0.0/site/language ),
making it multilanguage! The script just need a prefix on root,
such as like www.domain.com/english/ or www.domain.com/french.
This works as expected, if only a domain is used, but I would like to use two different domains (domain.fr / domain.co.uk).
So, I want to catch the current request URL, to know what language to display. What's important is that, the request urls keep persistent.
For example,
http://domain.co.uk/language_english
http://domain.co.uk/language_english/somepage.php
http://domain.co.uk/language_english/somedirectory/someotherpage.php
While,
http://domain.fr/language_french
http://domain.fr/language_french/somepage.php
http://domain.fr/language_french/somedirectory/someotherpage.php
This two domains are actuall hosted in same hosting account, let's said
127.0.0.1/language_variable/somepage.php
Any suggestions or good practices?
If I got your question , It's a feature in Web Hosting's solution which is called Addon Domains and depend on hosting company that how many Addon Domain they let you to put into one account !
I have a classifieds site and I want to know whether creating subdomains or sub-folders is better, as I am in state of confusion.
If we need to take sub-domains then what are the benefits which we can get from sub-domains?
If we need to take sub-folders then what are the benefits we can get from them?
If we create sub-domains then Google considers sub-domains as individual domains and would show only 2 results per page.
So please clear my doubts and let me know which one is better.
Search engines will treat subdomains more like separate domains, so it many cases using sub-folders is the way to go, so that you are not spreading yourself to thin.
using both is a bad idea, as search engines will try to index both, and one will get flagged as duplicate content.
Here's an article from SEOMoz explaining it in more detail:
http://www.seomoz.org/blog/understanding-root-domains-subdomains-vs-subfolders-microsites
Personally, I go off the logic that a subdomain is a different application / site owned by the same company. A subfolder is part of the same application / site.
It is probably better for your PageRank / search engine listings if you have 'one-big-site', rather than lots of different loosely coupled domains. If the content of the sites is distinctly different, e.g. a personal site might have a gallery or blog subdomain which keeps the content distinctly seperate from the main site - then it probably makes sense for a subdomain, otherwise, I'd stick with folders.
p.s. Side note, dunno if this is important, but web-browsers only open two connections at once to a website when downloading the different files that constitute a page. So there is a reason for a subdomain in this instance where it actively speeds up (though, on a fast site, minimally) the page load time.
It depends on what content you want to create subfolder/-domains for.
Is it related to your original site? Then you should definitely use sub-folder as this belongs to the same domain. It's much better for the link juice to spread if you use sub folders.
As for the PageRank, it's better to use subfolders.
Subdomains is considered as a new site. Subfolders is not, and will get better rankings if your original site is powerful.
You can use both subdomains and subfolders if you like, but don't forget to use the canonical-tag to avoid duplicate content.
Two relevant links that explains this further:
http://www.searchmarketingstandard.com/when-to-use-subdomains-vs-subfolders
http://www.searchenginejournal.com/subdomains-or-subfolders-which-are-better-for-seo/6849/
Why not both? Have demandb.com/foo and foo.demandb.com go to the same place.
Technically, a subdomain is a different server. The company I work for has a domain with several subdomains where every subdomain is located on a different (virtual or real) computer/server. That way, if one of them crashes, the rest just keeps running.
From a developer's perspective, a subdomain would force everything within the subdomain to be a different application while in a subfolder, the subfolder and subsubfolders could be part of the application in the root folder. When I create web applications, those web applications are often tested first on a test server in a subfolder. Once they make it through the tests, they are moved to the root of their own subdomain.
When two subfolders are related to one another, they're often part of the same application, thus it would be better to keep them in their own subfolder so they can share cookies and sessions more easily.
2 comments:
Use sub folders if you need SSL- then you only need 1 basic certificate for the root
If you use both, make sure you redirect 301 one to the other. That will avoid the search engine duplication issue, but would still be problematic for SSL in certain situations.
If your site can be easily partitioned by the subdomains and each subdomain can operate independently then do it! You can then easily scale out your application by deploying different servers(or clusters) for each subdomain.
Examples:
Craigslist: by region(seattle.craigslist.org, sfbay.craigslist.org, etc)
Livejournal: by community/user
Technically, you can do this with folders, but it requires a web proxy farm, whereas subdomains can be done with simple DNS entries.
its also depends on your needs whether u want separate login system for sub domains, because it wont be possible is you are using sub-folder. Sub-folder share same session.
For sub domains you have to set shared cookie for all domains.