Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By t.a. barnhart on
i will try this again because i have yet to come across a good answer (ie, one that i understand)
i have a single install of 5.5 that works perfectly.
i have created a subdomain. i want that to have its own database. in my working domain, i created the correct directory under sites
rather than use symlinks, i have tried to redirect my subdomain. i've tried redirecting it to the domain, the domain/sites, domain/sites/subdomain, and even domain/sites/subdomain/settings.php
to no avail.
this should work. if i have a clean copy of settings.php & Drupal finds it at sites/subdomain, should that not prompt it to create the new database and point the whole thing to my base url: subdomain.domain.net?
or will redirecting always fail? do i need symlinks? i have shell access (allegedly); just having a log-on issue with that.
Comments
go here to create your
go here to create your subdomain:
https://panel.dreamhost.com/index.cgi?tree=domain.manage&
choose Mirrored
(A "mirror" of another site's content; browser URL remains the same.)
in
Domain that mirrors:
sub-domains are okay!
you put yoursubdomain.yourdomain.com
in
Domain to mirror:
you select your main domain with drupal install
that's it
ps: drupal will not create a new database, you need to create it in dreamhost panel, drupal will populate it.
but not for full domains?
this worked great for my subdomain. thanks so much. this will be so useful in the future.
but i also need to do regular domains. and that's where i'm really running into problems. the mirror thing does not work for full domains.
neither do any of the usual directions given in here. especially when i have to do symlink! i find it amazing that i cannot find decent directions on how to do multisites.
Yes it does indeed. As you
Yes it does indeed. As you understood, I'm on dreamhost too and I do multi installs too.
I used both sub domains and domains using the exact same method (mirror)
just make sure, as I do, that in your main domain sites folder you create folders for each of your additional domains,without the www part:
/sites/newdomain.com/settings.php
/sites/newdomain.com/modules/
/sites/newdomain.com/themes/
Cheers,
James
almost there... try assigning web folder rather than mirroring.
hi t.a. barnhart. Best wishes on this cusp of years if you celebrate the western calendar's dates, and bravo for your persistence so far.
The short answer is to try in DH's domain manager to assign each multisite "child" domain's 'web folder' to your main "parent" drupal installation's web folder, remembering to erase empty folders created by this process inside your main installation's web folder. I believe I currently have that working for top-level domains and subdomains with equal ease. I believe that's a more standard practice than mirroring.
I think the result is a symlink to your main installation parent folder from each child multisite domain. If not, it behaves like one.
http://drupal.org/node/125736 is older but shorter, directs you to other support.
The long answer, well, it's long. Not a plug for or a critique of our current hosting company, dreamhost, named once in this comment for search purposes and otherwise DH, and not linked to them for my profit. Anyway, it's really long. See below. Yeah, it just keeps on going. Exhaustive? No. Exhausting both to writer and reader? Probably.
Accurate? Probably, mostly, I hope...
I understand your frustration. Really, I do. In this predicament, the search function [on this site and on the web in general] is your friend. These days there's actually an abundance of good explanations of multisite creation, maybe hundreds more than there were a couple years ago. Not all are useful for my particular needs. Not all are clear or detailed. Few are bleeding-edge up-to-date, cause that's the web.
It works so well when you get it to work it's easy to forget how we got there: the documentation and the software it documents is built/rebuilt/maintained by an internationally distributed, non-linearly intertwined, ever-changing and ever-more-variegated group of users who are ALWAYS aiming for a moving target with a near-infinite variety of environment/intent/support/experience/language/skill/friendliness variables/hours of sleep. For free.
Sometimes it sucks and more often it blows everything else out of the water. Either way, I find that there's no satisfaction in blaming complexity for being complex.
Here's yet another run at describing the arcana of multisites in as linear a way as I can. It'll be very pedantic just 'cause I am, not because I in any way question your ability or intelligence. It'll duplicate much else on drupal.org, and I'm starting from near to the beginning in case it illuminates someone else's issue.
My setup: DH, drupal 5.5, multisites that aren't all subdomains
[I'm using friendly, simple, thoroughly documented graphical user interfaces wherever possible in this process. I think of them as disability aids, and I'm grateful they exist. If you're more familiar with the command line, by all means adapt this process to suit your tool of choice.]
Let's say I want to build my mentalmulch-selling empire with a vast chain of similar sites. Well, maybe a chain of around 8, including mentalmulch. com, much.mentalmulch. com, many.mentalmulch. com, mentalmulchmerch. com, etc.
Let's say I've been struggling with trying to make these sites happen forever.
Let's presume that my user name on DH [not the name with which I log in to the panel, but the user name created using the panel] is compost, and that user is assigned to operate on the shared server .fertilizer hosted by DH. I've paid for and set up registration for all of these sites, and they all point to DH's servers, wherever they're registered, parked or set up as 'fully hosted'. I've created and tested a few email addresses each for these new sites. This part of the process recedes into the mist of time.
More recently, I've used DH's web panel functions to create one database host name, one database user and 8 new databases, each named for one of my sites-to-be.
I've waited a while for the web to settle from all my activity :) and for the addresses to gel. Time has passed.
On the day it's all gonna change, I check that there are no outstanding security issues suddenly come to light with drupal OR DH or .fertilizer in particular (I don't expect problems, but Murphy's law dictates that if something busts it'll be at a crucial time.)
I log in to my DH folder address via SFTP and refamiliarize myself with the state of affairs on .fertilizer (DH's graphical web-based SFTP is my tool this time. Your mileage may vary). From previous efforts, I have other user names on .fertilizer containing other folders with some of the names of some of these mentalmulch-related urls in various stages of undress. I've made a jumbled mess. I log in via SFTP as each of these users, back up everything, then empty their folders of any mentalmulch-related content. Once the folders are cleaner [or empty], I'll make a note to delete the redundant users too if they're not holding any live material or current projects.
I download the most recent stable version of drupal 5 to my computer from drupal.org. I log in to DH as compostusing SFTP and clean any unused items from the user folder home/.fertilizer/compost/
If there are old mentalmulch-related folders here, I back them up and erase them.
I create a new folder within my base user folder named for what will be my parent site url:
home/.fertilizer/compost/mentalmulch. com. If I remember how, I'll set the folder's permissions to 755.
Still using the web-based SFTP software, still logged in as compost, I upload the fresh drupal5.5.tar.zip file from my computer to the new folder
home/.fertilizer/compost/mentalmulch. com.
When it's up there,
I use SFTP to unzip (open up or decompress) the file home/.fertilizer/compost/mentalmulch. com/drupal5.5.tar.zip, which leaves me with a new folder drupal5.5. as well as the zip. When it's done unpacking, I erase the the file home/.fertilizer/compost/mentalmulch. com/drupal5.5.tar.zip that I won't need any more.
I use a freshly-opened, cookieless but cookie-enabled new version of Firefox to visit panel.DH . com, where I choose 'domains', then 'manage domains'.
When I select to edit my domain mentalmulch. com, I get the option to assign it a web folder.
I think it defaults to home/.fertilizer/compost/mentalmulch. com
I change it to
home/.fertilizer/compost/mentalmulch. com/drupal5.5
I wait a bit. This involves stretching and at least one Guinness.
I open a new tab in Firefox and navigate to http://mentalmulch. com
the browser thinks for a moment, then opens the drupal installer. I fall over with glee, then walk through the install for the single site mentalmulch. com. It's during this installer dialogue that I have to tell drupal the name of the database, database host address database user and password. It succeeds and brings me to the start page where I make myself user1, rename user1 and give drupal my email when asked. Drupal sets me up with a password, and gives me a chance to alter, confirm and log in with this new password. I go to site information to name it mentalmulch. com, put the whole site on 'maintenance' for the moment to avoid embarrassment and twiddle enough with module and theme updates, file structure and database settings to have a site that looks like a site and isn't giving me any errors [or too many warnings] in the log, but I'm not going mess with it too much or set file systems up yet.
Now I'm ready for the child sites.
[home/.fertilizer/compost/mentalmulch. com/drupal5.5 is the web folder for mentalmulch. com, the parent of my multisite tree. It's handy to me to have that reminder of what the folder's doing, but I could have renamed it before assigning it as a web folder.]
Back in Firefox's other tab, I'm still looking at the 'manage domains' page. There, I assign home/.fertilizer/compost/mentalmulch. com/drupal5.5 as the web folder for the multisite 'children' sites, too, and confirm sure that they're all pointing to DH's nameservers and all share the same user compost.
For simplicity, I'm going to set it up through the same panel to use the domain name without www, and to point addresses that include www at the shorter address without it.
eg much.mentalmulch. com, many.mentalmulch. com, much2. com AND sonofmentalmulch. com. It doesn't on our host seem to matter if they're subdomains or not, and the parent site could also be a subdomain, eg parentdrupalinstall.mentalmulch. com]
For each of these domain names, DH has auto-created a folder with the domain name inside the home/.fertilizer/compost/mentalmulch. com/drupal5.5 folder.
this folder may now even contain a confusingly-named
home/.fertilizer/compost/mentalmulch. com/drupal5.5/mentalmulch. com
I ignore them for a moment, and go instead to the sites folder within the drupal folder at
home/.fertilizer/compost/mentalmulch. com/drupal5.5/sites
I use the SFTP application to make folders called
sonofmentalmulchhead. com,
many.mentalmulch. com,
much.mentalmulch. com,
etc. inside of
home/.fertilizer/compost/mentalmulch. com/drupal5.5/sites/
I don't need to make a folder for my parent site, but I could put information about the parent site into the settings file within a 'default' folder that already exists there.
I need to populate each of these site folders with a unique settings file containing the database and base url information for that domain, and I need to put in each of these site folders a files folder, themes folder, scripts folder, etc. for all the unique content of those sites.
That will look like
home/.fertilizer/compost/mentalmulch. com/drupal5.5/sites/yetanothermentalmulchsite. com/files
home/.fertilizer/compost/mentalmulch. com/drupal5.5/sites/yetanothermentalmulchsite. com/themes
home/.fertilizer/compost/mentalmulch. com/drupal5.5/sites/yetanothermentalmulchsite. com/scripts
etc.
Shared content goes in
home/.fertilizer/compost/mentalmulch. com/drupal5.5/sites/all/themes,
home/.fertilizer/compost/mentalmulch. com/drupal5.5/sites/all/scripts, etc.
the 'all' folder doesn't need a settings file.
This way (if I'm using public file transfers), each site folder contains everything relevant to recreating/rebuilding/backing up each site,
[except for the database content and the shared files I forgot to take out of
home/.fertilizer/compost/mentalmulch. com/drupal5.5/misc and a couple other 'gotchas']
OK. Why isn't it working yet?
back to My SFTP application, and back to my home/.fertilizer/compost/mentalmulch. com/drupal5.5 folder/
I need to go through and ERASE
home/.fertilizer/compost/mentalmulch. com/drupal5.5/sonofmentalmulchmuncher. com,
home/.fertilizer/compost/mentalmulch. com/drupal5.5/much.mentalmulch. com,
home/.fertilizer/compost/mentalmulch. com/drupal5.5/many.mentalmulch. com,
and all those other empty zombie folders DH had auto-created for me inside of home/.fertilizer/compost/mentalmulch. com/drupal5.5/
If I have an empty folder called
home/.fertilizer/compost/mentalmulch. com/drupal5.5/mentalmulch. com, this in particular must be erased immediately.
While I'm cleaning up, I'll look also for zombie folders that have somehow dropped into other folders, like
home/.fertilizer/compost/mentalmulch. com/much.mentalmulch. com,
home/.fertilizer/compost/many.mentalmulch. com,
or
home/.fertilizer/compost/mentalmulch. com/drupal5.5/mentalmulch. com/misplacedmentalmulch. com
and so on.
The zombies are distracting my symlink away from where I want it to look. With them gone, my child addresses link to [or look for their brains in] the powerful application in home/.fertilizer/compost/mentalmulch. com/drupal5.5, which will be their operating back end, directing them each to their appropriate, eponymous site folder in the 'sites' folder.
With the empty folders put to rest, my new sites can live!
for each of the site-named, settings-containing 'real' site folders I've created
in the folder
home/.fertilizer/compost/mentalmulch. com/drupal5.5/sites
I have deleted a zombie 'unreal' empty folder of exactly the same name
in the folder home/.fertilizer/compost/mentalmulch. com/drupal5.5/.
Now I'll navigate to each of my child site web addresses in firefox
eg
http://mostlymentalmulch2. com, http://www.monstrousmentalmulch.net, etc
where I fully expect to encounter a drupal install dialogue at each address, for each of which I'll need to enter unique database information (or information about which tables to share, if this has gone too smoothly so far and i want to make things REALLY hairy. I've avoided this complexity for now because I still want to further complicate my life with an embedded Gallery2 install, a static IP shared store pointing at home/.fertilizer/compost/mentalmulch. com/, and a few other bits of nonsense.)
The drupal wizards [and a host of other experienced folk] have been shouting forever that best practice is about neat compartmentalization of content and standardization of basic structure so that upgrades, test sites, and other crucial elements are more feasible and less confusing. I'm starting to get it, after having been told a zillion times. Good luck!
-----------------------------------------------------------------------------
- fumbling happily along an infinite sequence of challenges...
I've had no problem
I've had no problem whatsoever in setting domains and subdomain directly as mirror of the main domain (the one with the drupal install)
When I say no problem I'm of course even talking about google and search engines referencing, they don't see all my domains as the same website. All my domains behave like they are totally separate websites, except of course they have the same IP, but in dreamhost all your domains will have the same ip anyway, mirroring or not.
As for the database, since dreamhost offer unlimited databases, I'm not sharing database between apps. Every drupal site has its database and if I install another app I'll use another database. Except of course if for one reason or another one app would need to be on the same database as drupal for it to be totally integrated in drupal. I don't know if there's one such requirement, but that would be the only case. Otherwise I prefer to have well separated databases for each use.
sorry, cant help with your problem
but its good to know drupal 5.5 is working on dreamhost!
It's working fine! I always
It's working fine! I always activate cache, because Drupal can bring down shared hosting with modules such as "similar entries" or "tagadelic" and more. So it's better to activate cache as soon as your site begins to grow over a thousand visitors a day.
I just bought a space from
I just bought a space from Dreamhost, their server is really slow ... so it is better idea to keep away from them ...
bullshit.. I am with them
bullshit.. I am with them since over a year and decided to buy 10 years last month, because the service has been the best I encountered in over 10 years of web hosting experiences on various hosts.
Honestly you should admit your comment is senseless. There must be another issue, like where you are when you visit it or something like that. I'm from Europe, dreamhost is based in the US, but it's fast enough, I don't feel any difference with european hosts where I also have some sites.
I know I read things about mysl servers being slow at dreamhost but I haven't find it to be the case and I have a fairly high traffic sites hosted on this dreamhost account. But as I said I have cache enabled and css aggregator too. All the traffic is from guests so the cache is working a lot. But even so, the cache is still in the database, and I don't have any problem of speed that I see. Maybe I should check with devel module, but I honestly don't feel any problem.
It is not bullshit, I wrote
It is not bullshit, I wrote what I have seen from them so far ... I am using internet service over 2gps from Australia but with thier panel (panel.dreamhost.com) it seems to me that I am using dail-up.
I do not have the experience that you have in web hosting but I just compare their service with siteground.com ... and based on that I can say siteground is better than dreamhost. However, dreamhost is not too bad.
all hosts are variable
i have had some bad days with DH, but far more good days. their tech support is excellent: responsive and persistent. i've used a number of other hosts, and none are great -- ie, none provide instant access to pages like we all hope for in the future! DH is, for the most part, all i hoped it would be. i will continue with them for the next year, happily
one of the selling points for me, btw, is that they are owner-operated. i like that. they have a vested interest in providing a quality product. unlike a host that is part of a corporation.
and they are not right-wing sexist misogynists like GoDaddy (with a shitty hosting interface)