Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

Installing SilverStripe /

Getting SilverStripe up and running on your computer and on your web server.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

SilverStripe and Multiple Sites?


Go to End


5 Posts   2343 Views

Avatar
Murray

Community Member, 2 Posts

19 November 2015 at 2:33pm

I work for a web design company that currently hosts several hundred sites for our clients. Most of these sites are small 4-6 page brochure-type sites.

We currently use a CMS that was built specifically for us that lets each site owner log in and edit text and images on their site. However we feel we've outgrown our old CMS and are evaluating our options. We will either create a new CMS from scratch or use an off-the-shelf CMS, and as such we're looking at SilverStripe. We would leave all existing sites on the old CMS and use the new CMS for any new sites going forward, so we don't really need a migration path.

I've got a bunch of questions on using SS in an environment like ours:

Is SS multi-site? I.e. can one installation of SS handle multiple (possibly several hundred) individual sites, with each site being separate? By "separate" I mean that each site would have it's own domain name and a CMS user that can edit just that site's content, without seeing the content of any other site (eg we DON'T want a shared asset library, each site would need it's own set of images, stylesheets, etc).

Are we able to specify what parts of a page our clients can edit on their site? For example we would want them to be able to edit main body text and images, but not be able to edit text in the footer or other parts of the page. We also don't want them to be able to add new pages, edit meta tag details in the HTML head (because we've carefully structured these for SEO purposes), etc.

If SS isn't really multi-site (in the sense that I've outlined above) then the alternative option would be a separate installtion of SS for each site. I can't find any disk space requirements for SS, does anyone know what an average installation uses? The down-side to doing it this way is the problem of upgrading SS or modules, imagine having to upgrade 500 copies of SS!

So is SS a realistic option for us or should I be looking elsewhere?

Avatar
Murray

Community Member, 2 Posts

24 November 2015 at 2:04pm

So no one runs SilverStripe in a large web design business?

Avatar
camfindlay

Forum Moderator, 267 Posts

24 November 2015 at 5:05pm

Some options are the mutlisites and the subsites modules, you will however want to look over what each module gives you and be aware that in some cases the users and assets in some of these setups end up shared (so might depend on the security needs of your clients).

https://github.com/silverstripe-australia/silverstripe-multisites

https://github.com/silverstripe/silverstripe-subsites

Personally I build a site on an older version of SilverStripe stripe (2.4) some time ago where clients could independently login and mange their content without hassle. I used the Subsites module for this and did have to do a little work compartmentalising some of the content. I haven't tried Multisites.

And as you say, you can use vhosts and run multiple copies of the codebase. If you use composer it's easy to update the modules and core. If you opt to use 1 codebase to run many sites you run into problems when clients want custom things (as you'd have to roll that out to everyone using the one CMS codebase). It's going to come down to what customers want, and what they might want going forward. SilverStripe is good for growing businesses that might have a 6 page site now, and may want something more complex in a few years.

Hope that helps.

Avatar
ZarockNZ

Community Member, 17 Posts

21 September 2016 at 5:02pm

Edited: 21/09/2016 5:05pm

Hi, just thought I would share our team's experience with this...

We have used the silverstripe-subsites module in a few projects and found it works quite well when used for actual subsites of the main site, where we want the same CMS users to be able to update all sites, and for them to share the same page types, assets etc.

In one project we "pushed the envelope" of what the subsites module is for and tried creating what looks and operates like 2 separate sites. This can only be done to a certain degree as subsites in SilverStripe share the same server, database, codebase, assets (uploaded files and documents) and also possibly themes (which might be desired). We knew this before development of the project and the 2 sites are for the same client so this aspect was not an issue.

What we did not anticipate was we ran in to complexity around the site search using Solr where pages in the main site would appear in the results of the search of the subsite and vice versa, so had to create our own search index and overload the search functions that CWP adds to the Page class to filter out results from the other site(s).

Also we found that many data objects are not subsite aware by default, for example the excellent Blocks module, so required extension to make them subsite aware (there is instructions on the subsites module how to do this) allowing only things created on one site to appear in the list of available items when adding existing in the CMS for that site etc.

Yes its possible to control what subsite(s) CMS users see and we did that in the project mentioned above so that only the people who maintain the subsite can see it and make updates in it and not the main site as well.

I have not used the multisites either, so can't share any experiences there.

Reflecting back on things, I think that if the sites are to be for separate customers then its best to actually create separate sites rather than trying to use the subsites module to achieve this - separation of things to the level desired for truly separate sites requires a bit of work; keep the subsites feature for actual subsites is my thinking at this time.

Cheers,
DouG.

Avatar
avantikathakur

Community Member, 2 Posts

24 September 2016 at 5:19pm

i have also try that for the first time and i like the backed it .