Thread

My company plans to use Site manager to manage all client sites built with EE.  Each client site is totally different from the others and they share very little in common.  So each site will have its own set of templates, weblogs, user groups…etc I think Site Manager is designed more to manage related sites such as a University campus with different faculties…etc

I play around with Site Manager but I don’t think this is feasible.  I recommend to build each site separately.  My company argues it is better off to use one instance of EE for easier maintenance. License is not an issue here but is it doable or a good solution?  I can imagine it will be hard to keep track of everything for a webmaster and it is also a challenge to add a new site from staging server to the LIVE server as Site Manager uses one database.

Opinion anyone?

Hi, Arnold - the Multiple Site Manager is intended for use by *one* owner with multiple, related internet properties.  Using it to host client sites (sites for third-parties) is not allowed by our license.

You will need a full license and separate installation for each client site.  This is best for you anyway as there is no way to have a totally separate membership database in the MSM, nor is there a way to split a Site out of the MSM if the client were to need to move on.

Arnold, the MSM is not meant to manage logically separate sites. Apart from being unfeasible, this is also against the license, yes: All sites must be owned and operated by the same person or entity. Take EllisLab as an example: the EE, CI and EL sites all run off a single installation. In your case, I strongly recommend a separate EE install per client.

As I mentioned earlier, license fee is not an issue.  My company will pay full license for each site we host under Site Manager.  I am more worrying about the Site Manager’s architecture. I don’t think it is designed to handle case like what we describe.

My manager has a mandate to make this happen. I try to convince him it is not working this way.  He said he checked your website and it is clearly stated to work this way.  Guess you guys should clarify the info a bit in the Site Manager section.  He’s not familiar with EE and I have a hard time to explain it.  I probably will forward your comments to make him understand the situation.

Let’s me know if you have further things to help the clarification.

Arnold - the fee here isn’t at issue; you’re breaking the license by using ExpressionEngine to host sites for third-parties.  You are correct, it is not intended to handle hosting sites for clients. 

As a quote from the License itself:

Restrictions

Unless you have been granted prior, written consent from EllisLab, Inc., you may not

Use the Software as the basis of a hosted weblogging service, or to provide hosting services to others.

We’d be happy to review anything that may be confusing on the MSM page.  Can you find out which part he believes says this is allowed and can be done, and let me know?  Thank you!

Hi Arnold,

license issues aside, the MSM is not designed or intended to do what you describe. You’ll run into issues quickly in the scenario you describe, which is one of the primary reasons for the license restriction.

Thanks for the clarification.  Do anyone know such product exist at all?

I don’t know of a product that does what you describe for complex sites. The major issue is that there are significant technical hurdles for doing so, especially as the number of sites grows. From a management perspective it is desirable but from a server admin viewpoint its not so clear cut. You would need some significant tools to manage the challenges of having unique properties that could grow very differently.

Actually, Drupal can do something like this. You can run a single code base with site-specific modules, themes, and whatnot; each site can use its own database or share a database with a different table prefix (and you can mix and match). On the database side, if you know what you’re doing you can even share individual tables between sites.

I don’t know that I would recommend Drupal for an all eggs in one basket setup if the individual sites are for clients, though. Before switching to EE, I used to run my sites as described above (shared code with site-specific add-ons, individual databases) and it’s debatable how well this setup scales. Any updates to Drupal core have to happen at the same time, which is fine for a couple, but not so fine for many tens and up. And not to forget the pain of major version upgrades.

Actually, Drupal can do something like this. You can run a single code base with site-specific modules, themes, and whatnot; each site can use its own database or share a database with a different table prefix (and you can mix and match). On the database side, if you know what you’re doing you can even share individual tables between sites.

I don’t know that I would recommend Drupal for an all eggs in one basket setup if the individual sites are for clients, though. Before switching to EE, I used to run my sites as described above (shared code with site-specific add-ons, individual databases) and it’s debatable how well this setup scales. Any updates to Drupal core have to happen at the same time, which is fine for a couple, but not so fine for many tens and up. And not to forget the pain of major version upgrades.

I agree this subject is totally debatable.  Our potential client base is over 100+ so our goal is trying to minimize maintenance work.  Imagine EE comes up with a security release and it may take quite an effort to update 100 sites compared to just one instance.  I don’t know at this point but look like we may abort EE due to this reason.  That’s too bad but I’ll continue to use it for my freelance projects.

Speaking of database, wonder if it is feasible to add a higher layer so EE can choose a separate database for each domain access.  Wouldn’t that solve the whole issue I have on-hand?  Or may be I am just talkng nonsense here…

I don’t mean to be critical here Arnold, but really a good FTP solution or work flow would solve this. We have developers that can update 100s of sites with minimal effort while enjoying the benefits that true separation brings, specifically the server end of things.

Look at it from the opposite view. Suppose whatever solution you use had a vulnerability and one site was compromised. Instantly all your sites would be compromised. You’d have no way of isolating a breech. Same with traffic spikes.

As to adding a layer on top, that is one approach, but also with issues. We hope this is a solvable issue in the future.

But for the present, while I agree there are important efficiency benefits to be gained from an “all-in-one” approach, there is a reason what you suggest isn’t a wide spread practice yet that has little do with with the available solutions and more about server efficiency and security. Whether you choose EE, Drupal, or something else, I would encourage your team to really think through the long term implications of what is being suggested, especially from the server end of things.

Thanks to all!  This has been a very helpful discussion on this matter.  I’ll relay all info to my team and see what they think.

.

What J-Slim is describing is something that EE was intended to do. He manages sites that are *related* to each other. What Arnold is talking about is very different.

I would point out that we are not just “moderators” but we are the makers of the software. We know its intended use and what its capabilities are very well.

A few belated comments.

There’s minimizing maintenance, and there’s minimizing stress. On any multi-site platform, a problem can potentially affect all sites at once. Usually this happens after deploying an update and even if you do QA on a mirrored copy, you won’t know for a fact how something behaves in production unless you put it into production. With individual installs, you can do the upgrades individually or in small batches and minimize your exposure.

The way I see it, the difference in maintenance between MSM and individual installs is the effort required to upgrade—which is negligible if you automate the process. In fact, if there are version-specific notes that apply, individual sites may well be faster and cleaner to upgrade than an MSM install.