A website I work on is currently running three different instances of Wordpress blogs, all with their own set of users & permissions, plugins and themes.
Unforauntely, I don't think Wordpress Network is a viable option due to the restrictions around where sub-blogs can be in terms of urls.
Here are the url structures of each blog:
sub.domain.com/blog-1 (lives in web_root/blog)
sub.domain.com/folder/blog-2 (lives web_root/blog-2, being aliased to folder via Apache)
sub.domain.com/blog-2 (lives in web_root/blog-2)
sub.domain.com is a Zend Framework website to complicate matters where all requests for files that don't physically exists are being rewritten to sub.domain.com/index.php
Any thoughts on how I can consolidate these instances into one Wordpress install? Thanks.
I am a huge fan of wordpress MU. There is no problem having separate user stores, and using separate plugins.
It will make updating Wordpress software 3 times easier.
Export all of the blogs and then import them into one Wordpress instance. The only strange one is sub.domain.com/folder/blog-2 but you can use the same apache mod_rewrite trick to redirect it to the lower folder.
Related
I have a client that maintains two different websites, each of which is set up as a separate virtual host in Apache. I installed and configured a Magento store within one host at domain1.com/store. They client now wants a store set up at domain2.com/store that shares products with the store on domain1.
All the instructions that I've seen to set up multiple websites within Magento require that the different websites be on the same host. Unfortunately, that isn't an option with our current setup. What's the best way to implement this?
So i think you should first think about your structure and what you're trying.
1.) Magento supports a multishop solution. For this you create many shops in one instance. Then you can set the Magento store in your vhost file with SET ENV or direct in your index.php file like this:
switch($_SERVER['HTTP_HOST']) {
case 'domain1.com':
$_SERVER["MAGE_RUN_CODE"] = "domain2";
$_SERVER["MAGE_RUN_TYPE"] = "store";
break;
default:
$_SERVER["MAGE_RUN_CODE"] = "domain1";
$_SERVER["MAGE_RUN_TYPE"] = "store";
break;
}
You have to change your index.php file that Magento know which shop the system should call (Create the shops in your Magento configuration).
2.) When you need more hosts Then make one database. Install the shop with all sites and then copy them to a new location. In the new location you can set the shop with the snippet in step 1.
Then you can build many hosts with one database but if you want with one administration and one database.
When you build the second solution you should think about that the database server should be in the same network.Otherwise you get a very bad performance.
You should point both Vhosts to the same magento install??
Then in the backend/admin section add a separate "Store"? Magento is totally designed to do this:
See Here
You can share store inventory, or keep it separated. You can also share main Template files -- Or keep them separated ... Share Skin files -- Or keep them separated. Point both vhosts to the same install directory and let Magento do the job it was designed for, without ever having to do the heavy Server Administration task of separating two installs by domain, but having the same Install.
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/...
Here's the problem: we have a family (approx. 8) of websites, each hosted on a different subdomain of a single domain common to every member of the family. E.g.,
ecommerce.my_domain.com
forums.my_domain.com
signup.my_domain.com
For various reasons, each subdomain is administered separately from the others--i.e., different servers, complete autonomously with respect to the others regarding nearly every development decision, including choice of web framework--for instance., two are Django, one is Zend, and so on (though all run Apache 2.2). We want to fix this, and someday we will, it just won't be anytime soon.
One direct consequence of this structure is that we have multiple Default page names. By 'Default Page' i'm referring to the page the server defaults to when no page on the subdomain is given--sometimes it's 'index.html', sometimes 'index.php', etc. (I know what they are, it's the fact that there are multiple pages that's a problem.)
(The Default page is the webpage to which your server defaults when no page on the domain is specified. For example, if the "index.html" page is served when you enter "www.my_domain.com", "index.html" is the Default page.)
Here's one problem it causes: our analytics code (javascript) will count page views to subdomain1.my_domain.com and subdomain1.my_domain.com/index.html as two separate pages, unless the correct default page is specified.By itself, this can cause a two-fold error in the basic page view measurement. In addition, the analytics system (Google Analytics) only allows a single Default Page to be specified.
After looking into this, it seems one way to do is at the Server (Apache 2.2) : (i) create a CGI directory without using ScriptAlias; (ii) use DirectoryIndex to specify a default document when only the directory is requested.
i suppose this can also be done within the Web Framework that supports each subdomain property, though given we have multiple different frameworks, that option is certainly less appealing.
I would be grateful for the Community's view on the preferred way to do this.
strong text*strong text*
What about using a .htaccess file to handle it?
Just add a line resembling the following with the order you want it to look for files to be your default:
DirectoryIndex index.html default.php default.htm foo.html index.cgi
.htaccess reference docs: http://httpd.apache.org/docs/current/howto/htaccess.html
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.
Today I discovered that my fresh installation of Apache HTTP Server is able to serve files from my C:\uploads\ directory.
I have two folders in C:\uploads:
C:\uploads\templates
C:\uploads\sites
Both folders contain testimage.jpg.
I found that Apache will serve the files from the templates folder if I request:
http://localhost/templates/testimage.jpg
However, http://localhost/sites/testimage.jpg 404's!
OMG - firstly, why does Apache serve the templates folder in the first place? Is it special?
Secondly, by what arbitrary set of rules does apache disallow access to other folders such the sites?
I'm so confused. Perhaps I've taken a wrong turn somewhere during the installation.
Did you look through your httpd.conf file to see what rules are in place for what is being served? Alternatively, are there .htaccess files that may be changing what is being served? You might have templates exposed in one or the other, but not sites... that's the first thing that comes to mind.
I would suggest going through these configuration files with a fine toothed comb to see what may cause the behavior you see.