Search

A colleague and I were wondering if it is possible to easily extract the core of symphony so that many sites can be run from a single install e.g. put the core deep in the server filesystem so that every site is just a workspace.

Yes, we have done this in the past by having a single physical directory containing /symphony/, and create aliased directory for your different sites to that physical location.

@rphilp You might also take a look at this tutorial that describe a technique that may help you.

What an amazing concept! Love it.. if only I has I site or 2 to play with!

Thanks for the suggestions, I suspected that this wouldn’t be a problem and it’s great to get some pointers.

Always good to see a responsive community, it makes me feel much more comfortable as I start development with a new framework/cms.

@rphilip I’m working on projects right now that use that “Ninja” technique to run 31 and 74 different web entities from one central control panel for each project. I continue to be amazed with Symphony – and you’re right, this forum is remarkably responsive.

There is clearly some interesting stuff going on here, but I was originally merely looking for a way to separate the “core” of symphony so that I don’t have duplicate files for every virtual host, and therefore also able to upgrade the install across multiple sites if necessary.

Of course this might not be desirable for compatibility purposes but it’s good to know just how flexible it is possible to be.

I have not even completed a single symphony-driven site yet, so this is purely theoretical!! Damned day job (and wife) eating up all my time.

This is a really good idea. Perhaps you’d be able to have different versions running side-by-side and simply change the location of the Symphony core in the config.php. Maybe you could have v2.0.6 running, but when 2.1 is released install that in a sibling directory and switch sites to upgrade as-and-when.

That’s exactly it Nick, it’s the sort of thing that is commonplace when working with PHP frameworks or sets of libraries etc, so why have unnecessary duplication with a CMS core if there is no need?

I’m sure even good old-fashioned symlinks for the core folders would work, but it’s not very elegant and it’s easy to lose track of what’s what.

Moreover, symlinks are not very nice for those who do not have root access on their webhosting account.

Yes, we have done this in the past by having a single physical directory containing /symphony/, and create aliased directory for your different sites to that physical location.

@allen, so does this mean /symphony/ is symlinked to the other sites you guys are running? but then all the other folders are physical on the other sites?

@carsten In this case, you might want to redefine a few constants on your index.php

to answer my own question, symlinking core folders from a central build will indeed work. If you want to keep a central extensions folder as well, symlinking will also work for that. I guess the only thing to keep in mind is to remember to remove the whichever folder you symlink before running the symlink.

Hi Guys,

There are a lot of posts re 'Multi-domain Symphony installs' already but my question is a little more theoretical and, as such, fits better in this thread.

My client expressed the wish to have one Symphony CMS handle multiple websites on different domains. His main motivation is two-fold: user-friendly-ness (one centralized login/environment) and maintainability (One place to update/fix/deply Symphony & extensions).

Here's the thing though: although these sites (we're thinking about max. 10) are quite similar they are not exactly the same. They will have some similar but slightly different sections (and forms and…). And (obviously) the front-end is different. They will not need to share content between the websites.

In my mind the multi-domain (e.g. through the Ninja Domain Technique) setup is quite a hassle.

In a multi-domain setup I would have to think about the following issues (con's):

  • Complex to set-up (especially with multiple websites on different hosts?)
  • Complex User Role management (site-editors should be able to manage only their own sites/sections)
  • Complex front-end (XSL filtering in page templates, sessions? etc)
  • Possibly bad for performance (huge DB with a lot of sections/entries)
  • Not user-friendly for developers (who would have to manage all the content in one place)

The Userfriendly argument could be relatively easily addressed by simply having a central 'proxy' login-form that would redirect to a seperate Symphony install, no? Would it be hard to have the user automatically logged in?

The Maintenance argument seems more valid: Symphony/extension updates and fixes would have to be deployed across various hosts/websites. I think, though, that (using Git and a streamlined Deployment strategy) this becomes less of an issue.

As you notice I currently believe a multi-website approach is too much of a hassle for this particular project.

However: reading the above I am also thinking there might be a middle ground: would it be possible to Symlink the core Symphony / Extension folders across hosts/domains? This way the Symphony/extensions updates/fixes could still be centralized?

Is this even possible?

So:

  • Do you agree with my arguments (in moveing away from a multi-site setup)?
  • Is it possible to have a simple central (proxy) login form, logging user in across hosts?
  • Could one symlink the Symphony core/extensions across hosts?
  • Am I missing things?

Thanks a lot!, Dave

However: reading the above I am also thinking there might be a middle ground: would it be possible to Symlink the core Symphony / Extension folders across hosts/domains? This way the Symphony/extensions updates/fixes could still be centralized?

In theory this should work. In fact, it's on the roadmap for 2.4 to look at restructuring Symphony's file system to abstract it this way by default.

Thanks for the quick answer Brendo. Re: 'middle ground': nice! I would have to think about how that would practically work (no cross-domain security issues?)

What do you think about the rest: is it better to just use different Symphony installs? Is it possible to have a central login form automatically logging users in on different domains? Would a git-on-the-server deployment strategy solve most of the maintenance pain?

Love to hear your thoughts.

I agree that your middle ground solution is probably the best when those websites don't need to share any content. If you symlink the system directories (symphony and extensions) everything wil still behave like independent installations. But you only have to deploy the software once. But you will have one backend for each website, meaning that you will have to create an author account multiple times. Considering the fact that in the end there might be authros which should not have access to all the websites — and this will happen, because you are working with a client! :-) — I would suggest to leave it like this.

Regarding security: If those directories are symlinked, any change will affect all the websites. This means that if one of the sites is hacked and the core files are changed, this will have an impact on all the websites.

Michael-e thanks. Good point re: symlinked core and security.

I actually doubt symlinking the /symphony folder since I rather stay away from the issues with one Symphony CMS back-end. Maybe only symlink /extensions

I would suggest to leave it like this

What do you mean? Leave it as the default separate Symphony installs?

That's probably what I'm going for. The maintenance issue will need some thinking through as well as the central-login but it seems less hassle than figuring out the consequences of multi-site install.

What do you mean? Leave it as the default separate Symphony installs?

I mean: Having completely seperate backends. If one author need access to more than one backend, you can create the account in all installs. I would not try to create a "one login for all (websites)" solution.

I actually doubt symlinking the /symphony folder since I rather stay away from the issues with one Symphony CMS back-end. Maybe only symlink /extensions…

If you symlink symphony, you will still have separate backends (because you are using different databases and workspace folders), but these backends will run on the same codebase.

ah I see: Yeah, editors responsible for Site-A would know to login at Site-A. Editors responsible for multiple sites would know where to be, I presume (if that scenario occurs at all).

Also: 1 central, symlinked, Symphony folder != 1 central /admin? Cool, then I understand: having 1 Symphony core (codebase) is easier.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details