Sharing CMS setup for multiple virtual hosts ??
-
upsetter
Sharing CMS setup for multiple virtual hosts ??
say I'd like to share a cms-setup among a dozen vhosts. Is this possible and in that case, how to best accomplish it. I really don't want fullblown cms file trees all over the place. I figure some directories like ./plugins and ./lib can be symlinked. Anyone been struggling with a similar setup and got some hints to share ?
Re: Sharing CMS setup for multiple virtual hosts ??
I don't anyone who has done this yet, but it should be possible. You can symlink everything except for ./tmp and config.php and (in theory) it should work. Obviously, you'd need to be pretty slick with the shell script to create a new instance, but it shouldn't be that hard. It's pretty much what webapp-config in gentoo does now for web applications in a virtual hosting environment.
Obviously, doing upgrades would be a slight pain, becuase you'd have to hit them all at once.
If you do come up with some good scripts, please share them. I'm sure others would like this setup as well.
Obviously, doing upgrades would be a slight pain, becuase you'd have to hit them all at once.
If you do come up with some good scripts, please share them. I'm sure others would like this setup as well.
-
upsetter
Re: Sharing CMS setup for multiple virtual hosts ??
"Obviously, doing upgrades would be a slight pain, becuase you'd have to hit them all at once."
Why is that? i thought symlinking would make it easier?
Regarding mySQL, is it better to run multiple DBs or use the db prefix to separate content?
Why is that? i thought symlinking would make it easier?
Regarding mySQL, is it better to run multiple DBs or use the db prefix to separate content?
Re: Sharing CMS setup for multiple virtual hosts ??
Yeah, you have to run the upgrade script on each for the database changes to propegate.
Sometimes a mixture of two is better, actually. More databases tend to take up more memory and possibly more disk space (storing some of the same data twice). However, it's much easier to manage multiple databases, at least in my experience. You can restore one, or drop one, etc without having to mess around making sure you're only touching certain tables. Or, in the case of rolling out a new instance, you can just have a backup of the database (using the same table prefix), and create it in about 3 lines of code...
I guess it depends on your resources.
Sometimes a mixture of two is better, actually. More databases tend to take up more memory and possibly more disk space (storing some of the same data twice). However, it's much easier to manage multiple databases, at least in my experience. You can restore one, or drop one, etc without having to mess around making sure you're only touching certain tables. Or, in the case of rolling out a new instance, you can just have a backup of the database (using the same table prefix), and create it in about 3 lines of code...
I guess it depends on your resources.
