multisite complication
I have a typical multisite setup with a dozen or so domain names or sub.domain names resolving to the same directory in which is the sites directory containing each of the domain and sub.domain names, some as symlinks when they are synonyms for another domain name. I need to add sub.domain/category_a sub.domain/category_b, etc. (mainly because category.sub.domain isn't supported, at least not by my hoster), but I can't figure out how to do this. Do I make category_a a symlink pointing to the drupal root? And if so, what do I put in the sites directory that would differentiate the two? Jeff -- Ayen Designs 388 Bullsboro Drive #105 · Newnan, Georgia 30263 404-271-9734 Web:ayendesigns.com <http://ayendesigns.com> Blog: theAccidentalCoder.com <http://theaccidentalcoder.com> Drupal: j. ayen green <http://drupal.org/user/367108> IRQ: j_ayen_green IM (Yahoo) baalwww (MSN) baalwww@yahoo.com Skype: ayendesigns Ayen Designs is a tradename of the computer services division of
So you want different sites on each category? On 13/11/2010 11:47 AM, <jeff@ayendesigns.com> wrote: I have a typical multisite setup with a dozen or so domain names or sub.domain names resolving to the same directory in which is the sites directory containing each of the domain and sub.domain names, some as symlinks when they are synonyms for another domain name. I need to add sub.domain/category_a sub.domain/category_b, etc. (mainly because category.sub.domain isn't supported, at least not by my hoster), but I can't figure out how to do this. Do I make category_a a symlink pointing to the drupal root? And if so, what do I put in the sites directory that would differentiate the two? Jeff -- Ayen Designs 388 Bullsboro Drive #105 · Newnan, Georgia 30263 404-271-9734 Web:ayendesigns.com Blog: theAccidentalCoder.com <http://theaccidentalcoder.com> Drupal: j. ayen green <http://drupal.org/user/367108> IRQ: j_ayen_green IM (Yahoo) baalwww (MSN) baalwww@yahoo.com Skype: ayendesigns Ayen Designs is a tradename of the computer services division of
Does having a site folder called sub.domain.category_1 work? You may need a symlink in your root folder to this folder, called "category_1". On 13/11/2010 12:29 PM, <jeff@ayendesigns.com> wrote: Right, so sub.domain/category_1 would run off the same code instance as sub.domain/category_2, but separate db's On 11/12/2010 08:23 PM, Christopher Skene wrote:
So you want different sites on each categor...
I don't know. I'll try that out. In thinking this through, another question sprung to mind: If these categories are going to be various demos, with the intent of pushing a database overwrite hourly to repair any pummeling done via users playing with the admin panel, are there risks in them sharing the same code base with production multisite sites? On 11/12/2010 09:38 PM, Christopher Skene wrote:
Does having a site folder called sub.domain.category_1 work? You may need a symlink in your root folder to this folder, called "category_1".
On 13/11/2010 12:29 PM, <jeff@ayendesigns.com <mailto:jeff@ayendesigns.com>> wrote:
Right, so sub.domain/category_1 would run off the same code instance as sub.domain/category_2, but separate db's
On 11/12/2010 08:23 PM, Christopher Skene wrote:
So you want different sites on each categor...
My unpopular opinion is that multisite is completely unnecessary for the vast majority of installs and has major drawbacks. The only fundamental advantage of multisite is that that it saves some disk space (does that matter?). But it has fundamental downsides: - It closely couples the database updates of many sites. (When you do a module or minor version update, you have to do the update and test on all the sites at that exact time. If you're doing it "right" it means that many sites may be offline until you're done. - It takes your filesystem risk and instead of having one site at risk at one time, they're all at risk. So if you have a new module you're introducing or an upgrade that has a bug it unfortunately affects all sites. - The files directory has to be managed exactly right; and it better not be sites/default/files. IMO, multisite and database prefixing were for the old days before we had unlimited accounts and disk space was free. That said, if you know exactly *why* you're doing multisite and you want to tie sites together, then that's fine. But "because Drupal does it and it seems cool" is not a good reason. Aegir is fundamentally a multisite idea, and it deals with all these problems. It's a maturing approach to doing multisite quite well, and many people are very happy with it. That's a good reason for doing multisite, and it has all the issues above dealt with. -Randy On Sat, Nov 13, 2010 at 8:56 AM, <jeff@ayendesigns.com> wrote:
I don't know. I'll try that out. In thinking this through, another question sprung to mind:
If these categories are going to be various demos, with the intent of pushing a database overwrite hourly to repair any pummeling done via users playing with the admin panel, are there risks in them sharing the same code base with production multisite sites?
On 11/12/2010 09:38 PM, Christopher Skene wrote:
Does having a site folder called sub.domain.category_1 work? You may need a symlink in your root folder to this folder, called "category_1".
On 13/11/2010 12:29 PM, <jeff@ayendesigns.com> wrote:
Right, so sub.domain/category_1 would run off the same code instance as sub.domain/category_2, but separate db's
On 11/12/2010 08:23 PM, Christopher Skene wrote:
So you want different sites on each categor...
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
My main reason for using multisite is time. I have 20 domains. If I am going to keep 20 Drupal sites 'in the green' (core/module status) with each having their own code base, it's 20x the effort. On 11/13/2010 11:30 AM, Randy Fay wrote:
My unpopular opinion is that multisite is completely unnecessary for the vast majority of installs and has major drawbacks. The only fundamental advantage of multisite is that that it saves some disk space (does that matter?). But it has fundamental downsides:
* It closely couples the database updates of many sites. (When you do a module or minor version update, you have to do the update and test on all the sites at that exact time. If you're doing it "right" it means that many sites may be offline until you're done. * It takes your filesystem risk and instead of having one site at risk at one time, they're all at risk. So if you have a new module you're introducing or an upgrade that has a bug it unfortunately affects all sites. * The files directory has to be managed exactly right; and it better not be sites/default/files.
IMO, multisite and database prefixing were for the old days before we had unlimited accounts and disk space was free.
That said, if you know exactly *why* you're doing multisite and you want to tie sites together, then that's fine. But "because Drupal does it and it seems cool" is not a good reason.
Aegir is fundamentally a multisite idea, and it deals with all these problems. It's a maturing approach to doing multisite quite well, and many people are very happy with it. That's a good reason for doing multisite, and it has all the issues above dealt with.
-Randy
I'd rather do a Take site offline cd /site/base git pull drush updatedb and test the results put site online on each site, than do Take all sites offline cd /site/base git pull cd into each sites dir one by one drush updatedb test each Put them online as it works out The time is about the same. The risk is much lower. You can still run them all of the same code repository; I have no issues with that. -Randy On Sat, Nov 13, 2010 at 9:58 AM, <jeff@ayendesigns.com> wrote:
My main reason for using multisite is time. I have 20 domains. If I am going to keep 20 Drupal sites 'in the green' (core/module status) with each having their own code base, it's 20x the effort.
On 11/13/2010 11:30 AM, Randy Fay wrote:
My unpopular opinion is that multisite is completely unnecessary for the vast majority of installs and has major drawbacks. The only fundamental advantage of multisite is that that it saves some disk space (does that matter?). But it has fundamental downsides:
- It closely couples the database updates of many sites. (When you do a module or minor version update, you have to do the update and test on all the sites at that exact time. If you're doing it "right" it means that many sites may be offline until you're done. - It takes your filesystem risk and instead of having one site at risk at one time, they're all at risk. So if you have a new module you're introducing or an upgrade that has a bug it unfortunately affects all sites. - The files directory has to be managed exactly right; and it better not be sites/default/files.
IMO, multisite and database prefixing were for the old days before we had unlimited accounts and disk space was free.
That said, if you know exactly *why* you're doing multisite and you want to tie sites together, then that's fine. But "because Drupal does it and it seems cool" is not a good reason.
Aegir is fundamentally a multisite idea, and it deals with all these problems. It's a maturing approach to doing multisite quite well, and many people are very happy with it. That's a good reason for doing multisite, and it has all the issues above dealt with.
-Randy
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
Many of us are too much used to the comfort of full access to the server. We need to remember that there is a huge number of Drupal installs on various shared hosts that do not offer any SSH access. No git, no drush. I myself still have quite a few sites at Rackspace Cloud and the ability of uploading modules once and then just running /update.php is a huge time saver. vacilando On Sat, Nov 13, 2010 at 18:21, Randy Fay <randy@randyfay.com> wrote:
I'd rather do a
Take site offline cd /site/base git pull drush updatedb and test the results put site online
on each site, than do
Take all sites offline cd /site/base git pull cd into each sites dir one by one drush updatedb test each Put them online as it works out
The time is about the same. The risk is much lower.
You can still run them all of the same code repository; I have no issues with that.
-Randy
On Sat, Nov 13, 2010 at 9:58 AM, <jeff@ayendesigns.com> wrote:
My main reason for using multisite is time. I have 20 domains. If I am going to keep 20 Drupal sites 'in the green' (core/module status) with each having their own code base, it's 20x the effort.
On 11/13/2010 11:30 AM, Randy Fay wrote:
My unpopular opinion is that multisite is completely unnecessary for the vast majority of installs and has major drawbacks. The only fundamental advantage of multisite is that that it saves some disk space (does that matter?). But it has fundamental downsides:
- It closely couples the database updates of many sites. (When you do a module or minor version update, you have to do the update and test on all the sites at that exact time. If you're doing it "right" it means that many sites may be offline until you're done. - It takes your filesystem risk and instead of having one site at risk at one time, they're all at risk. So if you have a new module you're introducing or an upgrade that has a bug it unfortunately affects all sites. - The files directory has to be managed exactly right; and it better not be sites/default/files.
IMO, multisite and database prefixing were for the old days before we had unlimited accounts and disk space was free.
That said, if you know exactly *why* you're doing multisite and you want to tie sites together, then that's fine. But "because Drupal does it and it seems cool" is not a good reason.
Aegir is fundamentally a multisite idea, and it deals with all these problems. It's a maturing approach to doing multisite quite well, and many people are very happy with it. That's a good reason for doing multisite, and it has all the issues above dealt with.
-Randy
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
IMO, it is a mix of both cases, Randym, Jeff.. You still do need to the same number of system updates when you are upgrading 20 sites or a multisite, and Randy, not necessarely all modules should go into sites/all/modules, many of them should only go to sites/custom/modules, so you don't need to update all sites when developing a custom module, and you still have to update all the sites when updating a module with major changes using the sites/all path.. Multisite is not only for limited account or disk space, it may help also sharing files (when non-security related), configuration, and many other things (that yet still can be done without multisite, I know), but you do have access from one site disk space to another, if this is your use case. Multisite can't be used on all setups, sometimes you need different versions of the same module and need to split completely from the multisite, because you can't have two modules (one in sites/all and other in sites/custom).. well, you may have, but expect the unexpected :) Multisite, under my point of view, is needed in some cases, and useless in others.. You just need to know when it fits your requirements. On Sat, Nov 13, 2010 at 6:21 PM, Randy Fay <randy@randyfay.com> wrote:
I'd rather do a
Take site offline cd /site/base git pull drush updatedb and test the results put site online
on each site, than do
Take all sites offline cd /site/base git pull cd into each sites dir one by one drush updatedb test each Put them online as it works out
The time is about the same. The risk is much lower.
You can still run them all of the same code repository; I have no issues with that.
-Randy
On Sat, Nov 13, 2010 at 9:58 AM, <jeff@ayendesigns.com> wrote:
My main reason for using multisite is time. I have 20 domains. If I am going to keep 20 Drupal sites 'in the green' (core/module status) with each having their own code base, it's 20x the effort.
On 11/13/2010 11:30 AM, Randy Fay wrote:
My unpopular opinion is that multisite is completely unnecessary for the vast majority of installs and has major drawbacks. The only fundamental advantage of multisite is that that it saves some disk space (does that matter?). But it has fundamental downsides:
- It closely couples the database updates of many sites. (When you do a module or minor version update, you have to do the update and test on all the sites at that exact time. If you're doing it "right" it means that many sites may be offline until you're done. - It takes your filesystem risk and instead of having one site at risk at one time, they're all at risk. So if you have a new module you're introducing or an upgrade that has a bug it unfortunately affects all sites. - The files directory has to be managed exactly right; and it better not be sites/default/files.
IMO, multisite and database prefixing were for the old days before we had unlimited accounts and disk space was free.
That said, if you know exactly *why* you're doing multisite and you want to tie sites together, then that's fine. But "because Drupal does it and it seems cool" is not a good reason.
Aegir is fundamentally a multisite idea, and it deals with all these problems. It's a maturing approach to doing multisite quite well, and many people are very happy with it. That's a good reason for doing multisite, and it has all the issues above dealt with.
-Randy
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
I have created a node type with a File field type using the Image widget. I've created four nodes that I want to use on the front page. I then created a View that displayed this image with a title and some text. So far so good. Then I logout and the images disappear. I've checked, and the node is published. I don't see any access permissions that need to be set, and a similar View with image nodes displays fine. The View is set to unrestricted and access all views is set for anonymous. Any ideas? Drupal 6.19, using a Zen theme and sub-theme. Thanks. -Don-
The quickest way to get this kind of behavior is with the content permissions module, which is not a node access module, but a field access module. Does the same thing happen if you're not user 1? -Randy On Sat, Nov 13, 2010 at 5:47 PM, Don <donald@fane.com> wrote:
I have created a node type with a File field type using the Image widget.
I've created four nodes that I want to use on the front page.
I then created a View that displayed this image with a title and some text.
So far so good. Then I logout and the images disappear. I've checked, and the node is published. I don't see any access permissions that need to be set, and a similar View with image nodes displays fine. The View is set to unrestricted and access all views is set for anonymous.
Any ideas?
Drupal 6.19, using a Zen theme and sub-theme.
Thanks. -Don-
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
Yep, you nailed it. Thanks. -Don- On 11/13/2010 9:08 PM, Randy Fay wrote:
The quickest way to get this kind of behavior is with the content permissions module, which is not a node access module, but a field access module.
Does the same thing happen if you're not user 1?
-Randy
On Sat, Nov 13, 2010 at 5:47 PM, Don <donald@fane.com <mailto:donald@fane.com>> wrote:
I have created a node type with a File field type using the Image widget.
I've created four nodes that I want to use on the front page.
I then created a View that displayed this image with a title and some text.
So far so good. Then I logout and the images disappear. I've checked, and the node is published. I don't see any access permissions that need to be set, and a similar View with image nodes displays fine. The View is set to unrestricted and access all views is set for anonymous.
Any ideas?
Drupal 6.19, using a Zen theme and sub-theme.
Thanks. -Don-
-- Randy Fay Drupal Module and Site Development randy@randyfay.com <mailto:randy@randyfay.com> +1 970.462.7450
All the previous points about Multisite and its advantages/disadvantages are valid, however in your case, as you plan to zap the database regularly and it doesn't sound like data integrity is important, I would probably start with multisite as well. I will add, that if you are using APC to improve performance, multisite has big performance benefits over separate codebases, as APC will reuse all the files. The benefits are partly lost with separate code bases. Either way, however, I would use git to manage the platform off a separate repository. Chris Skene chris@xtfer.com On 14/11/2010, at 2:56 AM, jeff@ayendesigns.com wrote:
I don't know. I'll try that out. In thinking this through, another question sprung to mind:
If these categories are going to be various demos, with the intent of pushing a database overwrite hourly to repair any pummeling done via users playing with the admin panel, are there risks in them sharing the same code base with production multisite sites?
On 11/12/2010 09:38 PM, Christopher Skene wrote:
Does having a site folder called sub.domain.category_1 work? You may need a symlink in your root folder to this folder, called "category_1".
On 13/11/2010 12:29 PM, <jeff@ayendesigns.com> wrote:
Right, so sub.domain/category_1 would run off the same code instance as sub.domain/category_2, but separate db's
On 11/12/2010 08:23 PM, Christopher Skene wrote:
So you want different sites on each categor...
In any case, multisite is a good thing, I think. Updates are a piece of cake, but you should keep two codebases around. Put all of your multisites on codebase A and let them run for a while. When updates are available, pull the updates down on codebase B and move your site directories over one by one and run update.php. It's a good process, and it's easily scriptable. It also happens to be the same process that Aegir uses (more or less). Thanks, Cameron On Sat, Nov 13, 2010 at 13:33, Chris Skene <chris@xtfer.com> wrote:
All the previous points about Multisite and its advantages/disadvantages are valid, however in your case, as you plan to zap the database regularly and it doesn't sound like data integrity is important, I would probably start with multisite as well.
I will add, that if you are using APC to improve performance, multisite has big performance benefits over separate codebases, as APC will reuse all the files. The benefits are partly lost with separate code bases.
Either way, however, I would use git to manage the platform off a separate repository.
Chris Skene chris@xtfer.com
On 14/11/2010, at 2:56 AM, jeff@ayendesigns.com wrote:
I don't know. I'll try that out. In thinking this through, another question sprung to mind:
If these categories are going to be various demos, with the intent of pushing a database overwrite hourly to repair any pummeling done via users playing with the admin panel, are there risks in them sharing the same code base with production multisite sites?
On 11/12/2010 09:38 PM, Christopher Skene wrote:
Does having a site folder called sub.domain.category_1 work? You may need a symlink in your root folder to this folder, called "category_1".
On 13/11/2010 12:29 PM, <jeff@ayendesigns.com> wrote:
Right, so sub.domain/category_1 would run off the same code instance as sub.domain/category_2, but separate db's
On 11/12/2010 08:23 PM, Christopher Skene wrote:
So you want different sites on each categor...
One consideration with multisites is that if you allow a user to use PHP in Drupal (block visibility, input format, etc.) then they will be able to read the settings.php for all your sites, and thus connect to all the databases. Aegir uses 'cloaked' credentials to handle this, putting the database details in the vhost files, and then just pulling those into the settings.php file for Drupal. Regards Steven Jones ComputerMinds ltd - Perfect Drupal Websites Phone : 024 7666 7277 Mobile : 07702 131 576 Twitter : darthsteven http://www.computerminds.co.uk On 13 November 2010 22:58, Cameron Eagans <cweagans@gmail.com> wrote:
In any case, multisite is a good thing, I think. Updates are a piece of cake, but you should keep two codebases around. Put all of your multisites on codebase A and let them run for a while. When updates are available, pull the updates down on codebase B and move your site directories over one by one and run update.php. It's a good process, and it's easily scriptable. It also happens to be the same process that Aegir uses (more or less). Thanks, Cameron
On Sat, Nov 13, 2010 at 13:33, Chris Skene <chris@xtfer.com> wrote:
All the previous points about Multisite and its advantages/disadvantages are valid, however in your case, as you plan to zap the database regularly and it doesn't sound like data integrity is important, I would probably start with multisite as well. I will add, that if you are using APC to improve performance, multisite has big performance benefits over separate codebases, as APC will reuse all the files. The benefits are partly lost with separate code bases. Either way, however, I would use git to manage the platform off a separate repository. Chris Skene chris@xtfer.com
On 14/11/2010, at 2:56 AM, jeff@ayendesigns.com wrote:
I don't know. I'll try that out. In thinking this through, another question sprung to mind:
If these categories are going to be various demos, with the intent of pushing a database overwrite hourly to repair any pummeling done via users playing with the admin panel, are there risks in them sharing the same code base with production multisite sites?
On 11/12/2010 09:38 PM, Christopher Skene wrote:
Does having a site folder called sub.domain.category_1 work? You may need a symlink in your root folder to this folder, called "category_1".
On 13/11/2010 12:29 PM, <jeff@ayendesigns.com> wrote:
Right, so sub.domain/category_1 would run off the same code instance as sub.domain/category_2, but separate db's
On 11/12/2010 08:23 PM, Christopher Skene wrote:
So you want different sites on each categor...
participants (9)
-
Cameron Eagans -
Chris Skene -
Christopher Skene
-
Don -
Iñaki Lopez -
jeff＠ayendesigns.com -
Randy Fay -
Steven Jones -
Tomáš Fülöpp (vacilando.org)