tonyair/silverstripe-subsites
1
0
Fork 0
mirror of https://github.com/silverstripe/silverstripe-subsites synced 2024-06-25 22:19:40 +02:00
Code Issues Projects Releases Wiki Activity

Update README.md

Browse Source 
Revert part 2
This commit is contained in:
Martina Lindenhofer 2023-10-06 13:39:56 +02:00 committed by GitHub
parent 7017c1c6f8
commit 60d75535c2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 47 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
README.md
View File

@ -29,31 +29,31 @@ For user documentation please see:
### Features: ### Features:
* Each subsite appears as a standalone website from a users prospective * Each subsite appears as a standalone website from a users prospective
* No need to duplicate existing code as all subsites use the same codebase as the main site * No need to duplicate existing code as all subsites use the same codebase as the main site
* You can set individual permissions on each subsite domain name * You can set individual permissions on each subsite domain name
* Ability to copy a page and its content from the main site into a subsite * Ability to copy a page and its content from the main site into a subsite
* Create translations of subsite pages * Create translations of subsite pages
* Schedule the publishing of subsite pages * Schedule the publishing of subsite pages
* The database is shared between subsites (meaning duplicating content is easy) * The database is shared between subsites (meaning duplicating content is easy)
* When recovering from a disaster it's much easier to bring up a new copy of a single environment with 100 subsites than it is to bring up 100 environments. * When recovering from a disaster it's much easier to bring up a new copy of a single environment with 100 subsites than it is to bring up 100 environments.
### Limitations: ### Limitations:
* Subsites are usually accessed via their own separate domains. * Subsites are usually accessed via their own separate domains.
In order to allow efficient cross-subsite CMS editing, In order to allow efficient cross-subsite CMS editing,
they can also be accessed via URL parameters rather than domain maps. they can also be accessed via URL parameters rather than domain maps.
This can weaken domain-specific security controls in your environment This can weaken domain-specific security controls in your environment
such as domain-specific IP whitelists, firewall rules or business logic. such as domain-specific IP whitelists, firewall rules or business logic.
* Each subsite domain name has to be set up on the server first, and DNS records need to be updated as appropriate. * Each subsite domain name has to be set up on the server first, and DNS records need to be updated as appropriate.
* A subsite cannot use a different codebase as the main site, they are intrinsically tied * A subsite cannot use a different codebase as the main site, they are intrinsically tied
* However, you can remove page types from a subsite when creating the subsite - [see the setup documentation for further details](docs/en/userguide/set_up.md) * However, you can remove page types from a subsite when creating the subsite - [see the setup documentation for further details](docs/en/userguide/set_up.md)
* The only code a developer can edit between subsites is the theme * The only code a developer can edit between subsites is the theme
* The separation between subsites in the CMS needs to be seen as cosmetic, and mostly applicable to the "Pages" and "Files" sections of the CMS. * The separation between subsites in the CMS needs to be seen as cosmetic, and mostly applicable to the "Pages" and "Files" sections of the CMS.
* All subsites run in the same process space and data set. Therefore if an outage affects one subsite it will affect all subsites, and if bad code or hardware corrupts one subsite's data, it's very likely that it has corrupted all subsite data. * All subsites run in the same process space and data set. Therefore if an outage affects one subsite it will affect all subsites, and if bad code or hardware corrupts one subsite's data, it's very likely that it has corrupted all subsite data.
* This principle applies to application error, security vulnerabilities and high levels of traffic * This principle applies to application error, security vulnerabilities and high levels of traffic
* It is not currently possible to backup or restore the data from a single subsite. * It is not currently possible to backup or restore the data from a single subsite.
* It is awkward (but not impossible) to have separate teams of developers working on different subsites - primarily because of the level of collaboration needed. It is more suited to the same group of developers being responsible for all of the subsites. * It is awkward (but not impossible) to have separate teams of developers working on different subsites - primarily because of the level of collaboration needed. It is more suited to the same group of developers being responsible for all of the subsites.
If more isolation of code, security, or performance is needed, then consider running multiple separate installations (e.g. on separate servers). If more isolation of code, security, or performance is needed, then consider running multiple separate installations (e.g. on separate servers).